NGINX-Tutorial: So automatisieren Sie Canary-Deployments für Microservices mit GitHub Actions

NGINX | 21. März 2023

Dieser Beitrag ist eines von vier Tutorials, die Ihnen dabei helfen, die Konzepte aus Microservices March 2023: Erste Schritte bei der Bereitstellung von Microservices:

So stellen Sie Microservices bereit und konfigurieren sie
So verwalten Sie Geheimnisse in Containern sicher
So automatisieren Sie Canary-Releases von Microservices mit GitHub Actions (dieser Beitrag)
So nutzen Sie OpenTelemetry-Tracing, um Ihre Microservices besser zu verstehen

Die Automatisierung von Bereitstellungen ist für den Erfolg der meisten Projekte von entscheidender Bedeutung. Es reicht jedoch nicht aus, lediglich den Code bereitzustellen. Sie müssen außerdem sicherstellen, dass Ausfallzeiten begrenzt (oder vollständig vermieden) werden, und im Fehlerfall schnell ein Rollback durchführen können. Die Kombination aus Canary-Bereitstellung und Blue-Green-Bereitstellung ist ein gängiger Ansatz, um sicherzustellen, dass neuer Code zuverlässig funktioniert. Diese Strategie umfasst zwei Schritte:

Schritt 1: Canary-Deployment für isolierte Tests – Stellen Sie Ihren Code auf einem isolierten Knoten, Server oder Container außerhalb Ihrer Umgebung bereit und testen Sie, ob der Code wie vorgesehen funktioniert.
Schritt 2: Blue-Green-Deployment zum Testen in der Produktionsumgebung – Wenn der Code im Canary-Deployment funktioniert, übertragen Sie ihn auf neu erstellte Server (oder Knoten bzw. Container) in Ihrer Produktionsumgebung, die parallel zu den Servern der aktuellen Version betrieben werden. Leiten Sie anschließend einen Teil des Produktionsdatenverkehrs an die neue Version weiter, um zu testen, ob sie auch unter höherer Last weiterhin zuverlässig funktioniert. In der Regel leiten Sie zunächst einen kleinen Prozentsatz (beispielsweise 10 %) an die neue Version weiter und erhöhen diesen schrittweise, bis die neue Version den gesamten Datenverkehr erhält. Die Größe der einzelnen Schritte hängt davon ab, wie sicher Sie sind, dass die neue Version den Datenverkehr bewältigen kann. Sie können auch in einem einzigen Schritt vollständig auf die neue Version umstellen.

Wenn Sie mit den verschiedenen Anwendungsfällen für die Verteilung des Datenverkehrs auf unterschiedliche Versionen einer App oder Website (Traffic Splitting) nicht vertraut sind, lesen Sie den Beitrag „So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Traffic-Management“ in unserem Blog. Darin erhalten Sie einen konzeptionellen Überblick über Blue-Green-Deployments, Canary-Releases, A/B-Tests, Ratenbegrenzung, Circuit Breaking und vieles mehr. Der Blogbeitrag bezieht sich zwar speziell auf Kubernetes, die Konzepte lassen sich jedoch allgemein auf Microservices-Anwendungen übertragen.

Überblick über das Tutorial

In diesem Tutorial zeigen wir, wie Sie den ersten Schritt eines Canary-Blue-Green-Deployments mithilfe von GitHub Actions automatisieren. In den vier Aufgaben des Tutorials verwenden Sie Microsoft Azure Container Apps, um eine neue Version Ihrer Anwendung bereitzustellen. Anschließend verwenden Sie Azure Traffic Manager, um den Datenverkehr von der alten Umgebung auf die neue Umgebung umzuleiten:

Eine NGINX-Container-App erstellen und bereitstellen
Berechtigungen für die Automatisierung von Azure Container Apps-Bereitstellungen einrichten
Erstellen Sie ein Canary-Blue-Green-Deployment mit einer GitHub Action
GitHub-Actions-Workflow testen

