🥇Ce este GitOps?

Nota traducătorului.: După publicarea recentă material despre metodele pull și push în GitOps, am observat un interes în această model în general, însă publicațiile în limba română pe acest subiect sunt foarte puține (pe Habr nu există practic deloc). Prin urmare, suntem bucuroși să vă oferim un traducere a unui alt articol — deși este aproape de un an! — de la compania Weaveworks, al cărei fondator a inventat termenul „GitOps”. În text se explică esența abordării și diferențele cheie față de cele existente.

Acum un an am publicat o introducere în GitOps. Atunci am povestit cum echipa Weaveworks a lansat un SaaS, complet bazat pe Kubernetes, și a dezvoltat un set de bune practici descriptive pentru implementare, gestionare și monitorizare în medii cloud native.

Articolul a fost popular. Alți oameni au început să discute despre GitOps, au început să publice noi instrumente pentru git push, dezvoltare, secrete, funcții, integrării continue etc. Pe site-ul nostru au apărut o mulțime de publicații și cazuri de utilizare a GitOps. Dar pentru unii oameni au rămas întrebări. Cu ce se diferențiază modelul de tradiționalul infrastructure as code și livrarea continuă (continuous delivery)? Este necesar să folosești Kubernetes?

În curând ne-am dat seama că este nevoie de o nouă descriere, care oferă:

O mulțime de exemple și povești;
O definiție clară a GitOps;
O comparație cu livrarea continuă tradițională.

În acest articol, am încercat să acoperim toate aceste subiecte. Aici veți găsi o introducere actualizată în GitOps și o perspectivă asupra acestuia din partea dezvoltatorilor și CI/CD. Ne concentrăm în principal pe Kubernetes, deși modelul poate fi generalizat.

Întâlniți: GitOps

Imaginați-vă-o pe Alice. Ea conduce compania Family Insurance, care oferă polițe de asigurare pentru sănătate, mașini, imobiliare și asigurare de călătorie persoanelor care sunt prea ocupate pentru a înțelege nuanțele contractelor pe cont propriu. Afacerea ei a început ca un proiect secundar, când Alice lucra în bancă ca data scientist. Într-o zi a realizat că poate utiliza algoritmi computaționali avansați pentru a analiza datele mai eficient și a crea pachete de asigurare. Investitorii au finanțat proiectul, iar acum compania ei generează peste 20 milioane de dolari pe an și crește rapid. În prezent, lucrează 180 de persoane în diverse funcții. Printre acestea se află o echipă tehnologică care se ocupă cu dezvoltarea, întreținerea site-ului, a bazei de date și analiza bazei de clienți. Echipă de 60 de persoane este condusă de Bob — directorul tehnic al companiei.

Echipa lui Bob desfășoară sisteme de producție în cloud. Aplicațiile lor principale funcționează pe GKE, beneficiind de avantajele Kubernetes în Google Cloud. De asemenea, ei utilizează diverse instrumente pentru gestionarea datelor și analitice.

Family Insurance nu plănuia să folosească containere, dar s-a molipsit de entuziasmul din jurul Docker. Curând, specialiștii companiei au descoperit că GKE permite desfășurarea clusterelor pentru testarea de noi funcții rapid și fără dificultăți. Au fost adăugate Jenkins pentru CI și Quay pentru organizarea unui registru de containere, au fost scrise scripturi pentru Jenkins, care împingeau noi containere și configurații în GKE.

A trecut ceva timp. Alice și Bob s-au dezamăgit de performanța abordării alese și de impactul acesteia asupra afacerii. Implementarea containerelor nu a crescut performanța atât de mult cât și-ar fi dorit echipa. Uneori, desfășurările se strică și nu era clar dacă modificările de cod sunt de vină. De asemenea, a fost dificil să se urmărească modificările configurațiilor. Adesea, a fost necesar să se creeze un nou cluster și să se mute aplicațiile în el, deoarece așa era cel mai simplu să se elimine haosul în care ajunsese sistemul. Alice se temea că situația se va agrava pe măsură ce aplicația se dezvoltă (în plus, un nou proiect bazat pe învățarea automată era pe cale să înceapă). Bob a automatizat o mare parte din muncă și nu înțelegea de ce pipeline-ul este în continuare instabil, se scalabează prost și necesită ocazional intervenție manuală.

