Flusso di lavoro di integrazione continua e recapito continuo con GitOps (Flux v2)

Le distribuzioni moderne di Kubernetes contengono più applicazioni, cluster e ambienti. Con GitOps è possibile gestire più facilmente queste configurazioni complesse, tenendo traccia dello stato desiderato degli ambienti Kubernetes in modo dichiarativo con Git. Usando gli strumenti Git comuni per dichiarare lo stato del cluster, è possibile aumentare la responsabilità, facilitare l'analisi degli errori e abilitare l'automazione per gestire gli ambienti.

Questo articolo descrive in che modo GitOps rientra nel ciclo di vita completo delle modifiche dell'applicazione usando Azure Arc, Azure Repos e Azure Pipelines. L'articolo fornisce anche un esempio di modifica di una singola applicazione in ambienti Kubernetes controllati da GitOps.

Architettura

Questo diagramma mostra il flusso di lavoro CI/CD di un'applicazione distribuita in uno o più ambienti Kubernetes.

Repository del codice dell'applicazione

Il repository dell'applicazione contiene il codice dell'applicazione su cui gli sviluppatori lavorano durante il ciclo interno. I modelli di distribuzione dell'applicazione si trovano in questo repository in un formato generico, ad esempio Helm o Kustomize. I valori specifici dell'ambiente non vengono archiviati nel repository.

Le modifiche apportate a questo repository richiamano una pipeline con richiesta pull o con integrazione continua che avvia il processo di distribuzione.

Registro contenitori

Il registro contenitori contiene tutte le immagini di prime e di terze parti usate negli ambienti Kubernetes. Le immagini delle applicazioni proprietarie sono contrassegnate con tag leggibili e il commit Git usato per compilare l'immagine. Le immagini di terze parti possono essere memorizzate nella cache per facilitare la sicurezza, la velocità e la resilienza. Impostare un piano per un test tempestivo e un'integrazione degli aggiornamenti della sicurezza.

Per altre informazioni, vedere Come usare e gestire il contenuto pubblico con le Attività del Registro Azure Container.

Pipeline di richieste pull

Le richieste pull inviate dagli sviluppatori al repository dell'applicazione vengono gestite in un'esecuzione corretta della pipeline di richieste pull. Questa pipeline esegue i controlli di qualità di base, ad esempio i controlli di linting e di unit test nel codice dell'applicazione. La pipeline testa l'applicazione ed esegue il linting di Dockerfiles e dei modelli Helm usati per la distribuzione in un ambiente Kubernetes. Le immagini Docker devono essere compilate e testate, ma non sottoposte a push. Mantenere la durata della pipeline relativamente breve per consentire un'iterazione rapida.

Pipeline di integrazione continua

La pipeline di integrazione continua dell'applicazione esegue tutti i passaggi della pipeline di richiesta pull, espandendo i controlli di test e distribuzione. La pipeline può essere eseguita per ogni commit principale oppure può essere eseguita a cadenza regolare con un gruppo di commit.

In questa fase è possibile eseguire dei test dell'applicazione che utilizzano una quantità di memoria eccessiva per la pipeline di richiesta pull, tra cui:

• Push di immagini nel registro contenitori
• Compilazione, linting e test delle immagini
• Generazione di modelli di file YAML non elaborati

Al termine della compilazione CI, vengono generati gli artefatti. Questi artefatti possono essere usati dal passaggio CD da utilizzare in preparazione alla distribuzione.

Estensione del cluster Flux

Flux è un agente che viene eseguito in ogni cluster come estensione del cluster. Questa estensione del cluster Flux è responsabile della gestione dello stato desiderato. L'agente esegue il polling del repository GitOps a un intervallo definito dall'utente, quindi riconcilia lo stato del cluster con lo stato dichiarato nel repository Git.

Per altre informazioni, vedere Esercitazione: Distribuire applicazioni con GitOps con Flux v2.

Pipeline di distribuzione continua

La pipeline CD viene attivata automaticamente dalle compilazioni CI riuscite. In questo ambiente della pipeline i valori specifici dell'ambiente vengono sostituiti nei modelli pubblicati in precedenza e viene generata una nuova richiesta pull nel repository GitOps con questi valori. Questa richiesta pull contiene le modifiche proposte allo stato desiderato di uno o più cluster Kubernetes. Gli amministratori del cluster esaminano la richiesta pull e approvano l'unione nel repository GitOps. La pipeline attende l'unione della richiesta pull, dopo la quale Flux sincronizza e applica le modifiche dello stato.

Repository GitOps

