Freigeben über

Anleitung: Konfigurieren einer kontinuierlichen Bereitstellung für eine Python-Web-App in Azure Container Apps

  • Artikel

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

In dieser Anleitung wirst du:

  • Konfigurieren Sie die kontinuierliche Bereitstellung für eine Container App mit Hilfe eines GitHub Actions-Workflows.
  • Nehmen Sie eine Änderung an einer Kopie des Beispiel-Repositorys vor, um den GitHub Actions-Workflow auszulösen.
  • Fehlerbehebung bei Problemen, die bei der Konfiguration der kontinuierlichen Bereitstellung auftreten können.
  • Entfernen Sie Ressourcen, die Sie nicht benötigen, wenn Sie die Lernprogrammreihe fertig stellen.

Die kontinuierliche Bereitstellung ist verwandt mit der DevOps-Praxis der kontinuierlichen Integration und der kontinuierlichen Bereitstellung (CI/CD), d.h. der Automatisierung Ihres Workflows zur Entwicklung von Apps.

Im folgenden Diagramm werden die Aufgaben in diesem Tutorial hervorgehoben.

Diagramm der Dienste, die an der Bereitstellung einer Python-App in Azure-Container-Apps beteiligt sind, wobei die Teile zur kontinuierlichen Bereitstellung hervorgehoben sind.

Voraussetzungen

Um die kontinuierliche Bereitstellung festzulegen, benötigen Sie:

  • Die Ressourcen (und ihre Konfiguration), die Sie in der vorherigen Anleitung erstellt haben, darunter eine Instanz von Azure Container Registry und eine Container App in Azure Container Apps.

  • Ein GitHub-Konto, auf dem Sie den Beispielcode geforkt haben (Django oder Flask), und mit dem Sie sich mit Azure Container Apps verbinden können. (Wenn Sie den Beispielcode heruntergeladen haben, anstatt ihn zu forken, müssen Sie Ihr lokales Repo auf Ihr GitHub-Konto pushen).

  • Optional können Sie Git in Ihrer Entwicklungsumgebung installieren, um Code-Änderungen vorzunehmen und an Ihr Repo in GitHub zu pushen. Alternativ können Sie die Änderungen direkt in GitHub vornehmen.

Konfigurieren der kontinuierlichen Bereitstellung für einen Container

Im vorherigen Lernprogramm 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-Containerregistrierungsinstanz. Das Image des Containers wird aus der Registry gezogen, wenn Sie eine Container Revision erstellen, wie z. B. wenn Sie die Container App zum ersten Mal einrichten.

In diesem Abschnitt richten Sie die kontinuierliche Bereitstellung mithilfe eines GitHub-Aktionsworkflows ein. Bei der kontinuierlichen Bereitstellung werden ein neues Docker-Image und eine neue Container-Revision auf der Grundlage eines Triggers erstellt. Der Trigger in diesem Tutorial ist jede Änderung am Main Branch Ihres Repositorys, wie z. B. bei einem Pull-Request. Wenn der Workflow ausgelöst wird, wird ein neues Docker-Image erstellt, an die Azure Container Registry-Instanz verschoben und die Container-App mithilfe des neuen Images auf eine neue Revision aktualisiert.

Sie können Azure CLI-Befehle in Azure Cloud Shell oder auf einer Arbeitsstation ausführen, auf der Azure CLI installiert ist.

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

  1. Erstellen Sie ein Dienstprinzipal mit dem Befehl az ad sp create-for-rbac:

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

    Im Befehl:

    • <app-name> ist ein optionaler Anzeigename für den Dienstprinzipal. Wenn Sie die Option --name weglassen, 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 id-Eigenschaft in der Ausgabe kopieren.
    • <Ressourcengruppenname> 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 Tutorial ausgeführt haben, ist der Name der Ressourcengruppe pythoncontainer-rg.

    Speichern Sie die Ausgabe dieses Befehls für den nächsten Schritt. Speichern Sie insbesondere die Client-ID (EigenschaftappId), das Client-Geheimnis (Eigenschaftpassword) und die Mandanten-ID (Eigenschafttenant).

  2. Konfigurieren Sie GitHub-Actions mit dem Befehl az containerapp github-action add:

    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

    Im Befehl:

    • <Ressourcengruppenname> ist der Name der Ressourcengruppe. In dieser Anleitung ist es pythoncontainer-rg.
    • <https://github.com/userid/repo> ist die URL Ihres GitHub-Repositorys. In dieser Anleitung ist es entweder https://github.com/userid/msdocs-python-django-azure-container-apps oder https://github.com/userid/msdocs-python-flask-azure-container-apps. Bei diesen URLs ist userid Ihre GitHub-Benutzer-ID.
    • <Registry-Name> ist die bestehende Azure Container Registry-Instanz, die Sie im vorherigen Lernprogramm erstellt haben, oder eine Instanz, 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 der Form 00000000-0000-0000-0000-00000000.
    • <tenant-id> ist der Wert der tenant-Eigenschaft aus dem vorherigen az ad sp create-for-rbac-Befehl. Bei der ID handelt es sich ebenfalls um eine GUID, die der Client-ID ähnlich ist.
    • <client-secret> ist der Wert der password-Eigenschaft aus dem vorherigen az ad sp create-for-rbac-Befehl.