Hinweis: In diesem Tutorial werden zwar Azure Container Apps verwendet, die Konzepte und Techniken lassen sich jedoch auf jeden cloudbasierten Host anwenden.

Voraussetzungen und Einrichtung

Voraussetzungen

Wenn Sie dieses Tutorial in Ihrer eigenen Umgebung durchführen möchten, benötigen Sie Folgendes:

Ein Azure-Konto. Wir empfehlen Ihnen, ein Konto zu verwenden, das nicht mit Ihrer Organisation verknüpft ist, da bei der Verwendung eines Organisationskontos möglicherweise Berechtigungsprobleme auftreten.
Die Azure CLI.
Die GitHub CLI, wenn Sie sie anstelle der (oder zusätzlich zur) browserbasierten GitHub-Benutzeroberfläche verwenden möchten.

Einrichtung

Erstellen und konfigurieren Sie die erforderlichen Basisressourcen. Forken und klonen Sie das Repository für das Tutorial, melden Sie sich bei der Azure CLI an und installieren Sie die Erweiterung für Azure Container Apps.

Erstellen Sie in Ihrem Home-Verzeichnis das Verzeichnis „microservices-march“. (Sie können auch einen anderen Verzeichnisnamen verwenden und die Anweisungen entsprechend anpassen.) Hinweis: In diesem Tutorial wird die Eingabeaufforderung der Linux-Befehlszeile weggelassen, damit Sie die Befehle einfacher kopieren und in Ihr Terminal einfügen können.

mkdir ~/microservices-marchcd ~/microservices-march

Forken und klonen Sie das Repository der Microservices March-Plattform in Ihr persönliches GitHub-Konto. Verwenden Sie dazu entweder die GitHub-CLI oder die grafische Benutzeroberfläche.
- Bei Verwendung der GitHub-Benutzeroberfläche:
  1. Klicken Sie oben rechts im Fenster auf „Fork“ und wählen Sie im Menü „Owner“ Ihr persönliches GitHub-Konto aus.
  2. Klonen Sie das Repository lokal und ersetzen Sie dabei <your_GitHub_account> durch Ihren Kontonamen:

git clone https://github.com/<your_GitHub_account>/platform.gitcd platform

Wenn Sie die GitHub CLI verwenden, führen Sie Folgendes aus:

gh repo fork microservices-march/platform -–clone

Melden Sie sich bei der Azure CLI an. Folgen Sie den Anweisungen, um sich über einen Browser anzumelden:

az login
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e",
    "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
    "user": {
      "name": "user@example.com",
      "type": "user"
    }
  }
]

Installieren Sie die Erweiterung „containerapp“:

az extension add --name containerapp -upgradeThe installed extension 'containerapp' is in preview.

Aufgabe 1: Erstellen und Bereitstellen einer NGINX-Container-App

In dieser ersten Aufgabe erstellen Sie eine NGINX Azure Container App als erste Version der Anwendung, die als Ausgangsbasis für das Canary-Blue-Green-Deployment dient. Azure Container Apps ist ein Microsoft Azure-Dienst, mit dem Sie in einem Container verpackten Anwendungscode ganz einfach in einer produktionsbereiten Containerumgebung ausführen können.

Erstellen Sie eine Azure-Ressourcengruppe für die Container-App:

az group create --name my-container-app-rg --location westus{
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg",
  "location: "westus",
  "managedBy": null,
  "name": "my-container-app-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

Stellen Sie den Container in Azure Container Apps bereit (dieser Schritt kann eine Weile dauern):

az containerapp up --resource-group my-container-app-rg --name my-container-app --source ./ingress --ingress external --target-port 80 --location westus
... 
- image:
    registry: cac085021b77acr.azurecr.io
    repository: my-container-app
    tag: "20230315212413756768"
    digest: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451...
  runtime-dependency:
    registry: registry.hub.docker.com
    repository: library/nginx
    tag: "1.23"
    digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce...
  git: {} 
Run ID: cf1 was successful after 27s
Creating Containerapp my-container-app in resource group my-container-app-rg
Adding registry password as a secret with name "ca2ffbce7810acrazurecrio-cac085021b77acr" 
Container app created. Access your app at https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/
...

Suchen Sie in der Ausgabe aus Schritt 2 den Namen und die URL der Container-App, die Sie in der Azure Container Registry (ACR) erstellt haben. In der Beispielausgabe sind sie orange hervorgehoben. Ersetzen Sie in den Befehlen im gesamten Tutorial die angegebenen Variablen durch die Werte aus Ihrer Ausgabe (die von der Beispielausgabe in Schritt 2 abweichen werden):
- Name der Container-App – Im Schlüssel image.registry die Zeichenfolge vor .azurecr.io. In der Beispielausgabe in Schritt 2 lautet sie cac085021b77acr. Ersetzen Sie in den nachfolgenden Befehlen <ACR_name> durch diese Zeichenfolge.
- URL der Container-App – Die URL in der Zeile, die mit Container app created beginnt. In der Beispielausgabe in Schritt 2 lautet sie https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/. Ersetzen Sie in den nachfolgenden Befehlen <ACR_URL> durch diese URL.
Aktivieren Sie Revisionen für die Container-App, wie für eine Blau-Grün-Bereitstellung erforderlich:

az containerapp revision set-mode --name my-container-app --resource-group my-container-app-rg --mode multiple
"Multiple"

(Optional) Testen Sie, ob die Bereitstellung funktioniert, indem Sie den Endpunkt /health im Container abfragen:

curl <ACR_URL>/healthOK

Herausforderung 2: Berechtigungen für die Automatisierung von Azure Container App-Bereitstellungen einrichten

In dieser Aufgabe rufen Sie das JSON-Token ab, mit dem Sie die Bereitstellung von Azure-Container-Apps automatisieren können.

Zunächst rufen Sie die ID für die Azure Container Registry (ACR) und anschließend die Prinzipal-ID für Ihre verwaltete Azure-Identität ab. Danach weisen Sie der verwalteten Identität die integrierte Azure-Rolle für ACR zu und konfigurieren die Container-App für die Verwendung der verwalteten Identität. Abschließend rufen Sie die JSON-Anmeldeinformationen für die verwaltete Identität ab, die von GitHub Actions zur Authentifizierung bei Azure verwendet werden.

Auch wenn diese Schritte mühsam erscheinen mögen, müssen Sie sie beim Erstellen einer neuen Anwendung nur einmal ausführen und können den Vorgang vollständig per Skript automatisieren. In diesem Tutorial führen Sie die Schritte manuell aus, um sich mit ihnen vertraut zu machen.

Hinweis: Dieses Verfahren zum Erstellen von Anmeldeinformationen für die Bereitstellung gilt speziell für Azure.

Ermitteln Sie die Prinzipal-ID Ihrer verwalteten Identität. Sie wird in der Spalte PrincipalID der Ausgabe angezeigt (die zur besseren Lesbarkeit auf zwei Zeilen aufgeteilt ist). Ersetzen Sie in Schritt 3 <managed_identity_principal_ID> durch diesen Wert:

az containerapp identity assign --name my-container-app --resource-group my-container-app-rg --system-assigned --output table
PrincipalId                          ...                           
------------------------------------ ...  
    39f8434b-12d6-4735-81d8-ba0apo14579f ...
 
    ... TenantId
    ... ------------------------------------
        ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

Ermitteln Sie die Ressourcen-ID der Container-App in ACR und ersetzen Sie dabei <ACR_name> durch den Namen, den Sie in Schritt 3 von Aufgabe 1 notiert haben. Im nächsten Schritt ersetzen Sie <ACR_resource_ID> durch diesen Wert:

az acr show --name <ACR_name> --query id --output tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

Weisen Sie die integrierte Azure-Rolle für ACR der verwalteten Identität der Container-App zu. Ersetzen Sie dabei <managed_identity_principal_ID> durch die in Schritt 1 abgerufene verwaltete Identität und <ACR_resource_ID> durch die in Schritt 2 abgerufene Ressourcen-ID:

az role assignment create --assignee <managed_identity_principal_ID> --role AcrPull --scope <ACR_resource_ID>
{
  "condition": null,
  "conditionVersion": null,
  "createdBy": null,
  "createdOn": "2023-03-15T20:28:40.831224+00:00",
  "delegatedManagedIdentityResourceId": null,
  "description": null,
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr/providers/Microsoft.Authorization/roleAssignments/f0773943-8769-44c6-a820-ed16007ff249",
  "name": "f0773943-8769-44c6-a820-ed16007ff249",
  "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f",
  "principalType": "ServicePrincipal",
  "resourceGroup": "my-container-app-rg",
  "roleDefinitionId": "/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d",
  "scope": "/subscriptions/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr",
  "type": "Microsoft.Authorization/roleAssignments",
  "updatedBy": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d",
  "updatedOn": "2023-03-15T20:28:41.127243+00:00"
}

Konfigurieren Sie die Container-App so, dass sie beim Abrufen von Images aus ACR die verwaltete Identität verwendet. Ersetzen Sie dabei <ACR_name> durch den Namen der Container-App, den Sie in Schritt 3 von Aufgabe 1 notiert (und auch oben in Schritt 2 verwendet) haben:

az containerapp registry set --name my-container-app --resource-group my-container-app-rg --server <ACR_name>.azurecr.io --identity system
[
  {
    "identity": "system",
    "passwordSecretRef": "",
    "server": "cac085021b77acr.azurecr.io",
    "username": ""
  }
]

Suchen Sie Ihre Azure-Abonnement-ID.

az account show --query id --output tsv0efafl2-38ad-41w8-g49a-0ecc6723l97c

Erstellen Sie ein JSON-Token mit den Anmeldeinformationen, die von der GitHub Action verwendet werden sollen, und ersetzen Sie dabei <subscription_ID> durch Ihre Azure-Abonnement-ID. Speichern Sie die Ausgabe, um sie als Wert des Secrets mit dem Namen AZURE_CREDENTIALS unter „Secrets zu Ihrem GitHub-Repository hinzufügen“ einzufügen. Sie können die Warnung, dass --sdk-auth veraltet ist, bedenkenlos ignorieren; es handelt sich um ein bekanntes Problem:

az ad sp create-for-rbac --name my-container-app-rbac --role contributor --scopes /subscriptions/<subscription_ID>/resourceGroups/my-container-app-rg --sdk-auth --output json
Option '--sdk-auth' has been deprecated and will be removed in a future release.
...
{
  "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er",
  "clientSecret": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe",
  "subscriptionId": "0efafl2-38ad-41w8-g49a-0ecc6723l97c",
  "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

Aufgabe 3: Erstellen einer GitHub Action für ein Canary-Blue-Green-Deployment

In dieser Aufgabe fügen Sie Ihrem GitHub-Repository Geheimnisse hinzu (mit denen vertrauliche Daten in Ihren GitHub-Action-Workflows verwaltet werden), erstellen eine Action-Workflow-Datei und führen den Action-Workflow aus.

Eine ausführliche Einführung in die Verwaltung von Geheimnissen finden Sie im zweiten Tutorial zum Microservices March 23, „Geheimnisse in Containern sicher verwalten“, in unserem Blog.

Geheimnisse zu Ihrem GitHub-Repository hinzufügen

Um eine neue Version der Anwendung bereitzustellen, müssen Sie im GitHub-Repository, das Sie unter „Einrichtung“ geforkt haben, eine Reihe von Geheimnissen erstellen. Bei den Geheimnissen handelt es sich um die JSON-Anmeldeinformationen für die unter „Aufgabe 2“ erstellte verwaltete Identität sowie um einige vertrauliche, bereitstellungsspezifische Parameter, die erforderlich sind, um neue Versionen des NGINX-Images in Azure bereitzustellen. Im nächsten Abschnitt verwenden Sie diese Geheimnisse in einer GitHub Action, um die Canary-Blue-Green-Bereitstellung zu automatisieren.

Bei Verwendung der GitHub-Benutzeroberfläche:
1. Navigieren Sie zu Ihrem geforkten GitHub-Repository.
2. Wählen Sie „Settings > Secrets and variables > Actions“ aus.
3. Klicken Sie auf „New repository secret“.
4. Geben Sie die folgenden Werte in die angegebenen Felder ein:
  - Name – AZURE_CREDENTIALS
  - Geheimnis – Die JSON-Anmeldeinformationen aus Schritt 6 von Aufgabe 2
5. Klicken Sie auf „Geheimnis hinzufügen“.
6. Wiederholen Sie die Schritte 3–5 dreimal, um die in der Tabelle aufgeführten Geheimnisse zu erstellen. Geben Sie die Werte aus den Spalten Geheimnisname und Geheimniswert jeweils in die Felder Name und Geheimnis der Benutzeroberfläche ein. Ersetzen Sie beim dritten Geheimnis <ACR_name> durch den Namen, der der Container-App zugewiesen wurde und den Sie in Schritt 3 von Aufgabe 1 notiert haben. Geheimnisname GeheimniswertCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>
7. Fahren Sie mit „GitHub Actions-Workflowdatei erstellen“ fort.
Bei Verwendung der GitHub CLI:
1. Erstellen Sie im Stammverzeichnis Ihres Repositorys eine temporäre Datei.

touch ~/creds.json

Öffnen Sie mit Ihrem bevorzugten Texteditor die Datei „creds.json“ und fügen Sie die JSON-Anmeldedaten ein, die Sie in Schritt 6 von „Challenge 2“ erstellt haben.
Erstellen Sie das Secret:

gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.json

Löschen Sie creds.json:

rm ~/creds.json

Wiederholen Sie diesen Befehl, um drei weitere Secrets zu erstellen:

gh secret set <secret_name> --repo <your_GitHub_account>/platform

Ersetzen Sie bei jeder Wiederholung <secret_name> durch einen der Werte aus der Spalte Geheimnisname der Tabelle. Fügen Sie bei der Eingabeaufforderung den zugehörigen Wert aus der Spalte Geheimniswert ein. Ersetzen Sie beim dritten Geheimnis <ACR_name> durch den Namen, der der Container-App zugewiesen wurde und den Sie in Schritt 3 von Aufgabe 1 notiert haben. Geheimnisname GeheimniswertCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>

GitHub-Actions-Workflowdatei erstellen

Nachdem die verwaltete Identität und die Geheimnisse eingerichtet wurden, können Sie eine Workflowdatei für eine GitHub Action erstellen, die das Canary-Blue-Green-Deployment automatisiert.

Hinweis: Workflowdateien werden im YAML-Format definiert, bei dem Leerzeichen von Bedeutung sind. Achten Sie darauf, die in den folgenden Schritten gezeigte Einrückung beizubehalten.

Erstellen Sie eine Datei für den Action-Workflow.
- Bei Verwendung der GitHub-Benutzeroberfläche:
  1. Navigieren Sie zu Ihrem GitHub-Repository.
  2. Wählen Sie „Actions > New workflow > Skip this and set up a workflow yourself“ aus.
- Wenn Sie die GitHub CLI verwenden, erstellen Sie das Verzeichnis .github/workflows und darin eine neue Datei namens main.yml:

mkdir .github/workflowstouch .github/workflows/main.yml

Fügen Sie den Text des Workflows mit Ihrem bevorzugten Texteditor in die Datei main.yml ein. Am einfachsten ist es, den Text aus der vollständigen Workflow-Datei zu kopieren. Alternativ können Sie die Datei manuell erstellen, indem Sie die in diesem Schritt erläuterten Codeausschnitte hinzufügen. Hinweis: Workflow-Dateien werden im YAML-Format definiert, bei dem Leerzeichen von Bedeutung sind. Wenn Sie die Codeausschnitte kopieren, achten Sie darauf, die Einrückung beizubehalten. Vergleichen Sie Ihre Datei zur Sicherheit außerdem mit der vollständigen Workflow-Datei.
- Definieren Sie den Namen des Workflows:

name: Deploy to Azure

Konfigurieren Sie den Workflow so, dass er ausgeführt wird, wenn ein Push oder Pull-Request für den Main-Branch erfolgt:

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

Definieren Sie im Abschnitt „jobs“ den Job „build-deploy“, der den Code auscheckt, sich bei Azure anmeldet und die Anwendung in Azure Container Apps bereitstellt:

jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Build and deploy Container App
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }}
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io

