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

Articolo
01/10/2024

In questa esercitazione si configurerà 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:

Creare un cluster Kubernetes o servizio Azure Kubernetes abilitato per Azure Arc.
Connessione l'applicazione e i repository GitOps in Azure Repos o GitHub.
Implementare il flusso CI/CD con Azure Pipelines o GitHub.
Connessione il Registro Azure Container ad Azure DevOps e Kubernetes.
Creare gruppi di variabili di ambiente o segreti.
Distribuire gli dev ambienti e stage .
Testare gli ambienti dell'applicazione.

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 in questo articolo, senza dover installare alcun elemento nell'ambiente locale.

Per avviare Azure Cloud Shell:

Opzione	Esempio/Collegamento
Selezionare Prova nell'angolo superiore destro di un codice o di un blocco di comandi. Selezionando Prova non viene copiato automaticamente il codice o il comando 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:

Avviare Cloud Shell.
Selezionare il pulsante Copia in un blocco di codice (o blocco di comandi) per copiare il codice o il comando.
Incollare il codice o il comando nella sessione di Cloud Shell selezionando CTRL+MAIUSC+V in Windows e Linux oppure selezionando CMD+MAIUSC+V in macOS.
Selezionare INVIO per eseguire il codice o il comando.

Prerequisiti

Completare l'esercitazione precedente per informazioni su come distribuire GitOps per l'ambiente CI/CD.
Comprendere i vantaggi e l'architettura di questa funzionalità.
Verificare di avere:
- Un cluster Kubernetes abilitato per Azure Arc connesso denominato arc-cicd-cluster.
- Un Registro Azure Container connesso con l'integrazione del servizio Azure Kubernetes o l'autenticazione del cluster non servizio Azure Kubernetes.
Installare le versioni più recenti di queste estensioni dell'interfaccia della riga di comando di Configurazione di Kubernetes e Kubernetes abilitate per Azure Arc:
```
az extension add --name connectedk8s
az extension add --name k8s-configuration
```
- Per aggiornare queste estensioni alla versione più recente, eseguire i comandi seguenti:
```
az extension update --name connectedk8s
az extension update --name k8s-configuration
```

Connessione Registro Azure Container a Kubernetes

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

Connessione Registro Azure Container ai cluster del servizio Azure Kubernetes esistenti

Integrare un Registro Azure Container esistente con i 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 al 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 seguente kubectl . Ripetere sia per gli spazi dei nomi che per gli devstage spazi dei nomi .

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 elemento imagePullSecret per ogni pod, è consigliabile aggiungere imagePullSecret all'account dev del servizio negli spazi dei nomi 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.
Verificare di disporre delle autorizzazioni "Build Amministrazione" e "Project Amministrazione" 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 di applicazioni arc-cicd-demo-src
- URL: https://github.com/Azure/arc-cicd-demo-src
- Contiene l'esempio di app Azure Vote che verrà distribuita con GitOps.
- Importare il repository con il 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 il nome arc-cicd-demo-gitops

Altre informazioni sull'importazione di repository Git.

Nota

L'importazione e l'uso di due repository separati per l'applicazione 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.

Connessione 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 di sviluppo e fase corrispondenti agli ambienti di distribuzione.

La 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 manifesto con manifesti aggiuntivi per distribuire l'app.

Creare una nuova connessione GitOps al repository arc-cicd-demo-gitops appena importato 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é per un cluster abilitato per Arc), usare -cluster-type managedClusters.

Controllare lo stato della distribuzione in portale di Azure.
- In caso di esito positivo, verranno visualizzati sia devstage gli spazi dei nomi che gli spazi dei nomi creati nel cluster.
- È anche possibile verificare che nella pagina portale di Azure del cluster venga creata una configurazione cluster-config nella scheda fGitOps.

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 .pipeline cartella con pipeline 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 della 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

Connessione Registro Azure Container ad Azure DevOps

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

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

Configurare la connessione al servizio pull

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

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

Installare GitOps Connessione or

