Esercitazione: implementare CI/CD con GitOps (Flux v2)

In questa esercitazione si configurerà una soluzione CI/CD usando GitOps con Flux v2 e cluster Kubernetes abilitati per Azure Arc o cluster del servizio Azure Kubernetes. Usando l'app Azure Vote di esempio è possibile:

Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

Azure Cloud Shell

Azure Cloud Shell è un ambiente di shell interattivo ospitato in Azure e usato tramite il browser. È possibile usare Bash o PowerShell con Cloud Shell per usare i servizi di Azure. È possibile usare i comandi preinstallati di Cloud Shell per eseguire il codice contenuto in questo articolo senza dover installare strumenti nell'ambiente locale.

Per avviare Azure Cloud Shell:

Opzione	Esempio/Collegamento
Selezionare Prova nell'angolo superiore destro di un blocco di codice o di comando. Quando si seleziona Prova, il codice o il comando non viene copiato automaticamente in Cloud Shell.
Passare a https://shell.azure.com o selezionare il pulsante Avvia Cloud Shell per aprire Cloud Shell nel browser.
Selezionare il pulsante Cloud Shell nella barra dei menu nell'angolo in alto a destra del portale di Azure.

Per usare Azure Cloud Shell:

1. Avviare Cloud Shell.

2. Selezionare il pulsante Copia in un blocco di codice (o in un blocco di comando) per copiare il codice o il comando.

3. Incollare il codice o il comando nella sessione di Cloud Shell selezionando CTRL+MAIUSC+V in Windows e Linux o selezionando CMD+MAIUSC+V in macOS.

4. Premere Invio per eseguire il codice o il comando.

Prerequisiti

• Completare l'esercitazione precedente per informazioni su come distribuire GitOps per l'ambiente CI/CD.

• Spiegare i vantaggi e l'architettura di questa funzionalità.

• Verificare di avere:

  • Un cluster Kubernetes abilitato per Azure Arc connesso denominato arc-cicd-cluster.
  • Registro Azure Container connesso con l'integrazione del servizio Azure Kubernetes o l'autenticazione del cluster non del servizio Azure Kubernetes.

• Installare le versioni più recenti di queste estensioni dell'interfaccia della riga di comando di Configurazione di Kubernetes e Kubernetes abilitato per Azure Arc:

  az extension add --name connectedk8s
  az extension add --name k8s-configuration
  

  • Eseguire i comandi seguenti per aggiornare le estensioni alle versioni più recenti:

    az extension update --name connectedk8s
    az extension update --name k8s-configuration
    

Connettere Registro Azure Container a Kubernetes

Abilitare il cluster Kubernetes per eseguire il pull delle immagini da Registro Azure Container. Se è privato, è necessaria l'autenticazione.

Connettere Registro Azure Container a cluster del servizio Azure Kubernetes esistenti

Integrare un Registro Azure Container esistente con cluster del servizio Azure Kubernetes esistenti usando il comando seguente:

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

Creare un segreto pull di immagini

Per connettere cluster non del servizio Azure Kubernetes e locali a Registro Azure Container, creare un segreto pull di immagini. Kubernetes usa segreti pull di immagini per archiviare le informazioni necessarie per autenticare il registro.

Creare un segreto pull di immagini con il comando kubectl seguente. Ripetere sia per gli spazi dei nomi dev che per gli spazi dei nomi stage.

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

Per evitare di dover impostare un oggetto imagePullSecret per ogni pod, è consigliabile aggiungere imagePullSecret all'account del servizio negli spazi dei nomi dev e stage. Per altre informazioni, vedere l'esercitazione su Kubernetes.

A seconda dell'agente di orchestrazione CI/CD preferito, è possibile procedere con le istruzioni per Azure DevOps o per GitHub.

Implementare integrazione continua e recapito continuo (CI/CD) con Azure DevOps

Questa esercitazione presuppone familiarità con Azure DevOps, Azure Repos e Pipeline e l'interfaccia della riga di comando di Azure.

Prima di tutto, assicurarsi di completare i passaggi seguenti:

• Accedere ad Azure DevOps Services.
• Accertarsi di possedere autorizzazioni di "amministratore build" e "amministratore progetto" per Azure Repos e Azure Pipelines.

Importare repository di applicazioni e GitOps in Azure Repos

Importare un repository di applicazioni e un repository GitOps in Azure Repos. Per questa esercitazione, usare i repository di esempio seguenti:

• Repository dell'applicazione arc-cicd-demo-src

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Contiene l'esempio di app Azure Vote che verrà distribuita usando GitOps.
  • Importare il repository con nome arc-cicd-demo-src

• Repository GitOps arc-cicd-demo-gitops

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Funziona come base per le risorse del cluster che ospitano l'app Azure Vote.
  • Importare il repository con nome arc-cicd-demo-gitops

Altre informazioni sull'importazione di repository Git.

Connettere il repository GitOps

Per distribuire continuamente l'app, connettere il repository dell'applicazione al cluster usando GitOps. Il repository GitOps arc-cicd-demo-gitops contiene le risorse di base per rendere operativa l'app nel cluster arc-cicd-cluster.

Il repository GitOps iniziale contiene solo un manifesto che crea gli spazi dei nomi dev e stage corrispondenti agli ambienti di distribuzione.

La connessione GitOps creata eseguirà le seguenti operazioni in modo automatico:

• Sincronizzare i manifesti nella directory del manifesto.
• Aggiornare lo stato del cluster.

Il flusso di lavoro CI/CD popola la directory del manifesto con manifesti aggiuntivi per distribuire l'app.

1. Creare una nuova connessione GitOps al repository appena importato arc-cicd-demo-gitops in Azure Repos.

   az k8s-configuration flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace flux-system \
      --resource-group myResourceGroup \
      -u https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
      --https-user <Azure Repos username> \
      --https-key <Azure Repos PAT token> \
      --scope cluster \
      --cluster-type connectedClusters \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

   Suggerimento

   Per un cluster del servizio Azure Kubernetes (anziché un cluster abilitato per Arc), usare -cluster-type managedClusters.

2. Controllare lo stato della distribuzione nel portale di Azure.

   • In caso di esito positivo, verranno visualizzati sia gli spazi dei nomi dev che gli spazi dei nomi stage creati nel cluster.
   • È anche possibile verificare che nella pagina del portale di Azure del cluster venga creata una configurazione cluster-config nella scheda GitOps.

Importare le pipeline CI/CD

Dopo aver sincronizzato una connessione GitOps, sarà necessario importare le pipeline CI/CD che creano i manifesti.

Il repository dell'applicazione contiene una cartella .pipeline con le pipeline che verranno usate per le richieste pull, l'integrazione continua e la distribuzione continua. Importare e rinominare le tre pipeline fornite nel repository di esempio:

Connettere Registro Azure Container ad Azure DevOps

Durante il processo di integrazione continua si distribuiranno i contenitori dell'applicazione in un registro. Per iniziare, creare una connessione al servizio di Azure:

1. In Azure DevOps aprire la pagina Connessioni al servizio dalla pagina delle impostazioni del progetto. In TFS aprire la pagina Servizi dall'icona Impostazioni nella barra dei menu superiore.
2. Scegliere + Nuova connessione al servizio e selezionare il tipo di connessione al servizio necessaria.
3. Specificare i parametri per la connessione del servizio. Per questa esercitazione:
   • Denominare la connessione al servizio arc-demo-acr.
   • Selezionare myResourceGroup come gruppo di risorse.
4. Selezionare Concedi l'autorizzazione di accesso a tutte le pipeline.
   • Questa opzione autorizza i file della pipeline YAML per le connessioni al servizio.
5. Scegliere OK per creare la connessione.

Configurare la connessione al servizio di richiesta pull

La pipeline di distribuzione continua modifica le richieste pull nel repository GitOps. Per eseguire questa operazione, è necessaria una connessione al servizio. Per configurare questa connessione:

1. In Azure DevOps aprire la pagina Connessioni al servizio dalla pagina delle impostazioni del progetto. In TFS aprire la pagina Servizi dall'icona Impostazioni nella barra dei menu superiore.
2. Scegliere + Nuova connessione al servizio e selezionare il tipo Generic.
3. Specificare i parametri per la connessione del servizio. Per questa esercitazione:
   • URL del server https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
   • Lasciare vuoti Nome utente e Password.
   • Denominare la connessione al servizio azdo-pr-connection.
4. Selezionare Concedi l'autorizzazione di accesso a tutte le pipeline.
   • Questa opzione autorizza i file della pipeline YAML per le connessioni al servizio.
5. Scegliere OK per creare la connessione.

