Nota. transl.: Després d'una publicació recent sobre els mètodes pull i push a GitOps, vam veure interès en aquest model en general, però hi havia molt poques publicacions en llengua russa sobre aquest tema (simplement no n'hi ha cap a Habré). Per tant, ens complau oferir a la vostra atenció una traducció d'un altre article, encara que fa gairebé un any! - de Weaveworks, el cap del qual va encunyar el terme "GitOps". El text explica l'essència de l'enfocament i les diferències clau dels existents.
Fa un any vam publicar . Aleshores, vam compartir com l'equip de Weaveworks va llançar un SaaS basat completament en Kubernetes i va desenvolupar un conjunt de bones pràctiques prescriptives per desplegar, gestionar i supervisar en un entorn natiu del núvol.
L'article va resultar ser popular. Altres persones van començar a parlar de GitOps i van començar a publicar noves eines per , , , , etcètera. Va aparèixer al nostre lloc web publicacions i casos d'ús de GitOps. Però algunes persones encara tenen preguntes. En què es diferencia el model del tradicional? i lliurament continu ()? És necessari utilitzar Kubernetes?
Aviat ens vam adonar que calia una nova descripció, oferint:
- Un gran nombre d'exemples i històries;
- Definició específica de GitOps;
- Comparació amb el lliurament continu tradicional.
En aquest article hem intentat cobrir tots aquests temes. Proporciona una introducció actualitzada a GitOps i una perspectiva de desenvolupador i CI/CD. Ens centrem principalment en Kubernetes, tot i que el model es pot generalitzar.
Coneix GitOps
Imagineu l'Alícia. Dirigeix l'assegurança familiar, que ofereix assegurances de salut, d'automòbil, de llar i de viatge a persones massa ocupades per esbrinar els detalls dels contractes. El seu negoci va començar com un projecte paralel quan l'Alice treballava en un banc com a científica de dades. Un dia es va adonar que podia utilitzar algorismes informàtics avançats per analitzar les dades de manera més eficaç i formular paquets d'assegurances. Els inversors van finançar el projecte i ara la seva empresa aporta més de 20 milions de dòlars anuals i està creixent ràpidament. Actualment, dóna feina a 180 persones en diferents llocs de treball. Això inclou un equip de tecnologia que desenvolupa, manté el lloc web, la base de dades i analitza la base de clients. L'equip de 60 persones està liderat per Bob, el director tècnic de l'empresa.
L'equip de Bob desplega sistemes de producció al núvol. Les seves aplicacions principals s'executen a GKE, aprofitant Kubernetes a Google Cloud. A més, utilitzen diverses dades i eines d'anàlisi en el seu treball.
Family Insurance no es va proposar utilitzar contenidors, però es va quedar atrapat per l'entusiasme de Docker. L'empresa va descobrir aviat que GKE va facilitar i sense esforç desplegar clústers per provar noves funcions. Es van afegir Jenkins per a CI i Quay per organitzar el registre de contenidors, es van escriure scripts per a Jenkins que van impulsar nous contenidors i configuracions a GKE.
Ha passat un temps. Alice i Bob van quedar decebuts amb el rendiment de l'enfocament escollit i el seu impacte en el negoci. La introducció dels contenidors no va millorar la productivitat tant com l'equip havia esperat. De vegades, els desplegaments es trencaven i no estava clar si els canvis de codi tenien la culpa. També va resultar difícil fer un seguiment dels canvis de configuració. Sovint era necessari crear un nou clúster i traslladar-hi aplicacions, ja que aquesta era la manera més senzilla d'eliminar l'embolic en què s'havia convertit el sistema. Alice tenia por que la situació empitjorés a mesura que es desenvolupava l'aplicació (a més, s'estava preparant un nou projecte basat en l'aprenentatge automàtic). Bob havia automatitzat la major part del treball i no entenia per què la canonada encara era inestable, no s'escalava bé i necessitava una intervenció manual periòdica?
Després van aprendre sobre GitOps. Aquesta decisió va resultar ser exactament la que necessitaven per avançar amb confiança.
L'Alice i el Bob fa anys que escolten parlar de Git, DevOps i la infraestructura com a fluxos de treball de codi. El que és únic de GitOps és que aporta un conjunt de bones pràctiques, tant definitives com normatives, per implementar aquestes idees en el context de Kubernetes. Aquest tema , inclòs a .
Family Insurance decideix implementar GitOps. L'empresa disposa ara d'un model d'operació automatitzada que és compatible amb Kubernetes i combina velocitat amb estabilitatperquè ells:
- va trobar que la productivitat de l'equip es doblava sense que ningú es tornés boig;
- va deixar de publicar scripts. En comptes d'això, ara poden centrar-se en noves funcions i millorar els mètodes d'enginyeria, per exemple, la introducció de llançaments canaris i la millora de les proves;
- hem millorat el procés de desplegament perquè poques vegades s'avaria;
- va tenir l'oportunitat de restaurar els desplegaments després de fallades parcials sense intervenció manual;
- comprat usatоMés confiança en els sistemes de lliurament. L'Alice i el Bob van descobrir que podien dividir l'equip en equips de microserveis treballant en paral·lel;
- pot fer 30-50 canvis al projecte cada dia gràcies als esforços de cada grup i provar noves tècniques;
- és fàcil atraure nous desenvolupadors al projecte, que tenen l'oportunitat de llançar actualitzacions de producció mitjançant sol·licituds d'extracció en poques hores;
- Superar fàcilment l'auditoria en el marc de SOC2 (per al compliment dels proveïdors de serveis amb els requisits per a la gestió segura de dades; llegiu-ne més, per exemple, -aprox. trad.).
Què va passar?
GitOps és dues coses:
- Model operatiu per a Kubernetes i natiu al núvol. Proporciona un conjunt de bones pràctiques per desplegar, gestionar i supervisar clústers i aplicacions en contenidors. Definició elegant en la forma d' :
- El camí per crear un entorn de gestió d'aplicacions centrat en el desenvolupador. Apliquem el flux de treball de Git tant a les operacions com al desenvolupament. Tingueu en compte que no es tracta només de Git push, sinó d'organitzar tot el conjunt d'eines CI/CD i UI/UX.
Unes paraules sobre Git
Si no esteu familiaritzat amb els sistemes de control de versions i el flux de treball basat en Git, us recomanem que apreneu-ne. Treballar amb branques i sol·licituds d'extracció pot semblar màgia negra al principi, però els beneficis valen la pena. Aquí començar.
Com funciona Kubernetes
A la nostra història, Alice i Bob van recórrer a GitOps després de treballar amb Kubernetes durant un temps. De fet, GitOps està estretament relacionat amb Kubernetes: és un model operatiu per a infraestructures i aplicacions basades en Kubernetes.
Què ofereix Kubernetes als usuaris?
Aquestes són algunes de les característiques principals:
- En el model de Kubernetes, tot es pot descriure en forma declarativa.
- El servidor de l'API de Kubernetes pren aquesta declaració com a entrada i després intenta contínuament portar el clúster a l'estat descrit a la declaració.
- Les declaracions són suficients per descriure i gestionar una gran varietat de càrregues de treball: "aplicacions".
- Com a resultat, es produeixen canvis a l'aplicació i al clúster a causa de:
- canvis en les imatges dels contenidors;
- canvis a l'especificació declarativa;
- errors en el medi ambient, per exemple, bloquejos de contenidors.
Grans capacitats de convergència de Kubernetes
Quan un administrador fa canvis de configuració, l'orquestrador de Kubernetes els aplicarà al clúster sempre que el seu estat sigui no s'acostarà a la nova configuració. Aquest model funciona per a qualsevol recurs de Kubernetes i és extensible amb definicions de recursos personalitzades (CRD). Per tant, els desplegaments de Kubernetes tenen les següents propietats meravelloses:
- Automatització: les actualitzacions de Kubernetes proporcionen un mecanisme per automatitzar el procés d'aplicació de canvis amb gràcia i de manera oportuna.
- Convergència: Kubernetes continuarà intentant actualitzacions fins que tingui èxit.
- Idempotència: Les aplicacions repetides de convergència condueixen al mateix resultat.
- Determinisme: Quan els recursos són suficients, l'estat del clúster actualitzat només depèn de l'estat desitjat.
Com funciona GitOps
Hem après prou sobre Kubernetes per explicar com funciona GitOps.
Tornem als equips de microserveis de Family Insurance. Què han de fer normalment? Mireu la llista següent (si hi ha elements estranys o desconeguts, si us plau, atureu-vos a criticar i romandre amb nosaltres). Aquests són només exemples de fluxos de treball basats en Jenkins. Hi ha molts altres processos quan es treballa amb altres eines.
El més important és que veiem que cada actualització acaba amb canvis als fitxers de configuració i als repositoris Git. Aquests canvis a Git fan que l'"operador GitOps" actualitzi el clúster:
1.Procés de treball: "Construcció Jenkins - branca mestra».
Llista de tasques:
- Jenkins envia imatges etiquetades a Quay;
- Jenkins envia els gràfics de configuració i Helm al cub d'emmagatzematge principal;
- La funció de núvol copia la configuració i els gràfics del cub d'emmagatzematge principal al repositori Git principal;
- L'operador GitOps actualitza el clúster.
2. Construcció de Jenkins: llançament o branca de hotfix:
- Jenkins envia imatges sense etiquetar a Quay;
- Jenkins envia els gràfics de configuració i Helm al cub d'emmagatzematge;
- La funció de núvol copia la configuració i els gràfics des del cub d'emmagatzematge en fase al dipòsit Git de posada en escena;
- L'operador GitOps actualitza el clúster.
3. Construcció de Jenkins: desenvolupament o branca de funcions:
- Jenkins envia imatges sense etiquetar a Quay;
- Jenkins introdueix els gràfics de configuració i Helm al cub d'emmagatzematge de desenvolupament;
- La funció de núvol copia la configuració i els gràfics del cub d'emmagatzematge de desenvolupament al dipòsit Git de desenvolupament;
- L'operador GitOps actualitza el clúster.
4. Afegeix un client nou:
- El gestor o administrador (LCM/ops) truca a Gradle per desplegar i configurar inicialment equilibradors de càrrega de xarxa (NLB);
- LCM/ops compromet una nova configuració per preparar el desplegament per a les actualitzacions;
- L'operador GitOps actualitza el clúster.
Breu descripció de GitOps
- Descriu l'estat desitjat de tot el sistema utilitzant especificacions declaratives per a cada entorn (a la nostra història, l'equip de Bob defineix tota la configuració del sistema a Git).
- El repositori Git és l'única font de veritat sobre l'estat desitjat de tot el sistema.
- Tots els canvis a l'estat desitjat es fan mitjançant commits a Git.
- Tots els paràmetres de clúster desitjats també es poden observar al propi clúster. D'aquesta manera podem determinar si coincideixen (convergeixen, convergir) o difereixen (divergen, divergir) estats desitjats i observats.
- Si els estats desitjats i observats difereixen, aleshores:
- Hi ha un mecanisme de convergència que tard o d'hora sincronitza automàticament l'objectiu i els estats observats. Dins del clúster, Kubernetes fa això.
- El procés comença immediatament amb una alerta de "canvi compromès".
- Després d'un període de temps configurable, es pot enviar una alerta "diff" si els estats són diferents.
- D'aquesta manera, totes les confirmacions de Git provoquen actualitzacions verificables i idempotents al clúster.
- El retrocés és la convergència a un estat desitjat prèviament.
- La convergència és definitiva. La seva aparició s'indica per:
- Sense alertes de diferència durant un període de temps determinat.
- alerta "convergent" (p. ex. webhook, esdeveniment d'escriptura de Git).
Què és la divergència?
Repetim de nou: totes les propietats del clúster desitjades han de ser observables en el propi clúster.
Alguns exemples de divergència:
- Canvi al fitxer de configuració a causa de la fusió de branques a Git.
- Un canvi en el fitxer de configuració a causa d'una confirmació de Git feta pel client GUI.
- Múltiples canvis a l'estat desitjat a causa del PR a Git seguits de la creació de la imatge del contenidor i els canvis de configuració.
- Un canvi en l'estat del clúster a causa d'un error, un conflicte de recursos que provoca un "mal comportament" o simplement una desviació aleatòria de l'estat original.
Quin és el mecanisme de convergència?
Alguns exemples:
- Per als contenidors i clústers, Kubernetes proporciona el mecanisme de convergència.
- El mateix mecanisme es pot utilitzar per gestionar aplicacions i dissenys basats en Kubernetes (com ara Istio i Kubeflow).
- Un mecanisme per gestionar la interacció operativa entre Kubernetes, repositoris d'imatges i Git ofereix , que forma part .
- Per a les màquines base, el mecanisme de convergència ha de ser declaratiu i autònom. Des de la nostra pròpia experiència ho podem dir més propera a aquesta definició, però encara requereix control humà. En aquest sentit, GitOps amplia la tradició d'Infraestructura com a codi.
GitOps combina Git amb l'excel·lent motor de convergència de Kubernetes per proporcionar un model d'explotació.
GitOps ens permet dir: Només aquells sistemes que es poden descriure i observar es poden automatitzar i controlar.
GitOps està pensat per a tota la pila nativa del núvol (per exemple, Terraform, etc.)
GitOps no és només Kubernetes. Volem que tot el sistema sigui impulsat de manera declarativa i utilitzi la convergència. Per tot el sistema entenem una col·lecció d'entorns que treballen amb Kubernetes, per exemple, "clúster de desenvolupament 1", "producció", etc. Cada entorn inclou màquines, clústers, aplicacions, així com interfícies per a serveis externs que proporcionen dades, monitoratge. i etc.
Observeu la importància que té Terraform per al problema d'arrencada en aquest cas. Kubernetes s'ha de desplegar en algun lloc, i utilitzar Terraform significa que podem aplicar els mateixos fluxos de treball de GitOps per crear la capa de control que sustenta Kubernetes i les aplicacions. Aquesta és una bona pràctica útil.
Hi ha un gran focus en l'aplicació dels conceptes de GitOps a les capes de Kubernetes. De moment, hi ha solucions de tipus GitOps per a Istio, Helm, Ksonnet, OpenFaaS i Kubeflow, així com, per exemple, per a Pulumi, que creen una capa per desenvolupar aplicacions natives del núvol.
Kubernetes CI/CD: comparació de GitOps amb altres enfocaments
Com s'ha dit, GitOps són dues coses:
- El model operatiu per a Kubernetes i natiu del núvol descrit anteriorment.
- El camí cap a un entorn de gestió d'aplicacions centrat en el desenvolupador.
Per a molts, GitOps és principalment un flux de treball basat en pushs de Git. També ens agrada. Però això no és tot: mirem ara els pipelines CI/CD.
GitOps permet el desplegament continu (CD) per a Kubernetes
GitOps ofereix un mecanisme de desplegament continu que elimina la necessitat de "sistemes de gestió de desplegament" separats. Kubernetes fa tot el treball per tu.
- L'actualització de l'aplicació requereix una actualització a Git. Aquesta és una actualització transaccional a l'estat desitjat. A continuació, el "desplegament" es fa dins del clúster pel mateix Kubernetes en funció de la descripció actualitzada.
- A causa de la naturalesa del funcionament de Kubernetes, aquestes actualitzacions són convergents. Això proporciona un mecanisme per al desplegament continu en el qual totes les actualitzacions són atòmiques.
- Nota: ofereix un operador GitOps que integra Git i Kubernetes i permet fer CD conciliant l'estat desitjat i actual del clúster.
Sense kubectl i scripts
Hauríeu d'evitar utilitzar Kubectl per actualitzar el vostre clúster i, sobretot, evitar utilitzar scripts per agrupar ordres de kubectl. En canvi, amb el pipeline GitOps, un usuari pot actualitzar el seu clúster Kubernetes mitjançant Git.
Els beneficis inclouen:
- Dret. Es poden aplicar, convergir i finalment validar un grup d'actualitzacions, apropant-nos a l'objectiu del desplegament atòmic. En canvi, utilitzar scripts no ofereix cap garantia de convergència (més informació a continuació).
- Безопасность. Kelsey Hightower: "Restringeix l'accés al teu clúster Kubernetes a les eines d'automatització i als administradors responsables de depurar-lo o mantenir-lo". Vegeu també sobre seguretat i compliment de les especificacions tècniques, així com robant credencials d'un guió de Jenkins escrit descuidadament.
- Experiència d'usuari. Kubectl exposa la mecànica del model d'objectes Kubernetes, que és força complexa. Idealment, els usuaris haurien d'interaccionar amb el sistema a un nivell d'abstracció superior. Aquí tornaré a referir-me a Kelsey i recomanaré veure'l .
Diferència entre CI i CD
GitOps millora els models CI/CD existents.
Un servidor CI modern és una eina d'orquestració. En particular, és una eina per orquestrar canalitzacions CI. Aquests inclouen la creació, prova, fusió amb tronc, etc. Els servidors CI automatitzen la gestió de canalitzacions complexes de diversos passos. Una temptació comuna és escriure un conjunt d'actualitzacions de Kubernetes i executar-lo com a part d'una canalització per impulsar els canvis al clúster. De fet, això és el que fan molts experts. Tanmateix, això no és òptim, i aquí teniu el perquè.
S'hauria d'utilitzar CI per enviar actualitzacions al tronc i el clúster de Kubernetes hauria de canviar-se en funció d'aquestes actualitzacions per gestionar el CD internament. L'anomenem , a diferència del model push CI. El CD forma part orquestració en temps d'execució.
Per què els servidors CI no haurien de fer CD mitjançant actualitzacions directes a Kubernetes
No utilitzeu un servidor CI per orquestrar actualitzacions directes a Kubernetes com a conjunt de treballs CI. Aquest és l'antipatró del qual estem parlant al teu bloc.
Tornem a l'Alice i en Bob.
Quins problemes es van enfrontar? El servidor CI de Bob aplica els canvis al clúster, però si es bloqueja en el procés, Bob no sabrà en quin estat es troba (o hauria d'estar) el clúster ni com solucionar-ho. El mateix passa en cas d'èxit.
Suposem que l'equip de Bob va crear una imatge nova i després va pegar els seus desplegaments per desplegar la imatge (tot des del pipeline CI).
Si la imatge es crea amb normalitat, però la canalització falla, l'equip haurà d'esbrinar:
- S'ha llançat l'actualització?
- Estrenem una nova construcció? Això comportarà efectes secundaris innecessaris, amb la possibilitat de tenir dues versions de la mateixa imatge immutable?
- Hem d'esperar la propera actualització abans d'executar la compilació?
- Què va fallar exactament? Quins passos s'han de repetir (i quins són segurs de repetir)?
Establir un flux de treball basat en Git no garanteix que l'equip de Bob no es trobi amb aquests problemes. Encara poden cometre un error amb el commit push, l'etiqueta o algun altre paràmetre; tanmateix, aquest enfocament encara està molt més a prop d'un enfocament explícit de tot o res.
Per resumir, aquí teniu per què els servidors CI no haurien de tractar amb CD:
- Els scripts d'actualització no sempre són deterministes; És fàcil cometre errors en ells.
- Els servidors CI no convergeixen al model de clúster declaratiu.
- És difícil garantir la idempotència. Els usuaris han d'entendre la semàntica profunda del sistema.
- És més difícil recuperar-se d'una fallada parcial.
Nota sobre Helm: si voleu utilitzar Helm, us recomanem que el combineu amb un operador GitOps com ara . Això ajudarà a garantir la convergència. Helm en si no és ni determinista ni atòmic.
GitOps com la millor manera d'implementar el lliurament continu per a Kubernetes
L'equip d'Alice i Bob implementa GitOps i descobreix que s'ha tornat molt més fàcil treballar amb productes de programari, mantenir un alt rendiment i estabilitat. Acabem aquest article amb una il·lustració que mostra com és el seu nou enfocament. Tingueu en compte que estem parlant principalment d'aplicacions i serveis, però GitOps es pot utilitzar per gestionar una plataforma sencera.
Model operatiu per a Kubernetes
Observa el diagrama següent. Presenta Git i el dipòsit d'imatges del contenidor com a recursos compartits per a dos cicles de vida orquestrats:
- Una canalització d'integració contínua que llegeix i escriu fitxers a Git i pot actualitzar un dipòsit d'imatges de contenidors.
- Un canal d'execució de GitOps que combina el desplegament amb la gestió i l'observabilitat. Llegeix i escriu fitxers a Git i pot descarregar imatges de contenidors.
Quines són les principals troballes?
- Separació de preocupacions: Tingueu en compte que ambdues canalitzacions només es poden comunicar actualitzant Git o el dipòsit d'imatges. En altres paraules, hi ha un tallafoc entre CI i l'entorn d'execució. L'anomenem "tallafocs d'immutabilitat" (tallafocs d'immutabilitat), ja que totes les actualitzacions del repositori creen noves versions. Per obtenir més informació sobre aquest tema, consulteu les diapositives 72-87 .
- Podeu utilitzar qualsevol servidor CI i Git: GitOps funciona amb qualsevol component. Podeu continuar utilitzant els vostres servidors CI i Git preferits, dipòsits d'imatges i suites de proves. Gairebé totes les altres eines de lliurament continu del mercat requereixen el seu propi servidor CI/Git o dipòsit d'imatges. Això pot esdevenir un factor limitant en el desenvolupament del cloud native. Amb GitOps, podeu utilitzar eines familiars.
- Els esdeveniments com a eina d'integració: tan aviat com s'actualitzen les dades de Git, Weave Flux (o l'operador de Weave Cloud) notifica el temps d'execució. Sempre que Kubernetes accepta un conjunt de canvis, Git s'actualitza. Això proporciona un model d'integració senzill per organitzar fluxos de treball per a GitOps, tal com es mostra a continuació.
Conclusió
GitOps ofereix les fortes garanties d'actualització requerides per qualsevol eina CI/CD moderna:
- automatització;
- convergència;
- idempotència;
- determinisme.
Això és important perquè ofereix un model operatiu per als desenvolupadors natius del núvol.
- Les eines tradicionals per gestionar i controlar sistemes s'associen amb equips d'operacions que operen dins d'un runbook (un conjunt de procediments i operacions rutinàries - aprox. traducció), vinculat a un desplegament específic.
- En la gestió nativa del núvol, les eines d'observabilitat són la millor manera de mesurar els resultats dels desplegaments perquè l'equip de desenvolupament pugui respondre ràpidament.
Imagineu molts clústers repartits per diferents núvols i molts serveis amb els seus propis equips i plans de desplegament. GitOps ofereix un model invariant d'escala per gestionar tota aquesta abundància.
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «».
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Sabíeu sobre GitOps abans que aquestes dues traduccions apareguessin a Habré?
-
Sí, ho sabia tot
-
Només superficialment
-
No
Han votat 35 usuaris. 10 usuaris es van abstenir.
Font: www.habr.com