Aggiungere repository GitOps Connessione or ai repository Helm:

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

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 disporre di Build: Read & execute autorizzazioni e Code: Full .

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 Connessione or.

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	(il servizio di Azure Connessione ion, che deve essere arc-demo-acr precedente 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 servizio Azure Kubernetes. Necessario per i test automatizzati.

Gruppo di variabili di ambiente di staging

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

Variabile	Valore
ENVIRONMENT_NAME	Fase
TARGET_NAMESPACE	`stage`

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

Creazione di ambienti

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

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.

Passare alla Project settings pagina principale del progetto Azure DevOps.
Selezionare Repos/Repositories.
Selezionare Security.
<Project Name> Build Service (<Organization Name>) Per e per Project Collection Build Service (<Organization Name>) (digitare nel campo di ricerca, se non viene visualizzato), consentire Contribute, Contribute to pull requestse Create branch.
Passare a Pipelines/Settings
Opzione Disattiva Protect access to repositories in YAML pipelines

Per altre informazioni, vedi:

Distribuire l'ambiente di sviluppo per la prima volta

Dopo aver creato le pipeline CI e CD, eseguire la pipeline CI per distribuire l'app per la prima volta.

Pipeline CI

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

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

La pipeline CI:

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 cd.
Verifica che l'immagine Docker sia stata modificata e che venga eseguito il push della nuova immagine.

Pipeline cd

Durante l'esecuzione iniziale della pipeline cd, è necessario concedere alla pipeline l'accesso al repository GitOps. Selezionare Visualizza quando viene richiesto che la pipeline richieda l'autorizzazione per accedere a una risorsa. Selezionare quindi Consenti di concedere l'autorizzazione per usare il repository GitOps per le esecuzioni correnti e future della pipeline.

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

Suggerimento

Se la pipeline cd non viene attivata automaticamente:

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

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

Trovare la richiesta pull creata dalla pipeline nel repository GitOps.
Verificare le modifiche apportate al repository GitOps. Dovrebbe essere visualizzato quanto segue:
- Modifiche al modello Helm di alto livello.
- Manifesti Kubernetes di basso livello che mostrano le modifiche sottostanti allo stato desiderato. Flux distribuisce questi manifesti.
Se tutto sembra corretto, approvare e completare la richiesta pull.
Dopo alcuni minuti, Flux preleva la modifica e avvia la distribuzione.
Monitorare lo stato del commit Git nella scheda Cronologia commit. Una volta che è succeeded, la pipeline cd avvia il test automatizzato.
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 all'indirizzo http://localhost:8080/.
Votare per i preferiti e prepararsi a 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.

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

Per altri dettagli, vedere l'esercitazione Definire l'approvazione e i controlli .

Al successivo 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.

Nel repository arc-cicd-demo-src modificare azure-vote/src/azure-vote-front/config_file.cfg il file.
Poiché "Cats vs Dogs" non riceve voti sufficienti, modificarlo in "Tabs vs Spaces" per aumentare il conteggio dei voti.
Eseguire il commit della modifica in un nuovo ramo, eseguirne il push e creare una richiesta pull. Questa sequenza di passaggi è il flusso di sviluppo tipico che avvia 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 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, è necessario sostituire i valori ragionevolmente simili a quelli 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.

Al termine dell'esecuzione della pipeline, si è garantita la qualità del codice dell'applicazione e del modello che la 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.

Suggerimento

In un ambiente reale, non dimenticare di impostare criteri di ramo per assicurarsi che la richiesta pull superi i controlli di qualità. Per altre informazioni, vedere Impostare i criteri dei rami.

Approvazioni del processo CD

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.

Approvare la distribuzione nell'ambiente dev .
Dopo aver generato il modello e il manifesto nel repository GitOps, la pipeline cd crea un commit, lo esegue il push e crea una richiesta pull per l'approvazione.
Verificare le modifiche apportate al repository GitOps. Dovrebbe essere visualizzato:
- Modifiche al modello Helm di alto livello.
- Manifesti Kubernetes di basso livello che mostrano le modifiche sottostanti allo stato desiderato.
Se tutto sembra corretto, approvare e completare la richiesta pull.
Attendere il completamento della distribuzione.
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 http://localhost:8080/ in e verificare che le scelte di voto siano state modificate in Schede e spazi.
Ripetere i passaggi da 1 a 7 per l'ambiente stage .

La distribuzione è completata.

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

Implementare CI/CD con GitHub

Questa esercitazione presuppone la familiarità con GitHub, GitHub Actions.

Repository Fork per applicazioni e GitOps

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

repository di applicazioni 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.

Connessione repository GitOps

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

La 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 manifesto con manifesti aggiuntivi per distribuire l'app.

Creare una nuova connessione GitOps al repository arc-cicd-demo-gitops appena creato tramite fork 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

Controllare lo stato della distribuzione in portale di Azure.
- In caso di esito positivo, verranno visualizzati sia devstage gli spazi dei nomi che gli spazi dei nomi creati nel cluster.

Installare GitOps Connessione or

Aggiungere repository GitOps Connessione or ai repository Helm:

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

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>

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 Connessione or.

Creare segreti di GitHub

Creare 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 servizio Azure Kubernetes. Necessario per i test automatizzati.
Token di accesso personali	Token PAT di GitHub con l'autorizzazione per la richiesta pull al repository GitOps

Creare segreti dell'ambiente GitHub

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

Segreto	Valore
ENVIRONMENT_NAME	Sviluppo
TARGET_NAMESPACE	`dev`

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

Segreto	Valore
ENVIRONMENT_NAME	Fase
TARGET_NAMESPACE	`stage`

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

Flusso di lavoro sviluppo CI/CD

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

Flusso di lavoro 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) 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.

