რა არის GitOps?

Შენიშვნა. თარგმნა: ბოლო გამოქვეყნების შემდეგ მასალა GitOps-ში მოზიდვისა და დაძაბვის მეთოდების შესახებ, ჩვენ დავინახეთ ინტერესი ამ მოდელის მიმართ ზოგადად, მაგრამ ძალიან ცოტა იყო რუსულენოვანი პუბლიკაცია ამ თემაზე (უბრალოდ არ არსებობს Habré-ზე). ამიტომ, მოხარული ვართ, რომ თქვენს ყურადღებას შემოგთავაზოთ კიდევ ერთი სტატიის თარგმანი - თუმცა თითქმის ერთი წლის წინ! — Weaveworks-დან, რომლის ხელმძღვანელმა გამოიგონა ტერმინი „GitOps“. ტექსტი განმარტავს მიდგომის არსს და ძირითად განსხვავებებს არსებული მიდგომებისგან.

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

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

ჩვენ მალე მივხვდით, რომ საჭირო იყო ახალი აღწერა, რომელიც გვთავაზობდა:

1. მაგალითებისა და მოთხრობების დიდი რაოდენობა;
2. GitOps-ის სპეციფიკური განმარტება;
3. შედარება ტრადიციულ უწყვეტ მიწოდებასთან.

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

გაიცანით GitOps

წარმოიდგინე ალისა. ის მართავს საოჯახო დაზღვევას, რომელიც სთავაზობს ჯანმრთელობის, მანქანის, სახლისა და სამოგზაურო დაზღვევას იმ ადამიანებს, რომლებიც ზედმეტად დაკავებულნი არიან იმისთვის, რომ თავად გაარკვიონ კონტრაქტების დეტალები. მისი ბიზნესი დაიწყო როგორც გვერდითი პროექტი, როდესაც ალისა მუშაობდა ბანკში, როგორც მონაცემთა მეცნიერი. ერთ დღეს მან გააცნობიერა, რომ მას შეეძლო გამოეყენებინა მოწინავე კომპიუტერული ალგორითმები მონაცემთა უფრო ეფექტურად გასაანალიზებლად და სადაზღვევო პაკეტების ფორმულირებისთვის. ინვესტორებმა დააფინანსეს პროექტი და ახლა მის კომპანიას წელიწადში 20 მილიონ დოლარზე მეტი შემოსავალი მოაქვს და სწრაფად იზრდება. ამჟამად მასში სხვადასხვა თანამდებობაზე 180 ადამიანია დასაქმებული. ეს მოიცავს ტექნოლოგიურ გუნდს, რომელიც ავითარებს, ინახავს ვებსაიტს, მონაცემთა ბაზას და აანალიზებს მომხმარებელთა ბაზას. 60 კაციან გუნდს კომპანიის ტექნიკური დირექტორი ბობი ხელმძღვანელობს.

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

საოჯახო დაზღვევა არ აპირებდა კონტეინერების გამოყენებას, მაგრამ დაემორჩილა Docker-ის ენთუზიაზმს. კომპანიამ მალევე აღმოაჩინა, რომ GKE-მ გააადვილა და უმტკივნეულოდ განათავსა კლასტერები ახალი ფუნქციების შესამოწმებლად. Jenkins for CI და Quay დაემატა კონტეინერების რეესტრის ორგანიზებას, დაიწერა სკრიპტები Jenkins-ისთვის, რომლებმაც ახალი კონტეინერები და კონფიგურაციები გადაიტანეს GKE-ში.

