Esercizio: creare la pipeline di distribuzione
Dopo aver creato tutti i chart Helm, sono ora disponibili tutti gli strumenti necessari per distribuire l'applicazione nel servizio Azure Kubernetes usando GitHub Actions. In questa unità si completa la pipeline CI/CD completando i passaggi di distribuzione finali.
I passaggi di distribuzione includono:
- Creare il processo di distribuzione.
- Configurare Open ID Connessione (OIDC).
- Distribuire l'applicazione con Helm.
- Eseguire la distribuzione nell'ambiente di produzione.
Aggiungere il processo di distribuzione
In GitHub passare al fork del repository.
Espandere la directory .github/workflows e aprire il file build-staging.yml per la modifica.
Aggiungere un nuovo
deploy
processo alla fine del file, dopo ilbuild_push_image
processo, come indicato di seguito. Assicurarsi di corrispondere al rientro.Il processo ha tre chiavi:
runs-on
,needs
epermissions
.- Per
runs-on
, usareubuntu-20.04
per essere coerente con l'altro processo. - Per
needs
usare il nome del primo processo,build_push_image
, quindi l'applicazione viene distribuita solo dopo la compilazione dell'immagine - Per
permissions
aggiungere due argomenti denominatiid-token
econtents
. Impostare suid-token
write
econtents
suread
per concedere a GitHub Actions l'accesso per inviare richieste e leggere il contenuto del repository.
- Per
Aggiungere
- uses: actions/checkout@v2
come primo passaggio del processo.Il processo aggiunto
deploy
dovrebbe essere simile al codice seguente:deploy: runs-on: ubuntu-20.04 needs: build_push_image permissions: id-token: write contents: read steps: - uses: actions/checkout@v2
Aggiungere il passaggio Installa Helm
Usare un'azione GitHub per scaricare e installare la versione v3.3.1
Helm.
Nel pannello destro della pagina di modifica cercare il programma di installazione dello strumento Helm. Selezionare il primo risultato pubblicato da Azure.
Selezionare l'icona di copia per copiare il file YAML di utilizzo.
Copiare e incollare il codice YAML sotto la
uses
chiave in build-staging.yml.Rinominare il passaggio da
Helm tool installer
a e aggiungere laversion
chiave av3.3.1
Install Helm
.steps: - uses: actions/checkout@v2 - name: Install Helm uses: Azure/setup-helm@v1 with: version: v3.3.1
Aggiungere il passaggio di autenticazione dell'account di accesso di Azure
Usare OIDC per autenticare GitHub Actions per accedere al servizio Azure Kubernetes.
Nel pannello di destra cercare Account di accesso di Azure e selezionare Accesso di Azure pubblicato da Azure.
Selezionare l'icona di copia per copiare il file YAML di utilizzo e incollarlo sotto il
Install Helm
passaggio in build-staging.yml.Modificare il nome del passaggio da
Azure Login
aSign in to Azure with OIDC
.Azure Login
richiede tre parametri per l'autenticazione:client-id
,tenant-id
esubscription-id
. Compilare questi parametri con segnaposto per i segreti impostati in un secondo momento.- name: Sign in to Azure with OIDC uses: Azure/login@v1.5.1 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
Nel pannello di destra cercare set context (Set context) e selezionare Azure Kubernetes set context pubblicato da Azure.
Selezionare l'icona di copia per copiare il file YAML di utilizzo e incollarlo sotto il
Sign in to Azure with OIDC
passaggio in build-staging.yml. Compilare iresource-group
parametri ecluster-name
con segnaposto per i segreti impostati in un'unità precedente.- name: Azure Kubernetes set context uses: Azure/aks-set-context@v3 with: resource-group: ${{ secrets.RESOURCE_GROUP }} cluster-name: ${{ secrets.CLUSTER_NAME }}
Il file build-staging.yml dovrebbe essere simile all'esempio seguente:
name: Build and push the latest build to staging on: push: branches: [ main ] jobs: build_push_image: runs-on: ubuntu-20.04 steps: - uses: actions/checkout@v2 - name: Set up Buildx uses: docker/setup-buildx-action@v3.0.0 - name: Docker Login uses: docker/login-action@v3.0.0 with: registry: ${{ secrets.ACR_NAME }} username: ${{ secrets.ACR_LOGIN }} password: ${{ secrets.ACR_PASSWORD }} - name: Build and push staging images uses: docker/build-push-action@v5.0.0 with: context: . push: true tags: ${{secrets.ACR_NAME}}/contoso-website:latest deploy: runs-on: ubuntu-20.04 needs: build_push_image # Will wait for the execution of the previous job permissions: id-token: write # This is required for requesting the JWT contents: read # This is required for actions/checkout steps: - uses: actions/checkout@v2 - name: Install Helm uses: Azure/setup-helm@v1 with: version: v3.3.1 - name: Sign in to Azure with OIDC uses: Azure/login@v1.5.1 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: Azure Kubernetes set context uses: Azure/aks-set-context@v3 with: resource-group: ${{ secrets.RESOURCE_GROUP }} cluster-name: ${{ secrets.CLUSTER_NAME }}
Configura open ID Connect (OIDC)
Assegnare valori ai segreti creando un'entità servizio e i certificati per accedere con OIDC.
Creare l'entità servizio
In Azure Cloud Shell eseguire
az account show
e salvare ilid
valore dall'output.Creare un'entità servizio eseguendo il comando seguente, sostituendo il
id
valore del comando precedente per$SUBSCRIPTION_ID
:az ad sp create-for-rbac --scopes /subscriptions/$SUBSCRIPTION_ID --role Contributor
Copiare l'output JSON e salvarlo per il passaggio successivo.
Impostare i segreti
Nella pagina del repository GitHub selezionare la scheda Impostazioni e quindi selezionare Segreti e variabili>Azioni dal menu a sinistra. Definire i tre nuovi segreti seguenti che usano l'output dei passaggi precedenti.
AZURE_CLIENT_ID
: valore dell'output"appId"
az ad sp create-for-rbac
AZURE_TENANT_ID
: valore dell'output"tenant"
az ad sp create-for-rbac
AZURE_SUBSCRIPTION_ID
: valore dell'outputid
az account show
Per ogni segreto:
- Selezionare Nuovo segreto repository.
- In Nome immettere il nome del segreto.
- In Segreto immettere il valore .
- Selezionare Aggiungi segreto.
Aggiungere credenziali federate
Creare certificati federati per autorizzare GitHub Actions ad accedere all'applicazione.
Nel portale di Azure passare a Registrazioni app.
Cercare e selezionare l'applicazione che corrisponde al
displayName
valore restituito nel passaggio precedenteaz ad sp create-for-rbac
. Per impostazione predefinita, il nome dell'applicazione usa il timestamp della creazione dell'entità servizio.Verificare che i valori di appID (ID client), ID oggetto (ID oggetto applicazione) e ID directory (ID tenant) corrispondano all'output JSON precedente.
Nel riquadro di spostamento a sinistra selezionare Certificati e segreti.
Nella schermata Certificati e segreti selezionare la scheda Credenziali federate.
Selezionare Aggiungi credenziale.
Per aggiungere le credenziali di staging, nella schermata Aggiungi credenziali selezionare o immettere le informazioni seguenti:
- Scenario di credenziali federate: selezionare GitHub Actions che distribuisce le risorse di Azure.
- Organizzazione: immettere il nome utente di GitHub.
- Repository: immettere mslearn-aks-deployment-pipeline-github-actions.
- Tipo di entità: selezionare Ramo.
- Nome del ramo GitHub: immettere main.
- Nome: immettere staging-cred.
- Descrizione Immettere test.
Selezionare Aggiungi.
Per aggiungere le credenziali di produzione, selezionare di nuovo Aggiungi credenziali e nella schermata Aggiungi credenziali immettere tutti gli stessi valori delle credenziali precedenti, ad eccezione di:
- Tipo di entità: selezionare Tag.
- Nome tag GitHub: immettere v2.0.0, perché nel passaggio successivo si distribuisce la versione 2.
- Nome: immettere prod-cred.
Selezionare Aggiungi.
Distribuisci l'applicazione con Helm
Dopo aver configurato Helm e concesso l'accesso al cluster, si è pronti per distribuire l'applicazione.
Aggiungere il passaggio Esegui distribuzione Helm
Tornare al file build-staging.yml in GitHub, dopo il passaggio più recente del
deploy
processo, creare un nuovo passaggio denominatoRun Helm Deploy
. Sotto di esso aggiungere un'altra chiave denominatarun
.- name: Run Helm Deploy run:
Puoi usare la chiave
run
per eseguire qualsiasi comando della shell all'interno del contenitore. Questa pipeline usa larun
chiave per eseguire il comando Helm seguente:helm upgrade --install --create-namespace --atomic --wait --namespace staging contoso-website \ ./kubernetes/contoso-website \ --set image.repository=${{ secrets.ACR_NAME }} \ --set dns.name=${{ secrets.DNS_NAME }}
Comprendere le operazioni di ogni parametro:
Parametro Azione o valore helm upgrade
Aggiorna una versione installata. --install
Se la versione non esiste, la installa. --create-namespace
Se lo spazio dei nomi nel --namespace
flag non esiste, lo crea.--atomic
Se la versione non riesce, rimuove tutti i carichi di lavoro installati. --wait
Attende il completamento della versione e restituisce OK
lo stato.--namespace staging contoso-website
Distribuisce la contoso-website
versione nello spazio deistaging
nomi ../kubernetes/contoso-website
Posizione della directory dei chart. --set image.repository
Aggiornamenti il valore di image.repository
nel file values.yaml solo per questa versione.--set dns.name
Aggiornamenti la dns.name
chiave nel file values.yaml solo per questa versione.Aggiungere il comando al file e impostarlo per l'esecuzione, a partire dal
|
carattere . IlRun Helm deploy
passaggio deve corrispondere a questo esempio:... - name: Run Helm Deploy run: | helm upgrade \ --install \ --create-namespace \ --atomic \ --wait \ --namespace staging \ contoso-website \ ./kubernetes/contoso-website \ --set image.repository=${{ secrets.ACR_NAME }} \ --set dns.name=${{ secrets.DNS_NAME }}
Il file di build-staging.yml completato dovrebbe essere simile all'esempio seguente:
name: Build and push the latest build to staging on: push: branches: [ main ] jobs: build_push_image: runs-on: ubuntu-20.04 steps: - uses: actions/checkout@v2 - name: Set up Buildx uses: docker/setup-buildx-action@v3.0.0 - name: Docker Login uses: docker/login-action@v3.0.0 with: registry: ${{ secrets.ACR_NAME }} username: ${{ secrets.ACR_LOGIN }} password: ${{ secrets.ACR_PASSWORD }} - name: Build and push staging images uses: docker/build-push-action@v5.0.0 with: context: . push: true tags: ${{secrets.ACR_NAME}}/contoso-website:latest deploy: runs-on: ubuntu-20.04 needs: build_push_image # Waits for the execution of the previous job permissions: id-token: write # Required for requesting the JWT contents: read # Required for actions/checkout steps: - uses: actions/checkout@v2 - name: Install Helm uses: Azure/setup-helm@v1 with: version: v3.3.1 - name: Sign in to Azure with OIDC uses: Azure/login@v1.5.1 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: Azure Kubernetes set context uses: Azure/aks-set-context@v3 with: resource-group: ${{ secrets.RESOURCE_GROUP }} cluster-name: ${{ secrets.CLUSTER_NAME }} - name: Run Helm Deploy run: | helm upgrade \ --install \ --create-namespace \ --atomic \ --wait \ --namespace staging \ contoso-website \ ./kubernetes/contoso-website \ --set image.repository=${{ secrets.ACR_NAME }} \ --set dns.name=${{ secrets.DNS_NAME }}
Impostare il segreto DNS_NAME
In una nuova scheda del browser passare al fork del repository, selezionare la scheda Impostazioni e quindi selezionare Segreti e variabili>Azioni dal menu a sinistra.
Selezionare Nuovo segreto repository.
Per Nome inserisci
DNS_NAME
.Per Segreto immettere il valore nome zona DNS servizio Azure Kubernetes dall'output dello script di installazione originale.
Se questo valore non è disponibile, eseguire il comando seguente in Cloud Shell, sostituendo i valori per
<resource-group-name>
e<aks-cluster-name>
:az aks show -g <resource-group-name> -n <aks-cluster-name> -o tsv --query addonProfiles.httpApplicationRouting.config.HTTPApplicationRoutingZoneName
Selezionare Aggiungi segreto.
Eseguire il commit delle modifiche e testare la distribuzione di staging
Per eseguire il commit delle modifiche, selezionare Commit changes (Esegui il commit delle modifiche). Immettere una descrizione per il commit e quindi selezionare Commit changes (Esegui il commit delle modifiche).
Selezionare la scheda Azioni per visualizzare la compilazione in esecuzione.
Al termine della compilazione, nel browser passare a
contoso-staging.<aks-dns-zone-name>
per verificare che venga visualizzato il sito Web.
Eseguire la distribuzione nell'ambiente di produzione
Il passaggio successivo consiste nel creare il flusso di lavoro di produzione.
Nella directory .github/workflows del repository aprire il file build-production.yml per la modifica.
Copiare il
deploy
processo dalla pipeline di staging e incollarlo sotto l'ultima riga nel file build-production.yml .Modificare il passaggio per eseguire la
Run Helm Deploy
distribuzione nello spazio dei nomi di produzione modificando il--namespace
flag dastaging
aproduction
.Alla fine del comando Helm, aggiungi un nuovo parametro,
--set image.tag=${GITHUB_REF##*/}
.In questo caso si usa una funzionalità Bash denominata espansione dei parametri. L'espansione
${ENV##<wildcard><character>}
restituisce l'ultima occorrenza della stringa dopocharacter
.In questo caso, devi ottenere solo il nome del tag, rappresentato come runtime di GitHub Actions,
GITHUB_REF
. I rami sonorefs/heads/<branch>
, mentre i tag sonorefs/tags/<tag>
.Si vuole rimuovere
refs/tags/
per ottenere solo il nome del tag, quindi passare${GITHUB_REF##*/}
per restituire tutto dopo l'ultimo/
nellaGITHUB_REF
variabile di ambiente.Il file di build-production.yml finale dovrebbe essere simile all'esempio seguente:
name: Build and push the tagged build to production permissions: id-token: write # This is required for requesting the JWT contents: read # This is required for actions/checkout on: push: tags: - 'v*' jobs: build_push_image: runs-on: ubuntu-20.04 steps: - uses: actions/checkout@v2 - name: Fetch latest version id: fetch_version run: echo ::set-output name=TAG::${GITHUB_REF#refs/tags/} - name: Set up Buildx uses: docker/setup-buildx-action@v3.0.0 - name: Docker Login uses: docker/login-action@v3.0.0 with: registry: ${{ secrets.ACR_NAME }} username: ${{ secrets.ACR_LOGIN }} password: ${{ secrets.ACR_PASSWORD }} - name: Build and push production images uses: docker/build-push-action@v2 with: context: . push: true tags: ${{secrets.ACR_NAME}}/contoso-website:latest,${{secrets.ACR_NAME}}/contoso-website:${{ steps.fetch_version.outputs.TAG }} deploy: runs-on: ubuntu-20.04 needs: build_push_image steps: - uses: actions/checkout@v2 - name: Install Helm uses: Azure/setup-helm@v1 with: version: v3.3.1 - name: Login to Azure with OIDC uses: azure/login@v1 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: Azure Kubernetes set context uses: Azure/aks-set-context@v3 with: resource-group: ${{ secrets.RESOURCE_GROUP }} cluster-name: ${{ secrets.CLUSTER_NAME }} - name: Run Helm Deploy run: | helm upgrade \ --install \ --create-namespace \ --atomic \ --wait \ --namespace production \ contoso-website \ ./kubernetes/contoso-website \ --set image.repository=${{ secrets.ACR_NAME }} \ --set dns.name=${{ secrets.DNS_NAME }} \ --set image.tag=${GITHUB_REF##*/}
Per eseguire il commit delle modifiche, selezionare Commit changes (Esegui il commit delle modifiche). Immettere una descrizione per il commit e quindi selezionare Commit changes (Esegui il commit delle modifiche).
Modifiche di produzione
Ogni volta che si esegue il flusso di lavoro di produzione, è necessario aggiornare il certificato federato con la versione del tag corrispondente, come indicato di seguito:
Nella portale di Azure passare alla pagina dell'applicazione e selezionare Certificati e segreti nel riquadro di spostamento a sinistra.
Selezionare la scheda Credenziali federate .
Selezionare le credenziali di prod-cred .
Nella schermata Modifica credenziali, accanto a In base alla selezione, incrementare il numero di tag a un nuovo v.x.x.x, ad esempio v.2.0.1.
Selezionare Aggiorna.
In Cloud Shell eseguire
git pull
per recuperare le modifiche più recenti. Eseguire quindi il comando seguente per contrassegnare ed eseguire il push delle modifiche, sostituendo il nuovo tag di versione per il segnaposto:git tag -a v<new version tag> -m 'Create new production deployment' && git push --tags
Quando richiesto, specificare il token di accesso personale degli esercizi precedenti come password.
In GitHub aprire la scheda Azioni e visualizzare il processo in esecuzione.
Al termine del flusso di lavoro, per testare la distribuzione di produzione, passare a
contoso-production.<aks-dns-zone-name>
nel browser e verificare che venga visualizzato il sito Web.
Continuare con l'unità successiva per eliminare le risorse in modo che non continuino a incorrere in addebiti.