GitOps: još jedna popularna riječ ili napredak u automatizaciji?

Većina nas, primijetivši još jedan novi pojam u IT blogosferi ili na konferenciji, prije ili kasnije postavi slično pitanje: “Što je ovo? Samo još jedna poštapalica, "poštapalica" ili nešto uistinu vrijedno pažnje, proučavanja i obećanja novih horizonata?" Isto mi se dogodilo s terminom GitOps prije nekog vremena. Naoružan mnogim postojećim člancima, kao i znanjem kolega iz tvrtke GitLab, pokušao sam dokučiti o kakvoj se zvijeri radi i kako bi njena upotreba mogla izgledati u praksi.

Usput, o novosti termina GitOps Naše nedavno istraživanje također kaže: više od polovice ispitanih još nije počelo raditi s njegovim načelima.

Dakle, problem upravljanja infrastrukturom nije nov. Mnogi pružatelji usluga oblaka dostupni su široj javnosti već dobrih desetak godina i, čini se, trebali su rad timova odgovornih za infrastrukturu učiniti jednostavnim i jasnim. Međutim, u usporedbi s procesom razvoja aplikacija (gdje automatizacija doseže sve više razine), infrastrukturni projekti još uvijek često uključuju mnoge ručne zadatke i zahtijevaju specijalizirano znanje i stručnost, posebno s obzirom na današnje zahtjeve za tolerancijom na pogreške, fleksibilnošću, skalabilnošću i elastičnošću.

Cloud servisi su te zahtjeve vrlo uspješno ispunili i upravo su oni dali značajan poticaj razvoju pristupa IaC. Ovo je razumljivo. Uostalom, omogućili su konfiguraciju potpuno virtualnog podatkovnog centra: nema fizičkih poslužitelja, regala ili mrežnih komponenti, cijela se infrastruktura može opisati pomoću skripti i konfiguracijskih datoteka.

Dakle, koja je točno razlika? GitOps iz IaC? Ovim sam pitanjem započeo svoje istraživanje. Nakon razgovora s kolegama uspio sam doći do sljedeće usporedbe:

GitOps

IaC

Sav kod je pohranjen u git repozitoriju

Verzija koda nije obavezna

Opis deklarativnog koda / Idempotencija

Prihvatljivi su i deklarativni i imperativni opisi

Promjene stupaju na snagu pomoću mehanizama Zahtjeva za spajanje / Zahtjeva za povlačenje

Dogovor, odobrenje i suradnja nisu obvezni

Proces uvođenja ažuriranja je automatiziran

Proces uvođenja ažuriranja nije standardiziran (automatski, ručno, kopiranje datoteka, korištenje naredbenog retka itd.)

Drugim riječima GitOps rođeno je upravo primjenom načela IaC. Prvo, infrastruktura i konfiguracije sada se mogu pohranjivati ​​na isti način kao i aplikacije. Kôd je jednostavan za pohranu, jednostavan za dijeljenje, usporedbu i korištenje mogućnosti izrade verzija. Verzije, grane, povijest. I sve to na javnom mjestu dostupnom cijelom timu. Stoga je korištenje sustava kontrole verzija postalo potpuno prirodan razvoj. Posebno git, kao najpopularniji.

S druge strane, postalo je moguće automatizirati procese upravljanja infrastrukturom. Sada se to može učiniti brže, pouzdanije i jeftinije. Štoviše, principi CI/CD-a već su bili poznati i popularni među programerima softvera. Bilo je potrebno samo već poznata znanja i vještine prenijeti i primijeniti na novo područje. Te su prakse, međutim, nadišle standardnu ​​definiciju infrastrukture kao koda, dakle koncepta GitOps.

Znatiželja GitOps, naravno, također 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.

Tvrtka GitLab razvili smo dvije definicije ovog novog pojma: teorijsku i praktičnu. Počnimo s teorijskim:

GitOps je metodologija koja preuzima najbolje DevOps principe koji se koriste za razvoj aplikacija, kao što su kontrola verzija, suradnja, orkestracija, CI/CD, i primjenjuje ih na izazove automatizacije upravljanja infrastrukturom.

Svi procesi GitOps Radim koristeći postojeće alate. Sav infrastrukturni kod pohranjen je u već poznatom git repozitoriju, promjene prolaze kroz isti postupak odobravanja kao i bilo koji drugi programski kod, a proces uvođenja je automatiziran, što nam omogućuje minimiziranje ljudskih pogrešaka, povećanje pouzdanosti i ponovljivosti.

S praktičnog gledišta, opisujemo GitOps kako slijedi:

Već smo razgovarali o infrastrukturi kao kodu kao jednoj od ključnih komponenti ove formule. Predstavimo i ostale sudionike.

Zahtjev za spajanje (alternativni naziv Pull Request). U smislu procesa, MR je zahtjev za primjenu promjena koda i zatim spajanje grana. Ali u smislu alata koje koristimo, ovo je više prilika za dobivanje cjelovite slike svih promjena koje su napravljene: ne samo razlika u kodu prikupljena iz određenog broja obveza, 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 prikladnijem i čitljivijem formatu. Za pružatelje usluga u oblaku, dobra je ideja znati kakav će biti financijski učinak ove promjene.

Ali MR je također sredstvo suradnje, interakcije i komunikacije. Mjesto gdje dolazi do izražaja sustav provjere i ravnoteže. Od jednostavnih komentara do formalnih odobrenja i odobrenja.

Pa, posljednja komponenta: CI/CD, kao što već znamo, omogućuje automatizaciju procesa izmjene infrastrukture i testiranja (od jednostavne provjere sintakse do složenije statičke analize koda). I također u naknadnom otkrivanju pomaka: razlike između stvarnog i željenog stanja sustava. Na primjer, kao rezultat neovlaštenih ručnih promjena ili kvara sustava.

Da, termin GitOps ne upoznaje nas s nečim posve novim, ne izmišlja ponovno kotač, već jednostavno primjenjuje već stečeno iskustvo na novom području. Ali tu leži njegova snaga.

A ako vas iznenada zainteresira kako to sve izgleda u praksi, pozivam vas da pogledate naš majstorska klasa, u kojem vam korak po korak govorim kako koristiti GitLab:

• Implementirajte osnovne principe GitOps-a

• Stvorite i napravite promjene u infrastrukturi oblaka (na primjeru Yandex Clouda)

• Automatsko otkrivanje odstupanja sustava od željenog stanja pomoću aktivnog nadzora

https://bit.ly/34tRpwZ

Izvor: www.habr.com