Installare GitOps Connector

1. Aggiungere il repository GitOps Connector ai repository Helm:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Installare il connettore nel cluster:

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=AZDO \
         --set ciCdOrchestratorType=AZDO \
         --set gitOpsOperatorType=FLUX \
         --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
         --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
         --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
         --set orchestratorPAT=<Azure Repos PAT token>
   

   Nota

   Azure Repos PAT token deve avere autorizzazioni Build: Read & execute e Code: Full.

3. Configurare Flux per inviare notifiche al connettore GitOps:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config 
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Per informazioni dettagliate sull'installazione, vedere il repository GitOps Connector.

Creare gruppi di variabili di ambiente

Gruppo di variabili del repository di app

Creare un gruppo di variabili denominato az-vote-app-dev. Imposta i valori seguenti:

Gruppo di variabili di ambiente di staging

1. Clonare il gruppo di variabili az-vote-app-dev.
2. Modificare il nome in az-vote-app-stage.
3. Verificare i valori seguenti per le variabili corrispondenti:

È ora possibile eseguire la distribuzione negli ambienti dev e stage.

Creazione di ambienti

Nel progetto Azure DevOps creare gli ambienti Dev e Stage. Per informazioni dettagliate, vedere Creare un ambiente e sceglierlo come destinazione.

Concedere altre autorizzazioni al servizio di compilazione

La pipeline CD usa il token di sicurezza della compilazione in esecuzione per eseguire l'autenticazione nel repository GitOps. Sono necessarie altre autorizzazioni per la pipeline per creare un nuovo ramo, eseguire il push delle modifiche e creare richieste pull.

1. Passare a Project settings dalla pagina principale del progetto Azure DevOps.
2. Selezionare Repos/Repositories.
3. Selezionare Security.
4. Per <Project Name> Build Service (<Organization Name>) e Project Collection Build Service (<Organization Name>) (digitare nel campo di ricerca, se non viene visualizzato), consentire Contribute, Contribute to pull requests e Create branch.
5. Passare a Pipelines/Settings
6. Disattivare l'opzione Protect access to repositories in YAML pipelines

Per altre informazioni, vedi:

• Concedere autorizzazioni di cluster virtuale al servizio di compilazione
• Gestire le autorizzazioni dell'account del servizio di compilazione

Distribuire l'ambiente di sviluppo per la prima volta

Dopo aver creato le pipeline di integrazione continua e distribuzione continua, eseguire la pipeline i integrazione continua per distribuire l'app per la prima volta.

Pipeline di integrazione continua

Durante l'esecuzione iniziale della pipeline di integrazione continua, è possibile che venga visualizzato un errore di autorizzazione della risorsa durante la lettura del nome della connessione al servizio.

1. Verificare che la variabile a cui si accede sia AZURE_SUBSCRIPTION.
2. Autorizzare l'uso.
3. Eseguire di nuovo la pipeline.

La pipeline di integrazione continua:

• Assicura che la modifica dell'applicazione superi tutti i controlli di qualità automatizzati per la distribuzione.
• Esegue qualsiasi convalida aggiuntiva che non è stato possibile completare nella pipeline di richiesta pull.
  • Specifica di GitOps, la pipeline pubblica anche gli artefatti per il commit che verrà distribuito dalla pipeline di distribuzione continua.
• Verifica che l'immagine Docker sia stata modificata e che venga eseguito il push della nuova immagine.

Pipeline di distribuzione continua

Durante l'esecuzione iniziale della pipeline di distribuzione continua, occorre concedere alla pipeline l'accesso al repository GitOps. Selezionare Visualizza quando viene comunicato che la pipeline deve richiedere l'autorizzazione per accedere a una risorsa. Selezionare quindi Consenti per concedere l'autorizzazione per usare il repository GitOps per le esecuzioni correnti e future della pipeline.

L'esecuzione corretta della pipeline di integrazione continua attiva la pipeline di distribuzione continua per completare il processo di distribuzione. Si distribuirà in ogni ambiente in modo incrementale.

Dopo aver generato il modello e il manifesto nel repository GitOps, la pipeline CD crea un commit, esegue il push e crea una richiesta pull per l'approvazione.

1. Trovare la richiesta pull creata dalla pipeline nel repository GitOps.

