Übung: Erstellen der Bereitstellungspipeline

  • 10 Minuten

Nachdem Sie die Helm-Diagramme erstellt haben, verfügen Sie nun über alle Tools, die Sie benötigen, um die Anwendung mit GitHub Actions in AKS bereitzustellen. In dieser Lerneinheit beenden Sie die CI/CD-Pipeline, indem Sie die letzten Bereitstellungsschritte ausführen.

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

Die Bereitstellungsschritte umfassen Folgendes:

  • Erstellen des Bereitstellungsauftrags
  • Einrichten von Open ID Connect (OIDC)
  • Bereitstellen der Anwendung mit Helm
  • Ausführen der Bereitstellung für die Produktion

Hinzufügen des Bereitstellungsauftrags

  1. Navigieren Sie in GitHub zu Ihrem Fork des Repositorys.

  2. Erweitern Sie das Verzeichnis .github/workflows, und öffnen Sie die Datei build-staging.yml für die Bearbeitung.

  3. Fügen Sie am Ende der Datei wie folgt einen neuen deploy-Auftrag nach dem build_push_image-Auftrag hinzu. Stellen Sie sicher, dass der Einzug übereinstimmt.

    Der Auftrag hat drei Schlüssel: runs-on, needs und permissions.

    • Verwenden Sie ubuntu-20.04 für runs-on, um die Konsistenz mit dem anderen Auftrag zu gewährleisten.
    • Verwenden Sie für needs den Namen des ersten Auftrags (build_push_image), sodass die Anwendung erst bereitgestellt wird, nachdem das Image erstellt wurde.
    • Fügen Sie für permissions zwei Argumente namens id-token und contents hinzu. Legen Sie id-token auf write und contents auf read fest. Dadurch erhält GitHub Actions Zugriff und kann Anforderungen senden und die Repositoryinhalte lesen.

  4. Fügen Sie - uses: actions/checkout@v2 als ersten Schritt des Auftrags hinzu.

    Der hinzugefügte deploy-Auftrag sollte folgendem Code ähneln:

          deploy:
        runs-on: ubuntu-20.04
        needs: build_push_image
        permissions:
          id-token: write
          contents: read

        steps:
          - uses: actions/checkout@v2

Hinzufügen des Schritts „Helm installieren“

Verwenden Sie eine GitHub-Aktion, um die Helm-Version v3.3.1 herunterzuladen und zu installieren.

  1. Suchen Sie im rechten Bereich der Bearbeitungsseite nach Installer für Helm-Tools. Klicken Sie auf das erste von Azure veröffentlichte Ergebnis.

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

  2. Wählen Sie das Kopiersymbol aus, um den YAML-Code zu kopieren.

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

  3. Fügen Sie den YAML-Code unterhalb des Schlüssels uses in build-staging.yml ein.

  4. Benennen Sie den Schritt von Helm tool installer in Install Helm um, und heften Sie den Schlüssel version an v3.3.1 an.

        steps:
      - uses: actions/checkout@v2

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

Hinzufügen des Schritts für die Azure-Anmeldeauthentifizierung

Verwenden Sie OIDC, um GitHub Actions für den Zugriff auf AKS zu authentifizieren.

  1. Suchen Sie im rechten Bereich nach Azure-Anmeldung, und wählen Sie Azure-Anmeldung (von Azure veröffentlicht) aus.

    Screenshot that shows results for the Azure Login search.

  2. Wählen Sie das Kopiersymbol aus, um den YAML-Code zu kopieren, und fügen Sie ihn unter dem Schritt Install Helm in build-staging.yml ein.

  3. Ändern Sie den Namen des Schritts von Azure Login in Sign in to Azure with OIDC.

  4. Azure Login erfordert drei Parameter für die Authentifizierung: client-id, tenant-id und subscription-id. Füllen Sie diese Parameter mit Platzhaltern für Geheimnisse aus, die Sie später festlegen.

          - 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. Suchen Sie im rechten Bereich nach Kontext festlegen, und wählen Sie Azure Kubernetes-Kontext festlegen (von Azure veröffentlicht) aus.

    Screenshot that shows the results for a Set Context search.

  6. Wählen Sie das Kopiersymbol aus, um den YAML-Code zu kopieren, und fügen Sie ihn unter dem Schritt Sign in to Azure with OIDC in build-staging.yml ein. Füllen Sie die Parameter resource-group und cluster-name mit Platzhaltern für die Geheimnisse aus, die Sie in einer früheren Lerneinheit festgelegt haben.

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

    Die Datei build-staging.yml sollte wie das folgende Beispiel aussehen:

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

