Notă. transl.: După o publicare recentă despre metodele pull și push în GitOps, am văzut interes pentru acest model în general, dar au existat foarte puține publicații în limba rusă pe această temă (pur și simplu nu există nici una pe Habré). Prin urmare, suntem încântați să vă oferim atenției o traducere a unui alt articol - deși acum aproape un an! — de la Weaveworks, al cărei cap a inventat termenul „GitOps”. Textul explică esența abordării și diferențele cheie față de cele existente.
Acum un an am publicat . Pe atunci, am împărtășit cum echipa Weaveworks a lansat un SaaS bazat în întregime pe Kubernetes și a dezvoltat un set de bune practici prescriptive pentru implementarea, gestionarea și monitorizarea într-un mediu nativ cloud.
Articolul s-a dovedit a fi popular. Alți oameni au început să vorbească despre GitOps și au început să publice noi instrumente pentru , , , , și așa mai departe. A apărut pe site-ul nostru publicații și cazuri de utilizare GitOps. Dar unii oameni mai au întrebări. Cum diferă modelul de cel tradițional? și livrare continuă ()? Este necesar să utilizați Kubernetes?
Curând ne-am dat seama că era nevoie de o nouă descriere, care să ofere:
- Un număr mare de exemple și povești;
- Definiție specifică GitOps;
- Comparație cu livrarea continuă tradițională.
În acest articol am încercat să acoperim toate aceste subiecte. Oferă o introducere actualizată la GitOps și o perspectivă pentru dezvoltatori și CI/CD. Ne concentrăm în primul rând pe Kubernetes, deși modelul poate fi generalizat.
Faceți cunoștință cu GitOps
Imaginează-ți Alice. Ea conduce asigurări de familie, care oferă asigurări de sănătate, auto, casă și de călătorie persoanelor care sunt prea ocupate pentru a-și da seama de dezavantajele contractelor. Afacerea ei a început ca un proiect secundar când Alice lucra la o bancă ca cercetător în domeniul datelor. Într-o zi și-a dat seama că ar putea folosi algoritmi avansati de computer pentru a analiza mai eficient datele și a formula pachete de asigurare. Investitorii au finanțat proiectul, iar acum compania ei aduce peste 20 de milioane de dolari pe an și crește rapid. În prezent, are 180 de angajați în diverse posturi. Aceasta include o echipă de tehnologie care dezvoltă, întreține site-ul web, baza de date și analizează baza de clienți. Echipa de 60 de oameni este condusă de Bob, directorul tehnic al companiei.
Echipa lui Bob implementează sisteme de producție în cloud. Aplicațiile lor de bază rulează pe GKE, profitând de Kubernetes pe Google Cloud. În plus, folosesc diverse instrumente de date și analize în munca lor.
Asigurările de Familie nu și-a propus să folosească containere, dar a fost prinsă de entuziasmul Docker. Compania a descoperit curând că GKE a facilitat implementarea clusterelor pentru a testa funcții noi. Jenkins pentru CI și Quay au fost adăugate pentru a organiza registrul containerelor, au fost scrise scripturi pentru Jenkins care au trimis containere și configurații noi la GKE.
A trecut ceva timp. Alice și Bob au fost dezamăgiți de performanța abordării alese și de impactul acesteia asupra afacerii. Introducerea containerelor nu a îmbunătățit productivitatea atât de mult pe cât sperase echipa. Uneori, implementările se întrerupeau și nu era clar dacă modificările codului erau de vină. De asemenea, sa dovedit a fi dificil de urmărit modificările de configurare. Adesea a fost necesar să se creeze un nou cluster și să se mute aplicațiile în el, deoarece aceasta era cea mai ușoară modalitate de a elimina mizeria pe care o devenise sistemul. Alice se temea că situația se va înrăutăți pe măsură ce aplicația se dezvolta (în plus, se prepara un nou proiect bazat pe machine learning). Bob automatizase cea mai mare parte a lucrării și nu înțelegea de ce conducta era încă instabilă, nu se scala bine și necesita intervenția manuală periodic?
Apoi au aflat despre GitOps. Această decizie s-a dovedit a fi exact ceea ce aveau nevoie pentru a merge mai departe cu încredere.
Alice și Bob aud de ani de zile despre Git, DevOps și infrastructură ca fluxuri de lucru de cod. Ceea ce este unic la GitOps este că aduce un set de bune practici – atât definitive, cât și normative – pentru implementarea acestor idei în contextul Kubernetes. Această temă , inclusiv în .
Asigurările de familie decide să implementeze GitOps. Compania are acum un model de operare automatizată compatibil cu Kubernetes și combine viteză cu stabilitatepentru că ei:
- a constatat că productivitatea echipei s-a dublat fără ca nimeni să înnebunească;
- a încetat să mai difuzeze scripturi. În schimb, se pot concentra acum pe noi caracteristici și se pot îmbunătăți metodele de inginerie - de exemplu, introducerea lansărilor Canary și îmbunătățirea testării;
- am îmbunătățit procesul de implementare, astfel încât rareori se defectează;
- a avut ocazia de a restabili implementările după defecțiuni parțiale fără intervenție manuală;
- cumparat folositоÎncredere mai mare în sistemele de livrare. Alice și Bob au descoperit că ar putea împărți echipa în echipe de microservicii care lucrează în paralel;
- poate face 30-50 de modificări în proiect în fiecare zi prin eforturile fiecărui grup și poate încerca noi tehnici;
- este ușor să atragi noi dezvoltatori către proiect, care au posibilitatea de a lansa actualizări în producție folosind solicitări de extragere în câteva ore;
- trece cu ușurință auditul în cadrul SOC2 (pentru conformitatea furnizorilor de servicii cu cerințele pentru gestionarea securizată a datelor; citiți mai multe, de exemplu, - aprox. traducere).
Ce s-a întâmplat?
GitOps este două lucruri:
- Model operațional pentru Kubernetes și cloud nativ. Acesta oferă un set de bune practici pentru implementarea, gestionarea și monitorizarea clusterelor și aplicațiilor containerizate. Definiție elegantă în formă din :
- Calea către crearea unui mediu de gestionare a aplicațiilor centrat pe dezvoltator. Aplicăm fluxul de lucru Git atât la operațiuni, cât și la dezvoltare. Vă rugăm să rețineți că nu este vorba doar despre Git push, ci despre organizarea întregului set de instrumente 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 să aflați despre acestea. Lucrul cu ramuri și solicitări de tragere poate părea magie neagră la început, dar beneficiile merită efortul. Aici a începe.
Cum funcționează Kubernetes
În povestea noastră, Alice și Bob au apelat la GitOps după ce au lucrat o perioadă cu Kubernetes. Într-adevăr, GitOps este strâns legat de Kubernetes - este un model operațional pentru infrastructură și aplicații bazate pe Kubernetes.
Ce oferă Kubernetes utilizatorilor?
Iată câteva caracteristici principale:
- În modelul Kubernetes, totul poate fi descris în formă declarativă.
- Serverul API Kubernetes ia această declarație ca intrare și apoi încearcă continuu să aducă clusterul î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 urmare, modificările aplicației și ale clusterului apar din cauza:
- modificări ale imaginilor containerului;
- modificări ale specificației declarative;
- erori în mediu - de exemplu, blocarea containerelor.
Marile capacități de convergență ale Kubernetes
Când un administrator face modificări de configurare, orchestratorul Kubernetes le va aplica clusterului atâta timp cât starea acestuia este nu se va apropia de noua configurație. Acest model funcționează pentru orice resursă Kubernetes și este extensibil cu definiții personalizate de resurse (CRD). Prin urmare, implementările Kubernetes au următoarele proprietăți minunate:
- Automatizare: Actualizările Kubernetes oferă un mecanism de automatizare a procesului de aplicare a modificărilor cu grație și în timp util.
- Convergenţă: Kubernetes va continua să încerce actualizări până la succes.
- Idempotenta: Aplicațiile repetate de convergență duc la același rezultat.
- Determinism: Când resursele sunt suficiente, starea clusterului actualizat depinde doar de starea dorită.
Cum funcționează GitOps
Am aflat destule despre Kubernetes pentru a explica cum funcționează GitOps.
Să revenim la echipele de microservicii ale Asigurărilor de Familie. Ce trebuie să facă de obicei? Uitați-vă la lista de mai jos (dacă vreun element din ea vi se pare ciudat sau necunoscut, vă rugăm să nu mai criticați și să rămâneți cu noi). Acestea sunt doar exemple de fluxuri de lucru bazate pe Jenkins. Există multe alte procese atunci când lucrați cu alte instrumente.
Principalul lucru este că vedem că fiecare actualizare se termină cu modificări ale fișierelor de configurare și ale depozitelor Git. Aceste modificări la Git fac ca „operatorul GitOps” să actualizeze cluster-ul:
1. Procesul de lucru: "Construcția Jenkins - ramură principală".
Lista de sarcini:
- Jenkins împinge imaginile etichetate în Quay;
- Jenkins împinge diagramele de configurare și Helm în compartimentul de stocare principal;
- Funcția cloud copiează configurația și diagramele din găleata de stocare principală în depozitul Git principal;
- Operatorul GitOps actualizează clusterul.
2. Jenkins build - lansare sau ramură de remediere rapidă:
- Jenkins împinge imagini neetichetate către Quay;
- Jenkins împinge diagramele de configurare și Helm în compartimentul de stocare;
- Funcția de cloud copiează configurația și diagramele din compartimentul de stocare în staging în depozitul Git;
- Operatorul GitOps actualizează clusterul.
3. Jenkins build - dezvoltă sau caracteristică ramură:
- Jenkins împinge imagini neetichetate către Quay;
- Jenkins împinge diagramele de configurare și Helm în compartimentul de stocare de dezvoltare;
- Funcția cloud copiează configurația și diagramele din compartimentul de stocare de dezvoltare în depozitul Git de dezvoltare;
- Operatorul GitOps actualizează clusterul.
4. Adăugarea unui nou client:
- Managerul sau administratorul (LCM/ops) îl cheamă pe Gradle pentru a implementa și configura inițial dispozitivele de echilibrare a sarcinii de rețea (NLB);
- LCM/ops comite o nouă configurație pentru a pregăti implementarea pentru actualizări;
- Operatorul GitOps actualizează clusterul.
Scurtă descriere a GitOps
- Descrieți 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 singura sursă de adevăr cu privire la starea dorită a întregului sistem.
- Toate modificările la starea dorită sunt făcute prin comitări în Git.
- Toți parametrii de cluster doriti sunt, de asemenea, observabili în clusterul însuși. În acest fel putem determina dacă acestea coincid (converg, converg) sau diferă (diverge, divergent) stări dorite și observate.
- Dacă stările dorite și cele observate diferă, atunci:
- Există un mecanism de convergență care, mai devreme sau mai târziu, sincronizează automat stările țintă și observate. În interiorul clusterului, Kubernetes face acest lucru.
- Procesul începe imediat cu o alertă „schimbare comisă”.
- După o perioadă de timp configurabilă, poate fi trimisă o alertă „diferă” dacă stările sunt diferite.
- În acest fel, toate comiterile din Git provoacă actualizări verificabile și idempotente ale clusterului.
- Rollback este convergența către o stare dorită anterior.
- Convergența este definitivă. Apariția sa este indicată de:
- Fără alerte de diferență pentru o anumită perioadă de timp.
- alertă „convergentă” (de exemplu, webhook, eveniment Git writeback).
Ce este divergența?
Să o repetăm din nou: toate proprietățile clusterului dorite trebuie să fie observabile în clusterul însuși.
Câteva exemple de divergență:
- Modificare în fișierul de configurare din cauza îmbinării ramurilor în Git.
- O modificare a fișierului de configurare din cauza unui commit Git făcut de clientul GUI.
- Modificări multiple la starea dorită datorită PR în Git, urmate de construirea imaginii containerului și modificări de configurare.
- O modificare a stării clusterului din cauza unei erori, a unui conflict de resurse care are ca rezultat „comportament prost” sau pur și simplu abateri aleatorii de la starea inițială.
Care este mecanismul de convergență?
Câteva exemple:
- Pentru containere și clustere, mecanismul de convergență este asigurat de Kubernetes.
- Același mecanism poate fi utilizat pentru a gestiona aplicațiile și design-urile bazate pe Kubernetes (cum ar fi Istio și Kubeflow).
- Un mecanism pentru gestionarea interacțiunii operaționale dintre Kubernetes, depozitele de imagini și Git oferă , care face parte .
- Pentru mașinile de bază, mecanismul de convergență trebuie să fie declarativ și autonom. Din propria experiență putem spune că cel mai apropiat de această definiție, dar necesită totuși control uman. În acest sens, GitOps extinde tradiția Infrastructurii ca Cod.
GitOps combină Git cu motorul de convergență excelent al Kubernetes pentru a oferi un model de exploatare.
GitOps ne permite să spunem: Numai acele sisteme care pot fi descrise și observate pot fi automatizate și controlate.
GitOps este destinat întregului stack nativ cloud (de exemplu, Terraform etc.)
GitOps nu este doar Kubernetes. Dorim ca întregul sistem să fie condus declarativ și să utilizeze convergența. Prin întregul sistem înțelegem o colecție de medii care lucrează cu Kubernetes - de exemplu, „dev cluster 1”, „producție”, etc. Fiecare mediu include mașini, clustere, aplicații, precum și interfețe pentru servicii externe care furnizează date, monitorizare. si etc.
Observați cât de important este Terraform pentru problema bootstrapping-ului în acest caz. Kubernetes trebuie să fie implementat undeva, iar utilizarea Terraform înseamnă că putem aplica aceleași fluxuri de lucru GitOps pentru a crea stratul de control care stă la baza Kubernetes și aplicațiile. Aceasta este o bună practică utilă.
Există un accent puternic pe aplicarea conceptelor GitOps la straturile de deasupra Kubernetes. În acest moment, 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 pentru cloud native.
Kubernetes CI/CD: compararea GitOps cu alte abordări
După cum sa spus, GitOps este două lucruri:
- Modelul de operare pentru Kubernetes și cloud nativ descris mai sus.
- Calea către un mediu de gestionare a aplicațiilor centrat pe dezvoltator.
Pentru mulți, GitOps este în primul rând un flux de lucru bazat pe push-uri Git. Și nouă ne place de el. Dar asta nu este tot: să ne uităm acum la conductele CI/CD.
GitOps permite implementarea continuă (CD) pentru Kubernetes
GitOps oferă un mecanism de implementare continuă care elimină nevoia de „sisteme de management al implementării” separate. Kubernetes face toată munca pentru tine.
- Actualizarea aplicației necesită actualizarea în Git. Aceasta este o actualizare tranzacțională la starea dorită. „Implementarea” se face apoi în cluster de către Kubernetes însuși, pe baza descrierii actualizate.
- Datorită naturii modului în care funcționează Kubernetes, aceste actualizări sunt convergente. Aceasta oferă un mecanism pentru implementare continuă în care toate actualizările sunt atomice.
- Nota: oferă un operator GitOps care integrează Git și Kubernetes și permite executarea CD-ului prin reconcilierea stării dorite și actuale a clusterului.
Fără kubectl și scripturi
Ar trebui să evitați să utilizați Kubectl pentru a vă actualiza clusterul și mai ales să evitați să utilizați scripturi pentru a grupa comenzile kubectl. În schimb, cu pipeline GitOps, un utilizator își poate actualiza clusterul Kubernetes prin Git.
Beneficiile includ:
- Dreapta. Un grup de actualizări pot fi aplicate, convergente și în cele din urmă validate, aducându-ne mai aproape de obiectivul implementării atomice. În schimb, utilizarea scripturilor nu oferă nicio garanție de convergență (mai multe despre asta mai jos).
- Безопасность. Kelsey Hightower: „Restricționați accesul la clusterul dumneavoastră Kubernetes la instrumentele de automatizare și administratorii care sunt responsabili pentru depanarea sau întreținerea acestuia.” Vezi si despre siguranță și respectarea specificațiilor tehnice, precum și prin furtul acreditărilor dintr-un scenariu Jenkins scris neglijent.
- Experiența utilizatorului. Kubectl expune mecanica modelului obiect Kubernetes, care este destul de complexă. În mod ideal, utilizatorii ar trebui să interacționeze cu sistemul la un nivel superior de abstractizare. Aici mă voi referi din nou la Kelsey și voi recomanda vizionarea .
Diferența dintre CI și CD
GitOps îmbunătățește modelele CI/CD existente.
Un server CI modern este un instrument de orchestrare. În special, este un instrument pentru orchestrarea conductelor CI. Acestea includ construirea, testarea, îmbinarea cu trunchiul etc. Serverele CI automatizează gestionarea conductelor complexe în mai mulți pași. O tentație obișnuită este să scrieți un set de actualizări Kubernetes și să îl rulați ca parte a unei conducte pentru a împinge modificări în cluster. Într-adevăr, asta fac mulți experți. Cu toate acestea, acest lucru nu este optim și iată de ce.
CI ar trebui utilizat pentru a trimite actualizări în trunchi, iar clusterul Kubernetes ar trebui să se schimbe pe baza acelor actualizări pentru a gestiona CD-ul intern. Ii spunem , spre deosebire de modelul CI push. CD-ul face parte orchestrare runtime.
De ce serverele CI nu ar trebui să facă CD-uri prin actualizări directe în Kubernetes
Nu utilizați un server CI pentru a orchestra actualizări directe către Kubernetes ca un set de joburi CI. Acesta este anti-modelul despre care vorbim pe blogul tău.
Să ne întoarcem la Alice și Bob.
Cu ce probleme s-au confruntat? Serverul CI al lui Bob aplică modificările clusterului, dar dacă acesta se blochează în acest proces, Bob nu va ști în ce stare se află (sau ar trebui să fie) clusterul sau cum să-l remedieze. Același lucru este valabil și în caz de succes.
Să presupunem că echipa lui Bob a creat o nouă imagine și apoi și-a corectat implementările pentru a implementa imaginea (toate din conducta CI).
Dacă imaginea se construiește normal, dar conducta eșuează, echipa va trebui să descopere:
- S-a lansat actualizarea?
- Lansăm o nouă construcție? Va duce acest lucru la efecte secundare inutile - cu posibilitatea de a avea două versiuni ale aceleiași imagini imuabile?
- Ar trebui să așteptăm următoarea actualizare înainte de a rula versiunea?
- Ce anume a mers prost? Ce pași trebuie repetați (și care sunt siguri de repetat)?
Stabilirea unui flux de lucru bazat pe Git nu garantează că echipa lui Bob nu va întâmpina aceste probleme. Ei pot face în continuare o greșeală cu commit push, eticheta sau alt parametru; totuși, această abordare este încă mult mai aproape de o abordare explicită de totul sau nimic.
Pentru a rezuma, 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 modelul de cluster declarativ.
- Este greu de garantat idempotenta. Utilizatorii trebuie să înțeleagă semantica profundă a sistemului.
- Este mai dificil să vă recuperați după o defecțiune parțială.
Notă despre Helm: dacă doriți să utilizați Helm, vă recomandăm să îl combinați cu un operator GitOps, cum ar fi . Acest lucru va ajuta la asigurarea convergenței. Helm în sine nu este nici determinist, nici atomic.
GitOps ca cea mai bună modalitate de a implementa Livrarea continuă pentru Kubernetes
Echipa lui Alice și Bob implementează GitOps și descoperă că a devenit mult mai ușor să lucrezi cu produse software, să menții performanța ridicată și stabilitatea. Să încheiem acest articol cu o ilustrare care arată cum arată noua lor abordare. Rețineți că vorbim mai ales despre aplicații și servicii, dar GitOps poate fi folosit pentru a gestiona o întreagă platformă.
Model de operare pentru Kubernetes
Priviți următoarea diagramă. Prezintă Git și depozitul de imagini container ca resurse partajate pentru două cicluri de viață orchestrate:
- O conductă de integrare continuă care citește și scrie fișiere în Git și poate actualiza un depozit de imagini container.
- O conductă Runtime GitOps care combină implementarea cu managementul și observabilitatea. Citește și scrie fișiere în Git și poate descărca imagini container.
Care sunt principalele constatări?
- Separarea preocupărilor: Vă rugăm să rețineți că ambele conducte pot comunica doar prin actualizarea Git sau a depozitului de imagini. Cu alte cuvinte, există un firewall între CI și mediul de rulare. Îl numim „firewall de imuabilitate” (firewall de imuabilitate), deoarece toate actualizările depozitului creează versiuni noi. Pentru mai multe informații despre acest subiect, consultați diapozitivele 72-87 .
- Puteți utiliza orice server CI și Git: GitOps funcționează cu orice componentă. Puteți continua să utilizați serverele CI și Git preferate, depozitele de imagini și suitele de testare. Aproape toate celelalte instrumente de livrare continuă de pe piață necesită propriul lor server CI/Git sau depozit de imagini. Acest lucru poate deveni un factor limitativ în dezvoltarea cloud native. Cu GitOps, puteți folosi instrumente familiare.
- Evenimentele ca instrument de integrare: De îndată ce datele din Git sunt actualizate, Weave Flux (sau operatorul Weave Cloud) notifică timpul de execuție. Ori de câte ori Kubernetes acceptă un set de modificări, Git este actualizat. Acesta oferă un model de integrare simplu pentru organizarea fluxurilor de lucru pentru GitOps, așa cum se arată mai jos.
Concluzie
GitOps oferă garanțiile puternice de actualizare cerute de orice instrument modern CI/CD:
- automatizare;
- convergenţă;
- idempotenta;
- determinism.
Acest lucru este important deoarece oferă un model operațional pentru dezvoltatorii nativi în cloud.
- Instrumentele tradiționale pentru gestionarea și monitorizarea sistemelor sunt asociate cu echipele de operațiuni care operează într-un runbook (un set de proceduri și operațiuni de rutină - aprox. traducere), legat de o anumită implementare.
- În managementul nativ în cloud, instrumentele de observabilitate sunt cea mai bună modalitate de a măsura rezultatele implementărilor, astfel încât echipa de dezvoltare să poată răspunde rapid.
Imaginați-vă multe clustere împrăștiate pe diferite nori și multe servicii cu propriile echipe și planuri de implementare. GitOps oferă un model invariant la scară pentru gestionarea acestei abundențe.
PS de la traducator
Citește și pe blogul nostru:
- «»;
- «»;
- «".
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Știați despre GitOps înainte ca aceste două traduceri să apară pe Habré?
-
Da, știam totul
-
Doar superficial
-
Nu
Au votat 35 utilizatori. 10 utilizatori s-au abținut.
Sursa: www.habr.com