გარკვეული დრო გავიდა. ალისა და ბობი იმედგაცრუებულნი იყვნენ თავიანთი არჩეული მიდგომის შესრულებით და მისი გავლენით ბიზნესზე. კონტეინერების დანერგვამ არ გააუმჯობესა პროდუქტიულობა ისე, როგორც გუნდი იმედოვნებდა. ზოგჯერ განლაგება იშლებოდა და გაურკვეველი იყო, იყო თუ არა კოდის ცვლილებების ბრალი. ასევე რთული აღმოჩნდა კონფიგურაციის ცვლილებების თვალყურის დევნება. ხშირად საჭირო იყო ახალი კლასტერის შექმნა და მასში აპლიკაციების გადატანა, რადგან ეს იყო უმარტივესი გზა სისტემის არევის აღმოსაფხვრელად. ალისას ეშინოდა, რომ აპლიკაციის განვითარებასთან ერთად სიტუაცია გაუარესდებოდა (გარდა ამისა, ახდენდა მანქანურ სწავლაზე დაფუძნებული ახალი პროექტი). ბობს ჰქონდა ავტომატიზირებული სამუშაოების უმეტესი ნაწილი და არ ესმოდა, რატომ იყო მილსადენი ჯერ კიდევ არასტაბილური, არ იყო კარგად მასშტაბური და საჭიროებდა პერიოდულად ხელით ჩარევას?

შემდეგ მათ გაიგეს GitOps-ის შესახებ. ეს გადაწყვეტილება სწორედ ის აღმოჩნდა, რაც მათ სჭირდებოდათ წინსვლის დამაჯერებლად.

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

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

• აღმოაჩინა, რომ გუნდის პროდუქტიულობა გაორმაგდა ისე, რომ არავინ გაგიჟდებოდა;
• შეწყვიტა სკრიპტების მომსახურება. ამის ნაცვლად, მათ ახლა შეუძლიათ ფოკუსირება ახალ მახასიათებლებზე და გააუმჯობესონ საინჟინრო მეთოდები - მაგალითად, კანარის გამოშვების დანერგვა და ტესტირების გაუმჯობესება;
• ჩვენ გავაუმჯობესეთ განლაგების პროცესი ისე, რომ ის იშვიათად იშლება;
• მიიღო შესაძლებლობა, აღედგინა განლაგება ნაწილობრივი წარუმატებლობის შემდეგ ხელით ჩარევის გარეშე;
• ნაყიდი მეორადიоმეტი ნდობა მიწოდების სისტემებში. ალისამ და ბობმა აღმოაჩინეს, რომ მათ შეეძლოთ გუნდი გაეყოთ პარალელურად მომუშავე მიკროსერვისის გუნდებად;
• შეუძლია პროექტში ყოველდღიურად 30-50 ცვლილება შეიტანოს თითოეული ჯგუფის ძალისხმევით და სცადო ახალი ტექნიკა;
• ადვილია პროექტში ახალი დეველოპერების მოზიდვა, რომლებსაც აქვთ შესაძლებლობა რამდენიმე საათში განაახლონ წარმოებაში მოთხოვნის გამოყენებით;
• მარტივად გაიარეთ აუდიტი SOC2-ის ფარგლებში (მომსახურების პროვაიდერების შესაბამისობისთვის მონაცემთა უსაფრთხო მართვის მოთხოვნებთან; წაიკითხეთ მეტი, მაგალითად, აქ - დაახლ. თარგმანი.).

რა მოხდა?

GitOps არის ორი რამ:

1. ოპერაციული მოდელი Kubernetes-ისთვის და ღრუბლისთვის. ის უზრუნველყოფს საუკეთესო პრაქტიკის ერთობლიობას კონტეინერირებული კლასტერებისა და აპლიკაციების განლაგების, მართვისა და მონიტორინგისთვის. ელეგანტური განმარტება ფორმაში ერთი სლაიდი საწყისი ლუის ფეისირა:
2. დეველოპერზე ორიენტირებული აპლიკაციის მართვის გარემოს შექმნის გზა. ჩვენ ვიყენებთ Git სამუშაო პროცესს როგორც ოპერაციებში, ასევე განვითარებაში. გთხოვთ გაითვალისწინოთ, რომ ეს არ ეხება მხოლოდ Git Push-ს, არამედ CI/CD და UI/UX ინსტრუმენტების მთელი ნაკრების ორგანიზებას.

რამდენიმე სიტყვა Git-ის შესახებ

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

როგორ მუშაობს Kubernetes

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

რას აძლევს Kubernetes მომხმარებლებს?

აქ არის რამდენიმე ძირითადი მახასიათებელი:

1. Kubernetes-ის მოდელში ყველაფერი შეიძლება აღწერილი იყოს დეკლარაციული ფორმით.
2. Kubernetes API სერვერი იღებს ამ დეკლარაციას შეყვანად და შემდეგ მუდმივად ცდილობს კლასტერის მოყვანას დეკლარაციაში აღწერილ მდგომარეობაში.
3. დეკლარაციები საკმარისია იმისთვის, რომ აღწერონ და მართონ მრავალფეროვანი დატვირთვები - „აპლიკაციები“.
4. შედეგად, ცვლილებები განაცხადსა და კლასტერში ხდება იმის გამო:
   • ცვლილებები კონტეინერის სურათებში;
   • ცვლილებები დეკლარაციულ სპეციფიკაციაში;
   • შეცდომები გარემოში - მაგალითად, კონტეინერის ავარია.

Kubernetes-ის დიდი კონვერგენციის შესაძლებლობები

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

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

როგორ მუშაობს GitOps

ჩვენ საკმარისად ვისწავლეთ Kubernetes-ის შესახებ, რათა აგიხსნათ როგორ მუშაობს GitOps.

დავუბრუნდეთ საოჯახო დაზღვევის მიკროსერვისების გუნდებს. რა უნდა გააკეთონ ჩვეულებრივ? შეხედეთ ქვემოთ მოცემულ სიას (თუ მასში არსებული რომელიმე ელემენტი უცნაურად ან უცხო გეჩვენებათ, გთხოვთ, თავი შეიკავოთ კრიტიკისგან და დარჩით ჩვენთან ერთად). ეს მხოლოდ ჯენკინსზე დაფუძნებული სამუშაო ნაკადების მაგალითებია. სხვა ინსტრუმენტებთან მუშაობისას ბევრი სხვა პროცესია.

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

1.სამუშაო პროცესი:"ჯენკინსის აშენება - სამაგისტრო ფილიალი".
Დავალებების სია:

• ჯენკინსი უბიძგებს მონიშნულ სურათებს Quay-ზე;
• ჯენკინსი უბიძგებს კონფიგურაციისა და Helm სქემებს სამაგისტრო შენახვის თაიგულზე;
• ღრუბლის ფუნქცია აკოპირებს კონფიგურაციას და სქემებს ძირითადი საცავის თაიგულიდან მთავარ Git საცავში;
• GitOps ოპერატორი აახლებს კლასტერს.

2. Jenkins build - გამოშვება ან Hotfix ფილიალი:

• ჯენკინსი უბიძგებს untagged სურათები Quay;
• ჯენკინსი უბიძგებს კონფიგურაციისა და Helm სქემებს დადგმის შენახვის თაიგულში;
• ღრუბლოვანი ფუნქცია აკოპირებს კონფიგურაციას და სქემებს დადგმის შენახვის თაიგულიდან დადგმის Git საცავში;
• GitOps ოპერატორი აახლებს კლასტერს.

3. ჯენკინსის აშენება - განავითაროს ან გამოავლინოს ფილიალი:

• ჯენკინსი უბიძგებს untagged სურათები Quay;
• Jenkins უბიძგებს config და Helm ჩარტებში შევიდა განვითარების შენახვის bucket;
• ღრუბლის ფუნქცია აკოპირებს კონფიგურაციას და დიაგრამებს განვითარების საცავის თაიგულიდან განვითარების Git საცავში;
• GitOps ოპერატორი აახლებს კლასტერს.

4. ახალი კლიენტის დამატება:

• მენეჯერი ან ადმინისტრატორი (LCM/ops) უწოდებს Gradle-ს, რათა თავდაპირველად განათავსოს და დააკონფიგურიროს ქსელის დატვირთვის ბალანსერები (NLBs);
• LCM/ops ახორციელებს ახალ კონფიგურაციას განახლებისთვის განლაგების მოსამზადებლად;
• GitOps ოპერატორი აახლებს კლასტერს.

GitOps-ის მოკლე აღწერა