In der Konfiguration der kontinuierlichen Bereitstellung ermöglicht ein Dienstprinzipal GitHub Actions, Zugriff auf Azure-Ressourcen zu gewähren und sie zu ändern. Die dem Dienstprinzipal zugewiesenen Rollen beschränken den Zugriff auf Ressourcen. Dem Dienstprinzipal wurde die integrierte Rolle Mitwirkender in der Ressourcengruppe zugewiesen, die die Container App enthält.

Wenn Sie die Schritte für das Portal befolgt haben, wurde das Dienstprinzipal automatisch für Sie erstellt. Wenn Sie die Schritte für das Azure CLI befolgt haben, haben Sie das Dienstprinzipal explizit erstellt, bevor Sie die kontinuierliche Bereitstellung konfiguriert haben.

Web-App erneut mit GitHub Actions bereitstellen

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

Falls Sie das noch nicht getan haben, erstellen Sie einen Fork des Beispiel-Repositorys (Django oder Flask). Sie können Ihre Codeänderungen direkt in GitHub oder in Ihrer Entwicklungsumgebung über die Befehlszeile mit Gitvornehmen.

  1. Gehen Sie zu Ihrem Fork des Beispiel-Repositorys und beginnen Sie im Main-Branch.

    Screenshot, der den Hauptzweig in einem Fork des Beispiel Repos zeigt.

  2. Nehmen Sie eine Änderung vor:

    1. Wechseln Sie zur datei /templates/base.html. (Bei Django lautet der Pfad restaurant_review/templates/restaurant_review/base.html.)
    2. Wählen Sie Bearbeiten und ändern Sie die Phrase Azure Restaurant Review in Azure Restaurant Review - Redeployed.

    Screenshot, der zeigt, wie Sie eine Änderung in einer Vorlagendatei im Fork des Beispiels Repo vornehmen.

  3. Vergewissern Sie sich unten auf der Seite, die Sie bearbeiten, dass Direkt an den Main-Branch übergeben ausgewählt ist. Wählen Sie dann die Schaltfläche Änderungen committen.

    Screenshot, der die Auswahlmöglichkeiten für das Commit einer Änderung in einer Vorlagendatei im Fork des Beispiel-Repo zeigt.

Der Commit startet den GitHub Actions-Workflow.

Anmerkung

Dieses Tutorial zeigt, wie Sie eine Änderung direkt im Main-Branch vornehmen. In typischen Software Workflows nehmen Sie eine Änderung in einem anderen Branch als Main vor und erstellen dann einen Pull-Request, um die Änderung in Main zusammenzuführen. Pullanforderungen starten auch den Workflow.

Verstehen von GitHub Actions

Anzeigen der Historie des Workflows

Wenn Sie den Workflowverlauf anzeigen müssen, verwenden Sie eines der folgenden Verfahren.

Gehen Sie auf GitHub zu Ihrem Fork des Beispiel-Repositorys und öffnen Sie die Registerkarte Actions.

Screenshot, der Workflows auf der Registerkarte

Geheimnisse des Workflows

Die .github/workflows/<workflow-name>.yml Workflow-Datei, die dem Repo hinzugefügt wurde, enthält Platzhalter für Anmeldeinformationen, die für die Build- und Container App Update Jobs des Workflows benötigt werden. Die Anmeldeinformationen werden verschlüsselt im Bereich Einstellungen des Repositorys unter Sicherheit>Secrets und Variablen>Aktionen gespeichert.

Screenshot, der Anmeldeinformationen als GitHub Actions Secrets zeigt.

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 Secrets in der GitHub Dokumentation.

Autorisierte OAuth-Apps

Wenn Sie eine kontinuierliche Bereitstellung einrichten, legen Sie Azure Container-Apps als autorisierte OAuth-App für Ihr GitHub-Konto fest. Container Apps verwendet den autorisierten Zugriff, um eine GitHub Actions YAML-Datei in .github/workflows/<workflow-name>.ymlzu erstellen. Sie können Ihre autorisierten Apps einsehen und Berechtigungen in Ihrem Konto widerrufen, unter Integrationen>Anwendungen.

Screenshot, der den Speicherort autorisierter Apps für einen Benutzer in GitHub zeigt.

Problembehandlung

Sie erhalten Fehler beim Einrichten eines Dienstprinzipals über das Azure CLI

