Većina nas, primjećujući još jedan novi termin u IT blogosferi ili na konferenciji, prije ili kasnije se suočava s pitanjem: “Što je to? Još jedna moderna riječ, 'buzzword' ili zapravo nešto vrijedno pozornosti, proučavanja i obećava nove horizonte?” Tako je i meni bilo s terminom GitOps neko vrijeme unatrag. Opremljen brojnim postojećim člancima, kao i znanjem kolega iz tvrtke , pokušao sam shvatiti što je to za čudovište, i kako bi njegova primjena mogla izgledati u praksi.
Usput, o novitetu termina GitOps govori i nedavna anketa koju smo proveli: više od polovice ispitanika još nije započelo raditi s njegovim principima.
Dakle, problem upravljanja infrastrukturom nije nov. Mnoge cloud usluge dostupne su široj javnosti već više od deset godina i, činilo bi se, trebale su olakšati rad timovima zaduženim za infrastrukturu. Međutim, u usporedbi s procesom razvoja aplikacija (gdje razina automatizacije doseže nove i nove horizonte), infrastrukturni projekti i dalje često uključuju mnoge ručne zadatke i zahtijevaju posebna znanja i stručnjake, osobito uzimajući u obzir moderne zahtjeve za otpornosti, fleksibilnosti, skalabilnosti i elastičnosti.
Cloud usluge su vrlo uspješno ispunjavale te zahtjeve i upravo su one dale značajan poticaj razvoju pristupa IaC. Nije ni čudo. Na kraju krajeva, one su omogućile konfiguriranje potpuno virtualnog centra za obradu podataka: nema fizičkih poslužitelja, ormara, mrežnih komponenti; cijela infrastruktura može se opisati pomoću skripti i konfiguracijskih datoteka.
Koja je zapravo razlika GitOps od IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Sav kod se pohranjuje u git repozitoriju
Verzioniranje koda nije obavezno
Deklarativni opis koda / Idempotentnost
Dopušteno je kako deklarativno, tako i imperativno opisivanje
Izmjene stupaju na snagu korištenjem mehanizama Merge Request / Pull Request
Usuglašavanje, odobrenje i suradnja nisu obavezni
Proces izbacivanja ažuriranja je automatiziran
Proces izbacivanja ažuriranja nije standardiziran (automatski, ručni, kopiranje datoteka, korištenje komandne linije i slično)
Drugačije rečeno GitOps rodio se upravo zahvaljujući primjeni principa IaC. Prvo, infrastrukturu i konfiguracije sada je moguće pohranjivati na isti način kao i aplikacije. Kod je lako pohraniti, lako ga je dijeliti, uspoređivati i koristiti mogućnosti verzioniranja. Verzije, grane, povijest. I sve to na javnom mjestu dostupnom cijelom timu. Stoga je upotreba sustava za kontrolu verzija, posebno gita kao najpopularnijeg, postalo prirodni razvoj.
S druge strane, otvorila se mogućnost automatizacije procesa upravljanja infrastrukturom. To se sada može raditi brže, pouzdanije i jeftinije. Osim toga, principi CI/CD već su bili poznati i popularni među programerima. Bilo je potrebno samo prenijeti i primijeniti poznato znanje i vještine na novo područje. Međutim, te su prakse nadmašivale standardnu definiciju infrastrukture kao koda, otud i pojam GitOps.
Radoznalost GitOps, naravno, leži i u tome što to nije proizvod, dodatak ili platforma povezana s bilo kojim dobavljačem. To je više paradigma i skup principa, slično drugom poznatom terminu: DevOps.
U kompaniji Izradili smo dvije definicije ovog novog pojma: teorijsku i praktičnu. Počnimo od teorijske:
GitOps je metodologija koja koristi napredne DevOps principe koji se koriste za razvoj aplikacija, poput kontrole verzija, suradnje, usklađivanja, CI/CD, i primjenjuje ih za rješavanje zadataka automatizacije upravljanja infrastrukturom.
Svi procesi GitOps rade korištenjem već postojećih alata. Sav infrastrukturni kod pohranjuje se u već poznatom git repozitoriju, promjene prolaze isti proces usklađivanja kao i svaki drugi programski kod, a proces isporuke je automatiziran, što minimizira ljudske greške, povećava pouzdanost i reproducibilnost.
Iz praktične perspektive opisujemo GitOps na sljedeći način:
Infrastrukturu kao kod već smo raspravili kao jednu od ključnih sastavnica ove formule. Predstavimo ostale dionike.
Merge Request (alternativni naziv za Pull Request). U okviru procesa MR, to je zahtjev za primjenom promjena u kodu i naknadnim spajanjem grana. Međutim, u okviru alata koje koristimo, to je više mogućnost za dobivanje potpune slike svih unesenih promjena: ne samo code diff-a, koji je sastavljen od određenog broja commit-a, već i konteksta, rezultata testiranja i konačnog očekivanog rezultata. Ako govorimo o infrastrukturnom kodu, zanima nas kako će točno promijeniti infrastrukturu, koliko novih resursa će biti dodano ili uklonjeno, promijenjeno. Preporučljivo je u nekom lakšem i čitljivijem formatu. U slučaju s cloud pružateljima, bilo bi dobro znati kakve će financijske posljedice imati ova promjena.
Ali MR je i sredstvo za suradnju, interakciju, komunikaciju. To je mjesto gdje dolazi do izražaja sustav ravnoteže snaga. Od jednostavnih komentara do formalnih odobrenja i potvrda.
I posljednja komponenta: CI/CD, kao što već znamo, omogućava automatizaciju procesa uvođenja infrastrukturnih promjena, testiranja (od jednostavne provjere sintakse do složenije statičke analize koda). Također, u sljedećem otkrivanju drifta: razlike između stvarnog i željenog stanja sustava. Na primjer, uslijed neovlaštenih ručnih promjena ili kvarova sustava.
Da, termin GitOps ne upoznaje nas ni s čim apsolutno novim, ne izmišlja bicikl, nego samo primjenjuje već stečeno iskustvo na novom području. Ali u tome leži njegova snaga.
A ako vas slučajno zanima kako to sve izgleda u praksi, pozivam vas da pogledate naš , u kojem korak po korak objašnjavam kako uz pomoć GitLab-a:
Implementirati osnovne principe GitOps-a
Kreirati i uvoditi promjene u cloud infrastrukturu (na primjeru Yandex Cloud-a)
Automatizirati otkrivanje drifta sustava od željenog stanja uz pomoć aktivnog monitoringa
https://bit.ly/34tRpwZ
Izvor: habr.com
