Verwenden von CI/CD mit GitHub Actions zum Bereitstellen einer Python-Web-App für Azure App Service für Linux

Verwenden Sie die GitHub Actions-Plattform für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD), um eine Python-Web-App für Azure-App Service unter Linux bereitzustellen. Ihr GitHub-Aktionen-Workflow erstellt automatisch den Code und stellt ihn im App-Dienst bereit, wenn ein Commit für das Repository vorhanden ist. Sie können ihrem GitHub-Aktionsworkflow weitere Automatisierung hinzufügen, z. B. Testskripts, Sicherheitsprüfungen und Multistages-Bereitstellung.

Erstellen eines Repositorys für Ihren App-Code

Wenn Sie bereits über eine Python-Web-App verfügen, stellen Sie sicher, dass sie zu einem GitHub-Repository verpflichtet ist.

Wenn Sie eine App zum Arbeiten benötigen, können Sie das Repository unter https://github.com/Microsoft/python-sample-vscode-flask-tutorial forken und klonen. Der Code stammt aus dem Tutorial Flask in Visual Studio Code.

Erstellen des Ziel-Azure-App-Diensts

Die schnellste Möglichkeit zum Erstellen einer App Service-Instanz besteht darin, die Azure-Befehlszeilenschnittstelle (CLI) über die interaktive Azure Cloud Shell zu verwenden. Die Cloud Shell umfasst Git und Azure CLI. In den folgenden Schritten verwenden Sie az webapp, um den App-Dienst zu erstellen und die erste Bereitstellung Ihrer App durchzuführen.

Schritt 1. Melden Sie sich unter https://portal.azure.com beim Azure-Portal an.

Schritt 2. Öffnen Sie die Azure CLI, indem Sie das Cloud Shell-Symbol auf der Portalsymbolleiste auswählen.

Schritt 3. Wählen Sie in der Cloud Shell bash aus der Dropdownliste aus.

Schritt 4. Klonen Sie In der Cloud Shell Ihr Repository mit Git Clone. Wenn Sie beispielsweise die Flask-Beispiel-App verwenden, lautet der Befehl:

git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git

Ersetzen Sie <Github-Benutzer> durch den Namen des GitHub-Kontos, in dem Sie das Repository verzweigt haben. Wenn Sie ein anderes App-Repository verwenden, richtet dieses Repository GitHub-Aktionen ein.

Schritt 5. Ändern Sie in der Cloud Shell das Verzeichnis in den Repositoryordner mit Ihrer Python-App, damit der Az Webapp-Befehl die App als Python erkennt. For the example, for the Flask sample app:

cd python-sample-vscode-flask-tutorial

Schritt 6: Verwenden Sie in der Cloud Shell az webapp up , um einen App-Dienst zu erstellen und ihre App zunächst bereitzustellen.

az webapp up --name <app-service-name> --runtime "PYTHON:3.9"

Geben Sie einen App Service-Namen an, der in Azure eindeutig ist. Der Name muss 3 bis 60 Zeichen lang sein und darf nur Buchstaben, Zahlen und Bindestriche enthalten. Der Name muss mit einem Buchstaben beginnen und mit einem Buchstaben oder einer Ziffer enden.

Dient az webapp list-runtimes zum Abrufen einer Liste der verfügbaren Laufzeiten. Verwenden Sie das PYTHON|X.Y Format, wobei X.Y es sich um die Python-Version handelt.

Sie können auch den Speicherort des App-Diensts mit dem --location Parameter angeben. Verwenden Sie den az account list-locations --output table Befehl, um eine Liste der verfügbaren Speicherorte abzurufen.

Schritt 7. Wenn Ihre App einen benutzerdefinierten Startbefehl verwendet, verwenden Sie den Befehl az webapp config . Wenn Ihre App keinen benutzerdefinierten Startbefehl hat, überspringen Sie diesen Schritt.

Die Python-sample-vscode-flask-tutorial-App enthält beispielsweise eine Datei mit dem Namen "startup.txt", die einen Startbefehl enthält, den Sie wie folgt verwenden können:

az webapp config set \
  --resource-group <resource-group-name> \
  --name <app-service-name> \
  --startup-file startup.txt

Sie finden den Ressourcengruppennamen aus der Ausgabe des vorherigen az webapp up Befehls. Der Ressourcengruppenname beginnt mit <azure-account-name>_rg_.

