GitOps: კიდევ ერთი ხმაურიანი სიტყვა თუ გარღვევა ავტომატიზაციაში?

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

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

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

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

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

GitOps

IaC

ყველა კოდი ინახება git საცავში

კოდის ვერსია არჩევითია

დეკლარაციული კოდის აღწერა / იმპოტენცია

მისაღებია როგორც დეკლარაციული, ასევე იმპერატიული აღწერილობები

ცვლილებები ძალაში შედის Merge Request/Pull Request მექანიზმების გამოყენებით

შეთანხმება, დამტკიცება და თანამშრომლობა არჩევითია

განახლების გაშვების პროცესი ავტომატიზებულია

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

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

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

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

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

GitOps არის მეთოდოლოგია, რომელიც იყენებს DevOps-ის საუკეთესო პრინციპებს, რომლებიც გამოიყენება აპლიკაციის შემუშავებისთვის, როგორიცაა ვერსიის კონტროლი, თანამშრომლობა, ორკესტრირება, CI/CD და იყენებს მათ ინფრასტრუქტურის მართვის ავტომატიზაციის გამოწვევებზე.

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

პრაქტიკული თვალსაზრისით, ჩვენ აღვწერთ GitOps შემდეგნაირად:

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

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

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

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

დიახ, ტერმინი GitOps არ გვაცნობს არაფერს სრულიად ახალს, არ იგონებს ბორბალს, არამედ უბრალოდ იყენებს უკვე დაგროვილ გამოცდილებას ახალ სფეროში. მაგრამ აქ არის მისი ძალა.

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

• განახორციელეთ GitOps-ის ძირითადი პრინციპები

• შექმენით და შეიტანეთ ცვლილებები ღრუბლოვან ინფრასტრუქტურაში (Yandex Cloud-ის მაგალითის გამოყენებით)

• სისტემის დრეიფის ავტომატიზირება სასურველი მდგომარეობიდან აქტიური მონიტორინგის გამოყენებით

https://bit.ly/34tRpwZ

წყარო: www.habr.com