უწყვეტი განლაგების ჩვენი განხორციელება მომხმარებლის პლატფორმაზე

ჩვენ True Engineering-ში შევქმენით პროცესი კლიენტების სერვერებზე განახლებების უწყვეტი მიწოდებისთვის და გვინდა გავუზიაროთ ეს გამოცდილება.

დასაწყისისთვის, ჩვენ შევქმენით ონლაინ სისტემა მომხმარებლისთვის და განვათავსეთ იგი ჩვენს Kubernetes კლასტერში. ახლა ჩვენი მაღალი დატვირთვის გადაწყვეტა გადავიდა მომხმარებლის პლატფორმაზე, რისთვისაც ჩვენ დავაყენეთ სრულად ავტომატური უწყვეტი განლაგების პროცესი. ამის წყალობით, ჩვენ დავაჩქარეთ დრო ბაზარზე - ცვლილებების მიწოდება პროდუქტის გარემოში.

ამ სტატიაში ვისაუბრებთ უწყვეტი განლაგების (CD) პროცესის ან მომხმარებლის პლატფორმაზე განახლებების მიწოდების ყველა ეტაპზე:

1. როგორ იწყება ეს პროცესი?
2. სინქრონიზაცია მომხმარებლის Git საცავთან,
3. უკანა ნაწილის და წინა ნაწილის შეკრება,
4. აპლიკაციის ავტომატური განლაგება სატესტო გარემოში,
5. ავტომატური განლაგება პროდ.

ჩვენ გაგიზიარებთ დაყენების დეტალებს გზად.

1. გაუშვით CD

უწყვეტი განლაგება იწყება იმით, რომ დეველოპერი ცვლის ჩვენი Git საცავის გამოშვების ფილიალს.

ჩვენი აპლიკაცია მუშაობს მიკროსერვისის არქიტექტურაზე და მისი ყველა კომპონენტი ინახება ერთ საცავში. ამის წყალობით, ყველა მიკროსერვისი გროვდება და ინსტალირებულია, მაშინაც კი, თუ რომელიმე მათგანი შეიცვალა.

ჩვენ მოვაწყვეთ მუშაობა ერთი საცავიდან რამდენიმე მიზეზის გამო:

• განვითარების სიმარტივე - აპლიკაცია აქტიურად ვითარდება, ასე რომ თქვენ შეგიძლიათ ერთდროულად იმუშაოთ ყველა კოდთან.
• ერთიანი CI/CD მილსადენი, რომელიც გარანტიას იძლევა, რომ აპლიკაცია, როგორც ერთიანი სისტემა, გაივლის ყველა ტესტს და მიეწოდება მომხმარებლის საწარმოო გარემოს.
• ჩვენ აღმოვფხვრით დაბნეულობას ვერსიებში - ჩვენ არ გვჭირდება შევინახოთ მიკროსერვისის ვერსიების რუკა და აღვწეროთ მისი კონფიგურაცია თითოეული მიკროსერვისისთვის Helm სკრიპტებში.

2. მომხმარებლის კოდის Git საცავთან სინქრონიზაცია

განხორციელებული ცვლილებები ავტომატურად სინქრონიზდება მომხმარებლის Git საცავთან. იქ არის აპლიკაციის ასამბლეის კონფიგურაცია, რომელიც ამოქმედდება ფილიალის განახლებისა და გაგრძელებაზე განლაგების შემდეგ. ორივე პროცესი წარმოიქმნება მათ გარემოში Git საცავიდან.

ჩვენ არ შეგვიძლია უშუალოდ მომხმარებლის საცავთან მუშაობა, რადგან გვჭირდება ჩვენი საკუთარი გარემო განვითარებისა და ტესტირებისთვის. ჩვენ ვიყენებთ ჩვენს Git საცავს ამ მიზნებისთვის - ის სინქრონიზებულია მათ Git საცავთან. როგორც კი დეველოპერი გამოაქვეყნებს ცვლილებებს ჩვენი საცავის შესაბამის ფილიალში, GitLab დაუყოვნებლივ უბიძგებს ამ ცვლილებებს მომხმარებელს.

ამის შემდეგ თქვენ უნდა გააკეთოთ შეკრება. იგი შედგება რამდენიმე ეტაპისგან: უკანა ნაწილისა და წინა ნაწილის აწყობა, ტესტირება და წარმოებამდე მიტანა.

3. ბექენდის და ფრონტენდის აწყობა

Backend-ისა და Frontend-ის აგება არის ორი პარალელური დავალება, რომლებიც შესრულებულია GitLab Runner სისტემაში. მისი ორიგინალური ასამბლეის კონფიგურაცია მდებარეობს იმავე საცავში.

ტუტორიალი YAML სკრიპტის დასაწერად GitLab-ში მშენებლობისთვის.

