GitOps: še en moderen termin ali preboj v avtomatizaciji?

Večina nas, ki opazimo še en nov termin v IT blogosferi ali na konferencah, prej ali slej zastavi podobno vprašanje: "Kaj to pomeni? Še ena modna beseda, 'buzzword' ali res nekaj, kar si zasluži pozornost, raziskovanje in obeta nove horizonte?" Tako je bilo tudi pri meni s terminom GitOps nekaj časa nazaj. Obešajoč se na številne že obstoječe članke ter znanje kolegov iz podjetja GitLab, sem poskušal razjasniti, kaj to pravzaprav je in kako bi njegova uporaba izgledala v praksi.

Mimogrede, o novosti termina GitOps tudi govori nedavna anketa, ki smo jo izvedli: več kot polovica anketiranih še ni začela delati s njegovimi načeli.

Torej, problem upravljanja infrastrukture ni nov. Številni oblačni ponudniki so že več kot desetletje dostopni širšemu občinstvu in zdelo bi se, da bi morali delo ekip, odgovornih za infrastrukturo, olajšati. Vendar pa se pri primerjavi z razvojem aplikacij (kjer dosega stopnja avtomatizacije vedno nove in nove horizonte) infrastrukturni projekti še vedno pogosto vključujejo številne ročne naloge in zahtevajo posebna znanja ter strokovnjake, zlasti ob upoštevanju sodobnih zahtev po odpornosti, prilagodljivosti, razširljivosti in elastičnosti.

Oblačne storitve so uspešno izpolnile te zahteve in prav te so dale znaten zagon razvoju pristopa IaC. To je razumljivo. Saj so prav one omogočile konfiguracijo popolnoma virtualnega centra za obdelavo podatkov: nobenih fizičnih strežnikov, omar, omrežnih komponent, vso infrastrukturo je mogoče opisati s pomočjo skriptov in konfiguracijskih datotek.

Kaj torej poganja razliko GitOps od IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:

GitOps

IaC

Vse kode se shranjujejo v git repozitoriju

Različnost kode ni obvezna

Deklarativni opis kode / Idempotentnost

Dovoljeno je tako deklarativno kot imperativno opisovanje

Spremembe začnejo veljati z uporabo mehanizmov Merge Request / Pull Request

Soglasje, odobritev in sodelovanje niso obvezni

Postopek izdaje posodobitev je avtomatiziran

Postopek izdaje posodobitev ni standardiziran (samodejno, ročno, kopiranje datotek, uporaba ukazne vrstice itd.)

Drugimi besedami GitOps se je pojavil na svetu prav zaradi uporabe načel IaC. Prvič, infrastrukturo in konfiguracije je zdaj mogoče shranjevati natanko tako kot aplikacije. Kodo je enostavno hraniti, z njo deliti, primerjati in uporabljati možnosti različic. Različice, veje, zgodovina. In vse to na dostopnem mestu za celotno ekipo. Zato je bilo povsem razumljivo, da se je začelo z uporabo sistemov nadzora različic. Zlasti git, kot najbolj priljubljen.

Na drugi strani se je pojavila možnost avtomatizacije procesov upravljanja infrastrukture. Zdaj je to mogoče narediti hitreje, zanesljiveje in ceneje. Še posebej, ker so bili načeli CI/CD že znani in priljubljeni med razvijalci programske opreme. Samo prenesti in uporabiti je bilo potrebno že znanje in veščine v novo področje. Te prakse pa so presegle standardno opredelitev infrastrukture kot kode, od tod tudi pojem GitOps.

Radovednost GitOps, seveda, je tudi v tem, da to ni izdelek, vtičnik ali platforma, povezana s katerim koli dobaviteljem. To je bolj paradigma in nabor načel, podobno znanemu terminu: DevOps.

V podjetju GitLab izoblikovali smo dve opredelitvi tega novega pojma: teoretično in praktično. Začnimo s teoretično:

GitOps je metodologija, ki uporablja napredna načela DevOps, uporabljena pri razvoju aplikacij, kot so nadzor različic, sodelovanje, usklajevanje, CI/CD, in jih uporablja za reševanje nalog avtomatizacije upravljanja infrastrukture.

Vsi procesi GitOps delujejo z uporabo že obstoječih orodij. Vsa infrastrukturna koda se hrani v že znanem git repozitoriju, spremembe preidejo skozi isti proces usklajevanja kot katera koli druga programska koda, proces izdajanja pa je avtomatiziran, kar zmanjša napake človeškega faktorja, poveča zanesljivost in ponovljivost.

Z praktičnega vidika pa opisujemo GitOps takole:

Infrastrukturo kot kodo smo že obravnavali kot eno ključnih sestavin te formule. Predstavljajmo si ostale udeležence.

Merge Request (alternativno ime Pull Request). U okviru procesa MR to je zahtev za primenu promena u kodu i naknadno spajanje grana. Međutim, u smislu alata kojima se koristimo, to je pre mogućnost da dobijemo potpunu sliku svih uvrštenih promena: ne samo code diff, sastavljen iz određenog broja commit-a, već i kontekst, rezultati testiranja, krajnji očekivani ishod. Kada govorimo o infrastrukturnom kodu, zanimljivo nam je kako se tačno menja infrastruktura, koliko novih resursa će biti dodato ili uklonjeno, promenjeno. Idealno je to predstaviti u nekom prikladnijem i lakšem formatu. U slučaju sa provajderima oblaka bilo bi dobro znati kakve će finansijske posledice izazvati ova promena.

Ali MR je takođe sredstvo za zajednički rad, interakciju, komunikaciju. To je mesto gde se aktivira sistem protuusluga i ravnoteže. Od jednostavnih komentara do formalnih odobrenja i potvrda.

I poslednji deo: CI/CD, kao što već znamo, omogućava automatizaciju procesa izvođenja infrastrukturnih promena, testiranja (od jednostavne provere sintakse do složenije statičke analize koda). Takođe i kasnije otkrivanje drifta: razlika između stvarnog i željenog stanja sistema. Na primer, kao rezultat neovlašćenih ručnih promena ili kvara sistema.

Da, termin GitOps nas ne upoznaje ni sa čim apsolutno novim, ne izmiče bicikl, već samo primenjuje već stečeno iskustvo u novoj oblasti. Ali u tome leži njegova snaga.

A ako vas iznenada zanima kako to sve izgleda u praksi, pozivam vas da pogledate našu masterclass, u kojoj korak po korak objašnjavam kako pomoću GitLab-a:

• Implementirati osnovne principe GitOps-a

• Kreirati i izvoditi promene u obrtnu infrastrukturu (na primeru Yandex Cloud-a)

• Automatizovati otkrivanje drifta sistema od željenog stanja uz aktivno praćenje

https://bit.ly/34tRpwZ

Izvor: habr.com