Apoi, au aflat despre GitOps. Această soluție s-a dovedit a fi exact ceea ce aveau nevoie pentru a avansa cu încredere.

Alice și Bob au auzit de ani de zile despre fluxurile de lucru bazate pe Git, DevOps și infrastructure as code. Unicitatea GitOps constă în faptul că aduce o serie de bune practici — categorice și normative — pentru implementarea acestor idei în contextul Kubernetes. Acest subiect a fost ridicat de mai multe ori, inclusiv în blogul Weaveworks.

Family Insurance decide să implementeze GitOps. Acum, compania are un model de operare automatizat, compatibil cu Kubernetes și care îmbină viteza cu stabilitatea, deoarece ei:

au descoperit că echipa și-a dublat productivitatea și nimeni nu își pierde mințile;
au încetat să mai întrețină scripturile. În loc de asta, acum se pot concentra pe noi funcționalități și să îmbunătățească metodele de inginerie — de exemplu, prin implementarea de rollout-uri canar și îmbunătățirea testării;
au perfecționat procesul de desfășurare — acum rareori se strică;
au obținut posibilitatea de a recupera desfășurările după eșecuri parțiale fără intervenție manuală;
au câștigat omaremai mare încredere în sistemele de livrare. Alice și Bob au descoperit că pot împărți echipa în grupuri care se ocupă cu microserviciile și lucrează simultan;
pot face între 30-50 de modificări în proiect în fiecare zi prin eforturile fiecărui grup și pot încerca noi tehnici;
atrage ușor dezvoltatori noi în proiect, care au posibilitatea de a aplica actualizări în producție prin pull request-uri în câteva ore;
trece ușor auditul în cadrul SOC2 (pentru conformitatea furnizorilor de servicii cu cerințele de gestionare sigură a datelor; citiți în continuare, de exemplu, aici — nota trad.).

Ce s-a întâmplat?

GitOps este două lucruri:

Un model de operare pentru Kubernetes și cloud native. Oferă un set de bune practici pentru desfășurarea, gestionarea și monitorizarea clusterelor și aplicațiilor adunate în containere. O definiție elegantă sub forma unui singur slide de la Luis Faceira:
Calea către crearea unui mediu orientat pe dezvoltatori pentru gestionarea aplicațiilor. Aplicăm fluxul de lucru Git atât pentru operare, cât și pentru dezvoltare. Rețineți că nu este vorba doar despre Git push, ci despre organizarea întregului set de unelte CI/CD și UI/UX.

Câteva cuvinte despre Git

Dacă nu sunteți familiarizat cu sistemele de control al versiunilor și fluxul de lucru bazat pe Git, vă recomandăm cu căldură să le studiați. La început, lucrul cu ramuri și pull request-uri poate părea magie neagră, dar avantajele merită efortul. Iată un articol bun pentru început.

Cum funcționează Kubernetes

În povestea noastră, Alice și Bob s-au îndreptat spre GitOps, după ce au lucrat ceva timp cu Kubernetes. De fapt, GitOps este strâns legat de Kubernetes — este un model de operare pentru infrastructura și aplicațiile bazate pe Kubernetes.

Ce oferă Kubernetes utilizatorilor?

Iată câteva dintre principalele sale capabilități:

În modelul Kubernetes, totul poate fi descris într-o formă declarativă.
API-serverul Kubernetes acceptă o astfel de declarație ca date de intrare și apoi încearcă constant să aducă cluster-ul în starea descrisă în declarație.
Declarațiile sunt suficiente pentru a descrie și gestiona o mare varietate de sarcini de lucru — „aplicații”.
Ca rezultat, modificările aplicației și clusterele au loc din cauza:
- modificărilor din imaginile containerelor;
- modificărilor din specificația declarativă;
- eroare în mediu — de exemplu, prăbușiri de containere.

Capacitățile extraordinare ale Kubernetes de convergență