1. აღწერეთ მთელი სისტემის სასურველი მდგომარეობა თითოეული გარემოსთვის დეკლარაციული სპეციფიკაციების გამოყენებით (ჩვენს ისტორიაში ბობის გუნდი განსაზღვრავს სისტემის მთელ კონფიგურაციას Git-ში).
   • Git საცავი არის სიმართლის ერთადერთი წყარო მთელი სისტემის სასურველ მდგომარეობასთან დაკავშირებით.
   • ყველა ცვლილება სასურველ მდგომარეობაზე ხდება Git-ში შეთანხმებების მეშვეობით.
   • ყველა სასურველი კლასტერული პარამეტრი ასევე შესამჩნევია თავად კლასტერში. ამ გზით ჩვენ შეგვიძლია განვსაზღვროთ, ემთხვევა თუ არა ისინი (ერთდებიან, დაახლოება) ან განსხვავდება (განსხვავება, განსხვავდებიან) სასურველი და დაკვირვებული მდგომარეობები.
2. თუ სასურველი და დაკვირვებული მდგომარეობები განსხვავდება, მაშინ:
   • არსებობს კონვერგენციის მექანიზმი, რომელიც ადრე თუ გვიან ავტომატურად ახდენს სამიზნე და დაკვირვებულ მდგომარეობების სინქრონიზაციას. კლასტერის შიგნით კუბერნეტესი ამას აკეთებს.
   • პროცესი დაუყოვნებლივ იწყება "შესრულებული ცვლილების" გაფრთხილებით.
   • გარკვეული კონფიგურირებადი პერიოდის შემდეგ, "განსხვავებული" გაფრთხილება შეიძლება გაიგზავნოს, თუ მდგომარეობები განსხვავებულია.
3. ამ გზით, ყველა ვალდებულება Git-ში იწვევს კლასტერში შესამოწმებელ და არაპოტენტურ განახლებებს.
   • უკან დაბრუნება არის კონვერგენცია ადრე სასურველ მდგომარეობამდე.
4. კონვერგენცია საბოლოოა. მისი გაჩენა მითითებულია:
   • არ არის განსხვავებული გაფრთხილებები გარკვეული პერიოდის განმავლობაში.
   • "კონვერგირებული" გაფრთხილება (მაგ. webhook, Git writeback event).

რა არის დივერგენცია?

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

განსხვავების რამდენიმე მაგალითი:

• კონფიგურაციის ფაილის შეცვლა Git-ში ფილიალების გაერთიანების გამო.
• კონფიგურაციის ფაილში ცვლილება Git commit-ის გამო GUI კლიენტის მიერ.
• მრავალჯერადი ცვლილება სასურველ მდგომარეობაში PR-ის გამო Git-ში, რასაც მოჰყვება კონტეინერის სურათის აგება და კონფიგურაციის ცვლილებები.
• კლასტერის მდგომარეობის ცვლილება შეცდომის გამო, რესურსების კონფლიქტის შედეგად, რომელიც იწვევს „ცუდ ქცევას“, ან უბრალოდ შემთხვევითი გადახრა საწყისი მდგომარეობიდან.

რა არის კონვერგენციის მექანიზმი?

რამდენიმე მაგალითი:

• კონტეინერებისა და კლასტერებისთვის კონვერგენციის მექანიზმი მოწოდებულია Kubernetes-ის მიერ.
• იგივე მექანიზმი შეიძლება გამოყენებულ იქნას Kubernetes-ზე დაფუძნებული აპლიკაციებისა და დიზაინის სამართავად (როგორიცაა Istio და Kubeflow).
• უზრუნველყოფს Kubernetes-ს, გამოსახულების საცავებსა და Git-ს შორის ოპერატიული ურთიერთქმედების მართვის მექანიზმს GitOps ოპერატორი Weave Flux, რომელიც არის ნაწილი ქსოვის ღრუბელი.
• საბაზისო მანქანებისთვის კონვერგენციის მექანიზმი უნდა იყოს დეკლარაციული და ავტონომიური. ჩვენი საკუთარი გამოცდილებიდან შეგვიძლია ვთქვათ Terraform ყველაზე ახლოს ამ განმარტებასთან, მაგრამ მაინც მოითხოვს ადამიანის კონტროლს. ამ თვალსაზრისით, GitOps ავრცელებს ინფრასტრუქტურის, როგორც კოდის ტრადიციას.

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

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

GitOps განკუთვნილია მთელი ღრუბლის მშობლიური სტეკისთვის (მაგალითად, Terraform და ა.შ.)

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

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