Schritt 8: Um die ausgeführte App anzuzeigen, öffnen Sie einen Browser, und wechseln Sie zu http:// app-service-name.azurewebsites.net>.<

Wenn eine generische Seite angezeigt wird, warten Sie einige Sekunden, bis der App-Dienst gestartet wird, und aktualisieren Sie die Seite. Wenn die generische Seite weiterhin angezeigt wird, überprüfen Sie, ob Sie aus dem richtigen Ordner bereitgestellt haben. Wenn Sie beispielsweise die Flask-Beispiel-App verwenden, ist der Ordner python-sample-vscode-flask-tutorial. Überprüfen Sie für die Flask-Beispiel-App außerdem, dass Sie den Startbefehl ordnungsgemäß festlegen.

Einrichten der kontinuierlichen Bereitstellung in App Service

In den folgenden Schritten richten Sie eine kontinuierliche Bereitstellung (CD) ein, was bedeutet, dass eine neue Codebereitstellung erfolgt, wenn ein Workflow ausgelöst wird. Der Auslöser in diesem Lernprogramm ist jede Änderung an der Standard Verzweigung Ihres Repositorys, z. B. mit einer Pullanforderung (PR).

Schritt 1. Fügen Sie GitHub-Aktion mit dem Befehl "github-actions" der az webapp-Bereitstellung hinzu .

az webapp deployment github-actions add \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Der --login-with-github Parameter verwendet eine interaktive Methode zum Abrufen eines persönlichen Zugriffstokens. Folgen Sie den Anweisungen, um die Authentifizierung abzuschließen.

Wenn eine vorhandene Workflowdatei vorhanden ist, die mit dem Namen "App Service" in Konflikt steht, werden Sie aufgefordert, auszuwählen, ob überschrieben werden soll. Verwenden Sie den --force Parameter, um ihn zu überschreiben, ohne ihn zu fragen.

Funktionsweise des Befehls zum Hinzufügen:

• Erstellt eine neue Workflowdatei: .github/workflows/<workflow-name.yml> in Ihrem Repository. Der Name der Datei enthält den Namen Ihres App-Diensts.
• Ruft ein Veröffentlichungsprofil mit geheimen Schlüsseln für Ihren App-Dienst ab und fügt es als GitHub-Aktionsgeheimnis hinzu. Der Name des geheimen Schlüssels beginnt mit AZUREAPPSERVICE_PUBLISHPROFILE_. Auf diesen geheimen Schlüssel wird in der Workflowdatei verwiesen.

Schritt 2. Rufen Sie die Details einer Bereitstellungskonfiguration für die Quellcodeverwaltung mit dem Befehl "az webapp deployment source show " ab.

az webapp deployment source show \
  --name <app-service-name> \
  --resource-group <resource-group-name>

Bestätigen Sie in der Ausgabe des Befehls die Werte für die und branch die repoUrl Eigenschaften. Diese Werte sollten mit den Werten übereinstimmen, die Sie im vorherigen Schritt angegeben haben.

Erläuterter GitHub-Workflow und -Aktionen

Ein Workflow wird durch eine YAML-Datei (yml) im Pfad /.github/workflows/ in Ihrem Repository definiert. Diese YAML-Datei enthält die verschiedenen Schritte und Parameter, aus denen der Workflow besteht, einem automatisierten Prozess, der einem GitHub-Repository zugeordnet ist. Sie können jedes Projekt auf GitHub mit einem Workflow erstellen, testen, verpacken, freigeben und bereitstellen.

Jeder Workflow besteht aus einem oder mehreren Aufträgen. Jeder Auftrag wiederum ist eine Reihe von Schritten. Und schließlich ist jeder Schritt ein Shellskript oder eine Aktion.

Im Hinblick auf den Workflow, der mit Ihrem Python-Code für die Bereitstellung in App Service eingerichtet wurde, hat der Workflow die folgenden Aktionen:

Die Workflowvorlage, die zum Erstellen des Workflows verwendet wird, ist Azure/actions-workflow-samples.

Der Workflow wird für Pushereignisse an die angegebene Verzweigung ausgelöst. Das Ereignis und die Verzweigung werden am Anfang der Workflowdatei definiert. Der folgende Codeausschnitt zeigt beispielsweise, dass der Workflow für Pushereignisse an die Standard Verzweigung ausgelöst wird:

on:
  push:
    branches:
    - main

Autorisierte OAuth-Apps

