BLOG | NGINX

NGINX-Tutorial: So verwenden Sie GitHub Actions zur Automatisierung von Microservices Canary-Bereitstellungen

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
Christopher Harrison Miniaturbild
Christopher Harrison
Veröffentlicht am 21. März 2023

Dieser Beitrag ist eines von vier Tutorials, die Ihnen helfen, Konzepte aus Microservices März 2023 in die Praxis umzusetzen: Beginnen Sie mit der Bereitstellung von Microservices :

 

Die Automatisierung von Bereitstellungen ist für den Erfolg der meisten Projekte von entscheidender Bedeutung. Es reicht jedoch nicht aus, einfach nur Ihren Code bereitzustellen. Sie müssen außerdem sicherstellen, dass Ausfallzeiten begrenzt (oder vermieden) werden, und Sie müssen im Falle eines Fehlers in der Lage sein, schnell ein Rollback durchzuführen. Die Kombination von Canary-Bereitstellung und Blue-Green-Bereitstellung ist ein gängiger Ansatz, um sicherzustellen, dass neuer Code funktionsfähig ist. Diese Strategie umfasst zwei Schritte:

  • Schritt 1: Canary-Bereitstellung zum isolierten Testen – Stellen Sie Ihren Code auf einem isolierten Knoten, Server oder Container außerhalb Ihrer Umgebung bereit und testen Sie, um sicherzustellen, dass der Code wie vorgesehen funktioniert.
  • Schritt 2: Blue-Green-Bereitstellung zum Testen in der Produktion : Vorausgesetzt, der Code funktioniert in der Canary-Bereitstellung, portieren Sie den Code neben den Servern für die aktuelle Version auf neu erstellte Server (oder Knoten oder Container) in Ihrer Produktionsumgebung. Leiten Sie dann einen Teil des Produktionsverkehrs auf die neue Version um, um zu testen, ob sie unter höherer Last weiterhin gut funktioniert. Normalerweise leiten Sie zunächst einen kleinen Prozentsatz (beispielsweise 10 %) an die neue Version weiter und erhöhen diesen dann schrittweise, bis die neue Version den gesamten Datenverkehr aufnimmt. Die Größe der Schritte hängt davon ab, wie sehr Sie davon ausgehen, dass die neue Version den Datenverkehr bewältigen kann. Sie können sogar in einem einzigen Schritt vollständig auf die neue Version umsteigen.

Wenn Sie mit den verschiedenen Anwendungsfällen für die Verteilung des Datenverkehrs zwischen verschiedenen Versionen einer App oder Website ( Datenverkehrsaufteilung ) nicht vertraut sind, lesen Sie in unserem Blog den Artikel „So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Datenverkehrsmanagement“ , um ein konzeptionelles Verständnis von Blue-Green-Bereitstellungen, Canary-Releases, A/B-Tests, Ratenbegrenzung, Circuit Breaking und mehr zu erlangen. Während sich der Blog speziell auf Kubernetes bezieht, sind die Konzepte allgemein auf Microservices-Apps anwendbar.

Tutorialübersicht

In diesem Tutorial zeigen wir, wie der erste Schritt einer Canary Blue‑Green‑Bereitstellung mit GitHub Actions automatisiert wird. In den vier Herausforderungen des Tutorials verwenden Sie Microsoft Azure Container Apps, um eine neue Version Ihrer Anwendung bereitzustellen, und verwenden dann Azure Traffic Manager, um den Datenverkehr von der alten in die neue Umgebung zu verschieben:

Notiz: Obwohl in diesem Tutorial Azure Container Apps verwendet werden, können die Konzepte und Techniken auf jeden beliebigen Cloud-basierten Host angewendet werden.

Voraussetzungen und Einrichtung

Voraussetzungen

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

  • 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 Probleme mit den Berechtigungen auftreten können.
  • Die Azure-Befehlszeilenschnittstelle .
  • Die GitHub CLI , wenn Sie sie anstelle (oder zusätzlich) der browserbasierten GitHub GUI verwenden möchten.