Dieser Abschnitt hilft Ihnen bei der Behebung von Fehlern, die beim Einrichten eines Dienstprinzipals mit dem Azure CLI az ad sp create-for-rba Befehl auftreten.

Wenn Sie eine Fehlermeldung erhalten, die lautet "InvalidSchema: Es wurden keine Verbindungsadapter gefunden":

Wenn Sie einen Fehler erhalten, der "Mehr als eine Anwendung hat denselben Anzeigenamen" enthält:

  • Der Name ist bereits für das Dienstprinzipal vergeben. Wählen Sie einen anderen Namen aus, oder lassen Sie das Argument --name aus. Es wird automatisch eine GUID als Anzeigename generiert.

GitHub Actions Workflow ist fehlgeschlagen

Um den Status eines Workflows zu überprüfen, wechseln Sie zur Registerkarte Aktionen des Repositorys:

  • Wenn es einen fehlgeschlagenen Workflow gibt, gehen Sie in die Workflow-Datei. Es sollten zwei Jobs vorhanden sein: Build und Bereitstellung. Prüfen Sie bei einem fehlgeschlagenen Job die Ausgabe der Aufgaben des Jobs, um nach Problemen zu suchen.
  • Wenn eine Fehlermeldung mit dem Inhalt "TLS handshake timeout" erscheint, führen Sie den Workflow manuell aus. Wählen Sie im Repo auf der Registerkarte Aktionen die Option Automatische Bereitstellung triggern, um zu sehen, ob die Zeitüberschreitung ein vorübergehendes Problem ist.
  • Wenn Sie eine kontinuierliche Bereitstellung für die Container-App einrichten, wie in diesem Tutorial gezeigt, wird die Workflow-Datei (.github/workflows/<Workflowname>.yml) automatisch für Sie erstellt. Für dieses Tutorial sollten Sie diese Datei nicht ändern müssen. Wenn Sie dies getan haben, stellen Sie Ihre Änderungen zurück und probieren Sie den Workflow aus.

Die Website zeigt keine Änderungen an, die Sie im Main Branch zusammengeführt haben

In GitHub:

  • Überprüfen Sie, ob der GitHub Actions Workflow ausgeführt wurde und ob Sie die Änderung in den Branch eingecheckt haben, der den Workflow triggert.

Im Azure-Portal:

  • Überprüfen Sie die Instanz der Azure Container Registry, um festzustellen, ob ein neues Docker-Image mit einem Zeitstempel nach Ihrer Änderung am Branch erstellt wurde.

  • Überprüfen Sie die Protokolle der Container-App, um festzustellen, ob ein Programmierfehler auftritt:

    1. Rufen Sie die Container App auf und gehen Sie dann zu Revisionsverwaltung><aktiver Container>>Revisionsdetails>Konsolenprotokolle.
    2. Wählen Sie die Reihenfolge der Spalten, um Zeit generiert, Stream_s und Log_s anzuzeigen.
    3. Sortieren Sie die Protokolle nach dem neuesten Datum und suchen Sie nach Python-stderr- und stdout-Nachrichten in der -Stream_s--Spalte. Python print Ausgabe ist stdout Nachrichten.

Führen Sie über die Azure CLI folgende Schritte aus:

Sie möchten die kontinuierliche Bereitstellung beenden

Das Anhalten der kontinuierlichen Bereitstellung bedeutet, dass Sie Ihre Container App von Ihrem Repo abkoppeln.

Im Azure-Portal:

  • Wechseln Sie zur Container-App. Wählen Sie im Menü des Dienstes Kontinuierliche Bereitstellung und dann Trennen.

Führen Sie über die Azure CLI folgende Schritte aus:

Nachdem Sie die Verbindung getrennt haben:

  • Die Datei .github/workflows/<workflow-name>.yml wird aus Ihrem Repo entfernt.
  • Geheime Schlüssel werden nicht aus dem Repository entfernt.
  • Azure Container Apps bleibt als autorisierte OAuth App für Ihr GitHub-Konto bestehen.
  • In Azure wird der Container mit dem zuletzt bereitgestellten Container belassen. Sie können die Container-App erneut mit der Azure Container Registry-Instanz verbinden, damit neue Containerrevisionen das neueste Image abrufen.
  • In Azure werden Dienstprinzipale, die Sie für die kontinuierliche Bereitstellung erstellt und verwendet haben, nicht gelöscht.

Ressourcen entfernen

Wenn Sie mit der Lernprogrammreihe fertig sind und keine zusätzlichen Kosten verursachen möchten, entfernen Sie die von Ihnen verwendeten Ressourcen.

Durch das Entfernen einer Ressourcengruppe werden alle Ressourcen in der Gruppe entfernt und es ist die schnellste Möglichkeit zum Entfernen von Ressourcen. Ein Beispiel für das Entfernen von Ressourcengruppen finden Sie unter Containerisierungstutorial Bereinigung.

Verwandte Inhalte

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