Definieren Sie den Auftrag test-deployment, der die Staging-URL der neu bereitgestellten Revision abruft und mithilfe einer GitHub Action den API-Endpunkt /health aufruft, um sicherzustellen, dass die neue Revision antwortet. Wenn die Integritätsprüfung erfolgreich ist, wird der Azure Traffic Manager der Container-App so aktualisiert, dass der gesamte Datenverkehr an den neu bereitgestellten Container weitergeleitet wird. Hinweis: Achten Sie darauf, den Schlüssel test-deployment auf derselben Ebene einzurücken wie den Schlüssel build-deploy, den Sie im vorherigen Aufzählungspunkt definiert haben:

  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade

          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Vollständige Workflow-Datei

Dies ist der vollständige Inhalt der Workflow-Datei für die Action.

name: Deploy to Azure
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
     
      - name: Build and deploy Container 
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp -upgrade
       
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }} 
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io
  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Install the containerapp extension for the Azure CLI
          az extension add --name containerapp --upgrade
          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Aktionsworkflow ausführen

Bei Verwendung der GitHub-Benutzeroberfläche:
1. Klicken Sie auf „Commit starten“, fügen Sie bei Bedarf eine Commit-Nachricht hinzu und wählen Sie im Dialogfeld „Neue Datei committen“ aus. Die neue Workflow-Datei wird in den Main-Branch gemergt und ausgeführt.
2. Klicken Sie auf „Actions“, um den Fortschritt des Workflows zu überwachen.
Bei Verwendung der GitHub CLI:
1. Fügen Sie „main.yml“ zum Git-Staging-Bereich hinzu:

git add .github/workflows/main.yml

Committen Sie die Datei:

git commit -m "feat: create GitHub Actions workflow"

Pushe deine Änderungen zu GitHub:

git push

Überwachen Sie den Fortschritt des Workflows:

gh workflow view main.yml --repo <your_GitHub_account>/platform

Aufgabe 4: GitHub-Actions-Workflow testen

In dieser Aufgabe testen Sie den Workflow. Zunächst simulieren Sie eine erfolgreiche Aktualisierung Ihres Ingress-Load-Balancers und überprüfen, ob die Anwendung aktualisiert wurde. Anschließend simulieren Sie eine fehlgeschlagene Aktualisierung (die zu einem internen Serverfehler führt) und überprüfen, ob die veröffentlichte Anwendung unverändert bleibt.

Erfolgreiches Update durchführen

Erstellen Sie ein erfolgreiches Update und beobachten Sie, wie der Workflow erfolgreich abgeschlossen wird.

Bei Verwendung der GitHub-Benutzeroberfläche:
1. Wählen Sie „Code > ingress > default.conf.template“ aus.
2. Öffnen Sie default.conf.template zur Bearbeitung, indem Sie das Stiftsymbol mit dem Tooltip „Diese Datei bearbeiten“ auswählen.
3. Ändern Sie im location-Block /health am Ende der Datei die return-Direktive wie angegeben:

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

