Konfigurieren von Continuous Deployment für eine Python-Web-App in Azure Container Apps

Dieser Artikel ist Teil eines Lernprogramms zum Containerisieren und Bereitstellen einer Python-Web-App für Azure-Container-Apps. Mit Container-Apps können Sie containerisierte Apps bereitstellen, ohne komplexe Infrastruktur zu verwalten.

In diesem Teil des Lernprogramms erfahren Sie, wie Sie eine kontinuierliche Bereitstellung oder Übermittlung (CD) für die Container-App konfigurieren. CD ist Teil der DevOps-Praxis der kontinuierlichen Integration / kontinuierlichen Zustellung (CI/CD), die Automatisierung Ihres App-Entwicklungsworkflows ist. Insbesondere verwenden Sie GitHub-Aktionen für die kontinuierliche Bereitstellung.

Dieses Dienstdiagramm hebt die in diesem Artikel behandelten Komponenten hervor: Konfiguration von CI/CD.

Voraussetzungen

Zum Einrichten der kontinuierlichen Bereitstellung benötigen Sie Folgendes:

• Die Ressourcen und ihre Konfiguration, die im vorherigen Artikel dieser Lernprogrammreihe erstellt wurden, einschließlich einer Azure-Containerregistrierung und einer Container-App in Azure-Container-Apps.

• Ein GitHub-Konto, bei dem Sie den Beispielcode (Django oder Flask) gezweigt haben, und Sie können eine Verbindung mit Azure-Container-Apps herstellen. (Wenn Sie den Beispielcode heruntergeladen haben, anstatt freihand zu machen, stellen Sie sicher, dass Sie Ihr lokales Repository an Ihr GitHub-Konto übertragen.)

• Optional ist Git in Ihrer Entwicklungsumgebung installiert, um Codeänderungen vorzunehmen und auf Ihr Repository in GitHub zu übertragen. Alternativ können Sie die Änderungen direkt in GitHub vornehmen.

Konfigurieren der CD für einen Container

In einem vorherigen Artikel dieses Lernprogramms haben Sie eine Container-App in Azure-Container-Apps erstellt und konfiguriert. Ein Teil der Konfiguration war das Abrufen eines Docker-Images aus einer Azure-Containerregistrierung. Das Containerimage wird beim Erstellen einer Containerrevision aus der Registrierung abgerufen, z. B. beim erstmaligen Einrichten der Container-App.

In diesem Abschnitt richten Sie die kontinuierliche Bereitstellung mit einem GitHub Actions-Workflow ein. Bei der kontinuierlichen Bereitstellung werden basierend auf einem Trigger ein neues Docker-Image und eine neue Containerrevision erstellt. Der Auslöser in diesem Lernprogramm ist jede Änderung an der Standard Verzweigung Ihres Repositorys, z. B. mit einer Pullanforderung (PR). Wenn der Workflow ausgelöst wird, erstellt der Workflow ein neues Docker-Image, verschiebt es an die Azure-Containerregistrierung und aktualisiert die Container-App mit dem neuen Image auf eine neue Revision.

Azure-Befehlszeilenschnittstelle

Azure CLI-Befehle können in der Azure Cloud Shell oder auf einer Workstation mit installierter Azure CLI ausgeführt werden.

Wenn Sie Befehle in einer Git Bash-Shell auf einem Windows-Computer ausführen, geben Sie den folgenden Befehl ein, bevor Sie fortfahren:

export MSYS_NO_PATHCONV=1

Schritt 1. Erstellen Sie einen Dienstprinzipal mit dem Az ad sp create-for-rbac-Befehl.

az ad sp create-for-rbac \
--name <app-name> \
--role Contributor \
--scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"

Hierbei gilt:

• <Der App-Name> ist ein optionaler Anzeigename für den Dienstprinzipal. Wenn Sie die --name Option verlassen, wird eine GUID als Anzeigename generiert.
• <Subscription-ID> ist die GUID, die Ihr Abonnement in Azure eindeutig identifiziert. Wenn Sie Ihre Abonnement-ID nicht kennen, können Sie den Befehl "az account show" ausführen und sie aus der Eigenschaft in der id Ausgabe kopieren.
• <"resource-group"-Name ist der Name> einer Ressourcengruppe, die den Container "Azure Container Apps" enthält. Die rollenbasierte Zugriffssteuerung (RBAC) befindet sich auf Ressourcengruppenebene. Wenn Sie die Schritte im vorherigen Artikel in diesem Lernprogramm ausgeführt haben, lautet pythoncontainer-rgder Name der Ressourcengruppe .