GitLab Runner იღებს კოდს საჭირო საცავიდან, აწყობს მას Java აპლიკაციის აშენების ბრძანებით და აგზავნის Docker-ის რეესტრში. აქ ჩვენ ვაწყობთ უკანა და ფრონტენტს, ვიღებთ დოკერის სურათებს, რომლებსაც ვათავსებთ კლიენტის მხარეს არსებულ საცავში. Docker სურათების სამართავად ჩვენ ვიყენებთ Gradle მოდული.

ჩვენ სინქრონიზაციას ვუწევთ ჩვენი სურათების ვერსიებს გამოშვების ვერსიასთან, რომელიც გამოქვეყნდება Docker-ში. შეუფერხებლად მუშაობისთვის, ჩვენ განვახორციელეთ რამდენიმე კორექტირება:

1. კონტეინერები არ კეთდება სატესტო გარემოსა და წარმოების გარემოს შორის. ჩვენ გავაკეთეთ პარამეტრიზაცია ისე, რომ ერთსა და იმავე კონტეინერს შეეძლო იმუშაოს ყველა პარამეტრთან, გარემოს ცვლადებთან და სერვისებთან, როგორც სატესტო გარემოში, ასევე წარმოებაში, ხელახლა აშენების გარეშე.

2. Helm-ის მეშვეობით აპლიკაციის განახლებისთვის, უნდა მიუთითოთ მისი ვერსია. ჩვენ ვაშენებთ backend-ს, frontend-ს და ვაახლებთ აპლიკაციას - ეს არის სამი განსხვავებული ამოცანა, ამიტომ მნიშვნელოვანია აპლიკაციის ერთი და იგივე ვერსიის გამოყენება ყველგან. ამ ამოცანისთვის ჩვენ ვიყენებთ მონაცემებს Git ისტორიიდან, რადგან ჩვენი K8S კლასტერის კონფიგურაცია და აპლიკაციები იმავე Git საცავშია.

ჩვენ ვიღებთ აპლიკაციის ვერსიას ბრძანების შესრულების შედეგებიდან
git describe --tags --abbrev=7.

4. ტესტის გარემოში ყველა ცვლილების ავტომატური განლაგება (UAT)

შემდეგი ნაბიჯი ამ build სკრიპტში არის K8S კლასტერის ავტომატურად განახლება. ეს ხდება იმ პირობით, რომ მთელი აპლიკაცია აშენდა და ყველა არტეფაქტი გამოქვეყნდა Docker Registry-ში. ამის შემდეგ იწყება სატესტო გარემოს განახლება.

კლასტერის განახლება დაწყებულია გამოყენებით Helm განახლება. თუ, შედეგად, რაღაც არ წავიდა გეგმის მიხედვით, Helm ავტომატურად და დამოუკიდებლად გააბრუნებს ყველა ცვლილებას. მის საქმიანობას კონტროლი არ სჭირდება.

ჩვენ ვაწვდით K8S კლასტერის კონფიგურაციას ასამბლეასთან ერთად. ამიტომ, შემდეგი ნაბიჯი არის მისი განახლება: configMaps, განლაგება, სერვისები, საიდუმლოებები და ნებისმიერი სხვა K8S კონფიგურაცია, რომელიც ჩვენ შევცვალეთ.

შემდეგ Helm აწარმოებს თავად აპლიკაციის RollOut განახლებას სატესტო გარემოში. სანამ განაცხადი განლაგდება წარმოებაში. ეს კეთდება იმისთვის, რომ მომხმარებლებმა ხელით შეამოწმონ ბიზნეს ფუნქციები, რომლებიც ჩვენ სატესტო გარემოში ვაყენებთ.

5. ყველა ცვლილების ავტომატური განლაგება პროდ

საწარმოო გარემოში განახლების გამოსაყენებლად, თქვენ უბრალოდ უნდა დააჭიროთ ერთ ღილაკს GitLab-ში - და კონტეინერები დაუყოვნებლივ მიეწოდება საწარმოო გარემოს.

ერთსა და იმავე აპლიკაციას შეუძლია იმუშაოს სხვადასხვა გარემოში - ტესტირება და წარმოება - აღდგენის გარეშე. ჩვენ ვიყენებთ იგივე არტეფაქტებს აპლიკაციაში არაფრის შეცვლის გარეშე და პარამეტრებს ვაყენებთ გარედან.

აპლიკაციის პარამეტრების მოქნილი პარამეტრიზაცია დამოკიდებულია იმ გარემოზე, რომელშიც აპლიკაცია შესრულდება. ჩვენ გადავიტანეთ გარემოს ყველა პარამეტრი გარედან: ყველაფერი პარამეტრიზებულია K8S კონფიგურაციისა და Helm პარამეტრების მეშვეობით. როდესაც Helm აყენებს ასამბლეას ტესტის გარემოში, ტესტის პარამეტრები გამოიყენება მასზე, ხოლო პროდუქტის პარამეტრები გამოიყენება წარმოების გარემოზე.