Il repository GitOps rappresenta lo stato desiderato corrente di tutti gli ambienti tra cluster. Qualsiasi modifica apportata a questo repository viene prelevata dal servizio Flux in ogni cluster e distribuita. Le modifiche allo stato desiderato dei cluster vengono presentate come richieste pull, che vengono quindi esaminate e infine unite dopo l'approvazione delle modifiche. Queste richieste pull contengono modifiche ai modelli di distribuzione e ai manifesti Kubernetes risultanti che sono sottoposti a rendering. I manifesti sottoposti a rendering di basso livello consentono un'analisi più attenta delle modifiche in genere non visualizzate a livello di modello.

Connettore GitOps

GitOps Connector crea una connessione tra l'agente Flux e la pipeline GitOps Repository/CD. Mentre le modifiche vengono applicate al cluster, Flux invia una notifica al connettore GitOps di ogni modifica della fase e del controllo integrità eseguiti. Questo componente funge da adattatore. Il componente comprende come comunicare con un repository Git e aggiorna lo stato del commit Git in modo che lo stato di sincronizzazione sia visibile nel repository GitOps. Al termine della distribuzione (a prescindere dall'esito, positivo o negativo), il connettore notifica alla pipeline CD di continuare in modo che la pipeline possa eseguire attività post-distribuzione, ad esempio i test di integrazione.

Cluster Kubernetes

Almeno un cluster Kubernetes abilitato per Azure Arc o il servizio Azure Kubernetes serve i diversi ambienti necessari per l'applicazione. Ad esempio un singolo cluster può servire sia un ambiente di sviluppo sia di controllo di qualità tramite spazi dei nomi diversi. Un secondo cluster può fornire una separazione più semplice degli ambienti e un controllo con granularità più fine.

Esempio di flusso di lavoro

Alice, sviluppatrice di applicazioni:

• Scrive il codice dell'applicazione.
• Determina come eseguire l'applicazione in un contenitore Docker.
• Definisce i modelli che eseguono il contenitore e i servizi dipendenti in un cluster Kubernetes.

Alice vuole assicurarsi che l'applicazione possa essere eseguita in più ambienti, ma non conosce le impostazioni specifiche di ogni ambiente.

Si supponga che Alice voglia apportare una modifica dell'applicazione in grado di cambiare l'immagine Docker usata nel modello di distribuzione dell'applicazione.

1. Alice modifica il modello di distribuzione, lo inserisce in un ramo remoto denominato alice nel repository dell'applicazione e apre una richiesta pull per la revisione nel ramo main.

2. Alice chiede al suo team di esaminare la modifica.

   • La pipeline di richiesta pull esegue la convalida.
   • Dopo un'esecuzione corretta della pipeline di richiesta pull e l'approvazione del team, la modifica viene unita.

3. La pipeline di integrazione continua avvia, convalida la modifica di Alice per poi essere completata correttamente.

   • La modifica è sicura da distribuire nel cluster e gli artefatti vengono salvati nell'esecuzione della pipeline di integrazione continua.

4. L'esecuzione corretta della pipeline CI attiva la pipeline CD.

   • La pipeline a distribuzione continua (CD) preleva gli artefatti archiviati dall'esecuzione della pipeline CI di Alice.
   • La pipeline CD sostituisce i modelli con valori specifici dell'ambiente ed esegue le fasi di tutte le modifiche dello stato del cluster esistente nel repository GitOps.
   • La pipeline CD crea una richiesta pull nel ramo di produzione del repository GitOps con le modifiche desiderate dello stato del cluster.

5. Il team di Alice esamina e approva la richiesta pull.

   • La modifica viene unita al ramo di destinazione corrispondente all'ambiente.

6. Entro pochi minuti Flux rileva una modifica nel repository GitOps ed esegue il pull della modifica di Alice.

   • A causa della modifica dell'immagine Docker, il pod dell'applicazione richiede un aggiornamento.
   • Flux applica la modifica al cluster.
   • Flux riporta lo stato della distribuzione al repository GitOps tramite GitOps Connector.

7. La pipeline CD esegue test automatizzati per verificare che la nuova distribuzione sia stata completata correttamente e funzioni come previsto.

   Nota

   Per gli ambienti aggiuntivi destinati alla distribuzione la pipeline CD esegue l'iterazione creando una richiesta pull per l'ambiente successivo e ripete i passaggi da 4 a 7. Il processo richiede un'approvazione aggiuntiva per le distribuzioni o gli ambienti più rischiosi, ad esempio una modifica correlata alla sicurezza o un ambiente di produzione.

8. Quando tutti gli ambienti hanno ricevuto distribuzioni riuscite, la pipeline viene completata.

Passaggi successivi

• Descrizione dell'esercitazione per implementare CI/CD con GitOps.
• Informazioni sulla creazione di connessioni tra il cluster e un repository Git con configurazioni Flux.