Speichern Sie die Ausgabe dieses Befehls für den nächsten Schritt, insbesondere die Client-ID (appId Eigenschaft), den geheimen Clientschlüssel (password Eigenschaft) und die Mandanten-ID (tenant Eigenschaft).

Schritt 2. Konfigurieren von GitHub-Aktionen mit az containerapp github-action add command.

az containerapp github-action add \
--resource-group <resource-group-name> \
--name python-container-app \
--repo-url <https://github.com/userid/repo> \
--branch main \
--registry-url <registry-name>.azurecr.io \
--service-principal-client-id <client-id> \
--service-principal-tenant-id <tenant-id> \
--service-principal-client-secret <client-secret> \
--login-with-github

Hierbei gilt:

• <ressourcengruppenname> ist der Name der Ressourcengruppe. Wenn Sie diesem Lernprogramm folgen, ist es "pythoncontainer-rg".
• <https://github.com/userid/repo> ist die URL Ihres GitHub-Repositorys. Wenn Sie die Schritte in diesem Lernprogramm ausführen, lautet dies entweder https://github.com/userid/msdocs-python-django-azure-container-apps oder https://github.com/userid/msdocs-python-flask-azure-container-apps; wo userid befindet sich Ihre GitHub-Benutzer-ID.
• <Der Registrierungsname> ist die vorhandene Containerregistrierung, die Sie für dieses Lernprogramm erstellt haben, oder eine, die Sie verwenden können.
• <Client-ID> ist der Wert der appId Eigenschaft aus dem vorherigen az ad sp create-for-rbac Befehl. Die ID ist eine GUID des Formulars 0000000-0000-0000-0000-00000-0000000.
• <Mandanten-ID> ist der Wert der tenant Eigenschaft aus dem vorherigen az ad sp create-for-rbac Befehl. Die ID ist auch eine GUID ähnlich der Client-ID.
• <Clientschlüssel> ist der Wert der password Eigenschaft aus dem vorherigen az ad sp create-for-rbac Befehl.

Azure portal

Schritt 1. Wechseln Sie im Azure-Portal zur Container-App, für die Sie die kontinuierliche Bereitstellung konfigurieren möchten, und wählen Sie die Ressource für die kontinuierliche Bereitstellung aus.

Schritt 2. Autorisieren Sie Azure Container-Apps für den Zugriff auf Ihr GitHub-Konto.

• Wählen Sie Mit GitHub anmelden aus.
• Wählen Sie im Autorisierungs-Popup "AuthorizeAppService" aus.

Container-App-Zugriff auf gitHub-Accont kann widerrufen werden, indem Sie zum Sicherheitsabschnitt Ihres Kontos wechseln und den Zugriff widerrufen.

Schritt 3. Konfigurieren Sie nach der Anmeldung mit GitHub die Details zur kontinuierlichen Bereitstellung.

• Organisation → Verwenden Sie Ihren GitHub-Benutzernamen.
• Repository → Wählen Sie die Verzweigung der Beispiel-App aus. (Wenn Sie den Beispielcode ursprünglich in Ihre Entwicklerumgebung heruntergeladen haben, übertragen Sie das Repository an GitHub.)
• Branch → Select Standard.
• Repositoryquelle → Azure Container Registry auswählen.
• Registrierung → Wählen Sie die Azure-Containerregistrierung aus, die Sie zuvor im Lernprogramm erstellt haben.
• Image → Wählen Sie den Docker-Imagenamen aus. Wenn Sie dem Lernprogramm folgen, ist es "python-container-app".
• Dienstprinzipal → Neues erstellen lassen und den Erstellungsprozess einen neuen Dienstprinzipal erstellen lassen.

Wählen Sie "Kontinuierliche Bereitstellung starten" aus, um die Konfiguration abzuschließen.

Schritt 4. Überprüfen Sie die Informationen zur kontinuierlichen Bereitstellung.