Wenn Sie eine kontinuierliche Bereitstellung einrichten, autorisieren Sie Azure-App Dienst als autorisierte OAuth-App für Ihr GitHub-Konto. App Service verwendet den autorisierten Zugriff, um eine GitHub-Aktions-YML-Datei in GITHUB/workflows/<workflow-name.yml> zu erstellen. Sie können Ihre autorisierten Apps anzeigen und Berechtigungen unter Ihren GitHub-Konten Einstellungen unter Integrationen/Anwendungen widerrufen.

Workflowveröffentlichungsprofilgeheimnis

In der Workflowdatei ".github/workflows/<workflow-name.yml>", die dem Repository hinzugefügt wurde, wird ein Platzhalter für die Veröffentlichung von Profilanmeldeinformationen angezeigt, die für den Bereitstellungsauftrag des Workflows erforderlich sind. Die Veröffentlichungsprofilinformationen werden im Repository Einstellungen unter "Sicherheit/Aktionen" verschlüsselt gespeichert.

In diesem Artikel authentifiziert sich die GitHub-Aktion mit einer Veröffentlichungsprofilanmeldeinformationen. Es gibt andere Möglichkeiten zum Authentifizieren, z. B. bei einem Dienstprinzipal oder openID-Verbinden. Weitere Informationen finden Sie unter Deploy to App Service using GitHub Actions.

Den Workflow ausführen

Jetzt testen Sie den Workflow, indem Sie eine Änderung am Repository vornehmen.

Schritt 1. Wechseln Sie zu Ihrer Verzweigung des Beispiel-Repositorys (oder des verwendeten Repositorys), und wählen Sie den Branch aus, den Sie als Teil des Triggers festgelegt haben.

Schritt 2. Nehmen Sie eine kleine Änderung vor.

Wenn Sie z. B. das Lernprogramm "VS Code Flask" verwendet haben, können Sie

• Wechseln Sie zur Datei "/hello-app/templates/home.html " der Trigger-Verzweigung.
• Wählen Sie "Bearbeiten" aus, und fügen Sie den Text "Erneut bereitgestellt!" hinzu.

Schritt 3. Übernehmen Sie die Änderung direkt auf die Verzweigung, in der Sie arbeiten.

• Wählen Sie oben rechts auf der Seite, die Sie bearbeiten, die Schaltfläche "Commitänderungen ausführen" aus. Das Fenster "Commitänderungen " wird geöffnet. Ändern Sie im Fenster "Commit-Änderungen übernehmen" die Commit-Nachricht bei Bedarf, und wählen Sie dann die Schaltfläche "Commit-Änderungen übernehmen " aus.
• Der Commit startet den GitHub Actions-Workflow.

Sie können den Workflow auch manuell starten.

Schritt 1. Wechseln Sie zur Registerkarte "Aktionen " des Repositorys, das für die kontinuierliche Bereitstellung eingerichtet ist.

Schritt 2. Wählen Sie den Workflow in der Liste der Workflows aus, und wählen Sie dann "Workflow ausführen" aus.

Problembehandlung für einen fehlgeschlagenen Workflow

Um den Status eines Workflows zu überprüfen, wechseln Sie zur Registerkarte "Aktionen" des Repositorys. Wenn Sie einen Drilldown in die workflowdatei ausführen, die in diesem Lernprogramm erstellt wurde, werden zwei Aufträge "build" und "deploy" angezeigt. Sehen Sie sich bei einem fehlgeschlagenen Auftrag die Ausgabe von Auftragsaufgaben an, um einen Hinweis auf den Fehler zu geben. Häufige Probleme sind beispielsweise die folgenden:

• Wenn die App aufgrund einer fehlenden Abhängigkeit fehlschlägt, wurde die Datei "requirements.txt " während der Bereitstellung nicht verarbeitet. Dieses Verhalten tritt auf, wenn Sie die Web-App direkt im Portal erstellt haben, anstatt den Befehl az webapp up zu verwenden, wie in diesem Artikel beschrieben.

• Wenn Sie den App-Dienst über das Portal bereitgestellt haben, wurde die Buildaktion SCM_DO_BUILD_DURING_DEPLOYMENT Einstellung möglicherweise nicht festgelegt. Diese Einstellung muss auf true. Der az webapp up Befehl legt die Buildaktion automatisch fest.

