Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird beschrieben, wie Sie die fortlaufende Integration und kontinuierliche Bereitstellung (CI/CD)-Plattform in GitHub Actions verwenden, um eine Python-Web-App auf Azure App Service unter Linux bereitzustellen. Ihr GitHub-Aktionen-Workflow erstellt den Code automatisch und stellt ihn in der App Service-Instanz 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 App-Code
Um die Verfahren in diesem Artikel abzuschließen, benötigen Sie eine Python-Web-App, die zu einem GitHub-Repository verpflichtet ist.
Vorhandene App: Um eine vorhandene Python-Web-App zu verwenden, stellen Sie sicher, dass die App einem GitHub-Repository zugesichert ist.
Neue App: Wenn Sie eine neue Python-Web-App benötigen, können Sie das https://github.com/Microsoft/python-sample-vscode-flask-tutorial GitHub-Repository verzweigen und klonen. Der Beispielcode unterstützt den Flask im Visual Studio Code-Lernprogramm und stellt eine funktionierende Python-Anwendung bereit.
Hinweis
Wenn Ihre App Django und eine SQLite-Datenbank verwendet, funktioniert sie für diese Verfahren nicht. SQLite wird in den meisten in der Cloud gehosteten Umgebungen aufgrund seiner lokalen dateibasierten Speicherbeschränkungen nicht unterstützt. Erwägen Sie, zu einer cloudkompatiblen Datenbank wie PostgreSQL oder Azure Cosmos DB zu wechseln. Weitere Informationen finden Sie unter Django-Überlegungen weiter unten in diesem Artikel.
Ziel-App-Service-Instanz erstellen
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 enthält Git und die Azure CLI. Im folgenden Verfahren verwenden Sie den Befehl az webapp up , um die App-Dienstinstanz zu erstellen und die erste Bereitstellung Ihrer App auszuführen.
Melden Sie sich unter https://portal.azure.com beim Azure-Portal an.
Öffnen Sie die Azure CLI, indem Sie die Cloud Shell-Option auf der Portalsymbolleiste auswählen:
Wählen Sie in Cloud Shell die Bash-Option aus dem Dropdownmenü aus:
Klonen Sie in Cloud Shell Ihr Repository mit dem Befehl "Git Clone ".
Tipp
Wenn Sie Befehle oder Text in Cloud Shell einfügen möchten, verwenden Sie die Tastenkombination STRG+UMSCHALT+V , oder klicken Sie mit der rechten Maustaste, und wählen Sie im Kontextmenü "Einfügen" aus.
Für die Flask-Beispiel-App können Sie den folgenden Befehl verwenden. Ersetzen Sie den
<github-user>
Teil durch den Namen des GitHub-Kontos, von dem Sie das Repository geforkt haben.git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git
Wenn sich Ihre App in einem anderen Repository befindet, richten Sie GitHub-Aktionen für das jeweilige Repository ein. Ersetzen Sie den
<github-user>
Teil durch den Namen des GitHub-Kontos, in das Sie das Repository geforkt haben, und geben Sie den tatsächlichen Repositorynamen im<repo-name>
Platzhalter an.git clone https://github.com/<github-user>/<repo-name>.git
Hinweis
Cloud Shell wird von einem Azure Storage-Konto in einer Ressourcengruppe mit dem Namen "Cloud-shell-storage-your-region<>" unterstützt. Dieses Speicherkonto enthält ein Bild des Cloud Shell-Dateisystems, das das geklonte Repository speichert. Für diesen Speicher gibt es kleine Kosten. Sie können das Speicherkonto löschen, nachdem Sie diesen Artikel abgeschlossen haben, zusammen mit anderen Ressourcen, die Sie erstellen.
Ändern Sie in Cloud Shell das Verzeichnis in den Repository-Ordner für Ihre Python-App, damit der az webapp up-Befehl die App als Python erkennt. Für die Flask-Beispiel-App verwenden Sie den folgenden Befehl:
cd python-sample-vscode-flask-tutorial
Verwenden Sie in Cloud Shell den Befehl az webapp up , um eine App Service-Instanz zu erstellen und die erste Bereitstellung für Ihre App durchzuführen:
az webapp up --name <app-service-name> --runtime "PYTHON:3.9"
Geben Sie für den
<app-service-name>
Platzhalter einen App-Dienstnamen 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.Verwenden Sie den
az webapp list-runtimes
Befehl, um eine Liste der verfügbaren Laufzeiten auf Ihrem System zu erhalten.Wenn Sie den Laufzeitwert in den Befehl eingeben, verwenden Sie das
PYTHON:X.Y
Format, wobeiX.Y
es sich um die Python-Haupt- und Nebenversion handelt.Sie können auch die Region der App Service-Instanz mit dem Parameter
--___location
angeben. Verwenden Sie für eine Liste der verfügbaren Speicherorte denaz account list-locations --output table
Befehl.
Wenn Ihre App über ein benutzerdefiniertes Startskript verfügt, verwenden Sie den Az webapp-Konfigurationsbefehl , um das Skript zu initiieren.
Wenn Ihre App nicht über ein benutzerdefiniertes Startskript verfügt, fahren Sie mit dem nächsten Schritt fort.
Für die Flask-Beispiel-App müssen Sie auf das Startskript in der dateistartup.txt zugreifen, indem Sie den folgenden Befehl ausführen:
az webapp config set \ --resource-group <resource-group-name> \ --name <app-service-name> \ --startup-file startup.txt
Geben Sie Ihren Ressourcengruppennamen und den App Service-Instanznamen in die
<resource-group-name>
und<app-service-name>
Platzhalter ein. Um den Ressourcengruppennamen zu finden, überprüfen Sie die Ausgabe des vorherigenaz webapp up
Befehls. Der Ressourcengruppenname enthält den Azure-Kontonamen gefolgt vom suffix _rg , wie in <azure-account-name>_rg_.
Um die ausgeführte App anzuzeigen, öffnen Sie einen Browser, und wechseln Sie zum Bereitstellungsendpunkt für Ihre App Service-Instanz. Ersetzen Sie in der folgenden URL den Platzhalter durch den
<app-service-name>
Namen Ihrer App-Dienstinstanz:http://<app-service-name>.azurewebsites.net
Wenn eine generische Seite angezeigt wird, warten Sie einige Sekunden, bis die App Service-Instanz gestartet wird, und aktualisieren Sie die Seite.
- Wenn Sie weiterhin eine generische Seite sehen, stellen Sie sicher, dass Sie die Anwendung aus dem richtigen Ordner bereitgestellt haben.
- Stellen Sie sicher, dass Sie die App für Flask aus dem Ordner python-sample-vscode-flask-tutorial bereitgestellt haben. Überprüfen Sie außerdem, ob Sie den Startbefehl ordnungsgemäß festlegen.
Einrichten der kontinuierlichen Bereitstellung in App Service
Im nächsten Verfahren richten Sie die kontinuierliche Zustellung (Continuous Delivery, CD) ein, was bedeutet, dass eine neue Codebereitstellung auftritt, wenn ein Workflow ausgelöst wird. Der Auslöser im Artikelbeispiel ist jede Änderung an der main-Hauptverzweigung Ihres Repositorys, z. B. mit einem Pull Request (PR).
Bestätigen Sie in Cloud Shell, dass Sie sich im Stammverzeichnis für Ihr System (
~
) befinden und nicht in einem App-Unterordner, z. B. python-sample-vscode-flask-tutorial.Fügen Sie GitHub-Aktionen mit dem Befehl az webapp deployment github-actions add hinzu. Ersetzen Sie alle Platzhalter durch Ihre spezifischen Werte:
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 Eingabeaufforderungen, und schließen Sie die Authentifizierung ab.Wenn im System eine vorhandene Workflowdatei mit demselben App Service-Instanznamen auftritt, folgen Sie den Anweisungen, um auszuwählen, ob der Workflow überschrieben werden soll. Sie können den
--force
Parameter mit dem Befehl verwenden, um alle in Konflikt stehenden Workflows automatisch zu überschreiben.
Der
add
Befehl schließt die folgenden Aufgaben ab:- Erstellt eine neue Workflowdatei im Github/workflows/<workflow-name>.yml Pfad in Ihrem Repository. Der Dateiname enthält den Namen Ihrer App Service-Instanz.
- Ruft ein Veröffentlichungsprofil mit geheimen Schlüsseln für Ihre App Service-Instanz ab und fügt es als GitHub-Aktionsschlüssel hinzu. Der Name des geheimen Schlüssels beginnt mit AZUREAPPSERVICE_PUBLISHPROFILE_. Auf diesen geheimen Schlüssel wird in der Workflowdatei verwiesen.
Rufen Sie die Details einer Bereitstellungskonfiguration für die Quellcodeverwaltung mit dem Befehl az webapp deployment source show ab. Ersetzen Sie die Platzhalterparameter durch Ihre spezifischen Werte:
az webapp deployment source show \ --name <app-service-name> \ --resource-group <resource-group-name>
Bestätigen Sie in der Befehlsausgabe die Werte für die
repoUrl
undbranch
Eigenschaften. Diese Werte sollten mit den Werten übereinstimmen, die Sie mit demadd
Befehl angegeben haben.
Untersuchen von GitHub-Workflows und -Aktionen
Eine Workflowdefinition wird in einer YAML-Datei (.yml) im Pfad /.github/workflows/ in Ihrem Repository angegeben. 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, und jeder Auftrag ist eine Reihe von Schritten. Jeder Schritt ist ein Shellskript oder eine Aktion. Jeder Auftrag verfügt über einen Aktionsabschnitt in der Workflowdatei.
Im Hinblick auf den Workflow, der mit Ihrem Python-Code für die Bereitstellung in Azure App Service eingerichtet ist, hat der Workflow die folgenden Aktionen:
Maßnahme | BESCHREIBUNG |
---|---|
checkout | Sehen Sie sich das Repository auf einem Runner, einem GitHub Actions-Agent, an. |
setup-python | Installieren Sie Python auf dem Runner. |
appservice-build | Erstellen der Web-App. |
webapps-deploy | Stellen Sie die Web-App bereit, indem Sie eine Anmeldeinformation für das Veröffentlichungsprofil verwenden, um sich in Azure zu authentifizieren. Die Anmeldeinformationen werden in einem GitHub-Geheimnis gespeichert. |
Die Workflowvorlage, die zum Erstellen des Workflows verwendet wird, ist Azure/actions-workflow-samples.
Der Workflow wird bei Push-Ereignissen auf dem angegebenen Branch 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 Hauptzweigung ausgelöst wird:
on:
push:
branches:
- main
Autorisierte OAuth-Apps
Wenn Sie eine kontinuierliche Bereitstellung einrichten, autorisieren Sie Azure App Service als autorisierte OAuth-App für Ihr GitHub-Konto. App Service verwendet den autorisierten Zugriff, um eine GitHub-Aktions-YAML-Datei auf der GITHUB/workflows/<workflow-name>.yml Pfad in Ihrem Repository zu erstellen.
Um Ihre autorisierten Apps anzuzeigen und Berechtigungen unter Ihren GitHub-Konten zu widerrufen, wechseln Sie zu "Einstellungen>integrations/Applications":
Workflow Profil Secret veröffentlichen
In der .github/workflows/<workflow-name>.yml Workflowdatei, die Ihrem Repository hinzugefügt wurde, gibt es einen Platzhalter für die Veröffentlichung von Profilanmeldeinformationen, die für den Bereitstellungsauftrag des Workflows erforderlich sind. Die Veröffentlichungsprofilinformationen werden im Repository verschlüsselt gespeichert.
Um das Geheimnis anzuzeigen, gehen Sie zu Einstellungen>Sicherheit>Geheimnis und Variablen>Aktionen:
In diesem Artikel authentifiziert sich die GitHub-Aktion mit einer Anmeldeinformation für das Veröffentlichungsprofil. Es gibt auch andere Möglichkeiten der Authentifizierung, wie z. B. mit einem Dienstprinzipal oder OpenID Connect. Weitere Informationen finden Sie unter Deploy to App Service using GitHub Actions.
Ausführen und Testen des Workflows
Der letzte Schritt besteht darin, den Workflow zu testen, indem sie eine Änderung am Repository vornehmen.
Öffnen Sie in einem Browser Ihren Fork des Beispiel-Repositorys (oder des verwendeten Repositorys), und wählen Sie den Branch aus, den Sie im Rahmen des Triggers festgelegt haben.
Nehmen Sie eine kleine Änderung an Ihrer Python-Web-App vor.
Im Flask-Lernprogramm finden Sie hier eine einfache Änderung:
- Gehen Sie zur Datei /hello-app/templates/home.html des Branch des Triggers.
- Wählen Sie "Bearbeiten" (Bleistift) aus.
- Suchen Sie im Editor nach der print-Anweisung
<p>
, und fügen Sie den Text "Erneut bereitgestellt!" hinzu.
Committen Sie die Änderung direkt in dem Branch, in dem Sie gerade arbeiten.
- Wählen Sie im Editor Änderungen bestätigen oben rechts aus. Das Fenster „Änderungen bestätigen“ wird geöffnet.
- Ändern Sie im Fenster "Änderungen übernehmen" die Commit-Nachricht nach Bedarf und wählen Sie Änderungen übernehmen aus.
Der Commitprozess löst den GitHub Actions-Workflow aus.
Sie können den Workflow auch manuell auslösen:
Wechseln Sie zur Registerkarte "Aktionen " des Repositorys, das für die kontinuierliche Bereitstellung eingerichtet ist.
Wählen Sie den Workflow in der Liste der Workflows aus, und wählen Sie dann " Workflow ausführen" aus.
Problembehandlung bei fehlgeschlagenen Workflows
Sie können den Status eines Workflows auf der Registerkarte "Aktionen " für das App-Repository überprüfen. Wenn Sie die in diesem Artikel erstellte Workflowdatei untersuchen, werden zwei Aufträge angezeigt: Erstellen und Bereitstellen. Als Erinnerung basiert der Workflow auf der Vorlage "Azure/actions-workflow-samples" .
Bei einem fehlgeschlagenen Job sehen Sie sich die Ausgabe der Job-Aufgaben an, um einen Hinweis auf den Fehler zu erhalten.
Hier sind einige häufige Probleme, die untersucht werden müssen:
Wenn die App aufgrund einer fehlenden Abhängigkeit fehlschlägt, wurde die requirements.txt Datei während der Bereitstellung nicht verarbeitet. Dieses Verhalten tritt auf, wenn Sie die Web-App direkt im Portal erstellt haben, anstatt den
az webapp up
Befehl zu verwenden, wie in diesem Artikel gezeigt.Wenn Sie den App-Dienst über das Portal bereitgestellt haben, ist die Einstellung für die Buildaktion
SCM_DO_BUILD_DURING_DEPLOYMENT
möglicherweise nicht festgelegt. Diese Einstellung muss auftrue
festgelegt werden. Deraz webapp up
Befehl legt die Buildaktion automatisch fest.Wenn eine Fehlermeldung bezüglich „TLS-Handshake-Timeout“ angezeigt wird, führen Sie den Workflow manuell aus, indem Sie unter der Registerkarte Aktionen des App-Repositorys Automatische Bereitstellung auslösen auswählen. Sie können feststellen, ob es sich bei dem Timeout um ein temporäres Problem handelt.
Wenn Sie die kontinuierliche Bereitstellung für die Container-App einrichten, wie in diesem Artikel gezeigt, wird die anfängliche Workflowdatei GITHUB/workflows/<workflow-name>.yml automatisch für Sie erstellt. Wenn Sie die Datei geändert haben, entfernen Sie die Änderungen, um festzustellen, ob sie den Fehler verursachen.
Ausführen des Skripts nach der Bereitstellung
Ein Skript nach der Bereitstellung kann mehrere Aufgaben ausführen, z. B. das Definieren von Umgebungsvariablen, die vom App-Code erwartet werden. Sie fügen das Skript als Teil des App-Codes hinzu und führen das Skript mithilfe des Startbefehls aus.
Um hartcodierende Variablenwerte in Ihrer Workflow-YAML-Datei zu vermeiden, sollten Sie die Variablen in GitHub konfigurieren und auf die 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 Verwenden von geheimen Schlüsseln in GitHub-Aktionen.
Überlegungen zu Django überprüfen
Wie weiter oben in diesem Artikel erwähnt, können Sie GitHub-Aktionen verwenden, um Django-Apps auf 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, wodurch sowohl Lese- als auch Schreibvorgänge verhindert werden. Dieses Verhalten wirkt sich nicht auf eine externe Datenbank aus.
Der Artikel "Configure Python app on App Service – Container startup process" beschreibt, wie App Service automatisch in Ihrem App-Code nach einer wsgi.py Datei sucht, 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 Code zeigt beispielsweise, wie der Startbefehl in der Workflowdatei angegeben wird:
startup-command: startup.txt
Wenn Sie Django verwenden, möchten Sie die Datenmodelle in der Regel mithilfe des python manage.py migrate
Befehls migrieren, nachdem Sie den App-Code bereitgestellt haben. Sie können den Befehl "Migrieren" in einem Skript nach der Bereitstellung ausführen.
GitHub Actions deaktivieren
Durch das Trennen von GitHub-Aktionen von Ihrer App Service-Instanz können Sie die App-Bereitstellung neu konfigurieren. Sie können auswählen, was mit Ihrer Workflowdatei passiert, nachdem Sie die Verbindung getrennt haben, und ob Sie die Datei speichern oder löschen möchten.
Trennen Sie GitHub-Aktionen mit dem folgenden Azure CLI az webapp Deployment github-actions remove-Befehl. Ersetzen Sie alle Platzhalter durch Ihre spezifischen Werte:
az webapp deployment github-actions remove \
--repo "<github-username>/<github-repo>" \
--resource-group <resource-group-name> \
--branch <branch-name> \
--name <app-service-name> \
--login-with-github
Bereinigen von Ressourcen
Um Gebühren für die in diesem Artikel erstellten Azure-Ressourcen zu vermeiden, löschen Sie die Ressourcengruppe, die die App Service-Instanz und den App Service-Plan enthält.
Überall, wo die Azure CLI installiert ist, einschließlich der Azure Cloud Shell, können Sie den Befehl "az group delete " verwenden, um eine Ressourcengruppe zu löschen:
az group delete --name <resource-group-name>
Speicherkonto löschen
Um das Speicherkonto zu löschen, das das Dateisystem für Cloud Shell verwaltet, das eine kleine monatliche Gebühr verursacht, 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.
Aktualisieren des GitHub-Kontos und des Repositorys
Wenn Sie die Azure-Ressourcengruppe löschen, sollten Sie die folgenden Änderungen am GitHub-Konto und repository vornehmen, das für die kontinuierliche Bereitstellung verbunden war:
- Entfernen Sie im App-Repository die .github/workflows/<workflow-name>.yml Datei.
- Entfernen Sie in den App-Repositoryeinstellungen den AZUREAPPSERVICE_PUBLISHPROFILE_ geheimen Schlüssel, der für den Workflow erstellt wurde.
- Entfernen Sie in den GitHub-Kontoeinstellungen Azure App Service als autorisierte Oauth-App für Ihr GitHub-Konto.