Nachdem die fortlaufende Bereitstellung konfiguriert wurde, finden Sie einen Link zur erstellten GitHub Actions-Workflowdatei. Azure-Container-Apps haben die Datei in Ihr Repository eingecheckt.

In der Konfiguration der kontinuierlichen Bereitstellung wird ein Dienstprinzipal verwendet, um GitHub-Aktionen für den Zugriff auf und die Änderung von Azure-Ressourcen zu ermöglichen. Der Zugriff auf Ressourcen wird durch die Rollen eingeschränkt, die dem Dienstprinzipal zugewiesen sind. Dem Dienstprinzipal wurde die integrierte Rolle "Mitwirkender" für die Ressourcengruppe zugewiesen, die die Container-App enthält.

Wenn Sie die Schritte für das Portal ausgeführt haben, wurde der Dienstprinzipal automatisch für Sie erstellt. Wenn Sie die Schritte für die Azure CLI ausgeführt haben, haben Sie den Dienstprinzipal zuerst explizit erstellt, bevor Sie die kontinuierliche Bereitstellung konfigurieren.

Erneutes Bereitstellen von Web-App mit GitHub-Aktionen

In diesem Abschnitt nehmen Sie eine Änderung an Ihrer verzweigten Kopie des Beispiel-Repositorys vor und bestätigen, dass die Änderung automatisch auf der Website bereitgestellt wird.

Falls noch nicht geschehen, erstellen Sie eine Verzweigung des Beispiel-Repositorys (Django oder Flask). Sie können Ihren Code direkt in GitHub oder in Ihrer Entwicklungsumgebung über eine Befehlszeile mit Git ändern.

GitHub

Schritt 1. Wechseln Sie zu Ihrer Verzweigung des Beispiel-Repositorys, und beginnen Sie in der Standard-Verzweigung.

Schritt 2. Führen Sie eine Änderung durch.

• Wechseln Sie zur Datei "/templates/base.html ". (Für Django lautet der Pfad: restaurant_review/templates/restaurant_review/base.html.)
• Wählen Sie "Bearbeiten" aus, und ändern Sie den Ausdruck "Azure Restaurant Review" in "Azure Restaurant Review - Redeployed".

Schritt 3. Übernehmen Sie die Änderung direkt in die Standard Verzweigung.

• Wählen Sie unten auf der Seite, die Sie bearbeiten, die Schaltfläche "Commit" aus.
• Der Commit startet den GitHub Actions-Workflow.

Befehlszeile

Falls noch nicht geschehen, verwenden Sie die Verwendung git clone , um Ihr Verzweigungsrepository in Ihre Entwicklungsumgebung zu ziehen und das Verzeichnis in das Repository zu ändern.

Schritt 1. Beginnen Sie in Standard.

git checkout main
git pull

Schritt 2. Führen Sie eine Änderung durch.

Wechseln Sie zur DATEI ./templates/base.html (./restaurant_review/templates/restaruant_review/base.html für Django), und ändern Sie den Ausdruck "Azure Restaurant Review" in "Azure Restaurant Review - Redeployed".

Schritt 3. Committen Sie die Änderung, und übertragen Sie diese mithilfe von Push an GitHub.

git commit -a -m "Redeploy with title change."
git push

Wenn Sie Git zum ersten Mal verwenden, müssen Sie möglicherweise globale Variablen "user.name" und "user.email" festlegen. Weitere Informationen finden Sie in der Hilfe zu git-config.

Der Push von Änderungen an der Standard Branch startet den GitHub Actions-Workflow.

Hinweis

Wir haben gezeigt, dass eine Änderung direkt in der Standard-Verzweigung vorgenommen wurde. In typischen Softwareworkflows nehmen Sie eine Änderung in einer anderen Verzweigung als Standard vor und erstellen dann eine Pullanforderung (PR), um diese Änderung in Standard zusammenzuführen. PRs starten auch den Workflow.

Über GitHub-Aktionen

Anzeigen des Workflowverlaufs

GitHub

Schritt 1. Wechseln Sie auf GitHub zu Ihrer Verzweigung des Beispiel-Repositorys, und öffnen Sie die Registerkarte "Aktionen ".

Befehlszeile

