Oefening: de implementatiepijplijn maken

Voltooid

Wanneer alle Helm-grafieken zijn gemaakt, hebt u alle hulpmiddelen die u nodig hebt om de toepassing te implementeren op AKS met behulp van GitHub Actions. In deze les voltooit u de CI/CD-pijplijn door de laatste implementatiestappen uit te voeren.

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

De implementatiestappen omvatten:

  • Maak de implementatietaak.
  • Open ID instellen Verbinding maken (OIDC).
  • Implementeer de toepassing met Helm.
  • Voer de implementatie uit in productie.

De implementatietaak toevoegen

  1. Ga in GitHub naar uw fork van de opslagplaats.

  2. Vouw de map .github/workflows uit en open het build-staging.yml-bestand voor bewerken.

  3. Voeg een nieuwe deploy taak toe aan het einde van het bestand, na de build_push_image taak, als volgt. Zorg ervoor dat deze overeenkomt met de inspringing.

    De taak heeft drie sleutels: runs-on, needsen permissions.

    • ubuntu-20.04 Gebruik dit runs-onom consistent te zijn met de andere taak.
    • Gebruik needsvoor , gebruik de naam van de eerste taak, build_push_imagezodat de toepassing alleen wordt geïmplementeerd nadat de installatiekopie is gebouwd
    • Voeg permissionstwee argumenten toe die worden aangeroepen id-token en contents. Ingesteld id-token op write en contents op read, om GitHub Actions toegang te verlenen tot het verzenden van aanvragen en het lezen van de inhoud van de opslagplaats.
  4. Voeg toe - uses: actions/checkout@v2 als de eerste stap van de taak.

    De toegevoegde deploy taak moet eruitzien als de volgende code:

          deploy:
            runs-on: ubuntu-20.04
            needs: build_push_image
            permissions:
              id-token: write
              contents: read
    
            steps:
              - uses: actions/checkout@v2
    

De helm-stap installeren toevoegen

Gebruik een GitHub-actie om de Helm-versie v3.3.1te downloaden en te installeren.

  1. Zoek in het rechterdeelvenster van de bewerkingspagina naar het installatieprogramma van het Helm-hulpprogramma. Selecteer het eerste resultaat dat door Azure is gepubliceerd.

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

  2. Selecteer het kopieerpictogram om de YAML voor gebruik te kopiëren.

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

  3. Kopieer en plak de YAML onder de uses sleutel in build-staging.yml.

  4. Wijzig de naam van de stap in Helm tool installer Install Helmen maak de version sleutel vast aan v3.3.1.

        steps:
          - uses: actions/checkout@v2
    
          - name: Install Helm
            uses: Azure/setup-helm@v1
            with:
              version: v3.3.1
    

De azure-aanmeldingsverificatiestap toevoegen

Gebruik OIDC om GitHub Actions te verifiëren voor toegang tot AKS.

  1. Zoek in het rechterdeelvenster naar Azure-aanmelding en selecteer Azure Login gepubliceerd door Azure.

    Screenshot that shows results for the Azure Login search.

  2. Selecteer het kopieerpictogram om de YAML voor gebruik te kopiëren en plak deze onder de Install Helm stap in build-staging.yml.

  3. Wijzig de naam van de stap in Azure Login Sign in to Azure with OIDC.

  4. Azure Login vereist drie parameters voor verificatie: client-id, tenant-iden subscription-id. Vul deze parameters in met tijdelijke aanduidingen voor geheimen die u later instelt.

          - 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. Zoek in het rechterdeelvenster naar de setcontext en selecteer Azure Kubernetes-setcontext die is gepubliceerd door Azure.

    Screenshot that shows the results for a Set Context search.

  6. Selecteer het kopieerpictogram om de YAML voor gebruik te kopiëren en plak deze onder de Sign in to Azure with OIDC stap in build-staging.yml. Vul de resource-group tijdelijke aanduidingen en cluster-name parameters in voor de geheimen die u in een eerdere eenheid hebt ingesteld.

          - name: Azure Kubernetes set context
            uses: Azure/aks-set-context@v3
            with:
              resource-group: ${{ secrets.RESOURCE_GROUP }}
              cluster-name: ${{ secrets.CLUSTER_NAME }}
    

    Uw build-staging.yml-bestand moet eruitzien als in het volgende voorbeeld:

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

Open ID instellen Verbinding maken (OIDC)

Wijs waarden toe aan uw geheimen door een service-principal en certificaten te maken om u aan te melden met OIDC.