2. Verificare le modifiche apportate al repository GitOps. Dovrebbe essere visualizzato quanto segue:

   • Modifiche generali al modello Helm.
   • Manifesti Kubernetes approfonditi che mostrano le modifiche sottostanti allo stato desiderato. Flux distribuisce questi manifesti.

3. Se tutto sembra corretto, approvare e completare la richiesta pull.

4. Dopo alcuni minuti, Flux preleva la modifica e avvia la distribuzione.

5. Monitorare lo stato del commit Git nella scheda Cronologia commit. Non appena è succeeded, la pipeline di distribuzione continua avvia il test automatizzato.

6. Inoltrare la porta in locale usando kubectl e assicurarsi che l'app funzioni correttamente usando:

   kubectl port-forward -n dev svc/azure-vote-front 8080:80
   

7. Visualizzare l'app Azure Vote nel browser in http://localhost:8080/.

8. Votare per i preferiti e prepararsi ad apportare alcune modifiche all'app.

Configurare le approvazioni dell'ambiente

Durante la distribuzione dell'app, non solo è possibile apportare modifiche al codice o ai modelli, ma è anche possibile inserire involontariamente il cluster in uno stato non valido.

Se l'ambiente di sviluppo rivela un'interruzione dopo la distribuzione, non passare agli ambienti successivi usando le approvazioni dell'ambiente.

1. Nel progetto Azure DevOps passare all'ambiente che deve essere protetto.
2. Passare ad Approvazioni e controlli per la risorsa.
3. Seleziona Crea.
4. Specificare i responsabili approvazione e un messaggio facoltativo.
5. Selezionare di nuovo Crea per completare l'aggiunta del controllo di approvazione manuale.

Per altre informazioni, vedere l'esercitazione Definire l'approvazione e i controlli.

Alla successiva esecuzione della pipeline CD, la pipeline verrà sospesa dopo la creazione della richiesta pull di GitOps. Verificare che la modifica sia stata sincronizzata correttamente e che passi le funzionalità di base. Approvare il controllo dalla pipeline per consentire il flusso di modifica all'ambiente successivo.

Apportare una modifica all'applicazione

Con questo set di base di modelli e manifesti che rappresentano lo stato nel cluster, si apporta una piccola modifica all'app.

1. Nel repository arc-cicd-demo-src modificare il file azure-vote/src/azure-vote-front/config_file.cfg.

2. Poiché "Cani e gatti" non riceve voti sufficienti, modificarlo in "Schede e spazi" per aumentare il conteggio dei voti.

3. Eseguire il commit della modifica in un nuovo ramo, eseguirne il push e creare una richiesta pull. Si tratta del tipico flusso di sviluppo che avvierà il ciclo di vita CI/CD.

Pipeline di convalida della richiesta pull

La pipeline di richiesta pull è la prima linea di difesa contro una modifica difettosa. I controlli di qualità del codice dell'applicazione consueti includono l'analisi statica e il linting. Dal punto di vista di GitOps, è anche necessario garantire la stessa qualità per la distribuzione dell'infrastruttura risultante.

I grafici Dockerfile e Helm dell'applicazione possono usare il linting in modo analogo all'applicazione.

Errori rilevati durante l'intervallo di linting dai file YAML formattati in modo non corretto, ai suggerimenti sulle procedure consigliate, ad esempio l'impostazione dei limiti di CPU e memoria per l'applicazione.

Gli errori rilevati durante l'esecuzione della pipeline vengono visualizzati nella sezione dei risultati del test dell'esecuzione. Da qui puoi:

• Tenere traccia delle statistiche utili sui tipi di errore.
• Trovare il primo commit in cui sono stati rilevati.
• Lo stile di traccia dello stack collega alle sezioni di codice che hanno causato l'errore.

Al termine dell'esecuzione della pipeline, si è garantita la qualità del codice dell'applicazione e del modello che lo distribuisce. È ora possibile approvare e completare la richiesta pull. L'integrazione continua verrà eseguita nuovamente, rigenerando i modelli e i manifesti, prima di attivare la pipeline CD.

Approvazioni del processo di distribuzione continua

Un'esecuzione corretta della pipeline CI attiva la pipeline CD per completare il processo di distribuzione. Questa volta, la pipeline richiede l'approvazione di ogni ambiente di distribuzione.