Diese Schritte verwenden die GitHub CLI.

Schritt 1. Erhalten Sie eine Zusammenfassung Ihres Workflows. Führen Sie den folgenden Befehl im Ordner aus, der Ihren Klon enthält:

gh workflow view

Mit diesem Befehl können Sie einen Workflow auswählen und dann einen Überblick über die letzten Ausführungen dieses Workflows erhalten.

Hinweis

Beim ersten Verwenden gh werden Sie möglicherweise zur Authentifizierung aufgefordert. Folgen Sie den GitHub CLI-Anweisungen, um sich zu authentifizieren.

Wenn Sie mehrere Remoteeinstellungen konfiguriert haben, werden Sie möglicherweise aufgefordertgh repo set-default, eine Standard-Remoterepository auszuwählen. Wählen Sie Ihre Verzweigung aus den angezeigten Optionen aus.

Sie können den gh workflow view Befehl aus einem beliebigen Ordner ausführen, ohne ein Standard-Repository festlegen zu müssen, indem Sie den --repo [HOST/]OWNER/REPO Parameter hinzufügen.

Schritt 2. Wechseln Sie zu GitHub, um Details zur Ausführung des Workflows zu erhalten.

gh workflow view --web

Workflow-Geheimnisse

In der Github/workflows/<workflow-name>.yml Workflowdatei, die dem Repository hinzugefügt wurde, werden Platzhalter für Anmeldeinformationen angezeigt, die für die Build- und Container-App-Updateaufträge des Workflows erforderlich sind. Die Anmeldeinformationen werden im Repository verschlüsselt Einstellungen unter "Sicherheitsgeheimnisse/" und "Variablenaktionen/" gespeichert.

Wenn sich Anmeldeinformationen ändern, können Sie sie hier aktualisieren. Wenn beispielsweise die Azure Container Registry-Kennwörter neu generiert werden, müssen Sie den REGISTRY_PASSWORD Wert aktualisieren. Weitere Informationen finden Sie unter Verschlüsselte geheime Schlüssel in der GitHub-Dokumentation.

Autorisierte OAuth-Apps

Wenn Sie eine kontinuierliche Bereitstellung einrichten, autorisieren Sie Azure Container-Apps als autorisierte OAuth-App für Ihr GitHub-Konto. Container-Apps verwenden den autorisierten Zugriff, um eine GitHub Actions YML-Datei in github/workflows/<workflow-name>.yml zu erstellen. Sie können Ihre autorisierten Apps anzeigen und Berechtigungen unter Integrationsanwendungen Ihres Kontos/widerrufen.

Tipps zur Problembehandlung

Fehler beim Einrichten eines Dienstprinzipals mit dem Azure CLI-Befehl az ad sp create-for-rba .

• Sie erhalten eine Fehlermeldung mit "InvalidSchema: Es wurden keine Verbindungsadapter gefunden".

  • Überprüfen Sie die Shell, in der Sie ausgeführt werden. Wenn Sie die Bash-Shell verwenden, legen Sie die MSYS_NO_PATHCONV Variablen wie folgt export MSYS_NO_PATHCONV=1fest. Weitere Informationen finden Sie im GitHub-Problem, bei dem der Dienstprinzipal mit Azure CLI von git bash shell nicht erstellt werden kann, es wurden keine Verbindungsadapter gefunden.

• Sie erhalten eine Fehlermeldung mit "Mehrere Anwendungen haben denselben Anzeigenamen".

  • Dieser Fehler gibt an, dass der Name bereits für den Dienstprinzipal verwendet wird. Wählen Sie einen anderen Namen aus, oder lassen Sie das --name Argument aus, und eine GUID wird automatisch als Anzeigename generiert.

GitHub-Aktionen-Workflow fehlgeschlagen.

