Većina nas, uočivši još jedan novi termin u IT blogosferi ili konferenciji, prije ili kasnije postavi slično pitanje: „Šta je ovo? Samo još jedna popularna riječ, „neznatna riječ“ ili nešto zaista vrijedno pažnje, proučavanja i obećanja novih horizonata?“ Ista stvar mi se desila sa terminom gitops prije nekog vremena. Naoružani mnogim postojećim artiklima, kao i znanjem kolega iz kompanije , pokušao sam da shvatim kakva je to zvijer i kako bi njena upotreba mogla izgledati u praksi.
Usput, o novosti pojma gitops Naše nedavno istraživanje takođe kaže: više od polovine ispitanih još nije počelo da radi na njegovim principima.
Dakle, problem upravljanja infrastrukturom nije nov. Mnogi provajderi oblaka dostupni su široj javnosti već desetak godina i, čini se, trebalo je da učine rad timova odgovornih za infrastrukturu jednostavnim i jednostavnim. Međutim, kada se uporedi sa procesom razvoja aplikacija (gde automatizacija dostiže sve nove nivoe), infrastrukturni projekti i dalje često uključuju mnogo ručnih zadataka i zahtevaju specijalizovano znanje i stručnost, posebno imajući u vidu današnje zahteve za toleranciju grešaka, fleksibilnost, skalabilnost i elastičnost.
Cloud servisi su vrlo uspješno ispunili ove zahtjeve i upravo su oni dali značajan poticaj razvoju pristupa IaC. Ovo je razumljivo. Na kraju krajeva, omogućili su konfiguraciju potpuno virtuelnog centra podataka: nema fizičkih servera, rekova ili mrežnih komponenti; cijela infrastruktura se može opisati pomoću skripti i konfiguracijskih datoteka.
U čemu je tačno razlika? gitops iz IaC? Sa ovim pitanjem sam započeo svoju istragu. Nakon razgovora sa kolegama, uspeo sam da dođem do sledećeg poređenja:
gitops
IaC
Sav kod je pohranjen u git spremištu
Verzija koda je opciona
Deklarativna šifra Opis / Idempotencija
I deklarativni i imperativni opisi su prihvatljivi
Promjene stupaju na snagu pomoću mehanizama zahtjeva za spajanjem / zahtjeva za povlačenjem
Dogovor, odobrenje i saradnja nisu obavezni
Proces uvođenja ažuriranja je automatiziran
Proces uvođenja ažuriranja nije standardiziran (automatski, ručno, kopiranje datoteka, korištenje komandne linije, itd.)
Drugim riječima gitops je rođen upravo kroz primjenu principa IaC. Prvo, infrastruktura i konfiguracije sada mogu biti pohranjene na isti način kao i aplikacije. Kod se lako skladišti, lako se dijeli, upoređuje i koristi mogućnosti verzioniranja. Verzije, grane, istorija. I sve to na mjestu koje je javno dostupno cijelom timu. Stoga je korištenje sistema kontrole verzija postalo potpuno prirodan razvoj. Konkretno, git, kao najpopularniji.
S druge strane, postalo je moguće automatizirati procese upravljanja infrastrukturom. Sada se to može uraditi brže, pouzdanije i jeftinije. Štaviše, principi CI/CD-a su već bili poznati i popularni među programerima softvera. Bilo je potrebno samo prenijeti i primijeniti već poznata znanja i vještine na novo područje. Ove prakse su, međutim, prevazišle standardnu definiciju infrastrukture kao koda, otuda i koncept gitops.
Radoznalost gitops, naravno, i u činjenici da to nije proizvod, dodatak ili platforma povezana s bilo kojim dobavljačem. To je više paradigma i skup principa, sličan drugom pojmu koji nam je poznat: DevOps.
U kompaniji razvili smo dvije definicije ovog novog pojma: teorijsku i praktičnu. Počnimo sa teorijskim:
GitOps je metodologija koja uzima najbolje DevOps principe koji se koriste za razvoj aplikacija, kao što su kontrola verzija, saradnja, orkestracija, CI/CD, i primjenjuje ih na izazove automatizacije upravljanja infrastrukturom.
Svi procesi gitops Radim koristeći postojeće alate. Sav infrastrukturni kod je pohranjen u već poznatom git repozitoriju, promjene prolaze kroz isti proces odobravanja kao i svaki drugi programski kod, a proces uvođenja je automatiziran, što nam omogućava da minimiziramo ljudske greške, povećamo pouzdanost i ponovljivost.
Sa praktične tačke gledišta, opisujemo gitops kako slijedi:
Već smo govorili o infrastrukturi kao kodu kao jednoj od ključnih komponenti ove formule. Hajde da predstavimo ostale učesnike.
Zahtjev za spajanjem (alternativni naziv Pull Request). U smislu procesa, MR je zahtjev za primjenom promjena koda i zatim spajanje grana. Ali u smislu alata koje koristimo, ovo je više prilika da se dobije potpuna slika svih promjena koje se vrše: ne samo kod diff prikupljen iz određenog broja urezivanja, već i kontekst, rezultati testa i konačni očekivani rezultat. Ako govorimo o infrastrukturnom kodu, onda nas zanima kako će se točno infrastruktura promijeniti, koliko će se novih resursa dodati ili ukloniti, promijeniti. Po mogućnosti u nekom pogodnijem formatu koji je lakši za čitanje. Za pružaoce usluga u oblaku, dobra je ideja da znaju kakav će biti finansijski uticaj ove promjene.
Ali MR je također sredstvo saradnje, interakcije i komunikacije. Mjesto gdje sistem provjere i ravnoteže stupa na snagu. Od jednostavnih komentara do formalnih odobrenja i odobrenja.
Pa, posljednja komponenta: CI/CD, kao što već znamo, omogućava automatizaciju procesa izmjene infrastrukture i testiranja (od jednostavne provjere sintakse do složenije statičke analize koda). I takođe u naknadnom otkrivanju pomaka: razlike između stvarnog i željenog stanja sistema. Na primjer, kao rezultat neovlaštenih ručnih promjena ili kvara sistema.
Da, termin gitops ne uvodi nas ni u šta potpuno novo, ne izmišlja točak, već jednostavno primjenjuje već stečeno iskustvo u novoj oblasti. Ali tu je njegova snaga.
A ako vas odjednom zainteresuje kako to sve izgleda u praksi, onda vas pozivam da pogledate naše , u kojem vam govorim korak po korak kako koristiti GitLab:
-
Implementirajte osnovne principe GitOps-a
-
Kreirajte i napravite promjene u infrastrukturi oblaka (koristeći primjer Yandex Clouda)
-
Automatsko otkrivanje pomaka sistema iz željenog stanja koristeći aktivni nadzor
https://bit.ly/34tRpwZ
izvor: www.habr.com