1. Approvare la distribuzione nell'ambiente dev.
2. Dopo aver generato il modello e il manifesto nel repository GitOps, la pipeline CD crea un commit, esegue il push e crea una richiesta pull per l'approvazione.
3. Verificare le modifiche apportate al repository GitOps. Dovrebbe essere visualizzato:
   • Modifiche generali al modello Helm.
   • Manifesti Kubernetes approfonditi che mostrano le modifiche sottostanti allo stato desiderato.
4. Se tutto sembra corretto, approvare e completare la richiesta pull.
5. Attendere il completamento della distribuzione.
6. Come smoke test di base, passare alla pagina dell'applicazione e verificare che l'app di voto ora visualizzi Schede e spazi.
   • Inoltrare la porta in locale usando kubectl e assicurarsi che l'app funzioni correttamente usando: kubectl port-forward -n dev svc/azure-vote-front 8080:80
   • Visualizzare l'app Azure Vote nel browser in http://localhost:8080/ e verificare che le scelte di voto siano state modificate in Schede e spazi.
7. Ripetere i passaggi 1 e 7 per l'ambiente stage.

La distribuzione è completata.

Per una panoramica dettagliata di tutte le tecniche e i passaggi implementati nei flussi di lavoro CI/CD usati in questa esercitazione, vedere il diagramma di flusso GitOps di Azure DevOps.

Implementare integrazione continua e recapito continuo con GitHub

Questa esercitazione presuppone che si abbia familiarità con GitHub e GitHub Actions.

Creare una copia tramite fork di repository di applicazioni e GitOps

Creare una copia tramite fork di un repository di applicazioni e un repository GitOps. Per questa esercitazione, usare i repository di esempio seguenti:

• Repository dell'applicazione arc-cicd-demo-src

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Contiene l'esempio di app Azure Vote che verrà distribuita usando GitOps.

• Repository GitOps arc-cicd-demo-gitops

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Funziona come base per le risorse del cluster che ospitano l'app Azure Vote.

Connettere il repository GitOps

Per distribuire continuamente l'app, connettere il repository dell'applicazione al cluster usando GitOps. Il repository GitOps arc-cicd-demo-gitops contiene le risorse di base per rendere operativa l'app nel cluster arc-cicd-cluster.

Il repository GitOps iniziale contiene solo un manifesto che crea gli spazi dei nomi dev e stage corrispondenti agli ambienti di distribuzione.

La connessione GitOps creata eseguirà le seguenti operazioni in modo automatico:

• Sincronizzare i manifesti nella directory del manifesto.
• Aggiornare lo stato del cluster.

Il flusso di lavoro CI/CD popola la directory del manifesto con manifesti aggiuntivi per distribuire l'app.

1. Creare una nuova connessione GitOps al repository appena sottoposto a fork arc-cicd-demo-gitops in GitHub.

   az k8s-configuration flux create \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --namespace cluster-config \
      --resource-group myResourceGroup \
      -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
      --https-user <Azure Repos username> \
      --https-key <Azure Repos PAT token> \
      --scope cluster \
      --cluster-type connectedClusters \
      --branch master \
      --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests
   

2. Controllare lo stato della distribuzione nel portale di Azure.

   • In caso di esito positivo, verranno visualizzati sia gli spazi dei nomi dev che gli spazi dei nomi stage creati nel cluster.

Installare GitOps Connector

1. Aggiungere il repository GitOps Connector ai repository Helm:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

2. Installare il connettore nel cluster:

      helm upgrade -i gitops-connector gitops-connector/gitops-connector \
         --namespace flux-system \
         --set gitRepositoryType=GITHUB \
         --set ciCdOrchestratorType=GITHUB \
         --set gitOpsOperatorType=FLUX \
         --set gitHubGitOpsRepoName=arc-cicd-demo-src \
         --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
         --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
         --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
         --set orchestratorPAT=<GitHub PAT token>
   

3. Configurare Flux per inviare notifiche al connettore GitOps:

   cat <<EOF | kubectl apply -f -
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Alert
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     eventSeverity: info
     eventSources:
     - kind: GitRepository
       name: cluster-config
     - kind: Kustomization
       name: cluster-config-cluster-config
     providerRef:
       name: gitops-connector
   ---
   apiVersion: notification.toolkit.fluxcd.io/v1beta1
   kind: Provider
   metadata:
     name: gitops-connector
     namespace: flux-system
   spec:
     type: generic
     address: http://gitops-connector:8080/gitopsphase
   EOF
   

Per informazioni dettagliate sull'installazione, vedere il repository GitOps Connector.