Wählen Sie im Dialogfeld Einen neuen Branch für diesen Commit erstellen und einen Pull-Request starten und anschließend Änderungen vorschlagen.
Klicken Sie auf „Pull Request erstellen“, um die Pull-Request-Vorlage aufzurufen.
Klicken Sie erneut auf „Create pull request“, um den Pull-Request zu erstellen.
Klicken Sie auf „Aktionen“, um den Fortschritt des Workflows zu überwachen.
Wenn der Workflow abgeschlossen ist, rufen Sie Ihre Container-App unter dem Endpunkt <ACR_URL>/health auf. Dabei ist <ACR_URL> die URL, die Sie sich in Schritt 3 von Aufgabe 1 notiert haben. Beachten Sie die Meldung „Successful Update!“.
Sie können die Meldung überprüfen, indem Sie eine Terminalsitzung starten und eine Integritätsprüfungsanforderung an die App senden. Ersetzen Sie dabei erneut <ACR_URL> durch den Wert, den Sie in Schritt 3 von Aufgabe 1 notiert haben:

curl <ACR_URL>/healthSuccessful Update!

Fahren Sie mit „Nicht erfolgreiche Aktualisierung durchführen“ fort.

Bei Verwendung der GitHub CLI:
1. Erstellen Sie einen neuen Branch namens „patch-1“:

