Cei mai mulți dintre noi, observând un alt termen nou în blogosfera sau conferința IT, mai devreme sau mai târziu ne punem o întrebare similară: „Ce este asta? Doar un alt cuvânt la modă, un „cuvânt la modă” sau ceva cu adevărat demn de atenție, studiu și promisiune de noi orizonturi? Același lucru mi s-a întâmplat cu termenul GitOps ceva timp în urmă. Înarmat cu multe articole existente, precum și cu cunoștințele colegilor din companie , am încercat să-mi dau seama ce fel de fiară este aceasta și cum ar putea arăta utilizarea ei în practică.
Apropo, despre noutatea termenului GitOps Sondajul nostru recent mai spune: mai mult de jumătate dintre cei chestionați nu au început încă să lucreze cu principiile sale.
Deci, problema managementului infrastructurii nu este nouă. Mulți furnizori de cloud sunt disponibili pentru publicul larg de o duzină de ani și, se pare, ar fi trebuit să facă munca echipelor responsabile de infrastructură simplă și simplă. Cu toate acestea, în comparație cu procesul de dezvoltare a aplicațiilor (unde automatizarea atinge niveluri din ce în ce mai noi), proiectele de infrastructură încă implică adesea multe sarcini manuale și necesită cunoștințe și expertiză specializate, mai ales având în vedere cerințele actuale de toleranță la erori, flexibilitate, scalabilitate și elasticitate.
Serviciile cloud au îndeplinit aceste cerințe cu mare succes și au fost cei care au dat un impuls semnificativ dezvoltării abordării IaC. Acest lucru este de înțeles. La urma urmei, au făcut posibilă configurarea unui centru de date complet virtual: nu există servere fizice, rafturi sau componente de rețea; întreaga infrastructură poate fi descrisă folosind scripturi și fișiere de configurare.
Deci, care este exact diferența? GitOps din IaC? Cu această întrebare mi-am început investigația. După ce am discutat cu colegii, am reușit să fac următoarea comparație:
GitOps
IaC
Tot codul este stocat într-un depozit git
Versiunea codului este opțională
Cod Declarativ Descriere / Idempotenta
Sunt acceptate atât descrierile declarative, cât și cele imperative
Modificările intră în vigoare utilizând mecanismele Merge Request / Pull Request
Acordul, aprobarea și colaborarea sunt opționale
Procesul de lansare a actualizării este automatizat
Procesul de lansare a actualizării nu este standardizat (automat, manual, copierea fișierelor, utilizarea liniei de comandă etc.)
Cu alte cuvinte GitOps s-a născut tocmai prin aplicarea principiilor IaC. În primul rând, infrastructura și configurațiile ar putea fi acum stocate în același mod ca aplicațiile. Codul este ușor de stocat, ușor de partajat, de comparat și de utilizat capabilitățile de versiune. Versiuni, ramuri, istorie. Și toate acestea într-un loc accesibil public întregii echipe. Prin urmare, utilizarea sistemelor de control al versiunilor a devenit o dezvoltare complet naturală. În special, git, ca fiind cel mai popular.
Pe de altă parte, a devenit posibilă automatizarea proceselor de management al infrastructurii. Acum acest lucru se poate face mai rapid, mai fiabil și mai ieftin. Mai mult decât atât, principiile CI/CD erau deja cunoscute și populare în rândul dezvoltatorilor de software. Era necesar doar transferul și aplicarea cunoștințelor și abilităților deja cunoscute într-un domeniu nou. Aceste practici au depășit însă definiția standard a infrastructurii ca cod, de unde și conceptul GitOps.
Curiozitate GitOps, desigur, și în faptul că nu este un produs, plugin sau platformă asociată vreunui furnizor. Este mai mult o paradigmă și un set de principii, similar unui alt termen cu care suntem familiarizați: DevOps.
Compania am dezvoltat două definiții ale acestui nou termen: teoretică și practică. Să începem cu cele teoretice:
GitOps este o metodologie care preia cele mai bune principii DevOps utilizate pentru dezvoltarea aplicațiilor, cum ar fi controlul versiunilor, colaborarea, orchestrarea, CI/CD și le aplică provocărilor de automatizare a managementului infrastructurii.
Toate procesele GitOps Lucrez folosind instrumentele existente. Tot codul de infrastructură este stocat în depozitul git deja familiar, modificările trec prin același proces de aprobare ca orice alt cod de program, iar procesul de lansare este automat, ceea ce ne permite să minimizăm erorile umane, să creștem fiabilitatea și reproductibilitatea.
Din punct de vedere practic, descriem GitOps după cum urmează:
Am discutat deja despre infrastructură ca cod ca una dintre componentele cheie ale acestei formule. Să-i prezentăm pe restul participanților.
Solicitare de îmbinare (nume alternativ Pull Request). În termeni de proces, MR este o solicitare de a aplica modificări de cod și apoi de a îmbina ramurile. Dar, în ceea ce privește instrumentele pe care le folosim, aceasta este mai degrabă o oportunitate de a obține o imagine completă a tuturor modificărilor efectuate: nu numai diferența de cod colectată de la un anumit număr de comiteri, ci și contextul, rezultatele testelor și rezultatul final așteptat. Dacă vorbim de codul de infrastructură, atunci ne interesează cum exact se va schimba infrastructura, câte resurse noi vor fi adăugate sau eliminate, modificate. De preferință într-un format mai convenabil și ușor de citit. Pentru furnizorii de cloud, este o idee bună să știți care va fi impactul financiar al acestei schimbări.
Dar MR este și un mijloc de colaborare, interacțiune și comunicare. Locul în care intră în joc sistemul de control și echilibru. De la simple comentarii la aprobări și aprobări formale.
Ei bine, ultima componentă: CI/CD, după cum știm deja, face posibilă automatizarea procesului de efectuare a modificărilor și de testare a infrastructurii (de la simpla verificare a sintaxei până la o analiză mai complexă a codului static). Și, de asemenea, în detectarea ulterioară a derivei: diferențe între starea reală și cea dorită a sistemului. De exemplu, ca urmare a unor modificări manuale neautorizate sau a unei defecțiuni a sistemului.
Da, termenul GitOps nu ne introduce în nimic complet nou, nu reinventează roata, ci pur și simplu aplică experiența deja acumulată într-o zonă nouă. Dar aici se află puterea lui.
Și dacă deveniți brusc interesat de cum arată toate acestea în practică, atunci vă invit să vă uitați la noi , în care vă spun pas cu pas cum să utilizați GitLab:
-
Implementați principiile de bază ale GitOps
-
Creați și faceți modificări în infrastructura cloud (folosind exemplul Yandex Cloud)
-
Automatizați detectarea devierii sistemului de la o stare dorită utilizând monitorizarea activă
https://bit.ly/34tRpwZ
Sursa: www.habr.com