ყველაზე რთული იყო ყველა გამოყენებული სერვისისა და ცვლადის პარამეტრიზაცია, რომელიც დამოკიდებულია გარემოზე, და მათი თარგმნა გარემოს ცვლადებად და გარემოს პარამეტრების აღწერა-კონფიგურაციებად Helm-ისთვის.

აპლიკაციის პარამეტრები იყენებს გარემოს ცვლადებს. მათი მნიშვნელობები დაყენებულია კონტეინერებში K8S configmap-ის გამოყენებით, რომელიც შაბლონირებულია Go შაბლონების გამოყენებით. მაგალითად, დომენის სახელზე გარემოს ცვლადის დაყენება შეიძლება ასე გაკეთდეს:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.ღირებულებები.გლობალური. env – ეს ცვლადი ინახავს გარემოს სახელს (prod, stage, UAT).
.Values.app.properties.app_external_domain – ამ ცვლადში ვაყენებთ სასურველ დომენს .Values.yaml ფაილში

აპლიკაციის განახლებისას Helm ქმნის configmap.yaml ფაილს შაბლონებიდან და ავსებს APP_EXTERNAL_DOMAIN მნიშვნელობას სასურველი მნიშვნელობით, იმისდა მიხედვით, თუ რა გარემოდან იწყება აპლიკაციის განახლება. ეს ცვლადი უკვე დაყენებულია კონტეინერში. მასზე წვდომა შესაძლებელია აპლიკაციიდან, ამიტომ თითოეულ აპლიკაციის გარემოს ექნება განსხვავებული მნიშვნელობა ამ ცვლადისთვის.

შედარებით ცოტა ხნის წინ, K8S მხარდაჭერა გამოჩნდა Spring Cloud-ში, მათ შორის მუშაობა configMaps-თან: გაზაფხულის ღრუბელი კუბერნეტები. მიუხედავად იმისა, რომ პროექტი აქტიურად ვითარდება და რადიკალურად იცვლება, წარმოებაში ვერ გამოვიყენებთ. მაგრამ ჩვენ აქტიურად ვაკვირდებით მის მდგომარეობას და ვიყენებთ მას DEV კონფიგურაციებში. როგორც კი ის დასტაბილურდება, ჩვენ მასზე გადავალთ გარემოს ცვლადების გამოყენებით.

საერთო ჯამში

ასე რომ, უწყვეტი განლაგება არის კონფიგურირებული და მუშაობს. ყველა განახლება ხდება ერთი კლავიშის დაჭერით. პროდუქტის გარემოში ცვლილებების მიწოდება ავტომატურია. და, რაც მთავარია, განახლებები არ აჩერებს სისტემას.

სამომავლო გეგმები: მონაცემთა ბაზის ავტომატური მიგრაცია

ჩვენ ვიფიქრეთ მონაცემთა ბაზის განახლებაზე და ამ ცვლილებების უკან დაბრუნებაზე. ყოველივე ამის შემდეგ, აპლიკაციის ორი განსხვავებული ვერსია მუშაობს ერთდროულად: ძველი გაშვებულია და ახალი. ძველს კი მხოლოდ მაშინ გავთიშავთ, როცა დავრწმუნდებით, რომ ახალი ვერსია მუშაობს. მონაცემთა ბაზის მიგრაცია საშუალებას მოგცემთ იმუშაოთ აპლიკაციის ორივე ვერსიასთან.

ამიტომ, ჩვენ არ შეგვიძლია უბრალოდ შევცვალოთ სვეტის სახელი ან სხვა მონაცემები. მაგრამ ჩვენ შეგვიძლია შევქმნათ ახალი სვეტი, დავაკოპიროთ მასში მონაცემები ძველი სვეტიდან და ჩავწეროთ ტრიგერები, რომლებიც მონაცემთა განახლებისას ერთდროულად დააკოპირებენ და განაახლებს მას სხვა სვეტში. და აპლიკაციის ახალი ვერსიის წარმატებით განლაგების შემდეგ, გაშვების შემდგომი მხარდაჭერის პერიოდის შემდეგ, ჩვენ შევძლებთ წაშალოთ ძველი სვეტი და ტრიგერი, რომელიც გახდა არასაჭირო.

თუ აპლიკაციის ახალი ვერსია არ მუშაობს სწორად, შეგვიძლია დავუბრუნდეთ წინა ვერსიას, მონაცემთა ბაზის წინა ვერსიის ჩათვლით. მოკლედ, ჩვენი ცვლილებები საშუალებას მოგცემთ ერთდროულად იმუშაოთ აპლიკაციის რამდენიმე ვერსიასთან.

ჩვენ ვგეგმავთ მონაცემთა ბაზის მიგრაციის ავტომატიზაციას K8S სამუშაოს მეშვეობით, მისი ინტეგრირება CD პროცესში. და ჩვენ აუცილებლად გაგიზიარებთ ამ გამოცდილებას Habré-ზე.

წყარო: www.habr.com