Einrichten von Open ID Connect (OIDC)

Weisen Sie Ihren Geheimnissen Werte zu, indem Sie einen Dienstprinzipal und Zertifikate zur Anmeldung mit OIDC erstellen.

Erstellen Sie den Dienstprinzipal

  1. Führen Sie az account show in Azure Cloud Shell aus, und speichern Sie den Wert id aus der Ausgabe.

  2. Erstellen Sie einen Dienstprinzipal, indem Sie den folgenden Befehl ausführen und den Wert id aus dem vorherigen Befehl für $SUBSCRIPTION_ID ersetzen:

    az ad sp create-for-rbac --scopes /subscriptions/$SUBSCRIPTION_ID --role Contributor

  3. Kopieren Sie die JSON-Ausgabe, und speichern Sie sie für den nächsten Schritt.

Festlegen der Geheimnisse

Wählen Sie auf der Seite des GitHub-Repositorys die Registerkarte Einstellungen aus, und klicken Sie dann im linken Menü auf Geheimnisse und Variablen>Aktionen. Definieren Sie die folgenden drei neuen Geheimnisse, die die Ausgabe aus den vorherigen Schritten verwenden.

  • AZURE_CLIENT_ID: Der Wert "appId" aus der Ausgabe von az ad sp create-for-rbac
  • AZURE_TENANT_ID: Der Wert "tenant" aus der Ausgabe von az ad sp create-for-rbac
  • AZURE_SUBSCRIPTION_ID: Der Wert id aus der Ausgabe von az account show

Für jedes Geheimnis

  1. Wählen Sie New repository secret (Neues Repositorygeheimnis) aus.
  2. Geben Sie für Name den Geheimnisnamen ein.
  3. Geben Sie unter Geheimnis den Wert ein.
  4. Klicken Sie auf Add secret (Geheimnis hinzufügen).

Hinzufügen von Verbundanmeldeinformationen

Erstellen Sie Verbundzertifikate, um GitHub Actions für den Zugriff auf die Anwendung zu autorisieren.

  1. Wechseln Sie im Azure-Portal zu App-Registrierungen.

  2. Suchen Sie nach der Anwendung, die dem im vorherigen Schritt az ad sp create-for-rbac zurückgegebenen displayName-Wert entspricht, und wählen Sie sie aus. Der Anwendungsname verwendet standardmäßig den Zeitstempel der Dienstprinzipalerstellung.

  3. Stellen Sie sicher, dass die Werte von appID (Client-ID), Objekt-ID (Anwendungsobjekt-ID) und Verzeichnis-ID (Mandanten-ID) mit der vorherigen JSON-Ausgabe übereinstimmen.

  4. Klicken Sie im linken Navigationsbereich auf Zertifikate & Geheimnisse.

  5. Wählen Sie auf dem Bildschirm Zertifikate und Geheimnisse die Registerkarte Verbundanmeldeinformationen aus.

  6. Wählen Sie Anmeldeinformationen hinzufügen aus.

  7. Wenn Sie die Staging-Anmeldeinformationen hinzufügen möchten, wählen Sie auf dem Bildschirm Anmeldeinformationen hinzufügen die folgenden Informationen aus, oder geben Sie sie ein:

    • Szenario mit Verbundanmeldeinformationen: Wählen Sie GitHub Actions stellt die Azure-Ressourcen bereit aus.
    • Organisation: Geben Sie Ihren GitHub-Benutzernamen ein.
    • Repository: Geben Sie mslearn-aks-deployment-pipeline-github-actionsein.
    • Entitätstyp: Wählen Sie Branch aus.
    • Name der GitHub-Verzweigung: Geben Sie main ein.
    • Name: Geben Sie staging-cred ein.
    • Beschreibung: Geben Sie Testing ein.

  8. Wählen Sie Hinzufügen aus.

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

  9. Wählen Sie zum Hinzufügen der Produktionsanmeldeinformationen erneut Anmeldeinformationen hinzufügen aus, und geben Sie auf dem Bildschirm Anmeldeinformationen hinzufügen die gleichen Werte wie für die vorherigen Anmeldeinformationen ein, mit folgender Ausnahme:

    • Entitätstyp: Wählen Sie Tag aus.
    • GitHub-Tagname: Geben Sie v2.0.0 ein, da Sie im nächsten Schritt Version 2 bereitstellen.
    • Name: Geben Sie prod-cred ein.

  10. Wählen Sie Hinzufügen aus.