git checkout -b patch-1

Öffnen Sie in Ihrem bevorzugten Texteditor die Datei „ingress/default.conf.template“ und ändern Sie im location-Block /health gegen Ende der Datei die return-Direktive wie angegeben:

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

Fügen Sie default.conf.template zum Git-Staging-Bereich hinzu:

git add ingress/default.conf.template

Committen Sie die Datei:

git commit -m "feat: update NGINX ingress"

Pushe deine Änderungen zu GitHub:

git push --set-upstream origin patch-1

Erstellen Sie einen Pull-Request (PR):

gh pr create --head patch-1 --fill --repo <your_GitHub_account>/platform

Überwachen Sie den Fortschritt des Workflows:

gh workflow view main.yml --repo <your_GitHub_account>/platform

Wenn der Workflow abgeschlossen ist, senden Sie eine Anfrage zur Integritätsprüfung an die App und ersetzen Sie dabei <ACR_URL> durch den Wert, den Sie in Schritt 3 von Aufgabe 1 notiert haben:

curl <ACR_URL>/health
Successful Update!

Ein fehlgeschlagenes Update durchführen

Erstellen Sie nun eine nicht erfolgreiche Aktualisierung und beobachten Sie, wie der Workflow fehlschlägt. Dazu wiederholen Sie im Wesentlichen die Schritte unter „Erfolgreiche Aktualisierung durchführen“, verwenden jedoch einen anderen Wert für die return-Direktive.

Bei Verwendung der GitHub-Benutzeroberfläche:
1. Wählen Sie „Code > ingress > default.conf.template“ aus.
2. Wählen Sie oben links main und anschließend den Namen des Branches aus, der auf patch-1 endet und den Sie im vorherigen Abschnitt erstellt haben.
3. Öffnen Sie default.conf.template zur Bearbeitung, indem Sie das Stiftsymbol mit dem Tooltip „Diese Datei bearbeiten“ auswählen.
4. Ändern Sie die return-Direktive wie angegeben:

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

Wählen Sie „Direkt in den Branch -patch-1 committen“ und anschließend „Änderungen committen“ aus.
Wählen Sie „Aktionen“ aus, um den Fortschritt des Workflows zu überwachen. Beachten Sie, dass der Workflow erneut ausgeführt wird, wenn Dateien im PR aktualisiert werden.
Wenn der Workflow abgeschlossen ist, navigieren Sie in Ihrer Container-App zum Endpunkt <ACR_URL>/health, wobei <ACR_URL> die URL ist, die Sie in Schritt 3 von Aufgabe 1 notiert haben. Beachten Sie, dass die Meldung Successful Update! lautet (genau wie nach der vorherigen erfolgreichen Aktualisierung). Auch wenn dies paradox erscheinen mag, bestätigt es tatsächlich, dass diese Aktualisierung fehlgeschlagen ist. Der Aktualisierungsversuch führte zum Status 500 (das bedeutet Internal Server Error) und wurde nicht angewendet.
Sie können die Meldung überprüfen, indem Sie eine Terminalsitzung starten und eine Integritätsprüfungsanforderung an die App senden. Ersetzen Sie dabei erneut <ACR_URL> durch den Wert, den Sie in Schritt 3 von Challenge 1 notiert haben:

