Nota. trad.: Dopo una recente pubblicazione riguardo ai metodi pull e push in GitOps, abbiamo visto interesse per questo modello in generale, ma c'erano pochissime pubblicazioni in lingua russa su questo argomento (semplicemente non ce ne sono su Habré). Pertanto, siamo lieti di offrire alla vostra attenzione la traduzione di un altro articolo, anche se quasi un anno fa! – da Weaveworks, il cui capo ha coniato il termine “GitOps”. Il testo spiega l'essenza dell'approccio e le principali differenze rispetto a quelli esistenti.
Un anno fa pubblicavamo . Allora, abbiamo condiviso come il team Weaveworks ha lanciato un SaaS interamente basato su Kubernetes e sviluppato una serie di best practice prescrittive per la distribuzione, la gestione e il monitoraggio in un ambiente nativo del cloud.
L'articolo si è rivelato popolare. Altre persone hanno iniziato a parlare di GitOps e hanno iniziato a pubblicare nuovi strumenti per , , , , e così via. Apparso sul nostro sito web pubblicazioni e casi d'uso GitOps. Ma alcune persone hanno ancora delle domande. In cosa differisce il modello da quello tradizionale? e consegna continua ()? È necessario utilizzare Kubernetes?
Ci siamo presto resi conto che era necessaria una nuova descrizione, offrendo:
- Un gran numero di esempi e storie;
- Definizione specifica di GitOps;
- Confronto con la consegna continua tradizionale.
In questo articolo abbiamo cercato di trattare tutti questi argomenti. Fornisce un'introduzione aggiornata a GitOps e una prospettiva per sviluppatori e CI/CD. Ci concentriamo principalmente su Kubernetes, sebbene il modello possa essere generalizzato.
Incontra GitOps
Immagina Alice. Gestisce l'assicurazione familiare, che offre assicurazioni sanitarie, automobilistiche, sulla casa e di viaggio a persone che sono troppo impegnate per capire da sole i dettagli dei contratti. La sua attività è iniziata come progetto parallelo quando Alice lavorava in una banca come scienziata dei dati. Un giorno si rese conto che avrebbe potuto utilizzare algoritmi informatici avanzati per analizzare in modo più efficace i dati e formulare pacchetti assicurativi. Gli investitori hanno finanziato il progetto e ora la sua azienda guadagna più di 20 milioni di dollari all’anno e sta crescendo rapidamente. Attualmente impiega 180 persone in varie posizioni. Ciò include un team tecnologico che sviluppa, mantiene il sito Web, il database e analizza la base clienti. Il team di 60 persone è guidato da Bob, direttore tecnico dell'azienda.
Il team di Bob distribuisce i sistemi di produzione nel cloud. Le loro applicazioni principali vengono eseguite su GKE, sfruttando Kubernetes su Google Cloud. Inoltre, utilizzano vari strumenti di dati e analisi nel loro lavoro.
La Family Insurance non aveva intenzione di utilizzare i container, ma si è lasciata prendere dall'entusiasmo di Docker. L'azienda ha presto scoperto che GKE semplificava l'implementazione dei cluster per testare nuove funzionalità. Jenkins per CI e Quay sono stati aggiunti per organizzare il registro dei contenitori, sono stati scritti script per Jenkins che hanno inviato nuovi contenitori e configurazioni a GKE.
È passato del tempo. Alice e Bob erano delusi dalle prestazioni dell'approccio scelto e dal suo impatto sull'azienda. L'introduzione dei container non ha migliorato la produttività quanto sperato dal team. A volte le distribuzioni si interrompevano e non era chiaro se la colpa fosse delle modifiche al codice. Si è rivelato anche difficile tenere traccia delle modifiche alla configurazione. Spesso era necessario creare un nuovo cluster e spostarvi le applicazioni, poiché questo era il modo più semplice per eliminare il caos in cui era diventato il sistema. Alice temeva che la situazione sarebbe peggiorata con lo sviluppo dell'applicazione (inoltre, si stava preparando un nuovo progetto basato sull'apprendimento automatico). Bob aveva automatizzato la maggior parte del lavoro e non capiva perché la pipeline era ancora instabile, non si adattava bene e richiedeva periodicamente un intervento manuale?
Poi hanno appreso di GitOps. Questa decisione si è rivelata esattamente ciò di cui avevano bisogno per andare avanti con sicurezza.
Alice e Bob sentono parlare da anni di Git, DevOps e dell'infrastruttura come flussi di lavoro del codice. La particolarità di GitOps è che offre una serie di best practice, sia definitive che normative, per implementare queste idee nel contesto di Kubernetes. Questo tema , Anche in .
L'assicurazione familiare decide di implementare GitOps. L'azienda dispone ora di un modello operativo automatizzato compatibile con Kubernetes e le mietitrebbie velocità con stabilitàperché essi:
- scoperto che la produttività del team raddoppiava senza che nessuno impazzisse;
- ha smesso di servire gli script. Invece, ora possono concentrarsi su nuove funzionalità e migliorare i metodi di progettazione, ad esempio introducendo implementazioni canary e migliorando i test;
- abbiamo migliorato il processo di distribuzione in modo che raramente si interrompa;
- avuto l'opportunità di ripristinare le distribuzioni dopo guasti parziali senza intervento manuale;
- acquistato usatoоMaggiore fiducia nei sistemi di consegna. Alice e Bob hanno scoperto che potevano dividere il team in team di microservizi che lavoravano in parallelo;
- può apportare 30-50 modifiche al progetto ogni giorno attraverso gli sforzi di ciascun gruppo e provare nuove tecniche;
- è facile attirare nuovi sviluppatori nel progetto, che hanno l'opportunità di implementare aggiornamenti in produzione utilizzando richieste pull entro poche ore;
- superare facilmente l'audit nell'ambito di SOC2 (per il rispetto da parte dei fornitori di servizi dei requisiti per la gestione sicura dei dati; leggi di più, ad esempio, - ca. trad.).
Che cosa è successo?
GitOps è due cose:
- Modello operativo per Kubernetes e cloud nativo. Fornisce una serie di best practice per la distribuzione, la gestione e il monitoraggio di cluster e applicazioni containerizzati. Elegante definizione nella forma от :
- Il percorso per creare un ambiente di gestione delle applicazioni incentrato sullo sviluppatore. Applichiamo il flusso di lavoro Git sia alle operazioni che allo sviluppo. Tieni presente che non si tratta solo di Git push, ma di organizzazione dell'intero set di strumenti CI/CD e UI/UX.
Qualche parola su Git
Se non hai familiarità con i sistemi di controllo della versione e il flusso di lavoro basato su Git, ti consigliamo vivamente di conoscerli. Lavorare con branch e pull request può sembrare all’inizio magia nera, ma i benefici valgono lo sforzo. Qui iniziare.
Come funziona Kubernetes
Nella nostra storia, Alice e Bob si sono rivolti a GitOps dopo aver lavorato con Kubernetes per un po'. In effetti, GitOps è strettamente correlato a Kubernetes: è un modello operativo per l'infrastruttura e le applicazioni basate su Kubernetes.
Cosa offre Kubernetes agli utenti?
Ecco alcune caratteristiche principali:
- Nel modello Kubernetes tutto può essere descritto in forma dichiarativa.
- Il server API Kubernetes accetta questa dichiarazione come input e quindi tenta continuamente di portare il cluster nello stato descritto nella dichiarazione.
- Le dichiarazioni sono sufficienti per descrivere e gestire un'ampia varietà di carichi di lavoro: "applicazioni".
- Di conseguenza, le modifiche all'applicazione e al cluster si verificano a causa di:
- cambiamenti nelle immagini del contenitore;
- modifiche alla specifica dichiarativa;
- errori nell'ambiente, ad esempio arresti anomali del contenitore.
Le grandi capacità di convergenza di Kubernetes
Quando un amministratore apporta modifiche alla configurazione, l'orchestratore Kubernetes le applicherà al cluster finché il suo stato rimane non si avvicinerà alla nuova configurazione. Questo modello funziona per qualsiasi risorsa Kubernetes ed è estensibile con Custom Resource Definitions (CRD). Pertanto, le distribuzioni Kubernetes hanno le seguenti meravigliose proprietà:
- Automazione: gli aggiornamenti Kubernetes forniscono un meccanismo per automatizzare il processo di applicazione delle modifiche in modo corretto e tempestivo.
- Convergenza: Kubernetes continuerà a tentare gli aggiornamenti finché non avranno esito positivo.
- Idempotenza: Ripetute applicazioni di convergenza portano allo stesso risultato.
- Determinismo: Quando le risorse sono sufficienti, lo stato del cluster aggiornato dipende solo dallo stato desiderato.
Come funziona GitOps
Abbiamo imparato abbastanza su Kubernetes per spiegare come funziona GitOps.
Torniamo ai team di microservizi di Family Insurance. Cosa devono fare di solito? Guarda l'elenco qui sotto (se qualche elemento in esso sembra strano o non familiare, per favore evita di criticare e resta con noi). Questi sono solo esempi di flussi di lavoro basati su Jenkins. Esistono molti altri processi quando si lavora con altri strumenti.
La cosa principale è che vediamo che ogni aggiornamento termina con modifiche ai file di configurazione e ai repository Git. Queste modifiche a Git fanno sì che l'"operatore GitOps" aggiorni il cluster:
1.Processo di lavoro: "Creazione Jenkins: ramo principale'.
Elenco delle attività:
- Jenkins invia le immagini contrassegnate a Quay;
- Jenkins invia la configurazione e i grafici Helm al bucket di archiviazione principale;
- La funzione cloud copia la configurazione e i grafici dal bucket di archiviazione principale al repository Git principale;
- L'operatore GitOps aggiorna il cluster.
2. Build Jenkins: ramo di rilascio o hotfix:
- Jenkins invia immagini senza tag a Quay;
- Jenkins invia la configurazione e i grafici Helm al bucket di archiviazione di staging;
- La funzione cloud copia la configurazione e i grafici dal bucket di archiviazione di staging al repository Git di staging;
- L'operatore GitOps aggiorna il cluster.
3. Jenkins build: sviluppa o presenta un ramo:
- Jenkins invia immagini senza tag a Quay;
- Jenkins inserisce i grafici di configurazione e Helm nel bucket di archiviazione di sviluppo;
- La funzione cloud copia la configurazione e i grafici dal bucket di archiviazione di sviluppo al repository Git di sviluppo;
- L'operatore GitOps aggiorna il cluster.
4. Aggiunta di un nuovo cliente:
- Il manager o l'amministratore (LCM/ops) chiama Gradle per distribuire e configurare inizialmente i bilanciatori del carico di rete (NLB);
- LCM/ops esegue il commit di una nuova configurazione per preparare la distribuzione per gli aggiornamenti;
- L'operatore GitOps aggiorna il cluster.
Breve descrizione di GitOps
- Descrivi lo stato desiderato dell'intero sistema utilizzando specifiche dichiarative per ciascun ambiente (nella nostra storia, il team di Bob definisce l'intera configurazione del sistema in Git).
- Il repository Git è l'unica fonte di verità riguardo allo stato desiderato dell'intero sistema.
- Tutte le modifiche allo stato desiderato vengono apportate tramite commit in Git.
- Tutti i parametri del cluster desiderati sono osservabili anche nel cluster stesso. In questo modo possiamo determinare se coincidono (convergono, converge) o differire (divergere, divergere) stati desiderati e osservati.
- Se gli stati desiderati e osservati differiscono, allora:
- Esiste un meccanismo di convergenza che prima o poi sincronizza automaticamente lo stato target e quello osservato. All'interno del cluster, Kubernetes fa questo.
- Il processo inizia immediatamente con un avviso di “modifica impegnata”.
- Dopo un periodo di tempo configurabile, è possibile inviare un avviso "diff" se gli stati sono diversi.
- In questo modo, tutti i commit in Git provocano aggiornamenti verificabili e idempotenti al cluster.
- Il rollback è la convergenza verso uno stato precedentemente desiderato.
- La convergenza è definitiva. La sua presenza è indicata da:
- Nessun avviso di differenza per un certo periodo di tempo.
- avviso "convergente" (ad esempio webhook, evento writeback Git).
Cos'è la divergenza?
Ripetiamo ancora: tutte le proprietà desiderate del cluster devono essere osservabili nel cluster stesso.
Alcuni esempi di divergenza:
- Modifica nel file di configurazione dovuta alla fusione dei rami in Git.
- Una modifica nel file di configurazione dovuta a un commit Git effettuato dal client della GUI.
- Modifiche multiple allo stato desiderato dovute a PR in Git seguite dalla creazione dell'immagine del contenitore e dalle modifiche alla configurazione.
- Un cambiamento nello stato del cluster dovuto a un errore, un conflitto di risorse con conseguente "cattivo comportamento" o semplicemente una deviazione casuale dallo stato originale.
Qual è il meccanismo di convergenza?
Alcuni esempi:
- Per contenitori e cluster il meccanismo di convergenza è fornito da Kubernetes.
- Lo stesso meccanismo può essere utilizzato per gestire applicazioni e progetti basati su Kubernetes (come Istio e Kubeflow).
- Fornisce un meccanismo per la gestione dell'interazione operativa tra Kubernetes, repository di immagini e Git , che fa parte .
- Per le macchine base, il meccanismo di convergenza deve essere dichiarativo e autonomo. Per nostra esperienza possiamo dirlo più vicino a questa definizione, ma richiede comunque il controllo umano. In questo senso, GitOps estende la tradizione dell’Infrastructure as Code.
GitOps combina Git con l'eccellente motore di convergenza di Kubernetes per fornire un modello di sfruttamento.
GitOps ci permette di dire: Solo i sistemi che possono essere descritti e osservati possono essere automatizzati e controllati.
GitOps è destinato all'intero stack nativo del cloud (ad esempio Terraform e così via)
GitOps non è solo Kubernetes. Vogliamo che l’intero sistema sia guidato in modo dichiarativo e utilizzi la convergenza. Per intero sistema intendiamo una raccolta di ambienti che lavorano con Kubernetes, ad esempio "dev cluster 1", "produzione", ecc. Ogni ambiente include macchine, cluster, applicazioni, nonché interfacce per servizi esterni che forniscono dati, monitoraggio ed ecc.
Nota quanto sia importante Terraform per il problema del bootstrap in questo caso. Kubernetes deve essere distribuito da qualche parte e utilizzare Terraform significa che possiamo applicare gli stessi flussi di lavoro GitOps per creare il livello di controllo che è alla base di Kubernetes e delle applicazioni. Questa è una best practice utile.
C'è una forte attenzione all'applicazione dei concetti GitOps ai livelli sopra Kubernetes. Al momento esistono soluzioni di tipo GitOps per Istio, Helm, Ksonnet, OpenFaaS e Kubeflow, nonché, ad esempio, per Pulumi, che creano un layer per lo sviluppo di applicazioni cloud native.
Kubernetes CI/CD: confronto tra GitOps e altri approcci
Come affermato, GitOps è due cose:
- Il modello operativo per Kubernetes e cloud native descritto sopra.
- Il percorso verso un ambiente di gestione delle applicazioni incentrato sullo sviluppatore.
Per molti, GitOps è principalmente un flusso di lavoro basato sui push Git. Piace anche a noi. Ma non è tutto: guardiamo ora le pipeline CI/CD.
GitOps consente la distribuzione continua (CD) per Kubernetes
GitOps offre un meccanismo di distribuzione continua che elimina la necessità di "sistemi di gestione della distribuzione" separati. Kubernetes fa tutto il lavoro per te.
- L'aggiornamento dell'applicazione richiede l'aggiornamento in Git. Questo è un aggiornamento transazionale allo stato desiderato. La "distribuzione" viene quindi eseguita all'interno del cluster da Kubernetes stesso in base alla descrizione aggiornata.
- A causa della natura del funzionamento di Kubernetes, questi aggiornamenti sono convergenti. Ciò fornisce un meccanismo per la distribuzione continua in cui tutti gli aggiornamenti sono atomici.
- Nota: offre un operatore GitOps che integra Git e Kubernetes e consente di eseguire il CD riconciliando lo stato desiderato e attuale del cluster.
Senza kubectl e script
Dovresti evitare di utilizzare Kubectl per aggiornare il tuo cluster e soprattutto evitare di utilizzare script per raggruppare i comandi kubectl. Invece, con la pipeline GitOps, un utente può aggiornare il proprio cluster Kubernetes tramite Git.
I vantaggi includono:
- Giusto. Un gruppo di aggiornamenti può essere applicato, convergente e infine convalidato, avvicinandoci all’obiettivo dello spiegamento atomico. Al contrario, l'utilizzo degli script non fornisce alcuna garanzia di convergenza (ne parleremo più avanti).
- sicurezza. Kelsey Hightower: "Limita l'accesso al tuo cluster Kubernetes agli strumenti di automazione e agli amministratori responsabili del debug o della manutenzione." Guarda anche sulla sicurezza e il rispetto delle specifiche tecniche, nonché rubando le credenziali da uno script Jenkins scritto con noncuranza.
- L'esperienza utente. Kubectl espone i meccanismi del modello a oggetti Kubernetes, che sono piuttosto complessi. Idealmente, gli utenti dovrebbero interagire con il sistema a un livello di astrazione più elevato. Qui farò nuovamente riferimento a Kelsey e consiglierò la visione .
Differenza tra CI e CD
GitOps migliora i modelli CI/CD esistenti.
Un moderno server CI è uno strumento di orchestrazione. In particolare, è uno strumento per orchestrare le pipeline CI. Questi includono creazione, test, unione al trunk, ecc. I server CI automatizzano la gestione di complesse pipeline multi-step. Una tentazione comune è quella di creare script di una serie di aggiornamenti Kubernetes ed eseguirli come parte di una pipeline per inviare le modifiche al cluster. In effetti, questo è ciò che fanno molti esperti. Tuttavia, questo non è ottimale, ed ecco perché.
La CI dovrebbe essere utilizzata per inviare gli aggiornamenti al trunk e il cluster Kubernetes dovrebbe modificarsi in base a tali aggiornamenti per gestire il CD internamente. Noi lo chiamiamo , a differenza del modello push CI. Il CD fa parte orchestrazione in fase di esecuzione.
Perché i server CI non dovrebbero eseguire CD tramite aggiornamenti diretti in Kubernetes
Non utilizzare un server CI per orchestrare gli aggiornamenti diretti a Kubernetes come un insieme di lavori CI. Questo è l'anti-modello di cui stiamo parlando sul tuo blog
Torniamo ad Alice e Bob.
Quali problemi hanno dovuto affrontare? Il server CI di Bob applica le modifiche al cluster, ma se si blocca durante il processo, Bob non saprà in quale stato si trova (o dovrebbe essere) il cluster o come risolverlo. Lo stesso vale in caso di successo.
Supponiamo che il team di Bob abbia creato una nuova immagine e quindi abbia corretto le proprie distribuzioni per distribuire l'immagine (tutto dalla pipeline CI).
Se l'immagine viene creata normalmente, ma la pipeline fallisce, il team dovrà capire:
- L'aggiornamento è stato lanciato?
- Stiamo lanciando una nuova build? Ciò comporterà effetti collaterali non necessari, con la possibilità di avere due build della stessa immagine immutabile?
- Dovremmo aspettare il prossimo aggiornamento prima di eseguire la build?
- Cosa è andato storto esattamente? Quali passaggi devono essere ripetuti (e quali sono sicuri da ripetere)?
Stabilire un flusso di lavoro basato su Git non garantisce che il team di Bob non incontrerà questi problemi. Possono ancora commettere errori con il commit push, il tag o qualche altro parametro; tuttavia, questo approccio è ancora molto più vicino a un approccio esplicito del tipo “tutto o niente”.
Per riassumere, ecco perché i server CI non dovrebbero gestire CD:
- Gli script di aggiornamento non sono sempre deterministici; È facile commettere errori in essi.
- I server CI non convergono al modello di cluster dichiarativo.
- È difficile garantire l’idempotenza. Gli utenti devono comprendere la semantica profonda del sistema.
- È più difficile recuperare da un fallimento parziale.
Nota su Helm: se desideri utilizzare Helm, ti consigliamo di combinarlo con un operatore GitOps come . Ciò contribuirà a garantire la convergenza. Helm in sé non è né deterministico né atomico.
GitOps come il modo migliore per implementare la distribuzione continua per Kubernetes
Il team di Alice e Bob implementa GitOps e scopre che è diventato molto più semplice lavorare con prodotti software, mantenere prestazioni elevate e stabilità. Concludiamo questo articolo con un'illustrazione che mostra come si presenta il loro nuovo approccio. Tieni presente che parliamo principalmente di applicazioni e servizi, ma GitOps può essere utilizzato per gestire un'intera piattaforma.
Modello operativo per Kubernetes
Osserva il seguente diagramma. Presenta Git e il repository di immagini del contenitore come risorse condivise per due cicli di vita orchestrati:
- Una pipeline di integrazione continua che legge e scrive file su Git e può aggiornare un repository di immagini del contenitore.
- Una pipeline Runtime GitOps che combina distribuzione con gestione e osservabilità. Legge e scrive file su Git e può scaricare immagini del contenitore.
Quali sono i risultati principali?
- Separazione degli interessi: Tieni presente che entrambe le pipeline possono comunicare solo aggiornando Git o il repository di immagini. In altre parole, esiste un firewall tra CI e l'ambiente di runtime. Lo chiamiamo "firewall dell'immutabilità" (firewall di immutabilità), poiché tutti gli aggiornamenti del repository creano nuove versioni. Per ulteriori informazioni su questo argomento, fare riferimento alle diapositive 72-87 .
- È possibile utilizzare qualsiasi server CI e Git: GitOps funziona con qualsiasi componente. Puoi continuare a utilizzare i tuoi server CI e Git preferiti, repository di immagini e suite di test. Quasi tutti gli altri strumenti di distribuzione continua sul mercato richiedono un proprio server CI/Git o un repository di immagini. Questo potrebbe diventare un fattore limitante nello sviluppo del cloud nativo. Con GitOps puoi utilizzare strumenti familiari.
- Gli eventi come strumento di integrazione: Non appena i dati in Git vengono aggiornati, Weave Flux (o l'operatore Weave Cloud) avvisa il runtime. Ogni volta che Kubernetes accetta un set di modifiche, Git viene aggiornato. Ciò fornisce un semplice modello di integrazione per organizzare i flussi di lavoro per GitOps, come mostrato di seguito.
conclusione
GitOps fornisce le solide garanzie di aggiornamento richieste da qualsiasi moderno strumento CI/CD:
- automazione;
- convergenza;
- idempotenza;
- determinismo.
Questo è importante perché offre un modello operativo per gli sviluppatori nativi del cloud.
- Gli strumenti tradizionali per la gestione e il monitoraggio dei sistemi sono associati ai team operativi che operano all'interno di un runbook (una serie di procedure e operazioni di routine - trad. ca.), legato ad uno specifico impiego.
- Nella gestione nativa del cloud, gli strumenti di osservabilità rappresentano il modo migliore per misurare i risultati delle distribuzioni in modo che il team di sviluppo possa rispondere rapidamente.
Immagina molti cluster sparsi su cloud diversi e molti servizi con i propri team e piani di distribuzione. GitOps offre un modello invariante di scala per gestire tutta questa abbondanza.
PS da traduttore
Leggi anche sul nostro blog:
- «";
- «";
- «'.
Solo gli utenti registrati possono partecipare al sondaggio. Per favore.
Conoscevi GitOps prima che queste due traduzioni apparissero su Habré?
-
Sì, sapevo tutto
-
Solo superficialmente
-
No
35 utenti hanno votato. 10 utenti si sono astenuti.
Fonte: habr.com