Când un administrator face modificări în configurație, orchestratorul Kubernetes va aplica aceste modificări în cluster până când starea sa se va apropia de noua configurație.. Acest model funcționează pentru orice resursă Kubernetes și se extinde prin intermediul Custom Resource Definitions (CRDs). Prin urmare, deployment-urile Kubernetes au următoarele proprietăți extraordinare:

Automatizarea: actualizările Kubernetes oferă un mecanism pentru automatizarea procesului de aplicare a modificărilor în mod corect și la timp.
Convergența: Kubernetes va continua să încerce actualizările până la atingerea succesului.
Idempotentă: aplicările repetate ale convergenței duc la același rezultat.
Determinism: în cazul suficienței resurselor, starea clusterului actualizat depinde doar de starea dorită.

Cum funcționează GitOps

Am învățat suficient despre Kubernetes pentru a explica principiile de funcționare ale GitOps.

Să ne întoarcem la echipele Family Insurance, legate de microservicii. Ce trebuie să facă de obicei? Uitați-vă la lista de mai jos (dacă unele elemente vi se par ciudate sau necunoscute — vă rugăm să nu critici și să rămâneți cu noi). Acestea sunt doar exemple de fluxuri de lucru bazate pe Jenkins. Există, de asemenea, multe alte procese folosind alte instrumente.

Ceea ce este important — vedem că fiecare actualizare se finalizează prin modificări în fișierele de configurare și în repositoarele Git. Aceste modificări din Git determină „operatorul GitOps” să actualizeze clusterul:

1. Flux de lucru: „Construire Jenkins — ramura master».
Lista de sarcini:

Jenkins trimite imagini etichetate în Quay;
Jenkins trimite configurarea și graficele Helm în bucket-ul stocării master;
O funcție cloud copiază configurarea și graficele din bucket-ul stocării master în repository-ul Git master;
Operatorul GitOps actualizează clusterul.

2. Construire Jenkins — ramura release sau hotfix:

Jenkins trimite imagini netichetate în Quay;
Jenkins trimite configurarea și graficele Helm în bucket-ul stocării staging;
O funcție cloud copiază configurarea și graficele din bucket-ul stocării staging în repository-ul Git staging;
Operatorul GitOps actualizează clusterul.

3. Construire Jenkins — ramura develop sau feature:

Jenkins trimite imagini netichetate în Quay;
Jenkins trimite configurarea și graficele Helm în bucket-ul stocării develop;
O funcție cloud copiază configurarea și graficele din bucket-ul stocării develop în repository-ul Git develop;
Operatorul GitOps actualizează clusterul.

4. Adăugarea unui nou client:

Managerul sau administratorul (LCM/ops) apelează Gradle pentru desfășurarea inițială și configurarea echilibratoarelor de sarcină (NLB);
LCM/ops comite noua configurație pentru a pregăti deployment-ul pentru actualizări;
Operatorul GitOps actualizează clusterul.

Prezentare generală a GitOps

Descrie starea dorită a întregului sistem, folosind specificații declarative pentru fiecare mediu (în povestea noastră, echipa lui Bob definește întreaga configurație a sistemului în Git).
- Depozitul Git este sursa unică de adevăr în ceea ce privește starea dorită a întregului sistem.
- Toate modificările în starea dorită se fac prin comituri în Git.
- Toate parametrii doriti ai clusterului sunt de asemenea observați în cadrul clusterului. Astfel, putem determina dacă acestea coincid (converge, converge) sau diferă (diverge, diverge) starea dorită și cea observată.
Dacă starea dorită și cea observată diferă, atunci:
- Există un mecanism de convergență care, mai devreme sau mai târziu, va sincroniza automat stările țintă și cele observate. În cadrul clusterului, acest lucru este gestionat de Kubernetes.
- Procesul pornește imediat cu notificarea „schimbare comisă”.
- După o anumită perioadă configurabilă, poate fi trimisă o notificare „diff”, dacă stările diferă.
Astfel, toate comituri din Git generează actualizări verificabile și idempotente în cluster.
- Rollback-ul este o convergență către o stare dorită anterioară.
Convergența este finală. Indiciile pentru existența sa sunt:
- Lipsa notificărilor „diff” pentru o anumită perioadă de timp.
- Notificarea „converged” (de exemplu, webhook, eveniment Git writeback).

