Cei mai mulți dintre noi, observând un nou termen în blogosfera IT sau la o conferință, mai devreme sau mai târziu se întreabă: “Ce înseamnă asta? Un cuvânt la modă sau cu adevărat ceva ce merită atenție, studiu și promite noi orizonturi?” Acel lucru mi s-a întâmplat și mie cu termenul GitOps . Învățând dintr-o mulțime de articole existente și folosindu-mă de cunoștințele colegilor din companie , am încercat să înțeleg ce este acest concept și cum poate fi aplicat în practică.
Apropo, despre noutatea termenului GitOps vorbește și un sondaj pe care l-am realizat recent: mai mult de jumătate dintre respondenți nu au început să lucreze cu principiile acestuia.
Așadar, problema gestionării infrastructurii nu este nouă. Numeroși furnizori de servicii cloud sunt disponibili publicului de mai bine de un deceniu și, în aparență, ar fi trebuit să facă munca echipelor responsabile cu infrastructura ușoară și lipsită de complicații. Totuși, comparativ cu procesul de dezvoltare a aplicațiilor (unde nivelul de automatizare atinge noi și noi culmi), proiectele de infrastructură încă includ frecvent multe sarcini efectuate manual și necesită cunoștințe și specialiști specializați, mai ales având în vedere cerințele moderne privind reziliența, flexibilitatea, scalabilitatea și elasticitatea.
Serviciile cloud au îndeplinit cu succes aceste cerințe și anume ele au dat un impuls semnificativ dezvoltării abordării IaC. Este ușor de înțeles. Întrucât ele au oferit posibilitatea de a configura un centru de date complet virtual: fără servere fizice, rack-uri, componente de rețea; întreaga infrastructură poate fi descrisă prin scripturi și fișiere de configurare.
Deci, care este de fapt diferența GitOps de la IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Întregul cod este stocat în repository-ul git
Versionarea codului nu este obligatorie
Descrierea declarativă a codului / Idempotent
Se acceptă atât descrierea declarativă, cât și cea imperativă
Modificările intră în vigoare folosind mecanisme de Merge Request / Pull Request
Aprobarea, confirmarea și colaborarea nu sunt obligatorii
Procesul de implementare a actualizărilor este automatizat
Procesul de implementare a actualizărilor nu este normalizat (automat, manual, copiere de fișiere, utilizând linia de comandă etc.)
Cu alte cuvinte GitOps a apărut în lume datorită aplicării principiilor IaC. În primul rând, infrastructura și configurațiile puteau acum fi stocate exact ca aplicațiile. Codul este ușor de păstrat, de distribuit, de comparat și de utilizat cu caracteristicile versiunii. Versiuni, ramuri, istorie. Și toate acestea într-un spațiu accesibil întregii echipe. De aceea, utilizarea sistemelor de control al versiunilor a fost o dezvoltare logică. În special, git, ca fiind cel mai popular.
Pe de altă parte, a apărut posibilitatea de a automatiza procesele de gestionare a infrastructurii. Acum acest lucru poate fi realizat mai repede, mai sigur și mai ieftin. Cu atât mai mult cu cât principiile CI/CD erau deja cunoscute și populare în rândul dezvoltatorilor de software. Era nevoie doar să transferăm și să aplicăm cunoștințele și abilitățile deja cunoscute în noua cale. Aceste practici, totuși, depășeau definiția standard a Infrastructurii ca text, de unde a apărut termenul GitOps.
Curiozitatea GitOps, desigur, constă și în faptul că acesta nu este un produs, un plugin sau o platformă legată de vreun vendor. Este mai degrabă o paradigmă și un set de principii, similar cu alt termen familiar: DevOps.
În compania am dezvoltat două definiții pentru acest nou termen: teoretică și practică. Să începem cu cea teoretică:
GitOps este o metodologie care utilizează principiile avansate DevOps folosite pentru dezvoltarea aplicațiilor, cum ar fi controlul versiunilor, colaborarea, armonizarea, CI/CD, și le aplică pentru a rezolva sarcini de automatizare a gestionării infrastructurii.
Toate procesele GitOps funcționează utilizând instrumentele deja existente. Tot codul infrastructurii este stocat în deja familiarul repository git, modificările trec prin același proces de armonizare ca orice alt cod software, iar procesul de release este automatizat, ceea ce permite minimizarea erorilor umane, sporind fiabilitatea și reproducibilitatea.
Din punct de vedere practic, descriem GitOps în următorul mod:
Infrastructura ca text am discutat deja ca una dintre componentele cheie ale acestei formule. Să-i imaginăm pe ceilalți participanți.
Cererea de fuziune (denumire alternativă pentru Pull Request). În cadrul procesului MR, aceasta este o solicitare de aplicare a modificărilor de cod și fuziunea ulterioară a ramurilor. Dar în ceea ce privește instrumentele pe care le folosim, aceasta este mai degrabă o oportunitate de a obține o imagine de ansamblu a tuturor modificărilor efectuate: nu doar un dif de cod reunit dintr-un număr oarecare de commit-uri, ci și contextul, rezultatele testelor și rezultatul final așteptat. Dacă vorbim despre codul de infrastructură, ne interesează cum va schimba cu adevărat infrastructura, câte resurse noi vor fi adăugate sau eliminate, modificate. Ar fi de preferat într-un format mai convenabil și ușor de citit. În cazul furnizorilor de cloud, ar fi bine să știm ce consecințe financiare va avea aceste modificări.
Dar MR este, de asemenea, un instrument de colaborare, interacțiune și comunicare. Acel loc unde intră în acțiune sistemul de reechilibrare. De la comentarii simple până la aprobări și formalizări.
Și ultima componentă: CI/CD, așa cum știm deja, oferă posibilitatea de a automatiza procesul de modificare a infrastructurii, testarea (de la verificarea simplă a sintaxei până la analizele statice mai complexe ale codului). De asemenea, în continuare, identificarea derapajului: diferențele dintre starea reală și cea dorită a sistemului. De exemplu, în urma modificărilor manuale neautorizate sau a defecțiunilor sistemului.
Da, termenul GitOps nu ne introduce în nimic absolut nou, nu reinventează roata, ci pur și simplu aplică experiența acumulată în domenii noi. Dar acesta este tocmai puterea sa.
Și dacă, dintr-o dată, veți fi interesați să vedeți cum arată totul în practică, vă invit să vizionați , în care explic pas cu pas cum, cu ajutorul GitLab:
Să implementăm principiile de bază ale GitOps
Să creăm și să facem modificări în infrastructura cloud (pe exemplul Yandex Cloud)
Să automatizăm detectarea derapajului sistemului de la starea dorită cu ajutorul monitorizării active
https://bit.ly/34tRpwZ
Sursa: habr.com