• 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 die kontinuierliche Bereitstellung für die Container-App einrichten, wie in diesem Lernprogramm gezeigt, wird die Workflowdatei (GITHUB/workflows/<workflow-name.yml>) zunächst automatisch für Sie erstellt. Wenn Sie sie geändert haben, entfernen Sie die Änderungen, um festzustellen, ob sie den Fehler verursachen.

Ausführen eines Skripts nach der Bereitstellung

Ein Skript nach der Bereitstellung kann z. B. Umgebungsvariablen definieren, die vom App-Code erwartet werden. Fügen Sie das Skript als Teil des App-Codes hinzu, und führen Sie es mithilfe des Startbefehls aus.

Um hartcodierende Variablenwerte in Ihrer Workflow-YML-Datei zu vermeiden, können Sie sie stattdessen in der GitHub-Weboberfläche verwenden und dann auf den Variablennamen im Skript verweisen. Sie können verschlüsselte geheime Schlüssel für ein Repository oder für eine Umgebung (Konto-Repository) erstellen. Weitere Informationen finden Sie unter Verschlüsselte geheime Schlüssel in GitHub-Dokumenten.

Überlegungen für Django

Wie weiter oben in diesem Artikel erwähnt, können Sie GitHub-Aktionen verwenden, um Django-Apps für Azure-App Service unter Linux bereitzustellen, wenn Sie eine separate Datenbank verwenden. Sie können keine SQLite-Datenbank verwenden, da App Service die Datei db.sqlite3 sperrt und damit sowohl Lese- als auch Schreibvorgänge verhindert. Dieses Verhalten wirkt sich nicht auf eine externe Datenbank aus.

Wie im Artikel "Python-App für App Service konfigurieren – Containerstartprozess" beschrieben, sucht App Service automatisch nach einer wsgi.py Datei in Ihrem App-Code, die normalerweise das App-Objekt enthält. Wenn Sie den webapp config set Befehl zum Festlegen des Startbefehls verwendet haben, haben Sie den --startup-file Parameter verwendet, um die Datei anzugeben, die das App-Objekt enthält. Der webapp config set Befehl ist in der Aktion "webapps-deploy" nicht verfügbar. Stattdessen können Sie den startup-command Parameter verwenden, um den Startbefehl anzugeben. Der folgende Codeausschnitt zeigt beispielsweise, wie der Startbefehl in der Workflowdatei angegeben wird:

startup-command: startup.txt

Bei Verwendung von Django möchten Sie die Datenmodelle in der Regel mithilfe python manage.py migrate des Befehls migrieren, nachdem Sie den App-Code bereitgestellt haben. Sie können den Befehl "Migrieren" in einem Skript nach der Bereitstellung ausführen.

GitHub-Aktionen trennen

Durch das Trennen von GitHub-Aktionen von Ihrem App-Dienst können Sie die App-Bereitstellung neu konfigurieren. Sie können auswählen, was mit Ihrer Workflowdatei passiert, nachdem Sie die Verbindung getrennt haben, ob Sie die Datei speichern oder löschen möchten.

az webapp deployment github-actions remove \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Bereinigen von Ressourcen

Um zu vermeiden, dass für die in diesem Tutorial erstellten Azure-Ressourcen Gebühren anfallen, löschen Sie die Ressourcengruppe, die den App Service und den App Service-Plan enthält.

az group delete --name <resource-group-name>

Um das Speicherkonto zu löschen, das das Dateisystem für Cloud Shell verwaltet und für das eine geringe monatliche Gebühr anfällt, löschen Sie die Ressourcengruppe, die mit cloud-shell-storage- beginnt. Wenn Sie der einzige Benutzer der Gruppe sind, ist es sicher, die Ressourcengruppe zu löschen. Wenn andere Benutzer vorhanden sind, können Sie ein Speicherkonto in der Ressourcengruppe löschen.

Wenn Sie die Azure-Ressourcengruppe gelöscht haben, sollten Sie auch die folgenden Änderungen am GitHub-Konto und Repository vornehmen, das für die kontinuierliche Bereitstellung verbunden war:

• Entfernen Sie im Repository die .github/workflows/<workflow-name.yml-Datei>.
• Entfernen Sie in den Repositoryeinstellungen den AZUREAPPSERVICE_PUBLISHPROFILE_ geheimen Schlüssel, der für den Workflow erstellt wurde.
• Entfernen Sie in den GitHub-Kontoeinstellungen Azure-App Dienst als autorisierte Oauth-App für Ihr GitHub-Konto.