• Um den Status eines Workflows zu überprüfen, wechseln Sie zur Registerkarte "Aktionen " des Repositorys.
• Wenn ein Workflow fehlgeschlagen ist, führen Sie einen Drilldown in die Workflowdatei durch. Es sollten zwei Aufträge "build" und "deploy" vorhanden sein. Sehen Sie sich bei einem fehlgeschlagenen Auftrag die Ausgabe der Aufgaben des Auftrags an, um nach Problemen zu suchen.
• Wenn eine Fehlermeldung mit "TLS Handshake Timeout" angezeigt wird, führen Sie den Workflow manuell aus, indem Sie die automatische Bereitstellung auslösen unter der Registerkarte "Aktionen" des Repositorys auswählen, um festzustellen, ob das Timeout ein temporäres Problem ist.
• Wenn Sie eine kontinuierliche Bereitstellung für die Container-App einrichten, wie in diesem Lernprogramm gezeigt, wird die Workflowdatei (GITHUB/workflows/<workflow-name>.yml) automatisch für Sie erstellt. Sie sollten diese Datei für dieses Lernprogramm nicht ändern müssen. Wenn Sie dies getan haben, rückgängig machen Sie Ihre Änderungen aus, und probieren Sie den Workflow aus.

Die Website zeigt keine Änderungen an, die Sie in der Standard Verzweigung zusammengeführt haben.

• Überprüfen Sie in GitHub, ob der GitHub-Aktionen-Workflow ausgeführt wurde und dass Sie die Änderung in die Verzweigung überprüft haben, die den Workflow auslöst.
• Überprüfen Sie in Azure-Portal: Überprüfen Sie die Azure-Containerregistrierung, um festzustellen, ob nach der Änderung in der Verzweigung ein neues Docker-Image mit einem Zeitstempel erstellt wurde.
• Überprüfen Sie in Azure-Portal die Protokolle der Container-App. Wenn ein Programmierfehler auftritt, wird er hier angezeigt.
  • Zur Container-App wechseln | Revisionsmanagement | <aktiver Container> | Überarbeitungsdetails | Konsolenprotokolle
  • Wählen Sie die Reihenfolge der Spalten aus, um "Zeit generiert", "Stream_s" und "Log_s" anzuzeigen. Sortieren Sie die Protokolle nach der neuesten ersten Und suchen Sie nach Python-Stderr- und Stdout-Nachrichten in der Spalte "Stream_s". Die Python-Ausgabe "print" ist stdout-Nachrichten .
• Verwenden Sie mit der Azure CLI den Befehl "az containerapp logs show ".

Was geschieht, wenn ich die kontinuierliche Bereitstellung getrennt habe?

• Das Beenden der kontinuierlichen Bereitstellung bedeutet, dass die Container-App von Ihrem Repository getrennt wird. So trennen Sie die Verbindung:

  • Wechseln Sie in Azure-Portal zur Container-App, wählen Sie die Ressource für die kontinuierliche Bereitstellung aus, und wählen Sie "Trennen" aus.
  • Verwenden Sie mit der Azure CLI den Befehl "github-action remove " der Az-Container-App.

• Nach dem Trennen in Ihrem GitHub-Repository:

  • Die Github/workflows/<workflow-name>.yml Datei wird aus Ihrem Repository entfernt.
  • Geheime Schlüssel werden nicht entfernt.
  • Azure Container Apps werden als autorisierte OAuth-App für Ihr GitHub-Konto neu Standard.

• Nach dem Trennen in Azure:

  • Der Container bleibt mit dem letzten bereitgestellten Container übrig. Sie können die Container-App erneut mit der Azure-Containerregistrierung verbinden, damit neue Containerrevisionen das neueste Image abrufen.
  • Dienstprinzipale, die für die kontinuierliche Bereitstellung erstellt und verwendet werden, werden nicht gelöscht.

Nächste Schritte

Wenn Sie mit dem Lernprogramm fertig sind und keine zusätzlichen Kosten verursachen möchten, entfernen Sie die verwendeten Ressourcen. Durch das Entfernen einer Ressourcengruppe werden alle Ressourcen in der Gruppe entfernt und die schnellste Möglichkeit zum Entfernen von Ressourcen. Ein Beispiel zum Entfernen von Ressourcengruppen finden Sie im Containerize-Lernprogramm sauber up.

Wenn Sie auf diesem Lernprogramm aufbauen möchten, finden Sie hier einige der nächsten Schritte, die Sie ausführen können.

• Festlegen von Skalierungsregeln in Azure Container Apps

• Binden von benutzerdefinierten Do Standard Namen und Zertifikaten in Azure-Container-Apps

• Überwachen einer App in Azure Container Apps