Aufstellen

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.

  1. Erstellen Sie in Ihrem Home-Verzeichnis das Verzeichnis „Microservices-March“ . (Sie können auch einen anderen Verzeichnisnamen verwenden und die Anweisungen entsprechend anpassen.)

    Notiz: Im gesamten Tutorial wird die Eingabeaufforderung in der Linux-Befehlszeile weggelassen, um das Kopieren und Einfügen der Befehle in Ihr Terminal zu erleichtern.

    mkdir ~/microservices-marchcd ~/microservices-march

  2. Forken und klonen Sie das Microservices March-Plattform -Repository in Ihr persönliches GitHub-Konto, indem Sie entweder die GitHub-CLI oder die GUI verwenden.

    • Bei Verwendung der GitHub-GUI:

      1. Klicken Sie oben rechts im Fenster auf „Fork“ und wählen Sie im Menü „Besitzer“ Ihr persönliches GitHub-Konto aus.

        Screenshot der GitHub-GUI, der den Fork des Repository für dieses Tutorial zeigt

      2. Klonen Sie das Repository lokal und ersetzen Sie Ihren Kontonamen durch <Ihr_GitHub_Konto>:

        Git-Klon https://github.com/<Ihr_GitHub_Konto>/platform.gitcd-Plattform

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

      gh Repo Fork Microservices-März/Plattform -–Klon

  3. 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-Abonnement 1“, „Status“: "Aktiviert", "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde", "Benutzer": { "Name": "user@example.com", "Typ": "Benutzer" } } ]

  4. Installieren Sie die Containerapp- Erweiterung:

    az extension add --name containerapp -upgrade Die installierte Erweiterung „Containerapp“ befindet sich in der Vorschau.

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

In dieser ersten Herausforderung erstellen Sie eine NGINX Azure Container App als erste Version der Anwendung, die als Basis für die Canary Blue‑Green‑Bereitstellung verwendet wird. Azure Container Apps ist ein Microsoft Azure-Dienst, mit dem Sie in einem Container gepackten Anwendungscode einfach in einer produktionsbereiten Containerumgebung ausführen können.

  1. 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": "Erfolgreich" }, "tags": null, "type": "Microsoft.Resources/resourceGroups" }

  2. 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: Registrierung: cac085021b77acr .azurecr.io Repository: my-container-app Tag: "20230315212413756768" Digest: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451... Laufzeitabhängigkeit: Registrierung: registry.hub.docker.com Repository: Bibliothek/nginx Tag: „1.23“-Digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce... git: {} Run-ID: cf1 war nach 27 s erfolgreich. Erstellen der Container-App „my-container-app“ in der Ressourcengruppe „my-container-app-rg“. Hinzufügen des Registrierungskennworts als Geheimnis mit dem Namen „ca2ffbce7810acrazurecrio-cac085021b77acr“. Container-App erstellt. Greifen Sie unter https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ auf Ihre App zu.

  3. Suchen Sie in der Ausgabe in Schritt 2 den Namen und die URL der Container-App, die Sie im Azure Container Registry (ACR) erstellt haben. Sie werden in der Beispielausgabe orange hervorgehoben. Sie ersetzen im gesamten Lernprogramm die Werte aus Ihrer Ausgabe (die sich von der Beispielausgabe in Schritt 2 unterscheidet) durch die angegebenen Variablen in Befehlen:

    • Name der Container-App – Im Schlüssel image.registry die Zeichenfolge vor .azurecr.io . In der Beispielausgabe in Schritt 2 ist es cac085021b77acr .

      Ersetzen Sie diese Zeichenfolge durch <ACR_Name> in nachfolgenden Befehlen.

    • URL der Container-App – Die URL in der Zeile, die mit „Container- App erstellt “ beginnt. In der Beispielausgabe in Schritt 2 ist es https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ .

      Ersetzen Sie diese URL durch <ACR_URL> in nachfolgenden Befehlen.

  4. Aktivieren Sie die Revisionen für die Container-App nach Bedarf für eine Blue‑Green‑Bereitstellung:

    az containerapp revision set-mode \ --name meine-Container-App \ --resource-group meine-Container-App-rg \ --mode multiple "Mehrere"

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

    Locke <ACR_URL>/GesundheitOK

Herausforderung 2: Einrichten von Berechtigungen zum Automatisieren der Bereitstellung von Azure Container-Apps