Ce este divergența?

Să repetăm încă o dată: toate proprietățile dorite ale clusterului trebuie să fie observabile în cadrul clusterului.

Câteva exemple de divergență:

Modificarea din fișierul de configurare din cauza unui merge de ramuri în Git.
Modificarea din fișierul de configurare din cauza unui commit în Git, efectuat de un client GUI.
Modificări multiple în starea dorită din cauza unui PR în Git urmat de construirea unei imagini de container și schimbări în configurație.
Modificarea stării clusterului din cauza unei erori, conflict de resurse, care duce la „comportament defectuos”, sau pur și simplu o deviere accidentală de la starea originală.

Ce reprezintă mecanismul de convergență?

Câteva exemple:

Pentru containere și clustere, mecanismul de convergență este furnizat de Kubernetes.
Același mecanism poate fi utilizat pentru gestionarea aplicațiilor și structurilor bazate pe Kubernetes (de exemplu, Istio și Kubeflow).
Mecanismul de gestionare a interacțiunii de lucru între Kubernetes, repositoarele de imagini și Git oferă Operatorul GitOps Weave Flux, care face parte din Weave Cloud.
Pentru mașinile de bază, mecanismul de convergență trebuie să fie declarațiv și autonom. Din experiența noastră, putem spune că Terraform se apropie cel mai mult de această definiție, dar necesită totuși control din partea omului. În acest sens, GitOps extinde tradițiile Infrastructure as Code.

GitOps combină Git cu un mecanism excelent de convergență Kubernetes, oferind un model pentru exploatare.

GitOps ne permite să afirmăm: automatisarea și controlul se aplică doar sistemelor care pot fi descrise și observate.

GitOps este destinat întregului stack cloud native (de exemplu, Terraform etc.)

GitOps nu este doar Kubernetes. Vrem ca întregul sistem să fie gestionat declarați și să folosească convergența. Prin întregul sistem ne referim la ansamblul mediilor care lucrează cu Kubernetes - de exemplu, «dev cluster 1», «production» etc. Fiecare mediu include mașini, clustere, aplicații, precum și interfețe pentru servicii externe care furnizează date, monitorizare etc.

Observați cât de important este Terraform în această problemă de bootstrapping. Kubernetes trebuie să fie desfășurat undeva, iar utilizarea Terraform înseamnă că putem aplica aceleași fluxuri de lucru GitOps pentru a crea un strat de control care se află la baza Kubernetes și aplicațiilor. Aceasta este o bună practică.

Se acordă o mare atenție aplicării conceptelor GitOps la straturile deasupra Kubernetes. Până în prezent, există soluții de tip GitOps pentru Istio, Helm, Ksonnet, OpenFaaS și Kubeflow, precum și, de exemplu, pentru Pulumi, care creează un strat pentru dezvoltarea aplicațiilor cloud native.

Kubernetes CI/CD: compararea GitOps cu alte abordări

Așa cum s-a spus, GitOps reprezintă două lucruri:

Un model de exploatare pentru Kubernetes și cloud native, descris mai sus.
Calea către organizarea unei medii orientate pe dezvoltatori pentru gestionarea aplicațiilor.

Pentru mulți, GitOps este înainte de toate un flux de lucru bazat pe Git pushes. Ne place și nouă. Dar nu este totul: acum să ne uităm la pipeline-urile CI/CD.

GitOps asigură desfășurarea continuă (CD) sub Kubernetes

GitOps oferă un mecanism de desfășurare continuă, eliminând necesitatea unor «sisteme de management al desfășurărilor» separate. Toată munca este realizată de Kubernetes.

Actualizarea aplicației necesită o actualizare în Git. Aceasta este o actualizare tranzacțională către starea dorită. "Dezvoltarea" este apoi realizată în cadrul clusterului de către Kubernetes pe baza descrierii actualizate.
Din cauza specificului funcționării Kubernetes, aceste actualizări sunt convergente. Aceasta asigură un mecanism pentru implementarea continuă, în care toate actualizările sunt atomice.
Notă: Weave Cloud oferă un operator GitOps care integrează Git și Kubernetes și permite realizarea CD prin alinierea stării dorite și a stării curente a clusterului.