დიდი ყურადღება გამახვილებულია GitOps კონცეფციების გამოყენებაზე Kubernetes-ის თავზე მდებარე ფენებზე. ამ დროისთვის არის GitOps-ის ტიპის გადაწყვეტილებები Istio, Helm, Ksonnet, OpenFaaS და Kubeflow-სთვის, ასევე, მაგალითად, Pulumi-სთვის, რომლებიც ქმნიან ფენას აპლიკაციების შემუშავებისთვის cloud native-სთვის.

Kubernetes CI/CD: GitOps-ის შედარება სხვა მიდგომებთან

როგორც ითქვა, GitOps არის ორი რამ:

1. ზემოთ აღწერილი Kubernetes-ისა და ღრუბლის მშობლიური ოპერაციული მოდელი.
2. გზა დეველოპერზე ორიენტირებული აპლიკაციების მართვის გარემოში.

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

GitOps საშუალებას აძლევს უწყვეტი განლაგებას (CD) Kubernetes-ისთვის

GitOps გთავაზობთ უწყვეტი განლაგების მექანიზმს, რომელიც გამორიცხავს ცალკეული „განლაგების მართვის სისტემების“ საჭიროებას. Kubernetes აკეთებს ყველა საქმეს თქვენთვის.

• აპლიკაციის განახლება საჭიროებს განახლებას Git-ში. ეს არის ტრანზაქციის განახლება სასურველ მდგომარეობამდე. შემდეგ "განლაგება" ხდება კლასტერში თავად Kubernetes-ის მიერ განახლებული აღწერილობის საფუძველზე.
• Kubernetes-ის მუშაობის ბუნებიდან გამომდინარე, ეს განახლებები კონვერგენციულია. ეს უზრუნველყოფს უწყვეტი განლაგების მექანიზმს, რომელშიც ყველა განახლება ატომურია.
• შენიშვნა: ქსოვის ღრუბელი გთავაზობთ GitOps ოპერატორს, რომელიც აერთიანებს Git-სა და Kubernetes-ს და საშუალებას აძლევს CD შესრულდეს კლასტერის სასურველი და მიმდინარე მდგომარეობის შეჯერებით.

კუბექტლისა და სკრიპტების გარეშე

თქვენ უნდა მოერიდოთ Kubectl-ის გამოყენებას თქვენი კლასტერის განახლებისთვის და განსაკუთრებით მოერიდეთ სკრიპტების გამოყენებას kubectl ბრძანებების დასაჯგუფებლად. ამის ნაცვლად, GitOps მილსადენით, მომხმარებელს შეუძლია განაახლოს თავისი Kubernetes კლასტერი Git-ის საშუალებით.

უპირატესობებში შედის:

1. უფლება. შესაძლებელია განახლებების ჯგუფის გამოყენება, დაახლოება და საბოლოოდ დადასტურება, რაც გვაახლოებს ატომური განლაგების მიზანთან. ამის საპირისპიროდ, სკრიპტების გამოყენება არ იძლევა კონვერგენციის რაიმე გარანტიას (დაწვრილებით ამის შესახებ ქვემოთ).
2. უსაფრთხოების. ციტირება Kelsey Hightower: „შეზღუდეთ წვდომა თქვენს Kubernetes კლასტერზე ავტომატიზაციის ხელსაწყოებზე და ადმინისტრატორებზე, რომლებიც პასუხისმგებელნი არიან მის გამართვაზე ან შენარჩუნებაზე“. იხილეთ ასევე ჩემი პუბლიკაცია უსაფრთხოებისა და ტექნიკურ მახასიათებლებთან შესაბამისობის შესახებ, ასევე სტატია Homebrew-ის გატეხვის შესახებ ჯენკინსის დაუდევრად დაწერილი სცენარიდან რწმუნებათა სიგელების მოპარვით.
3. Მომხმარებლის გამოცდილება. Kubectl ავლენს Kubernetes ობიექტის მოდელის მექანიკას, რომელიც საკმაოდ რთულია. იდეალურ შემთხვევაში, მომხმარებლებმა უნდა დაუკავშირდნენ სისტემას აბსტრაქციის უფრო მაღალ დონეზე. აქ კიდევ ერთხელ მივმართავ კელსის და გირჩევ ყურებას ასეთი რეზიუმე.