Creare segreti di GitHub

Creare segreti di un repository GitHub

Creare segreti dell'ambiente GitHub

1. Creare un ambiente az-vote-app-dev con i segreti seguenti:

1. Creare un ambiente az-vote-app-stage con i segreti seguenti:

È ora possibile eseguire la distribuzione negli ambienti dev e stage.

Flusso di lavoro di sviluppo CI/CD

Per avviare il flusso di lavoro di sviluppo CI/CD, modificare il codice sorgente. Nel repository dell'applicazione aggiornare i valori nel file .azure-vote/src/azure-vote-front/config_file.cfg ed eseguire il push delle modifiche nel repository.

Il flusso di lavoro di sviluppo CI/CD:

• Assicura che la modifica dell'applicazione superi tutti i controlli di qualità automatizzati per la distribuzione.
• Esegue qualsiasi convalida aggiuntiva che non è stato possibile completare nella pipeline di richiesta pull.
• Verifica che l'immagine Docker sia stata modificata e che venga eseguito il push della nuova immagine.
• Pubblica gli artefatti (tag di immagine Docker, modelli di manifesto, utilità) che verranno usati dalle fasi CD seguenti.
• Distribuisce l'applicazione nell'ambiente di sviluppo.
  • Genera manifesti nel repository GitOps.
  • Crea una richiesta pull al repository GitOps per l'approvazione.

1. Trovare la richiesta pull creata dalla pipeline nel repository GitOps.

2. Verificare le modifiche apportate al repository GitOps. Dovrebbe essere visualizzato quanto segue:

   • Modifiche generali al modello Helm.
   • Manifesti Kubernetes approfonditi che mostrano le modifiche sottostanti allo stato desiderato. Flux distribuisce questi manifesti.

3. Se tutto sembra corretto, approvare e completare la richiesta pull.

4. Dopo alcuni minuti, Flux preleva la modifica e avvia la distribuzione.

5. Monitorare lo stato del commit Git nella scheda Cronologia commit. Non appena è succeeded, il flusso di lavoro CD Stage verrà avviato.

6. Inoltrare la porta in locale usando kubectl e assicurarsi che l'app funzioni correttamente usando:

   kubectl port-forward -n dev svc/azure-vote-front 8080:80
   

7. Visualizzare l'app Azure Vote nel browser in http://localhost:8080/.

8. Votare per i preferiti e prepararsi ad apportare alcune modifiche all'app.

Flusso di lavoro della fase CD

Il flusso di lavoro della fase CD viene avviato automaticamente dopo che Flux ha distribuito correttamente l'applicazione nell'ambiente di sviluppo e invia una notifica alle azioni di GitHub tramite GitOps Connector.

Il flusso di lavoro della fase CD:

• Esegue smoke test dell'applicazione nell'ambiente di sviluppo
• Distribuisce l'applicazione nell'ambiente di anteprima.
  • Genera manifesti nel repository GitOps
  • Crea una richiesta pull al repository GitOps per l'approvazione

Dopo che la richiesta pull dei manifesti nell'ambiente di anteprima è stata unita e Flux applica correttamente tutte le modifiche, lo stato del commit Git viene aggiornato nel repository GitOps. La distribuzione è completata.

Per una panoramica dettagliata di tutte le tecniche e i passaggi implementati nei flussi di lavoro CI/CD usati in questa esercitazione, vedere il diagramma di flusso GitOps di GitHub.

Pulire le risorse

Se non si intende continuare a usare questa applicazione, eliminare le risorse seguendo questa procedura:

1. Eliminare la connessione di configurazione di GitOps di Azure Arc:

   az k8s-configuration flux delete \
         --name cluster-config \
         --cluster-name arc-cicd-cluster \
         --resource-group myResourceGroup \
         -t connectedClusters --yes
   

2. Eliminare GitOps Connector:

   helm uninstall gitops-connector -n flux-system
   kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
   kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system
   

Passaggi successivi

In questa esercitazione è stato configurato un flusso di lavoro CI/CD completo che implementa DevOps dallo sviluppo di applicazioni tramite la distribuzione. Le modifiche apportate all'app attivano automaticamente la convalida e la distribuzione, gestite dalle approvazioni manuali.

Passare all'articolo concettuale per altre informazioni su GitOps e sulle configurazioni con Kubernetes abilitato per Azure Arc.