De service-principal maken

  1. Voer az account showin Azure Cloud Shell de waarde uit en sla deze id op uit de uitvoer.

  2. Maak een service-principal door de volgende opdracht uit te voeren, waarbij u de id waarde van de vorige opdracht $SUBSCRIPTION_IDvervangt door:

    az ad sp create-for-rbac --scopes /subscriptions/$SUBSCRIPTION_ID --role Contributor 
    
  3. Kopieer de JSON-uitvoer en sla deze op voor de volgende stap.

De geheimen instellen

Selecteer op de pagina van uw GitHub-opslagplaats het tabblad Instellingen en selecteer vervolgens Acties voor geheimen en variabelen>in het linkermenu. Definieer de volgende drie nieuwe geheimen die gebruikmaken van de uitvoer uit de voorgaande stappen.

  • AZURE_CLIENT_ID: De "appId" waarde uit az ad sp create-for-rbac de uitvoer
  • AZURE_TENANT_ID: De "tenant" waarde uit az ad sp create-for-rbac de uitvoer
  • AZURE_SUBSCRIPTION_ID: De id waarde uit az account show de uitvoer

Voor elk geheim:

  1. Selecteer Nieuw opslagplaatsgeheim.
  2. Voer bij Naam de geheime naam in.
  3. Voer voor Geheim de waarde in.
  4. Selecteer Geheim toevoegen.

Federatieve referenties toevoegen

Federatieve certificaten maken om GitHub Actions toegang te geven tot de toepassing.

  1. Ga in Azure Portal naar App-registraties.

  2. Zoek en selecteer de toepassing die overeenkomt met de displayName waarde die in de vorige az ad sp create-for-rbac stap is geretourneerd. De toepassingsnaam gebruikt standaard de tijdstempel van het maken van de service-principal.

  3. Controleer of de waarden van de appID (client-id), object-id (toepassingsobject-id) en map-id (tenant-id) overeenkomen met de vorige JSON-uitvoer.

  4. Selecteer certificaten en geheimen in het linkernavigatievenster.

  5. Selecteer in het scherm Certificaten en geheimen het tabblad Federatieve referenties .

  6. Selecteer Referentie toevoegen.

  7. Als u de faseringsreferentie wilt toevoegen, selecteert of voert u in het scherm Referentie toevoegen de volgende gegevens in:

    • Scenario met federatieve referenties: Selecteer GitHub Actions die Azure-resources implementeren.
    • Organisatie: voer uw GitHub-gebruikersnaam in.
    • Opslagplaats: Voer mslearn-aks-deployment-pipeline-github-actions in.
    • Entiteitstype: Vertakking selecteren.
    • Naam van GitHub-vertakking: Voer de hoofdtekst in.
    • Naam: Voer staging-cred in.
    • Beschrijving Voer testen in.
  8. Selecteer Toevoegen.

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

  9. Als u de productiereferentie wilt toevoegen, selecteert u Opnieuw referentie toevoegen en voert u in het scherm Een referentie toevoegen dezelfde waarden in als voor de vorige referentie, behalve:

    • Entiteitstype: Selecteer Tag.
    • Naam van GitHub-tag: Voer v2.0.0 in, omdat u in de volgende stap versie 2 implementeert.
    • Naam: Voer prod-cred in.
  10. Selecteer Toevoegen.

De toepassing implementeren met Helm

Nu u Helm hebt geconfigureerd en toegang hebt verleend tot uw cluster, kunt u de toepassing implementeren.

De stap Helm-implementatie uitvoeren toevoegen

  1. Maak in het build-staging.yml-bestand in GitHub, na de laatste stap in de taak, een nieuwe stap met de deploy naam Run Helm Deploy. Voeg eronder nog een sleutel toe met de naam run.

              - name: Run Helm Deploy
                run:
    
  2. U kunt de run sleutel gebruiken om elke shell-opdracht in de container uit te voeren. Deze pijplijn gebruikt de run sleutel om de volgende Helm-opdracht uit te voeren:

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

    Begrijpen wat elke parameter doet:

    Parameter Actie of waarde
    helm upgrade Hiermee wordt een geïnstalleerde versie bijgewerkt.
    --install Als de release niet bestaat, installeert u deze.
    --create-namespace Als de naamruimte in de --namespace vlag niet bestaat, maakt u deze.
    --atomic Als de release mislukt, verwijdert u alle workloads die zijn geïnstalleerd.
    --wait Wacht tot de release is voltooid en retourneert OK de status.
    --namespace staging contoso-website Hiermee wordt de contoso-website release geïmplementeerd in de staging naamruimte.
    ./kubernetes/contoso-website Locatie van grafiekmap.
    --set image.repository Werkt de waarde van image.repository het bestand values.yaml alleen voor deze release bij.
    --set dns.name Werkt de dns.name sleutel alleen bij in het bestand values.yaml voor deze release.
  3. Voeg de opdracht toe aan het bestand en stel deze in om uit te voeren, te beginnen met het | teken. De Run Helm deploy stap moet overeenkomen met dit voorbeeld:

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

    Het voltooide build-staging.yml-bestand moet eruitzien als in het volgende voorbeeld:

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