Bei dieser Herausforderung erhalten Sie das JSON-Token, mit dem Sie die Bereitstellung von Azure-Container-Apps automatisieren können.

Sie beginnen mit dem Abrufen der ID für die Azure Container Registry (ACR) und dann der Prinzipal-ID für Ihre verwaltete Azure-Identität . Anschließend 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. Schließlich erhalten Sie die JSON-Anmeldeinformationen für die verwaltete Identität, die von GitHub Actions zur Authentifizierung bei Azure verwendet werden.

Diese Schritte erscheinen zwar möglicherweise mühsam, Sie müssen sie jedoch beim Erstellen einer neuen Anwendung nur einmal ausführen und können den Vorgang vollständig skripten. Im Lernprogramm führen Sie die Schritte manuell aus, damit Sie sich mit ihnen vertraut machen können.

Notiz: Dieser Prozess zum Erstellen von Anmeldeinformationen für die Bereitstellung ist spezifisch für Azure.

  1. Suchen Sie die Prinzipal-ID Ihrer verwalteten Identität. Es wird in der Spalte „PrincipalID“ der Ausgabe angezeigt (die zur besseren Lesbarkeit auf zwei Zeilen aufgeteilt ist). Sie ersetzen diesen Wert durch <verwaltete_Identitätsprinzipal-ID> in Schritt 3:

    az containerapp identity assign \ --name meine-Container-App \ --resource-group meine-Container-App-rg \ --system-assigned \ --output table PrincipalId ... ------------------------------------ …  
    39f8434b-12d6-4735-81d8-ba0apo14579f ... ... Mandanten-ID ... --------------------------------- ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

  2. Suchen Sie die Ressourcen-ID der Container-App in ACR und ersetzen Sie <ACR_Name> mit dem Namen, den Sie in Schritt 3 von Herausforderung 1. Sie ersetzen diesen Wert durch <ACR_Ressourcen-ID> im nächsten Schritt:

    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

  3. Weisen Sie der verwalteten Identität der Container-App die integrierte Azure-Rolle für ACR zu und ersetzen Sie <verwaltete_Identitätsprinzipal-ID> mit der in Schritt 1 erhaltenen verwalteten Identität und <ACR_Ressourcen-ID> mit der in Schritt 2 erhaltenen Ressourcen-ID:

    az-Rollenzuweisung erstellen \ --assignee <verwaltete_Identitätsprinzipal-ID> \
