NGINX-Tutorial: So verwenden Sie GitHub Actions zur Automatisierung von Microservices Canary-Bereitstellungen
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 :
- So stellen Sie Microservices bereit und konfigurieren sie
- So verwalten Sie Geheimnisse in Containern sicher
- So verwenden Sie GitHub Actions zum Automatisieren von Microservices Canary Releases (dieser Beitrag)
- So nutzen Sie OpenTelemetry Tracing zum Verständnis Ihrer 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:
- Erstellen und Bereitstellen einer NGINX-Container-App
- Einrichten von Berechtigungen zur Automatisierung von Azure Container App-Bereitstellungen
- Erstellen einer Canary Blue‑Green‑Bereitstellung mit einer GitHub‑Aktion
- Testen des GitHub Actions-Workflows
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
Richten Sie die grundlegenden Ressourcen ein und konfigurieren Sie sie. Forken und klonen Sie das Tutorial-Repository, 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.)
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-marchForken 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:
Klicken Sie oben rechts im Fenster auf „Fork“ und wählen Sie im Menü „Besitzer“ Ihr persönliches GitHub-Konto aus.
Klonen Sie das Repository lokal und ersetzen Sie Ihren Kontonamen durch
<Ihr_GitHub_Konto>: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
Containerapp-Erweiterung:az extension add --name containerapp -upgradeThe installed extension 'containerapp' is in preview.
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.
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 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.registrydie Zeichenfolge vor.azurecr.io. In der Beispielausgabe in Schritt 2 ist escac085021b77acr.Ersetzen Sie diese Zeichenfolge durch
<ACR_Name>in nachfolgenden Befehlen.URL der Container-App – Die URL in der Zeile, die mit
„Container-Apperstellt“ beginnt. In der Beispielausgabe in Schritt 2 ist eshttps://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/.Ersetzen Sie diese URL durch
<ACR_URL>in nachfolgenden Befehlen.
Aktivieren Sie die Revisionen für die Container-App nach Bedarf für eine Blue‑Green‑Bereitstellung:
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 /health- Endpunkt im Container abfragen:
curl <ACR_URL>/healthOK
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.
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 my-container-app \ --resource-group my-container-app-rg \ --system-assigned \ --output table PrincipalId ... ------------------------------------ ... 39f8434b-12d6-4735-81d8-ba0apo14579f ... ... TenantId ... ------------------------------------ ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsdeSuchen Sie in ACR die Ressourcen-ID der Container-App und ersetzen Sie
<ACR_name>durch den Namen, den Sie in Schritt 3 von Challenge 1 notiert haben. Diesen Wert setzen Sie im nächsten Schritt für<ACR_resource_ID>ein: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/cac085021b77acrWeisen Sie der verwalteten Identität der Container-App die integrierte Azure-Rolle für ACR zu, indem Sie
<managed_identity_principal_ID>durch die in Schritt 1 ermittelte verwaltete Identität und<ACR_resource_ID>durch die in Schritt 2 ermittelte Ressourcen-ID ersetzen: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 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 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 nach Ihrer Azure-Abonnement-ID .
az account show --query id --output tsv0efafl2-38ad-41w8-g49a-0ecc6723l97cErstellen 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ügenAZURE_CREDENTIALSIn Fügen Sie Ihrem GitHub-Repository Geheimnisse hinzu. Sie können die Warnung, dass--sdk-authveraltet 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/<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/" }
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:
- Navigieren Sie zu Ihrem gegabelten GitHub-Repository.
- Wählen Sie Einstellungen > Geheimnisse und Variablen > Aktionen .
- Klicken Sie auf Neues Repository-Geheimnis .
Geben Sie die folgenden Werte in die angegebenen Felder ein:
- Name –
AZURE_CREDENTIALS - Geheim – Die JSON-Anmeldeinformationen aus Schritt 6 der Herausforderung 2
- Name –
- Klicken Sie auf „Geheimnis hinzufügen“ .
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_NAMEmeine-container-appRESSOURCENGRUPPEmeine-Container-App-rgACR_NAME<ACR_Name>- Fahren Sie mit dem Erstellen einer GitHub Action-Workflow-Datei fort.
Bei Verwendung der GitHub-CLI:
Erstellen Sie im Stammverzeichnis Ihres Repository eine temporäre Datei.
touch ~/creds.json- Öffnen Sie creds.json mit Ihrem bevorzugten Texteditor und kopieren Sie die JSON-Anmeldeinformationen, die Sie in Schritt 6 von Challenge 2 erstellt haben.
Erstellen Sie das Geheimnis:
gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.jsonLöschen Sie creds.json :
rm ~/creds.jsonWiederholen Sie diesen Befehl, um drei weitere Geheimnisse zu erstellen:
gh secret set <secret_name> --repo <your_GitHub_account>/platformErsetzen 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_NAMEmeine-container-appRESSOURCENGRUPPEmeine-Container-App-rgACR_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.
Erstellen Sie eine Datei für den Aktionsworkflow.
Bei Verwendung der GitHub-GUI:
- Navigieren Sie zu Ihrem GitHub-Repository.
- 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
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: Deploy to AzureKonfigurieren Sie den Workflow so, dass er ausgeführt wird, wenn eine Push- oder Pull-Anforderung an den Hauptzweig gestellt wird:
on: push: branches: - main pull_request: branches: - mainDefinieren Sie im Abschnitt
„Jobs“ denBuild-Deploy-Job, der den Code auscheckt, sich bei Azure anmeldet und die Anwendung in der Azure Container App 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.ioDefinieren 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: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 Text für die Aktions-Workflow-Datei.
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"
Ausführen des Aktionsworkflows
Bei Verwendung der GitHub-GUI:
- 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.
- Klicken Sie auf „Aktionen“, um den Fortschritt des Workflows zu überwachen.
Bei Verwendung der GitHub-CLI:
Fügen Sie main.yml zum Git-Staging-Bereich hinzu:
git add .github/workflows/main.ymlÜbernehmen Sie die Datei:
git commit -m "feat: create GitHub Actions workflow"Übertragen Sie Ihre Änderungen auf GitHub:
git pushÜberwachen Sie den Fortschritt des Workflows:
gh workflow view main.yml --repo <your_GitHub_account>/platform
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:
- Wählen Sie Code > ingress > default.conf.template .
- Öffnen Sie default.conf.template zum Bearbeiten, indem Sie das Bleistiftsymbol mit dem Tooltip „Diese Datei bearbeiten“ auswählen.
Ändern Sie im
Speicherort-/Health-Block am Ende der Datei dieReturn-Direktive wie angegeben:location /health { access_log off; return 200 "Successful Update!\n"; }- Wählen Sie im Dialogfeld Einen neuen Branch für dieses Commit erstellen und einen Pull Request starten und dann Änderungen vorschlagen aus .
- Klicken Sie auf „Pull Request erstellen“, um auf die Pull Request-Vorlage zuzugreifen.
- Klicken Sie erneut auf „Pull Request erstellen“, um den Pull Request zu erstellen.
- Klicken Sie auf „Aktionen“, um den Fortschritt des Workflows zu überwachen.
- 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!“. 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:curl <ACR_URL>/healthSuccessful Update!- Fahren Sie mit der Durchführung eines erfolglosen Updates fort.
Bei Verwendung der GitHub-CLI:
Erstellen Sie einen neuen Zweig mit dem Namen patch-1 :
git checkout -b patch-1Öffnen Sie ingress/default.conf.template in Ihrem bevorzugten Texteditor und ändern Sie im
Speicherort-/Health-Block am Ende der Datei dieReturn-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Übernehmen Sie die Datei:
git commit -m "feat: update NGINX ingress"Übertragen Sie Ihre Änderungen auf GitHub:
git push --set-upstream origin patch-1Erstellen Sie eine Pull-Anfrage (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>/platformWenn 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:curl <ACR_URL>/health Successful 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:
- Wählen Sie Code > ingress > default.conf.template .
- 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.
- Öffnen Sie default.conf.template zum Bearbeiten, indem Sie das Bleistiftsymbol mit dem Tooltip „Diese Datei bearbeiten“ auswählen.
Ändern Sie die
Rückgabeanweisungwie angegeben:location /health { access_log off; return 500 "Unsuccessful Update!\n"; }- Wählen Sie „Direkt zum -patch-1-Zweig Commit“ und dann „Änderungen Commit“ 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 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
„Updateerfolgreich!“ 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„InternerServerfehler“) und wurde nicht angewendet.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:curl <ACR_URL>/healthSuccessful Update!
Bei Verwendung der GitHub-CLI:
Sehen Sie sich den Patch-1 -Zweig an, den Sie im vorherigen Abschnitt erstellt haben:
git checkout patch-1Ö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 "Unsuccessful Update!\n"; }Fügen Sie default.conf.template zum Git-Staging-Bereich hinzu:
git add ingress/default.conf.templateÜbernehmen Sie die Datei:
git commit -m "feat: update NGINX ingress again"Übertragen Sie Ihre Änderungen auf GitHub:
git pushÜberwachen Sie den Fortschritt des Workflows:
gh workflow view main.yml --repo <your_GitHub_account>/platformWenn 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:curl <ACR_URL>/healthSuccessful 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„InternerServerfehler“) und wurde nicht angewendet.
Bereinigung von Ressourcen
Um spätere Kosten zu vermeiden, sollten Sie die im Tutorial bereitgestellten Azure-Ressourcen löschen:
az group delete -n my-container-app-rg -y
Sie können den erstellten Fork bei Bedarf auch löschen.
Bei Verwendung der GitHub-GUI:
- Klicken Sie auf Einstellungen .
- Scrollen Sie zum Ende der Seite.
- Klicken Sie auf Dieses Repository löschen .
- Typ <Ihr_GitHub_Konto>/Plattform und wählen Sie Ich verstehe die Konsequenzen. Lösche dieses Repository..
Bei Verwendung der GitHub-CLI:
gh repo delete <your_GitHub_account>/platform -yes
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:
- Informationen zu Workflows
- Informationen zur kontinuierlichen Integration mit GitHub Actions
- Informationen zur kontinuierlichen Bereitstellung mit GitHub Actions
- Informationen zur Überwachung und Fehlerbehebung
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.
„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."