Bereitstellen der Anwendung mit Helm

Nachdem Sie Helm konfiguriert und Zugriff auf Ihren Cluster gewährt haben, können Sie nun die Anwendung bereitstellen.

Hinzufügen des Schritts „Helm-Bereitstellung durchführen“

  1. Wechseln Sie zurück zur Datei build-staging.yml in GitHub, und erstellen Sie nach dem letzten Schritt im deploy-Auftrag einen neuen Schritt namens Run Helm Deploy. Fügen Sie darunter einen weiteren Schlüssel namens run hinzu.

              - name: Run Helm Deploy
            run:

  2. Sie können mit dem run-Schlüssel beliebige Shellbefehle innerhalb des Containers auszuführen. Diese Pipeline verwendet den Schlüsselrun, um den folgenden Helm-Befehl auszuführen:

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

    Grundlegendes zur Funktionsweise der einzelnen Parameter

    Parameter Aktion oder Wert
    helm upgrade Mit diesem Parameter wird ein Upgrade für ein installiertes Release durchgeführt.
    --install Wenn das Release nicht vorhanden ist, wird dieses installiert.
    --create-namespace Wenn der Namespace im --namespace-Flag nicht vorhanden ist, wird er erstellt.
    --atomic Wenn das Release fehlschlägt, werden alle Workloads entfernt, die installiert wurden.
    --wait Wartet, bis das Release abgeschlossen ist, und gibt den Status OK zurück.
    --namespace staging contoso-website Stellt das Release contoso-website im staging-Namespace bereit.
    ./kubernetes/contoso-website Dieser Parameter gibt den Chartverzeichnispfad an.
    --set image.repository Dieser Parameter aktualisiert den Wert von image.repository in der Datei values.yamlnur für dieses Release.
    --set dns.name Dieser Parameter aktualisiert den dns.name-Schlüssel in der Datei values.yamlnur für dieses Release.

  3. Fügen Sie der Datei den Befehl hinzu, und legen Sie seine Ausführung fest, beginnend mit dem Zeichen |. Der Schritt Run Helm deploy sollte mit diesem Beispiel übereinstimmen:

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

    Die vollständige Datei build-staging.yml sollte wie das folgende Beispiel aussehen:

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

Festlegen des DNS_NAME-Geheimnisses

  1. Wechseln Sie auf einer neuen Browserregisterkarte zu Ihrem Fork des Repositorys, und wählen Sie die Registerkarte Einstellungen und dann im linken Menü Geheimnisse und Variablen>Aktionen aus.

  2. Wählen Sie New repository secret (Neues Repositorygeheimnis) aus.

  3. Geben Sie unter NameDNS_NAME ein.

  4. Geben Sie unter Geheimnis den Wert von DNS-Zonenname für AKS aus der ursprünglichen Ausgabe des Setupskripts ein.

    Wenn Sie diesen Wert nicht haben, führen Sie den folgenden Befehl in Cloud Shell aus, und ersetzen Sie die Werte für <resource-group-name> und <aks-cluster-name>:

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

  5. Klicken Sie auf Add secret (Geheimnis hinzufügen).