Fără kubectl și scripturi

Este recomandat să evitați utilizarea Kubectl pentru actualizarea clusterului, în special a scripturilor pentru gruparea comenzilor kubectl. În schimb, prin intermediul unui pipeline GitOps, utilizatorul poate actualiza clusterul Kubernetes prin Git.

Avantajele includ:

Corectitudinea. O grupă de actualizări poate fi aplicată, convergența, și în cele din urmă validată, ceea ce ne apropie de obiectivul unei implementări atomice. Spre deosebire de aceasta, utilizarea scripturilor nu oferă nicio garanție de convergență (mai multe despre acest subiect mai jos).
Securitate. Citat din Kelsey Hightower: "Limitați accesul la clusterul Kubernetes instrumentelor de automatizare și administratorilor care sunt responsabili de depanarea sau menținerea acestuia în funcțiune". Vezi de asemenea publicația mea despre securitate și conformitatea cu cerințele tehnice, precum și articolul despre hack-ul Homebrew prin furtul acreditivelor dintr-un script Jenkins neglijent.
Experiența utilizatorului. Kubectl expune mecanica modelului obiectual Kubernetes, care este destul de complex. În ideal, utilizatorii ar trebui să interacționeze cu sistemul la un nivel de abstracție mai înalt. Aici mă voi referi din nou la Kelsey și recomand să vizionați un astfel de rezumat.

Diferența între CI și CD

GitOps îmbunătățește modelele CI/CD existente.

Un server CI modern este un instrument pentru orchestrare. În special, acesta este un instrument pentru orchestrarea pipeline-urilor CI. Acestea includ build, testare, unirea în trunk etc. Serverele CI automatizează gestionarea pipeline-urilor complexe în mai mulți pași. O tentație frecventă este de a crea un script pentru un set de actualizări Kubernetes și de a-l rula ca un element al pipeline-ului pentru a împinge modificările în cluster. Cu adevărat, mulți specialiști procedează astfel. Cu toate acestea, aceasta nu este optimă, și iată de ce.

CI ar trebui să fie folosit pentru a aduce actualizări în trunk, iar clusterul Kubernetes ar trebui să se schimbe pe baza acestor actualizări, pentru a gestiona CD „în mod intern”. Numim acest lucru un model pull pentru CD, spre deosebire de modelul push de CI. CD este parte din orchestrarea runtime.

De ce serverele CI nu ar trebui să facă CD prin actualizări directe în Kubernetes

Nu folosiți serverul CI pentru orchestrarea actualizărilor directe în Kubernetes sub forma unui set de sarcini CI. Acesta este un anti-model despre care noi a povestit deja vorbim în blogul nostru.

Să ne întoarcem la Alice și Bob.

Ce probleme au întâmpinat? Serverul CI al lui Bob aplică modificările în cluster, dar dacă în proces acesta se prăbușește, Bob nu va ști în ce stare se află (sau ar trebui să fie) clusterul și cum să-l repare. Aceeași situație se aplică și în caz de succes.

Să presupunem că echipa lui Bob a construit o nouă imagine și apoi a aplicat patch-uri la deployment-urile lor pentru a desfășura imaginea (toate acestea din pipeline-ul CI).

Dacă imaginea se construiește corect, dar pipeline-ul se prăbușește, echipa va trebui să afle:

S-a desfășurat actualizarea?
Desfășurăm o nouă construcție? Va provoca aceasta efecte secundare nedorite — având posibilitatea de a obține două construcții ale aceleași imagini nemodificate?
Ar trebui să așteptăm următoarea actualizare înainte de a desfășura construcția?
Ce anume a mers prost? Ce pași trebuie să repetăm (și care dintre aceștia pot fi repetați în siguranță)?

Organizarea unui flux de lucru bazat pe Git nu garantează că echipa lui Bob nu se va confrunta cu aceste probleme. Aceștia pot să greșească în continuare cu push-ul unui commit, cu un tag sau cu orice alt parametru; totuși, această abordare este mult mai apropiată de un model expres de tot sau nimic.