--role AcrPull \
--scope <ACR_Ressourcen-ID>
{
"Bedingung": null,
"BedingungsVersion": null,
"erstellt von": null,
"erstellt am": "2023-03-15T20:28:40.831224+00:00", "delegatedManagedIdentityResourceId": null, "Beschreibung": 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", "Haupttyp": "ServicePrincipal", "Ressourcengruppe": "my-container-app-rg", "Rollendefinitions-ID": "/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d", "Bereich": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/Ressourcengruppe/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr", "Typ": "Microsoft.Authorization/roleAssignments", "aktualisiert durch": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d", "aktualisiert am": „2023-03-15T20:28:41.127243+00:00“ }

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

    az containerapp registry set \ --name meine-container-app \
--resource-group meine-container-app-rg \
--server <ACR_Name>.azurecr.io \
--Identitätssystem
[
{
"Identität": "System",
"PasswortGeheimer Verweis": "",
"Server": "cac085021b77acr.azurecr.io",
"Benutzername": ""
}
]

  5. Suchen Sie nach Ihrer Azure-Abonnement-ID .

    az-Konto anzeigen --Query-ID --Output TSV 0efafl2-38ad-41w8-g49a-0ecc6723l97c

  6. Erstellen Sie ein JSON-Token, das die von der GitHub-Aktion zu verwendenden Anmeldeinformationen enthält, und ersetzen Sie <Abonnement-ID> mit Ihrer Azure-Abonnement-ID. Speichern Sie die Ausgabe, um sie als Wert des Geheimnisses mit dem Namen einzufügen AZURE_CREDENTIALS In Fügen Sie Ihrem GitHub-Repository Geheimnisse hinzu. Sie können die Warnung, dass --sdk-auth veraltet ist, getrost ignorieren. Es handelt sich um ein bekanntes Problem :

    az ad sp create-for-rbac \ --name my-container-app-rbac \
--role contributor \
--scopes /subscriptions/<Abonnement-ID>/resourceGroups/my-container-app-rg \
--sdk-auth \
--output json
Option '--sdk-auth' ist veraltet und wird in einer zukünftigen Version entfernt.
...
{
"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/" }

Herausforderung 3: Erstellen einer Canary Blue-Green Deployment GitHub-Aktion

Bei dieser Herausforderung fügen Sie Ihrem GitHub-Repository Geheimnisse hinzu (die zum Verwalten vertraulicher Daten in Ihren GitHub-Action-Workflows verwendet werden), erstellen eine Action-Workflow-Datei und führen den Action-Workflow aus .

Eine ausführliche Einführung in die Geheimnisverwaltung finden Sie im zweiten Tutorial für Microservices vom 23. März, „Sichere Verwaltung von Geheimnissen in Containern“ auf unserem Blog.

Fügen Sie Ihrem GitHub-Repository Geheimnisse hinzu

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

  • Bei Verwendung der GitHub-GUI:

    1. Navigieren Sie zu Ihrem gegabelten GitHub-Repository.
    2. Wählen Sie Einstellungen > Geheimnisse und Variablen > Aktionen .
    3. Klicken Sie auf Neues Repository-Geheimnis .

    4. Geben Sie die folgenden Werte in die angegebenen Felder ein:

      • Name – AZURE_CREDENTIALS
      • Geheim – Die JSON-Anmeldeinformationen aus Schritt 6 der Herausforderung 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 „Geheimer Name“ und „Geheimer Wert“ in die Felder „Name“ und „Geheim“ der GUI ein. Für das dritte Geheimnis ersetzen Sie <ACR_Name> mit dem Namen, der der Container-App zugewiesen wurde und den Sie in Schritt 3 von Herausforderung 1.

      Geheimer Name Geheimer Wert
      CONTAINER_APP_NAME meine-container-app
      RESSOURCENGRUPPE meine-Container-App-rg
      ACR_NAME <ACR_Name>
    7. Fahren Sie mit dem Erstellen einer GitHub Action-Workflow-Datei fort.

  • Bei Verwendung der GitHub-CLI:

    1. Erstellen Sie im Stammverzeichnis Ihres Repository eine temporäre Datei.

      berühren Sie ~/creds.json
    2. Öffnen Sie creds.json mit Ihrem bevorzugten Texteditor und kopieren Sie die JSON-Anmeldeinformationen, die Sie in Schritt 6 von Challenge 2 erstellt haben.

    3. Erstellen Sie das Geheimnis:

      gh geheimer Satz AZURE_CREDENTIALS --repo <Ihr_GitHub_Konto>/Plattform < ~/creds.json

    4. Löschen Sie creds.json :

      rm ~/creds.json

    5. Wiederholen Sie diesen Befehl, um drei weitere Geheimnisse zu erstellen:

      gh geheimes Set <geheimer_Name> --repo <Ihr_GitHub_Konto>/Plattform

      Ersetzen Sie bei jeder Wiederholung <geheimer_Name> mit einem der Werte in der Geheimer Name in der Tabelle. Fügen Sie bei der Eingabeaufforderung den zugehörigen Wert aus der Spalte „Geheimer Wert“ ein. Für das dritte Geheimnis ersetzen Sie <ACR_Name> mit dem Namen, der der Container-App zugewiesen wurde und den Sie in Schritt 3 von Herausforderung 1.

      Geheimer Name Geheimer Wert
      CONTAINER_APP_NAME meine-container-app
      RESSOURCENGRUPPE meine-Container-App-rg
      ACR_NAME <ACR_Name>

Erstellen einer GitHub Action-Workflow-Datei

Wenn die verwaltete Identität und die Geheimnisse vorhanden sind, können Sie eine Workflow-Datei für eine GitHub-Aktion erstellen, die die Blue-Green-Bereitstellung des Canary automatisiert.

Notiz: Workflow-Dateien werden im YAML-Format definiert, wobei Leerzeichen eine Rolle spielen. Achten Sie darauf, die in den folgenden Schritten angezeigte Einrückung beizubehalten.

  1. Erstellen Sie eine Datei für den Aktionsworkflow.

    • Bei Verwendung der GitHub-GUI:

      1. Navigieren Sie zu Ihrem GitHub-Repository.
      2. Wählen Sie Aktionen > Neuer Workflow > Überspringen Sie dies und richten Sie selbst einen Workflow ein .

    • Wenn Sie die GitHub-CLI verwenden, erstellen Sie das Verzeichnis .github/workflows und erstellen Sie eine neue Datei namens main.yml :

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

  2. Fügen Sie mit Ihrem bevorzugten Texteditor den Text des Workflows zu main.yml hinzu. Die einfachste Methode besteht darin, den Text zu kopieren, der in der vollständigen Workflow-Datei angezeigt wird. Alternativ können Sie die Datei manuell erstellen, indem Sie die in diesem Schritt kommentierten Snippets hinzufügen.

    Notiz: Workflow-Dateien werden im YAML-Format definiert, wobei Leerzeichen eine Rolle spielen. Achten Sie beim Kopieren der Snippets darauf, die Einrückung beizubehalten (und vergleichen Sie Ihre Datei zur Sicherheit mit der vollständigen Workflow-Datei ).

    • Definieren Sie den Namen des Workflows:

      Name: Bereitstellen in Azure

    • Konfigurieren Sie den Workflow so, dass er ausgeführt wird, wenn eine Push- oder Pull-Anforderung an den Hauptzweig gestellt wird:

      an:
push:
Zweige:
- Haupt
pull_request:
Zweige:
- Haupt

    • Definieren Sie im Abschnitt „Jobs “ den Build-Deploy- Job, der den Code auscheckt, sich bei Azure anmeldet und die Anwendung in der Azure Container App bereitstellt:

      Jobs: Build-Deploy: Läuft auf: Ubuntu-22.04 Schritte: - Name: Schauen Sie sich die Codebasis an, die verwendet wird: actions/checkout@v3 - Name: Zur Anmeldung bei Azure verwenden Sie: azure/login@v1 mit: creds:${{ secrets.AZURE_CREDENTIALS } } - Name: Erstellen und Bereitstellen der Container-App. Ausführen: | # Fügen Sie die Container-App-Erweiterung manuell hinzu. az extension add --name containerapp --upgrade # Verwenden Sie die Azure CLI zum Bereitstellen des Updates az containerapp up -n${{ secrets.CONTAINER_APP_NAME } }\ -G${{ secrets.RESOURCE_GROUP } } \ --Quelle${{ github.workspace } }/ingress \ --registry-server${{ secrets.ACR_NAME } }.azurecr.io

    • Definieren Sie den Testbereitstellungsjob , der die Staging-URL der neu bereitgestellten Revision abruft und mithilfe einer GitHub-Aktion den API-Endpunkt /health anpingt, um sicherzustellen, dass die neue Revision reagiert. Wenn die Integritätsprüfung erfolgreich ist, wird der Azure Traffic Manager in der Container-App aktualisiert, um den gesamten Datenverkehr auf den neu bereitgestellten Container umzuleiten.

      Notiz: Denken Sie daran, den Schlüssel „test-deployment“ auf derselben Ebene einzurücken wie den Schlüssel „build-deploy“, den Sie im vorherigen Aufzählungspunkt definiert haben:

        Testbereitstellung: Anforderungen: Build-Deploy läuft auf: Ubuntu 22.04 Schritte: - Name: Zur Anmeldung bei Azure verwenden Sie: azure/login@v1 mit: creds:${{ secrets.AZURE_CREDENTIALS } } - Name: Neuen Containernamen abrufen. Ausführen: | # Containerapp-Erweiterung manuell hinzufügen. az extension add --name containerapp --upgrade # Zuletzt bereitgestellten Revisionsnamen abrufen. REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -G${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # FQDN der letzten bereitgestellten Revision abrufen REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -G${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # Werte in Umgebungsvariablen speichern echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - Name: Testbereitstellungs-ID: Testbereitstellung verwendet: jtalk/url-health-check-action@v3 # Marktplatzaktion zum Berühren des Endpunkts mit: URL: "https://${{ env.REVISION_FQDN } }/health" # Staging-Endpunkt - Name: Bereitstellung erfolgreich. Ausführen: | echo "Bereitstellung erfolgreich! Neue Revision aktivieren" 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 Text für die Aktions-Workflow-Datei.

Name: In Azure bereitstellen auf: Push: Zweige: – Haupt-Pull_Request: Zweige: – Hauptjobs: Build-Deploy: Läuft auf: Ubuntu-22.04 Schritte: – Name: Schauen Sie sich die Codebasis an, die verwendet wird: actions/checkout@v3 - Name: Zur Anmeldung bei Azure verwenden Sie: azure/login@v1 mit: creds:${{ secrets.AZURE_CREDENTIALS } } - Name: Erstellen und Bereitstellen von Containerausführung: | # Fügen Sie die Containerapp-Erweiterung manuell hinzu az extension add --name containerapp -upgrade # Verwenden Sie Azure CLI zum Bereitstellen von Updates az containerapp up -n${{ secrets.CONTAINER_APP_NAME } } \ -G${{ secrets.RESOURCE_GROUP } } \ --Quelle${{ github.workspace } }/ingress \ --registry-server${{ secrets.ACR_NAME } }.azurecr.io Testbereitstellung: Anforderungen: Build-Deploy läuft auf: Ubuntu 22.04 Schritte: - Name: Zur Anmeldung bei Azure verwenden Sie: azure/login@v1 mit: creds:${{ secrets.AZURE_CREDENTIALS } } - Name: Neuen Containernamen abrufen. Ausführen: | # Containerapp-Erweiterung für die Azure CLI installieren. az extension add --name containerapp --upgrade # Zuletzt bereitgestellten Revisionsnamen abrufen. REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -G${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # FQDN der letzten bereitgestellten Revision abrufen REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -G${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # Werte in Umgebungsvariablen speichern echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - Name: Testbereitstellungs-ID: Testbereitstellung verwendet: jtalk/url-health-check-action@v3 # Marktplatzaktion zum Berühren des Endpunkts mit: URL: "https://${{ env.REVISION_FQDN } }/health" # Staging-Endpunkt - Name: Bereitstellung erfolgreich. Ausführen: | echo "Bereitstellung erfolgreich! Neue Revision aktivieren" az containerapp ingress traffic set -n${{ secrets.CONTAINER_APP_NAME } } -G${{ secrets.RESOURCE_GROUP } } --revision-weight "${{ env.REVISION_NAME } }=100"

Ausführen des Aktionsworkflows

  • Bei Verwendung der GitHub-GUI:

    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 Hauptzweig integriert und die Ausführung beginnt.
    2. Klicken Sie auf „Aktionen“, 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

    2. Übernehmen Sie die Datei:

      git commit -m "feat: GitHub Actions-Workflow erstellen"

    3. Übertragen Sie Ihre Änderungen auf GitHub:

      git push

    4. Überwachen Sie den Fortschritt des Workflows:

      gh Workflow-Ansicht main.yml --repo <Ihr_GitHub_Konto>/Plattform

Herausforderung 4: Testen des GitHub Actions-Workflows

In dieser Herausforderung testen Sie den Workflow. Sie simulieren zunächst eine erfolgreiche Aktualisierung Ihres Ingress-Load Balancers und bestätigen, dass die Anwendung aktualisiert wurde. Anschließend simulieren Sie ein erfolgloses Update (das zu einem internen Serverfehler führt) und bestätigen, dass die veröffentlichte Anwendung unverändert bleibt.

Führen Sie ein erfolgreiches Update durch

Erstellen Sie ein erfolgreiches Update und beobachten Sie, wie der Workflow erfolgreich verläuft.

  • Bei Verwendung der GitHub-GUI:

    1. Wählen Sie Code > ingress > default.conf.template .
    2. Öffnen Sie default.conf.template zum Bearbeiten, indem Sie das Bleistiftsymbol mit dem Tooltip „Diese Datei bearbeiten“ auswählen.

    3. Ändern Sie im Speicherort- /Health- Block am Ende der Datei die Return- Direktive wie angegeben:

      location /health {
access_log off;
return 200 "Update erfolgreich!\n";
}
    4. Wählen Sie im Dialogfeld Einen neuen Branch für dieses Commit erstellen und einen Pull Request starten und dann Änderungen vorschlagen aus .
    5. Klicken Sie auf „Pull Request erstellen“, um auf die Pull Request-Vorlage zuzugreifen.
    6. Klicken Sie erneut auf „Pull Request erstellen“, um den Pull Request zu erstellen.
    7. Klicken Sie auf „Aktionen“, um den Fortschritt des Workflows zu überwachen.
    8. Wenn der Workflow abgeschlossen ist, navigieren Sie zu Ihrer Container-App unter <ACR_URL>/Gesundheit Endpunkt, an dem die <ACR_URL> ist die URL, die Sie in Schritt 3 von notiert haben Herausforderung 1. Beachten Sie die Meldung „Update erfolgreich !“ .

    9. Sie können die Meldung bestätigen, indem Sie eine Terminalsitzung starten und eine Integritätsprüfungsanfrage an die App senden. Ersetzen Sie dabei erneut <ACR_URL> mit dem Wert, den Sie in Schritt 3 von Herausforderung 1:

      Locke <ACR_URL>/GesundheitErfolgreiches Update!
    10. Fahren Sie mit der Durchführung eines erfolglosen Updates fort.

  • Bei Verwendung der GitHub-CLI:

    1. Erstellen Sie einen neuen Zweig mit dem Namen patch-1 :

      git checkout -b patch-1

    2. Öffnen Sie ingress/default.conf.template in Ihrem bevorzugten Texteditor und ändern Sie im Speicherort- /Health- Block am Ende der Datei die Return- Direktive wie angegeben:

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

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

      git add ingress/default.conf.template

    4. Übernehmen Sie die Datei:

      git commit -m "feat: NGINX-Ingress aktualisieren"

    5. Übertragen Sie Ihre Änderungen auf GitHub:

      git push --set-upstream Herkunft Patch-1

    6. Erstellen Sie eine Pull-Anfrage (PR):

      gh pr erstellen --head patch-1 --fill --repo <Ihr_GitHub_Konto>/Plattform

    7. Überwachen Sie den Fortschritt des Workflows:

      gh Workflow-Ansicht main.yml --repo <Ihr_GitHub_Konto>/Plattform

    8. Wenn der Workflow abgeschlossen ist, senden Sie eine Integritätsprüfungsanforderung an die App und ersetzen Sie <ACR_URL> mit dem Wert, den Sie in Schritt 3 von Herausforderung 1:

      Locke <ACR_URL>/Gesundheit
Erfolgreiches Update!

Führen Sie ein fehlgeschlagenes Update durch

Erstellen Sie jetzt ein erfolgloses Update und beobachten Sie, wie der Workflow fehlschlägt. Dabei werden grundsätzlich die Schritte unter „Erfolgreiches Update durchführen“ wiederholt, allerdings mit einem anderen Wert für die Return -Direktive.

  • Bei Verwendung der GitHub-GUI:

    1. Wählen Sie Code > ingress > default.conf.template .
    2. Wählen Sie oben links „main“ und dann den Namen des Zweigs aus, der mit „patch-1“ endet und den Sie im vorherigen Abschnitt erstellt haben.
    3. Öffnen Sie default.conf.template zum Bearbeiten, indem Sie das Bleistiftsymbol mit dem Tooltip „Diese Datei bearbeiten“ auswählen.

    4. Ändern Sie die Rückgabeanweisung wie angegeben:

      location /health {
access_log off;
return 500 "Update nicht erfolgreich!\n";
}
    5. Wählen Sie „Direkt zum -patch-1-Zweig Commit“ und dann „Änderungen Commit“ aus.
    6. 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.

    7. Wenn der Workflow abgeschlossen ist, navigieren Sie zu Ihrer Container-App unter <ACR_URL>/Gesundheit Endpunkt, an dem die <ACR_URL> ist die URL, die Sie in Schritt 3 von Herausforderung 1.

       

      Beachten Sie, dass die Meldung „Update erfolgreich !“ lautet (dieselbe wie nach dem vorherigen, erfolgreichen Update). Das mag zwar paradox erscheinen, bestätigt aber tatsächlich, dass dieses Update fehlgeschlagen ist – der Updateversuch führte zu dem Status500 (bedeutet „ Interner Serverfehler “) und wurde nicht angewendet.

    8. Sie können die Meldung bestätigen, indem Sie eine Terminalsitzung starten und eine Integritätsprüfungsanfrage an die App senden. Ersetzen Sie dabei erneut <ACR_URL> mit dem Wert, den Sie in Schritt 3 von Herausforderung 1:

      Locke <ACR_URL>/GesundheitErfolgreiches Update!

  • Bei Verwendung der GitHub-CLI:

    1. Sehen Sie sich den Patch-1 -Zweig an, den Sie im vorherigen Abschnitt erstellt haben:

      git checkout patch-1

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

      location /health {
access_log off;
return 500 "Update nicht erfolgreich!\n";
}

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

      git add ingress/default.conf.template

    4. Übernehmen Sie die Datei:

      git commit -m "feat: NGINX-Ingress erneut aktualisieren"

    5. Übertragen Sie Ihre Änderungen auf GitHub:

      git push

    6. Überwachen Sie den Fortschritt des Workflows:

      gh Workflow-Ansicht main.yml --repo <Ihr_GitHub_Konto>/Plattform

    7. Wenn der Workflow abgeschlossen ist, senden Sie eine Integritätsprüfungsanforderung an die App und ersetzen Sie <ACR_URL> mit dem Wert, den Sie in Schritt 3 von Herausforderung 1:

      Locke <ACR_URL>/GesundheitErfolgreiches Update!

      Es mag paradox erscheinen, dass die Meldung „Update erfolgreich !“ lautet (dieselbe wie nach dem vorherigen, erfolgreichen Update). Das mag zwar paradox erscheinen, bestätigt aber tatsächlich, dass dieses Update fehlgeschlagen ist – der Update-Versuch führte zu dem Status500 (bedeutet „ Interner Serverfehler “) und wurde nicht angewendet.

Ressourcenbereinigung

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

az group delete -n meine-Container-App-rg -y

Sie können den erstellten Fork bei Bedarf auch löschen.

  • Bei Verwendung der GitHub-GUI:

    1. Klicken Sie auf Einstellungen .
    2. Scrollen Sie zum Ende der Seite.
    3. Klicken Sie auf Dieses Repository löschen .
    4. Typ <Ihr_GitHub_Konto>/Plattform und wählen Sie Ich verstehe die Konsequenzen. Lösche dieses Repository..

  • Bei Verwendung der GitHub-CLI:

    GH-Repo löschen <Ihr_GitHub_Konto>/Plattform -ja

Nächste Schritte

Glückwunsch! Sie haben gelernt, wie Sie mit GitHub Actions eine Canary Blue‑Green-Bereitstellung einer Microservices-App durchführen. Sehen Sie sich diese Artikel in den GitHub-Dokumenten an, um Ihr DevOps-Wissen weiter zu erkunden und zu erweitern:

Wenn Sie bereit sind, den zweiten Schritt einer Canary-Bereitstellung (Testen in der Produktion) auszuprobieren, sehen Sie sich das Tutorial von Microservices März 2022 „Verbessern Sie Betriebszeit und Ausfallsicherheit mit einer Canary-Bereitstellung“ auf unserem Blog an. Es verwendet NGINX Service Mesh für den schrittweisen Übergang zu einer neuen App-Version. Auch wenn Ihre Bereitstellungen noch nicht so komplex sind, dass ein Service Mesh erforderlich ist, oder Sie Kubernetes nicht verwenden, gelten die Prinzipien dennoch für einfachere Bereitstellungen, bei denen nur ein Ingress-Controller oder Load Balancer verwendet wird.

Um Ihre Microservices-Ausbildung fortzusetzen, sehen Sie sich Microservices März 2023 an. In Einheit 3, „Beschleunigen Sie die Bereitstellung von Microservices durch Automatisierung“ , erfahren Sie mehr über die Automatisierung von Bereitstellungen.

Weitere Blogbeiträge zu F5 NGINX lesen ›

„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."