Committen der Änderungen und Testen der Stagingbereitstellung

  1. Wenn Sie Ihre Änderungen committen möchten, wählen Sie Änderungen committen aus. Geben Sie eine Beschreibung für den Commit ein, und wählen Sie dann Änderungen committen aus.

  2. Wählen Sie die Registerkarte Aktionen aus, um den ausgeführten Build anzuzeigen.

  3. Nach erfolgreicher Buildausführung wechseln Sie in Ihrem Browser zu contoso-staging.<aks-dns-zone-name>, um zu überprüfen, ob die Website angezeigt wird.

Ausführen der Bereitstellung für die Produktion

Der nächste Schritt besteht darin, den Produktionsworkflow zu erstellen.

  1. Öffnen Sie im Verzeichnis .github/workflows in Ihrem Repository die Datei build-production.yml für die Bearbeitung.

  2. Kopieren Sie den deploy-Auftrag aus der Stagingpipeline, und fügen Sie ihn unter der letzten Zeile in der Datei build-production.yml ein.

  3. Ändern Sie den Schritt Run Helm Deploy so, dass die Bereitstellung im Produktionsnamespace durchgeführt wird. Ändern Sie dazu das Flag --namespace von staging in production.

  4. Fügen Sie einen neuen Parameter, --set image.tag=${GITHUB_REF##*/}, am Ende des Helm-Befehls hinzu.

    Sie verwenden hier ein Bash-Feature namens Parameter Expansion (Parametererweiterung). Die Erweiterung ${ENV##<wildcard><character>} gibt das letzte Vorkommen der Zeichenfolge nach character zurück.

    In diesem Fall möchten Sie nur den Tagnamen abrufen, der als GitHub Actions-Runtime GITHUB_REF dargestellt wird. Die Branches sind refs/heads/<branch>, während die Tags refs/tags/<tag> sind.

    Sie möchten refs/tags/ entfernen, um nur den Tagnamen abzurufen, also übergeben Sie ${GITHUB_REF##*/}. Dadurch wird alles nach dem letzten /-Zeichen in der Umgebungsvariable GITHUB_REF zurückgegeben.

    Die endgültige Datei build-production.yml sollte wie das folgende Beispiel aussehen:

    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. Wenn Sie Ihre Änderungen committen möchten, wählen Sie Änderungen committen aus. Geben Sie eine Beschreibung für den Commit ein, und wählen Sie dann Änderungen committen aus.

Produktionsänderungen

Jedes Mal, wenn Sie den Produktionsworkflow ausführen, müssen Sie das Verbundzertifikat mit der entsprechenden Tagversion wie folgt aktualisieren:

  1. Navigieren Sie im Azure-Portal zur Anwendungsseite, und wählen Sie in der linken Navigationsleiste Zertifikate und Geheimnisse aus.

  2. Wählen Sie die Registerkarte Verbundanmeldeinformationen aus.

  3. Wählen Sie die Anmeldeinformationen für prod-cred aus.

  4. Erhöhen Sie auf dem Bildschirm Anmeldeinformationen bearbeiten neben Auf Grundlage der Auswahl die Tagnummer auf einen neuen Wert im Format „v.x.x.x“, etwa v.2.0.1.

  5. Wählen Sie Aktualisieren.

  6. Führen Sie git pull in Cloud Shell aus, um die neuesten Änderungen abzurufen. Führen Sie dann den folgenden Befehl aus, um die Änderungen zu markieren und zu pushen, und ersetzen Sie dabei den Platzhalter durch das neue Versionstag:

    git tag -a v<new version tag> -m 'Create new production deployment' && git push --tags

  7. Wenn Sie dazu aufgefordert werden, geben Sie das PAT aus vorherigen Übungen als Kennwort an.

  8. Öffnen Sie in GitHub die Registerkarte Actions (Aktionen), um den aktiven Prozess anzusehen.

  9. Navigieren Sie nach erfolgreicher Ausführung des Workflows in Ihrem Browser zu contoso-production.<aks-dns-zone-name>, um die Produktionsbereitstellung zu testen und um zu überprüfen, ob die Website angezeigt wird.

Fahren Sie mit der nächsten Lerneinheit fort, um Ihre Ressourcen zu löschen, damit keine weiteren Gebühren anfallen.