Esercizio: creare la pipeline di distribuzione

  • 10 minuti

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.

Diagram that shows the procession from triggers, through three build steps, to the deploy step in a pipeline.

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

  1. In GitHub passare al fork del repository.

  2. Espandere la directory .github/workflows e aprire il file build-staging.yml per la modifica.

  3. Aggiungere un nuovo deploy processo alla fine del file, dopo il build_push_image processo, come indicato di seguito. Assicurarsi di corrispondere al rientro.

    Il processo ha tre chiavi: runs-on, needse permissions.

    • Per runs-on, usare ubuntu-20.04 per essere coerente con l'altro processo.
    • Per needsusare il nome del primo processo, build_push_image, quindi l'applicazione viene distribuita solo dopo la compilazione dell'immagine
    • Per permissionsaggiungere due argomenti denominati id-token e contents. Impostare su id-tokenwrite e contents su readper concedere a GitHub Actions l'accesso per inviare richieste e leggere il contenuto del repository.

  4. 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.1Helm.

  1. Nel pannello destro della pagina di modifica cercare il programma di installazione dello strumento Helm. Selezionare il primo risultato pubblicato da Azure.

    Screenshot that shows the search results for the Helm installer action.

  2. Selezionare l'icona di copia per copiare il file YAML di utilizzo.

    Screenshot that shows the copy function after selecting the Helm installer action.

  3. Copiare e incollare il codice YAML sotto la uses chiave in build-staging.yml.

  4. Rinominare il passaggio da Helm tool installer a e aggiungere la version chiave a v3.3.1Install 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.

  1. Nel pannello di destra cercare Account di accesso di Azure e selezionare Accesso di Azure pubblicato da Azure.

    Screenshot that shows results for the Azure Login search.

  2. Selezionare l'icona di copia per copiare il file YAML di utilizzo e incollarlo sotto il Install Helm passaggio in build-staging.yml.

  3. Modificare il nome del passaggio da Azure Login a Sign in to Azure with OIDC.

  4. Azure Login richiede tre parametri per l'autenticazione: client-id, tenant-ide subscription-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 }}

  5. Nel pannello di destra cercare set context (Set context) e selezionare Azure Kubernetes set context pubblicato da Azure.

    Screenshot that shows the results for a Set Context search.

  6. 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 i resource-group parametri e cluster-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

  1. In Azure Cloud Shell eseguire az account showe salvare il id valore dall'output.

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

  3. 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'output idaz account show

Per ogni segreto:

  1. Selezionare Nuovo segreto repository.
  2. In Nome immettere il nome del segreto.
  3. In Segreto immettere il valore .
  4. Selezionare Aggiungi segreto.

Aggiungere credenziali federate

Creare certificati federati per autorizzare GitHub Actions ad accedere all'applicazione.

  1. Nel portale di Azure passare a Registrazioni app.

  2. Cercare e selezionare l'applicazione che corrisponde al displayName valore restituito nel passaggio precedente az ad sp create-for-rbac . Per impostazione predefinita, il nome dell'applicazione usa il timestamp della creazione dell'entità servizio.

  3. Verificare che i valori di appID (ID client), ID oggetto (ID oggetto applicazione) e ID directory (ID tenant) corrispondano all'output JSON precedente.

  4. Nel riquadro di spostamento a sinistra selezionare Certificati e segreti.

  5. Nella schermata Certificati e segreti selezionare la scheda Credenziali federate.

  6. Selezionare Aggiungi credenziale.

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

  8. Selezionare Aggiungi.

    Screenshot of the Add credential screen for the GitHub Actions staging credential.

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

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

  1. Tornare al file build-staging.yml in GitHub, dopo il passaggio più recente del deploy processo, creare un nuovo passaggio denominato Run Helm Deploy. Sotto di esso aggiungere un'altra chiave denominata run.

              - name: Run Helm Deploy
            run:

  2. Puoi usare la chiave run per eseguire qualsiasi comando della shell all'interno del contenitore. Questa pipeline usa la run 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 dei staging 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.

  3. Aggiungere il comando al file e impostarlo per l'esecuzione, a partire dal | carattere . Il Run 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

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

  2. Selezionare Nuovo segreto repository.

  3. Per Nome inserisci DNS_NAME.

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

  5. Selezionare Aggiungi segreto.

Eseguire il commit delle modifiche e testare la distribuzione di staging

  1. 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).

  2. Selezionare la scheda Azioni per visualizzare la compilazione in esecuzione.

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

  1. Nella directory .github/workflows del repository aprire il file build-production.yml per la modifica.

  2. Copiare il deploy processo dalla pipeline di staging e incollarlo sotto l'ultima riga nel file build-production.yml .

  3. Modificare il passaggio per eseguire la Run Helm Deploy distribuzione nello spazio dei nomi di produzione modificando il --namespace flag da staging a production.

  4. 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 dopo character.

    In questo caso, devi ottenere solo il nome del tag, rappresentato come runtime di GitHub Actions, GITHUB_REF. I rami sono refs/heads/<branch>, mentre i tag sono refs/tags/<tag>.

    Si vuole rimuovere refs/tags/ per ottenere solo il nome del tag, quindi passare ${GITHUB_REF##*/} per restituire tutto dopo l'ultimo / nella GITHUB_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##*/}

  5. 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:

  1. Nella portale di Azure passare alla pagina dell'applicazione e selezionare Certificati e segreti nel riquadro di spostamento a sinistra.

  2. Selezionare la scheda Credenziali federate .

  3. Selezionare le credenziali di prod-cred .

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

  5. Selezionare Aggiorna.

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

  7. Quando richiesto, specificare il token di accesso personale degli esercizi precedenti come password.

  8. In GitHub aprire la scheda Azioni e visualizzare il processo in esecuzione.

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