în concluzie, iată de ce serverele CI nu ar trebui să se ocupe de CD:

Scripturile de actualizare nu sunt întotdeauna deterministe; este ușor să faci greșeli în ele.
Serverele CI nu converg către un model declarațional de cluster.
Este greu de garantat idempotentitatea. Utilizatorii trebuie să înțeleagă semantica profundă a sistemului.
Este mai greu să recuperezi după o eroare parțială.

Notă despre Helm: dacă doriți să folosiți Helm, vă recomandăm să-l combinați cu un operator GitOps, cum ar fi Flux-Helm. Acest lucru va ajuta la asigurarea convergenței. Helm, de sine stătător, nu este nici determinist, nici atomic.

GitOps ca cea mai bună metodă de a realiza Continuous Delivery pentru Kubernetes

Echipa lui Alice și Bob implementează GitOps și descoperă că este mult mai ușor să lucreze cu produsele software, menținând o performanță și stabilitate ridicate. Să încheiem acest articol cu ilustrații care arată cum arată noul lor abordare. Rețineți că vorbim în principal despre aplicații și servicii, însă GitOps poate fi folosit pentru a gestiona întreaga platformă.

Modelul de operare pentru Kubernetes

Uitați-vă la următoarea diagramă. Aceasta reprezintă Git și depozitul de imagini ale containerelor ca resurse comune pentru cele două cicluri de viață orchestrate:

Pipeline-ul de integrare continuă, care citește și scrie fișiere în Git și poate actualiza depozitul imaginilor containerelor.
Pipeline-ul Runtime GitOps, care combină desfășurarea cu gestionarea și observabilitatea. Acesta citește și scrie fișiere în Git și poate încărca imagini ale containerelor.

Care sunt principalele concluzii?

Separarea problemelor: Rețineți că ambele pipeline-uri pot face schimb de date, actualizând doar Git sau depozitul imaginilor. Cu alte cuvinte, există un firewall între CI și mediu de runtime. Îl numim „firewall-ul imutabilității” (immutability firewall), deoarece toate actualizările depozitelor creează versiuni noi. Pentru informații suplimentare cu privire la acest subiect, consultați slide-urile 72-87 această prezentare.
Orice server CI și Git poate fi folosit: GitOps funcționează cu orice componente. Puteți continua să folosiți serverele și depozitele de Git preferate, imagini ale containerelor și seturi de teste. Aproape toate celelalte instrumente pentru Continuous Delivery de pe piață necesită propriul server CI/Git sau depozit de imagini. Acest lucru poate deveni un factor limitativ în dezvoltarea cloud native. În cazul GitOps, puteți folosi instrumentele cunoscute.
Evenimentele ca instrument de integrare: De îndată ce datele din Git sunt actualizate, Weave Flux (sau operatorul Weave Cloud) notifică despre aceasta runtime-ul. De fiecare dată când Kubernetes primește un set de modificări, Git este actualizat. Acest lucru asigură un model simplu de integrare pentru organizarea fluxurilor de lucru pentru GitOps, așa cum se arată mai jos.

Concluzie

GitOps oferă garanții semnificative de actualizare necesare oricărui instrument modern de CI/CD:

automatul;
convergență;
idempotentă;
determinism.

Este important, deoarece oferă un model de operare pentru dezvoltatori în domeniul cloud native.

Instrumentele tradiționale pentru gestionarea și monitorizarea sistemelor sunt asociate cu echipele de operare care acționează în cadrul runbook-ului (set de proceduri și operațiuni de rutină - n.red.), legat de un deployment specific.
În managementul sistemelor cloud native, instrumentele de observare reprezintă cea mai bună modalitate de a evalua rezultatele desfășurărilor, astfel încât echipa de dezvoltare să poată reacționa rapid la acestea.

Imaginați-vă numeroase clustere răspândite în diferite cloud-uri și o mulțime de servicii cu propriile echipe și planuri de desfășurare. GitOps oferă un model invariant și la scară pentru a gestiona toată această abundență.