განსხვავება CI და CD-ს შორის

GitOps აუმჯობესებს არსებულ CI/CD მოდელებს.

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

CI უნდა იყოს გამოყენებული ტრანკში განახლებების გადასატანად, ხოლო Kubernetes კლასტერი თავად უნდა შეიცვალოს ამ განახლებების საფუძველზე CD-ის შიდა მართვისთვის. ჩვენ მას ვეძახით pull მოდელი CD-სთვისCI push მოდელისგან განსხვავებით. CD არის ნაწილი გაშვების ორკესტრირება.

რატომ არ უნდა გააკეთონ CI სერვერებმა CD-ები Kubernetes-ში პირდაპირი განახლების საშუალებით

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

დავუბრუნდეთ ალისას და ბობს.

რა პრობლემები შეექმნათ მათ? Bob's CI სერვერი იყენებს ცვლილებებს კლასტერში, მაგრამ თუ ის ავარიაში ხდება, ბობ არ იცის რა მდგომარეობაშია (ან უნდა იყოს) კლასტერი ან როგორ გაასწოროს იგი. იგივეა წარმატების შემთხვევაშიც.

დავუშვათ, რომ ბობის გუნდმა შექმნა ახალი სურათი და შემდეგ გაასწორა მათი განლაგება გამოსახულების განსათავსებლად (ყველა CI მილსადენიდან).

თუ გამოსახულება ნორმალურად იქმნება, მაგრამ მილსადენი ვერ ხერხდება, გუნდს მოუწევს გაარკვიოს:

• გამოვიდა განახლება?
• ვიწყებთ ახალ მშენებლობას? გამოიწვევს თუ არა ეს არასაჭირო გვერდით მოვლენებს - ერთი და იგივე უცვლელი გამოსახულების ორი კონსტრუქციის არსებობის შესაძლებლობით?
• უნდა ველოდოთ შემდეგ განახლებას build-ის გაშვებამდე?
• კონკრეტულად რა მოხდა? რომელი ნაბიჯების გამეორებაა საჭირო (და რომელია უსაფრთხო გამეორება)?

Git-ზე დაფუძნებული სამუშაო ნაკადის ჩამოყალიბება არ იძლევა გარანტიას, რომ ბობის გუნდი არ წააწყდება ამ პრობლემებს. მათ მაინც შეუძლიათ შეცდომა დაუშვან commit push-ით, ტეგით ან სხვა პარამეტრით; თუმცა, ეს მიდგომა ჯერ კიდევ უფრო ახლოს არის აშკარა-ყველა ან არაფერი მიდგომასთან.

რომ შევაჯამოთ, აი, რატომ არ უნდა ეხებოდეს CI სერვერები CD-ს:

• განახლების სკრიპტები ყოველთვის არ არის განმსაზღვრელი; მათში შეცდომების დაშვება ადვილია.
• CI სერვერები არ ემთხვევა დეკლარაციულ კლასტერულ მოდელს.
• იმპოტენციის გარანტია რთულია. მომხმარებლებმა უნდა გაიგონ სისტემის ღრმა სემანტიკა.
• ნაწილობრივი წარუმატებლობისგან აღდგენა უფრო რთულია.

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

GitOps, როგორც საუკეთესო გზა Kubernetes-ისთვის უწყვეტი მიწოდების განსახორციელებლად

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

ოპერაციული მოდელი Kubernetes-ისთვის

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

• უწყვეტი ინტეგრაციის მილსადენი, რომელიც კითხულობს და წერს ფაილებს Git-ში და შეუძლია განაახლოს კონტეინერის სურათების საცავი.
• Runtime GitOps მილსადენი, რომელიც აერთიანებს განლაგებას მენეჯმენტთან და დაკვირვებადობასთან. ის კითხულობს და წერს ფაილებს Git-ში და შეუძლია კონტეინერის სურათების ჩამოტვირთვა.

რა არის ძირითადი დასკვნები?