curl <ACR_URL>/healthSuccessful Update!

Bei Verwendung der GitHub CLI:
1. Wechsle zu dem Branch „patch-1“, den du im vorherigen Abschnitt erstellt hast:

git checkout patch-1

Öffnen Sie in Ihrem bevorzugten Texteditor die Datei ingress/default.conf.template und ändern Sie erneut die return-Direktive wie angegeben:

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

Fügen Sie „default.conf.template“ zum Git-Staging-Bereich hinzu:

git add ingress/default.conf.template

Committen Sie die Datei:

git commit -m "feat: update NGINX ingress again"

Pushe deine Änderungen zu GitHub:

git push

Überwachen Sie den Fortschritt des Workflows:

gh workflow view main.yml --repo <your_GitHub_account>/platform

Wenn der Workflow abgeschlossen ist, senden Sie eine Integritätsprüfungsanfrage an die App und ersetzen Sie dabei <ACR_URL> durch den Wert, den Sie in Schritt 3 von Aufgabe 1 notiert haben:

curl <ACR_URL>/healthSuccessful Update!

Es mag paradox erscheinen, dass die Meldung „Successful Update!“ lautet (genau wie nach der vorherigen, erfolgreichen Aktualisierung). Doch so paradox das auch erscheinen mag, bestätigt es tatsächlich, dass diese Aktualisierung fehlgeschlagen ist – der Aktualisierungsversuch führte zum Statuscode 500 (das bedeutet „Internal Server Error“) und wurde nicht übernommen.

Ressourcenbereinigung

Sie sollten die im Tutorial bereitgestellten Azure-Ressourcen entfernen, um mögliche spätere Kosten zu vermeiden:

az group delete -n my-container-app-rg -y

Wenn Sie möchten, können Sie auch den von Ihnen erstellten Fork löschen.

Bei Verwendung der GitHub-Benutzeroberfläche:
1. Klicken Sie auf „Einstellungen“.
2. Scrollen Sie bis zum Ende der Seite.
3. Klicken Sie auf „Dieses Repository löschen“.
4. Geben Sie <your_GitHub_account>/platform ein und wählen Sie Ich verstehe die Konsequenzen, dieses Repository löschen aus.
Bei Verwendung der GitHub CLI:

gh repo delete <your_GitHub_account>/platform -yes

Nächste Schritte

Herzlichen Glückwunsch! Sie haben gelernt, wie Sie mit GitHub Actions ein Canary-Blue-Green-Deployment einer Microservices-App durchführen. In diesen Artikeln in der GitHub-Dokumentation können Sie sich weiter mit DevOps beschäftigen und Ihre Kenntnisse vertiefen:

Wenn Sie bereit sind, den zweiten Schritt eines Canary-Deployments (Tests in der Produktionsumgebung) auszuprobieren, lesen Sie das Tutorial vom Microservices March 2022: „Verfügbarkeit und Ausfallsicherheit mit einem Canary-Deployment verbessern“ in unserem Blog. Darin wird NGINX Service Mesh verwendet, um schrittweise auf eine neue App-Version umzustellen. Auch wenn Ihre Deployments noch nicht komplex genug sind, um ein Service Mesh zu benötigen, oder Sie Kubernetes nicht verwenden, gelten die Prinzipien ebenso für einfachere Deployments, die lediglich einen Ingress-Controller oder Load Balancer verwenden.

Wenn Sie Ihr Wissen über Microservices vertiefen möchten, sehen Sie sich den Microservices March 2023 an. In Einheit 3: Microservices-Bereitstellungen durch Automatisierung beschleunigen erfahren Sie mehr über die Automatisierung von Bereitstellungen.