Trovare la richiesta pull creata dalla pipeline nel repository GitOps.
Verificare le modifiche apportate al repository GitOps. Dovrebbe essere visualizzato quanto segue:
- Modifiche al modello Helm di alto livello.
- Manifesti Kubernetes di basso livello che mostrano le modifiche sottostanti allo stato desiderato. Flux distribuisce questi manifesti.
Se tutto sembra corretto, approvare e completare la richiesta pull.
Dopo alcuni minuti, Flux preleva la modifica e avvia la distribuzione.
Monitorare lo stato del commit Git nella scheda Cronologia commit. Una volta che è succeeded, verrà avviato il CD Stage flusso di lavoro.
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 all'indirizzo http://localhost:8080/.
Votare per i preferiti e prepararsi a apportare alcune modifiche all'app.

Flusso di lavoro della fase CD

Il flusso di lavoro della fase CD viene avviato automaticamente dopo che Flux distribuisce correttamente l'applicazione nell'ambiente di sviluppo e invia una notifica a GitHub actions tramite GitOps Connessione or.

Flusso di lavoro della fase CD:

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

Dopo che la richiesta pull dei manifesti nell'ambiente stage viene 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 tutti i passaggi e le tecniche implementati nei flussi di lavoro CI/CD usati in questa esercitazione, vedere il diagramma di GitHub GitOps Flow.

Pulire le risorse

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

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

Eliminare GitOps Connessione or:

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.

Flusso di lavoro CI/CD concettuale con GitOps

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

Azure Cloud Shell

Prerequisiti

Connessione Registro Azure Container a Kubernetes

Connessione Registro Azure Container ai cluster del servizio Azure Kubernetes esistenti

Creare un segreto pull di immagini

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

Importare repository di applicazioni e GitOps in Azure Repos

Connessione repository GitOps

Importare le pipeline CI/CD

Connessione Registro Azure Container ad Azure DevOps

Configurare la connessione al servizio pull

Installare GitOps Connessione or

Creare gruppi di variabili di ambiente

Gruppo di variabili del repository di app

Gruppo di variabili di ambiente di staging

Creazione di ambienti

Concedere altre autorizzazioni al servizio di compilazione

Distribuire l'ambiente di sviluppo per la prima volta

Pipeline CI

Pipeline cd

Configurare le approvazioni dell'ambiente

Apportare una modifica all'applicazione

Pipeline di convalida della richiesta pull

Approvazioni del processo CD

Implementare CI/CD con GitHub

Repository Fork per applicazioni e GitOps

Connessione repository GitOps

Installare GitOps Connessione or

Creare segreti di GitHub

Creare segreti del repository GitHub

Creare segreti dell'ambiente GitHub

Flusso di lavoro sviluppo CI/CD

Flusso di lavoro della fase CD

Pulire le risorse

Passaggi successivi

Risorse aggiuntive