1. შეშფოთების გამიჯვნა: გთხოვთ, გაითვალისწინოთ, რომ ორივე მილსადენს შეუძლია კომუნიკაცია მხოლოდ Git-ის ან სურათების საცავების განახლებით. სხვა სიტყვებით რომ ვთქვათ, არსებობს firewall CI-სა და გაშვების გარემოს შორის. ჩვენ მას ვუწოდებთ "უცვლელობის ფეიერვალს" (უცვლელობის firewall), ვინაიდან საცავის ყველა განახლება ქმნის ახალ ვერსიებს. ამ თემაზე დამატებითი ინფორმაციისთვის იხილეთ სლაიდები 72-87 ამ პრეზენტაციას.
2. შეგიძლიათ გამოიყენოთ ნებისმიერი CI და Git სერვერი: GitOps მუშაობს ნებისმიერ კომპონენტთან. შეგიძლიათ გააგრძელოთ თქვენი საყვარელი CI და Git სერვერების, სურათების საცავებისა და სატესტო კომპლექტების გამოყენება. თითქმის ყველა სხვა უწყვეტი მიწოდების ინსტრუმენტი ბაზარზე მოითხოვს საკუთარ CI/Git სერვერს ან გამოსახულების საცავს. ეს შეიძლება გახდეს შემაკავებელი ფაქტორი ღრუბლოვანი ბუნების განვითარებაში. GitOps-ით შეგიძლიათ გამოიყენოთ ნაცნობი ინსტრუმენტები.
3. მოვლენები, როგორც ინტეგრაციის ინსტრუმენტი: როგორც კი მონაცემები Git-ში განახლდება, Weave Flux (ან Weave Cloud ოპერატორი) აცნობებს გაშვების დროს. როდესაც Kubernetes მიიღებს ცვლილებების კომპლექტს, Git განახლდება. ეს უზრუნველყოფს მარტივ ინტეგრაციის მოდელს GitOps-ისთვის სამუშაო ნაკადების ორგანიზებისთვის, როგორც ეს ნაჩვენებია ქვემოთ.

დასკვნა

GitOps უზრუნველყოფს განახლების ძლიერ გარანტიებს, რომლებიც საჭიროა ნებისმიერი თანამედროვე CI/CD ინსტრუმენტისთვის:

• ავტომატიზაცია;
• კონვერგენცია;
• იმპოტენცია;
• დეტერმინიზმი.

ეს მნიშვნელოვანია, რადგან ის გთავაზობთ ოპერაციულ მოდელს ღრუბლის მშობლიური დეველოპერებისთვის.

• სისტემების მართვისა და მონიტორინგის ტრადიციული ინსტრუმენტები ასოცირდება ოპერაციულ გუნდებთან, რომლებიც მოქმედებენ runbook-ში (რუტინული პროცედურებისა და ოპერაციების ნაკრები - დაახლ. თარგმანი.), მიბმული კონკრეტულ განლაგებასთან.
• ღრუბლოვან მენეჯმენტში, დაკვირვებადობის ინსტრუმენტები საუკეთესო საშუალებაა განლაგების შედეგების გასაზომად, რათა განვითარების გუნდმა შეძლოს სწრაფად რეაგირება.

წარმოიდგინეთ მრავალი კლასტერი მიმოფანტული სხვადასხვა ღრუბლებში და მრავალი სერვისი საკუთარი გუნდებით და განლაგების გეგმებით. GitOps გთავაზობთ მასშტაბის უცვლელ მოდელს მთელი ამ სიმრავლის მართვისთვის.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «GitOps: აწევისა და დაძაბვის მეთოდების შედარება";
• «წარმოგიდგენთ kubedog-ს, ბიბლიოთეკას Kubernetes რესურსების თვალყურის დევნებისთვის";
• «Kubernetes-ის გაფართოება და შევსება (მიმოხილვა და ვიდეო ანგარიში)".

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

იცოდით GitOps-ის შესახებ, სანამ ეს ორი თარგმანი გამოჩნდებოდა Habré-ზე?

• დიახ, ყველაფერი ვიცოდი

• მხოლოდ ზედაპირულად

• არარის

მისცა ხმა 35 მომხმარებელმა. 10-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com