Condividi tramite

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

  • Articolo

In questa esercitazione viene configurata una soluzione CI/CD usando GitOps con Flux v2 e i cluster Kubernetes abilitati per Azure Arc o servizio Azure Kubernetes (AKS). Usando l'app Azure Vote di esempio, è possibile:

  • Connettere l'applicazione e i repository GitOps ad Azure Devops (Azure Repos) o a GitHub.
  • Implementare il flusso CI/CD con Azure Pipelines o GitHub.
  • Connettere Registro Azure Container ad Azure DevOps e Kubernetes.
  • Creare segreti o gruppi di variabili di ambiente.
  • Distribuire gli ambienti dev e stage.
  • Testare gli ambienti applicativi.

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

Prerequisiti

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:

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:

Altre informazioni sull'importazione di repository Git.

Nota

L'importazione e l'uso di due repository separati per le applicazioni e i repository GitOps possono migliorare la sicurezza e la semplicità. Le autorizzazioni e la visibilità dei repository GitOps e dell'applicazione possono essere ottimizzate singolarmente. Ad esempio, l'amministratore del cluster potrebbe non trovare le modifiche nel codice dell'applicazione pertinenti allo stato desiderato del cluster. Al contrario, uno sviluppatore di applicazioni non deve conoscere i parametri specifici per ogni ambiente. Un set di valori di test che forniscono copertura per i parametri può essere sufficiente.

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 sincronizza automaticamente i manifesti nella directory del manifesto e aggiorna 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, vengono visualizzati sia dev stage gli spazi dei nomi che gli spazi dei nomi 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, è 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:

Nome file di pipeline Descrizione
.pipelines/az-vote-pr-pipeline.yaml Pipeline di richiesta pull dell'applicazione denominata arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml Pipeline CI dell'applicazione denominata arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml Pipeline CD dell'applicazione denominata arc-cicd-demo-src CD

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 Salva per creare la connessione.

Configurare la connessione al servizio di richiesta pull

La pipeline cd modifica le richieste pull nel repository GitOps, che richiede 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 Salva 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:

Variabile valore
AZURE_SUBSCRIPTION (connessione al servizio di Azure, che deve essere quella precedente denominata arc-demo-acr nell'esercitazione)
AZ_ACR_NAME Nome del Registro Azure Container, ad esempio arc-demo-acr
ENVIRONMENT_NAME Sviluppo
MANIFESTS_BRANCH master
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Nome dell'organizzazione di Azure DevOps
PROJECT_NAME Nome del progetto GitOps in Azure DevOps
REPO_URL URL completo per il repository GitOps
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev
VOTE_APP_TITLE Applicazione di voto
AKS_RESOURCE_GROUP Gruppo di risorse del servizio Azure Kubernetes. Necessario per i test automatizzati.
AKS_NAME Nome del servizio Azure Kubernetes. Necessario per i test automatizzati.

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:

    Variabile valore
    ENVIRONMENT_NAME Fase
    TARGET_NAMESPACE stage

È 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 e usare ambienti di 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. Per abilitare queste autorizzazioni:

  1. In Azure DevOps, apri Impostazioni di progetto.
  2. In Repository selezionare Repository.
  3. Seleziona Sicurezza.
  4. Trovare <Project Name> Build Service (<Organization Name>) e Project Collection Build Service (<Organization Name>) (usare la ricerca se non vengono visualizzati) e consentire Contributi, Contribuire alle richieste pull e Crea ramo.
  5. In Pipeline selezionare Impostazioni.
  6. Disattivare l'opzione Proteggi l'accesso ai repository nelle pipeline YAML.

Per altre informazioni, vedere Concedere le autorizzazioni di controllo della versione al servizio di compilazione e 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 CI, se viene visualizzato un errore di autorizzazione della risorsa durante la lettura del nome della connessione al servizio, eseguire le operazioni seguenti:

  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 esegue la distribuzione in ogni ambiente in modo incrementale.

Suggerimento

Se la pipeline di distribuzione continua non viene attivata automaticamente:

  1. Verificare che il nome corrisponda al trigger di ramo in .pipelines/az-vote-cd-pipeline.yaml
    • Il valore dovrebbe essere arc-cicd-demo-src CI.
  2. Eseguire nuovamente la pipeline di integrazione continua.

Dopo aver generato il modello e il manifesto nel repository GitOps, la pipeline cd crea un commit, lo inserisce 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 git commit stato nella scheda Cronologia commit. Una volta che è succeeded, la pipeline cd 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, è 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, l'abilitazione delle approvazioni dell'ambiente consente di evitare il problema dagli ambienti successivi.

  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 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 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 del 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.

Nota

Per ottenere la migliore copertura da Helm linting in un'applicazione reale, sostituire i valori ragionevolmente simili ai valori che verrebbero usati in un ambiente reale.

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.

L'esecuzione della pipeline termina, confermando la qualità del codice dell'applicazione e il modello che la distribuisce. È ora possibile approvare e completare la richiesta pull. L'integrazione continua viene eseguita nuovamente, rigenerando i modelli e i manifesti, prima di attivare la pipeline cd.

Suggerimento

In un ambiente reale assicurarsi di impostare criteri di ramo per assicurarsi che la richiesta pull superi i controlli di qualità. Per altre informazioni, vedere Branch policies and settings .For more information, see Branch policies and settings.

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 test di smoke test di base, passare alla pagina dell'applicazione e verificare che l'app di voto ora visualizzi Tabulazioni 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:

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.

Connessione GitOps creata automaticamente:

  • 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, vengono visualizzati sia dev stage gli spazi dei nomi che gli spazi dei nomi 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

Il passaggio successivo consiste nel creare segreti di ambiente e repository GitHub.

Creare segreti di un repository GitHub

Usare i valori seguenti per i segreti del repository GitHub:

Segreto Valore
AZURE_CREDENTIALS Credenziali per Azure nel formato seguente {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID":"GUID"}
AZ_ACR_NAME Nome del Registro Azure Container, ad esempio arc-demo-acr
MANIFESTS_BRANCH master
MANIFESTS_FOLDER arc-cicd-cluster
MANIFESTS_REPO https://github.com/your-organization/arc-cicd-demo-gitops
VOTE_APP_TITLE Applicazione di voto
AKS_RESOURCE_GROUP Gruppo di risorse del servizio Azure Kubernetes. Necessario per i test automatizzati.
AKS_NAME Nome del servizio Azure Kubernetes. Necessario per i test automatizzati.
PAT Token PAT di GitHub con l'autorizzazione per la richiesta pull al repository GitOps

Creare segreti dell'ambiente GitHub

  1. Creare un ambiente az-vote-app-dev con i segreti seguenti:
Segreto Valore
ENVIRONMENT_NAME Sviluppo
TARGET_NAMESPACE dev
  1. Creare un ambiente az-vote-app-stage con i segreti seguenti:
Segreto Valore
ENVIRONMENT_NAME Fase
TARGET_NAMESPACE stage

È 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, Utils) 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.

Al termine di questi passaggi:

  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 git commit stato nella scheda Cronologia commit. Una volta che è succeeded, viene avviato il CD Stage flusso di lavoro.

  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 viene 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.

Concetto: processo CD con GitOpsImplementazione di esempio: esplorare il flusso CI/CD con GitOps