Het DNS_NAME geheim instellen

  1. Ga in een nieuw browsertabblad naar de fork van de opslagplaats, selecteer het tabblad Instellingen en selecteer vervolgens Acties voor geheimen en variabelen>in het linkermenu.

  2. Selecteer Nieuw opslagplaatsgeheim.

  3. Voer bij Naam de tekst DNS_NAME in.

  4. Voer voor Geheim de waarde van de AKS DNS-zonenaam in uit de uitvoer van het oorspronkelijke installatiescript.

    Als u deze waarde niet hebt, voert u de volgende opdracht uit in Cloud Shell, waarbij u uw waarden vervangt door <resource-group-name> en <aks-cluster-name>:

    az aks show -g <resource-group-name> -n <aks-cluster-name> -o tsv --query addonProfiles.httpApplicationRouting.config.HTTPApplicationRoutingZoneName
    
  5. Selecteer Geheim toevoegen.

De wijzigingen doorvoeren en de faseringsimplementatie testen

  1. Als u uw wijzigingen wilt doorvoeren, selecteert u Wijzigingen doorvoeren. Voer een beschrijving in voor de doorvoer en selecteer Wijzigingen doorvoeren.

  2. Selecteer het tabblad Acties om de build uit te voeren.

  3. Nadat de build is voltooid, gaat u in uw browser om te contoso-staging.<aks-dns-zone-name> bevestigen dat de website wordt weergegeven.

De implementatie uitvoeren in productie

De volgende stap is het maken van de productiewerkstroom.

  1. Open in de map .github/workflows in uw opslagplaats het build-production.yml bestand om te bewerken.

  2. Kopieer de deploy taak uit de faseringspijplijn en plak deze onder de laatste regel in het bestand build-production.yml .

  3. Wijzig de Run Helm Deploy stap voor implementatie in de productienaamruimte door de --namespace vlag te wijzigen van staging in production.

  4. Voeg aan het einde van de Helm-opdracht een nieuwe parameter toe. --set image.tag=${GITHUB_REF##*/}

    Hier gebruikt u een Bash-functie met de naam parameteruitbreiding. De uitbreiding ${ENV##<wildcard><character>} retourneert het laatste exemplaar van de tekenreeks na character.

    In dit geval wilt u alleen de tagnaam ophalen, die wordt weergegeven als de GitHub Actions-runtime. GITHUB_REF Vertakkingen zijn refs/heads/<branch>, terwijl tags zijn refs/tags/<tag>.

    U wilt verwijderen refs/tags/ om alleen de tagnaam op te halen, dus u geeft ${GITHUB_REF##*/} door om alles terug te geven na de laatste / in de GITHUB_REF omgevingsvariabele.

    Het uiteindelijke build-production.yml-bestand moet eruitzien als in het volgende voorbeeld:

    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. Als u uw wijzigingen wilt doorvoeren, selecteert u Wijzigingen doorvoeren. Voer een beschrijving in voor de doorvoer en selecteer Wijzigingen doorvoeren.

Productiewijzigingen

Telkens wanneer u de productiewerkstroom uitvoert, moet u het federatieve certificaat als volgt bijwerken met de bijbehorende tagversie:

  1. Ga in Azure Portal naar uw toepassingspagina en selecteer Certificaten en geheimen in het linkernavigatievenster.

  2. Selecteer het tabblad Federatieve referenties .

  3. Selecteer de prod-cred-referentie .

  4. In het scherm Een referentie bewerken, naast Op basis van selectie, kunt u het tagnummer verhogen naar een nieuwe v.x.x.x, zoals v.2.0.1.

  5. Selecteer Bijwerken.

  6. Voer in Cloud Shell uit git pull om de meest recente wijzigingen op te halen. Voer vervolgens de volgende opdracht uit om de wijzigingen te taggen en pushen, waarbij u de nieuwe versietag vervangt door de tijdelijke aanduiding:

    git tag -a v<new version tag> -m 'Create new production deployment' && git push --tags
    
  7. Wanneer u hierom wordt gevraagd, geeft u de PAT op uit de vorige oefeningen als het wachtwoord.

  8. Open in GitHub het tabblad Acties en bekijk het actieve proces.

  9. Nadat de werkstroom is geslaagd, gaat u naar contoso-production.<aks-dns-zone-name> uw browser om de productie-implementatie te testen en controleert u of de website wordt weergegeven.

Ga door naar de volgende eenheid om uw resources te verwijderen, zodat er geen kosten in rekening worden gebracht.