Freigeben über

Konfigurieren einer Linux-Python-App für Azure App Service

Bereitstellen in Azure

In diesem Artikel wird beschrieben, wie Azure App Service Python-Apps ausführt, wie Sie vorhandene Apps zu Azure migrieren und wie Sie das Verhalten von App Service bei Bedarf anpassen können. Python-Apps müssen mit allen erforderlichen Pip-Modulen bereitgestellt werden.

Das App Service-Bereitstellungsmodul aktiviert automatisch eine virtuelle Umgebung und führt pip install -r requirements.txt aus, wenn Sie ein Git-Repository oder ein ZIP-Paketmit aktivierter Buildautomatisierung bereitstellen.

Hinweis

Derzeit erfordert App Service requirements.txt im Stammverzeichnis Ihres Projekts, auch wenn Sie über ein pyproject.toml verfügen. Empfohlen Ansätze finden Sie unter Generieren von requirements.txt von pyproject.toml.

Dieser Leitfaden enthält wichtige Konzepte und Anleitungen für Python-Entwickler, die in App Service einen integrierten Linux-Container verwenden. Wenn Sie Azure App Service noch nie verwendet haben, folgen Sie zuerst dem Python-Schnellstart - und Flask-, Django- oder FastAPI-Lernprogramm für PostgreSQL.

Sie können entweder das Azure-Portal oder die Azure CLI für die Konfiguration verwenden:

  • Verwenden Sie im Azure-Portal die Seite "Einstellungskonfiguration>" der App, wie unter "Konfigurieren einer App Service-App" im Azure-Portal beschrieben.

  • Azure CLI: Sie haben zwei Optionen.

    • Führen Sie Befehle in der Azure Cloud Shell aus.
    • Führen Sie Befehle lokal aus, indem Sie die neueste Version der Azure CLI installieren und sich dann mit az login bei Azure anmelden.

Hinweis

Linux ist die einzige Betriebssystemoption zum Ausführen von Python-Apps in App Service. Python unter Windows wird nicht mehr unterstützt. Sie können jedoch Ihr eigenes benutzerdefiniertes Windows-Containerimage erstellen und dieses in App Service ausführen. Weitere Informationen finden Sie unter Verwenden eines benutzerdefinierten Docker-Images.

Konfigurieren der Python-Version

  • Azure-Portal: Verwenden Sie die Registerkarte " Allgemeine Einstellungen " auf der Seite " Konfiguration ", wie unter "Allgemeine Einstellungen für Linux-Container konfigurieren" beschrieben.

  • Azure CLI:

    • Anzeigen der aktuellen Python-Version mit az webapp config show:

      az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

      Ersetzen Sie <resource-group-name> und <app-name> durch die entsprechenden Namen für Ihre Web-App.

    • Festlegen der Python-Version mit az webapp config set

      az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.11"

    • Alle Python-Versionen anzeigen, die in Azure App Service mit az webapp list-runtimes unterstützt werden:

      az webapp list-runtimes --os linux | grep PYTHON

Sie können auch eine nicht unterstützte Version von Python ausführen, indem Sie stattdessen Ihr eigenes Containerimage erstellen. Weitere Informationen finden Sie unter Verwenden eines benutzerdefinierten Docker-Images.

Was geschieht mit veralteten Laufzeiten in App Service?

Veraltete Runtimes werden von der Aufrechterhaltungsorganisation nicht mehr unterstützt, oder es wurde festgestellt, dass erhebliche Sicherheitsrisiken vorliegen. Dementsprechend werden sie aus dem Erstellen und Konfigurieren von Seiten im Portal entfernt. Wenn eine veraltete Laufzeit im Portal ausgeblendet ist, wird jede App, die diese Laufzeit verwendet, weiterhin ausgeführt.

Wenn Sie eine App mit einer veralteten Laufzeitversion erstellen möchten, die nicht mehr im Portal angezeigt wird, verwenden Sie die Azure CLI-, ARM-Vorlage oder Bicep. Mit diesen Bereitstellungsalternativen können Sie veraltete Laufzeiten erstellen, die im Portal entfernt wurden, aber weiterhin unterstützt werden.

Wenn eine Laufzeit vollständig von der App Service-Plattform entfernt wird, erhält Ihr Azure-Abonnementbesitzer vor dem Entfernen eine E-Mail-Benachrichtigung.

Anpassen der Buildautomatisierung

Hinweis

Wenn Python-Anwendungen mit Build-Automatisierung bereitgestellt werden, werden die Inhalte nach /tmp/<uid> bereitgestellt und von dort aus bedient, nicht unter /home/site/wwwroot. Auf dieses Inhaltsverzeichnis kann über die APP_PATH Umgebungsvariable zugegriffen werden. Alle zur Laufzeit erstellten zusätzlichen Dateien sollten an einem Speicherort abgelegt werden, der entweder unter /home liegt oder indem Sie Bring Your Own Storage für die Persistenz nutzen. Weitere Informationen zu diesem Verhalten finden Sie hier.

Das Buildsystem von App Service mit dem Namen Oryx führt die folgenden Schritte beim Bereitstellen Ihrer App aus, wenn die Einstellung SCM_DO_BUILD_DURING_DEPLOYMENT auf 1 festgelegt ist:

  1. Führen Sie ein benutzerdefiniertes Pre-Build-Skript aus, wenn dieser Schritt in der Einstellung PRE_BUILD_COMMAND angegeben ist. (Vom Skript können selbst auch andere Python- und Node.js-Skripts, pip- und npm-Befehle und Node-basierte Tools wie yarn, z. B. yarn install und yarn build, ausgeführt werden.)

  2. Führen Sie pip install -r requirements.txt aus. Die requirements.txt Datei muss im Stammordner des Projekts vorhanden sein. Andernfalls wird vom Buildprozess ein Fehler der folgenden Art gemeldet: „setup.py oder requirements.txt nicht gefunden. pip-Installation wird nicht ausgeführt.“

  3. Wenn manage.py im Stammverzeichnis des Repositorys (angibt eine Django-App) gefunden wird, führen Sie manage.py collectstatic aus. Wenn die Einstellung DISABLE_COLLECTSTATIC aber auf true festgelegt ist, wird dieser Schritt übersprungen.

  4. Führen Sie ein benutzerdefiniertes Post-Build-Skript aus, wenn dieser Schritt in der Einstellung POST_BUILD_COMMAND angegeben ist. (Auch hier können vom Skript selbst andere Python- und Node.js-Skripts, pip- und npm-Befehle und Node-basierte Tools ausgeführt werden.)

Standardmäßig sind die Einstellungen für PRE_BUILD_COMMAND, POST_BUILD_COMMAND und DISABLE_COLLECTSTATIC leer.

  • Wenn Sie bei der Erstellung von Django-Apps die Ausführung von „collectstatic“ deaktivieren möchten, legen Sie die Einstellung DISABLE_COLLECTSTATIC auf true fest.

  • Legen Sie zum Ausführen von Pre-Build-Befehlen die Einstellung PRE_BUILD_COMMAND so fest, dass sie entweder einen Befehl, z. B. echo Pre-build command, oder einen Pfad zu einer Skriptdatei relativ zu Ihrem Projektstamm enthält, z. B. scripts/prebuild.sh. Für alle Befehle müssen relative Pfade zum Stammordner des Projekts verwendet werden.

  • Legen Sie zum Ausführen von Post-Build-Befehlen die Einstellung POST_BUILD_COMMAND so fest, dass sie entweder einen Befehl, z. B. echo Post-build command, oder einen Pfad zu einer Skriptdatei relativ zu Ihrem Projektstamm enthält, z. B. scripts/postbuild.sh. Für alle Befehle müssen relative Pfade zum Stammordner des Projekts verwendet werden.

Weitere Einstellungen, die die Buildautomatisierung anpassen, finden Sie unter Oryx-Konfiguration.

Informationen zum Zugriff auf die Build- und Bereitstellungsprotokolle finden Sie in den Access-Bereitstellungsprotokollen.

Weitere Informationen dazu, wie App Service Python-Apps in Linux ausführt und erstellt, finden Sie unter Wie Oryx Python-Apps erkennt und erstellt.

Hinweis

Die Einstellungen PRE_BUILD_SCRIPT_PATH und POST_BUILD_SCRIPT_PATH sind mit PRE_BUILD_COMMAND und POST_BUILD_COMMAND identisch und werden aus Legacygründen unterstützt.

Eine Einstellung mit dem Namen SCM_DO_BUILD_DURING_DEPLOYMENT löst, sofern sie true oder 1 enthält, einen Oryx-Build aus, der während der Bereitstellung ausgeführt wird. Die Einstellung ist true, wenn Sie mit Git, dem Azure CLI-Befehl az webapp up und Visual Studio Code bereitstellen.

Hinweis

Verwenden Sie in allen Prä- und Postbuildskripts immer relative Pfade, da sich der Buildcontainer, in dem Oryx ausgeführt wird, von dem Runtimecontainer unterscheidet, in dem die App ausgeführt wird. Verlassen Sie sich niemals auf die genaue Platzierung Ihres App-Projektordners innerhalb des Containers (z. B. die Position unter "site/wwwroot").

Generieren von requirements.txt aus pyproject.toml

Der App-Dienst unterstützt pyproject.toml derzeit nicht direkt. Wenn Sie Tools wie Poesie oder UV verwenden, empfiehlt es sich, vor der Bereitstellung im Stammverzeichnis Ihres Projekts einen kompatiblen requirements.txt zu generieren:

Verwenden von Poesie

Verwenden von Poesie mit dem Export-Plug-In:


poetry export -f requirements.txt --output requirements.txt --without-hashes

Verwenden von uv

Verwendung von uv:


uv export --format requirements-txt --no-hashes --output-file requirements.txt

Migrieren von vorhandenen Anwendungen zu Azure

Vorhandene Webanwendungen können in Azure wie folgt erneut bereitgestellt werden:

  1. Quell-Repository: Verwalten Sie Ihren Quellcode in einem geeigneten Repository wie GitHub, mit dem Sie die kontinuierliche Bereitstellung später in diesem Prozess einrichten können.

    • Ihre requirements.txt Datei muss sich im Stammverzeichnis Ihres Repositorys für App Service befinden, um die erforderlichen Pakete automatisch zu installieren.

  2. Datenbank: Wenn Ihre App von einer Datenbank abhängt, erstellen Sie auch die erforderlichen Ressourcen in Azure.

  3. App-Dienstressourcen: Erstellen Sie eine Ressourcengruppe, einen App Service-Plan und eine App Service-Web-App, um Ihre Anwendung zu hosten. Sie können dies ganz einfach mit dem Azure CLI-Befehl az webapp up ausführen. Oder Sie können Ressourcen wie im Lernprogramm Flask, Django oder FastAPI mit PostgreSQL erstellen und bereitstellen. Ersetzen Sie die Namen der Ressourcengruppe, des App Service-Plans und der Web-App durch Namen, die für Ihre Anwendung besser geeignet sind.

  4. Umgebungsvariablen: Wenn Ihre Anwendung Umgebungsvariablen erfordert, erstellen Sie entsprechende App Service-Anwendungseinstellungen. Diese App Service-Einstellungen werden ihrem Code als Umgebungsvariablen angezeigt, wie in Access-Umgebungsvariablen beschrieben.

  5. App-Start: Lesen Sie den Abschnitt Containerstartprozess weiter unten in diesem Artikel, um zu verstehen, wie App Service versucht, Ihre App auszuführen. Der App-Dienst verwendet standardmäßig den Gunicorn-Webserver, der in der Lage sein muss, Ihr App-Objekt oder wsgi.py Ordner zu finden. Bei Bedarf können Sie den Startbefehl anpassen.

  6. Kontinuierliche Bereitstellung: Einrichten einer kontinuierlichen Bereitstellung von GitHub-Aktionen, Bitbucket oder Azure Repos, wie im Artikel "Fortlaufende Bereitstellung für Azure App Service" beschrieben. Oder richten Sie eine kontinuierliche Bereitstellung von lokalem Git ein, wie im Artikel "Lokale Git-Bereitstellung" für Azure App Service beschrieben.

  7. Benutzerdefinierte Aktionen: Zum Ausführen von Aktionen innerhalb des App-Dienstcontainers, der Ihre App hostt, z. B. Django-Datenbankmigrationen, können Sie über SSH eine Verbindung mit dem Container herstellen. Ein Beispiel für das Ausführen von Django-Datenbankmigrationen finden Sie im Lernprogramm: Bereitstellen einer Django-Web-App mit PostgreSQL – Generieren eines Datenbankschemas.

    • Wenn Sie eine fortlaufende Bereitstellung verwenden, können Sie diese Aktionen mithilfe von Postbuildbefehlen ausführen, wie weiter oben unter "Buildautomatisierung anpassen" beschrieben.

Nachdem Sie diese Schritte abgeschlossen haben, sollten Sie in der Lage sein, Änderungen an Ihrem Quellrepository zu committen, und diese Aktualisierungen werden dann automatisch in App Service bereitgestellt.

Produktionseinstellungen für Django-Apps

Für eine Produktionsumgebung wie Azure App Service sollten Django-Apps der Prüfliste für die Bereitstellung von Django folgen.

In der folgenden Tabelle sind die Produktionseinstellungen beschrieben, die für Azure relevant sind. Diese Einstellungen werden in der setting.py-Datei der App definiert.

Django-Einstellung Anleitung für Azure
SECRET_KEY Speichern Sie den Wert in einer App Service-Einstellung, wie unter Access-App-Einstellungen als Umgebungsvariablen beschrieben. Alternativ können Sie den Wert als geheimer Schlüssel im Azure Key Vault speichern.
DEBUG Erstellen Sie in App Service die Einstellung DEBUG mit dem Wert 0 (false), und laden Sie den Wert dann als Umgebungsvariable. Erstellen Sie in Ihrer Entwicklungsumgebung die Umgebungsvariable DEBUG mit dem Wert 1 (true).
ALLOWED_HOSTS In der Produktion erfordert Django, dass Sie die URL der App in das ALLOWED_HOSTS Array von settings.py einschließen. Sie können diese URL zur Laufzeit mit dem Code os.environ['WEBSITE_HOSTNAME'] abrufen. Von App Service wird die Umgebungsvariable WEBSITE_HOSTNAME automatisch auf die URL der App festgelegt.
DATABASES Definieren Sie Einstellungen in App Service für die Datenbankverbindung, und laden Sie sie als Umgebungsvariablen, um das Wörterbuch DATABASES aufzufüllen. Alternativ können Sie die Werte (insbesondere den Benutzernamen und das Kennwort) als geheime Azure Key Vault-Schlüssel speichern.

Bereitstellen von statischen Dateien für Django-Apps

Wenn Ihre Django-Web-App statische Front-End-Dateien enthält, folgen Sie zuerst den Anweisungen zum Verwalten statischer Dateien in der Django-Dokumentation.

Anschließend nehmen Sie für App Service die folgenden Änderungen vor:

  1. Erwägen Sie, Umgebungsvariablen (für die lokale Entwicklung) und App-Einstellungen (bei der Bereitstellung in der Cloud) zu verwenden, um die Django-Variablen STATIC_URL und STATIC_ROOT dynamisch festzulegen. Beispiel:

    STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")

    DJANGO_STATIC_URL und DJANGO_STATIC_ROOT können für Ihre lokalen und Cloudumgebungen wie gewünscht geändert werden. Falls diese Variablen vom Buildprozess für Ihre statischen Dateien beispielsweise in einem Ordner mit dem Namen django-static angeordnet werden, können Sie DJANGO_STATIC_URL auf /django-static/ festlegen, um die Verwendung der Standardeinstellung zu vermeiden.

  2. Wenn Sie über ein Präbuildskript verfügen, mit dem statische Dateien in einem anderen Ordner generiert werden, sollten Sie diesen Ordner in die Django-Variable STATICFILES_DIRS einfügen, damit die Dateien vom collectstatic-Prozess von Django gefunden werden können. Wenn Sie beispielsweise yarn build in Ihrem Front-End-Ordner ausführen und Yarn einen build/static-Ordner mit statischen Dateien generiert, schließen Sie diesen Ordner wie folgt ein:

    FRONTEND_DIR = "path-to-frontend-folder" 
STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]

    FRONTEND_DIR wird hier verwendet, um einen Pfad zu dem Ort zu erstellen, an dem ein Buildtool wie yarn ausgeführt wird. Sie können auch hier wie gewünscht eine Umgebungsvariable und eine App-Einstellung verwenden.

  3. Fügen Sie whitenoise Ihrer requirements.txt-Datei hinzu. WhiteNoise (whitenoise.evans.io) ist ein Python-Paket, das es für eine Django-Produktions-App einfach macht, eigene statische Dateien zu bedienen. WhiteNoise stellt genau die Dateien bereit, die sich in dem durch die Django-Variable STATIC_ROOT angegebenen Ordner befinden.

  4. Fügen Sie in Ihrer settings.py-Datei die folgende Zeile für WhiteNoise hinzu:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Ändern Sie außerdem die Listen MIDDLEWARE und INSTALLED_APPS so, dass sie WhiteNoise enthalten:

    MIDDLEWARE = [                                                                   
    'django.middleware.security.SecurityMiddleware',
    # Add whitenoise middleware after the security middleware                             
    'whitenoise.middleware.WhiteNoiseMiddleware',
    # Other values follow
]

INSTALLED_APPS = [
    "whitenoise.runserver_nostatic",
    # Other values follow
]

Bereitstellen von statischen Dateien für Flask-Apps

Wenn Ihre Flask Web App statische Front-End-Dateien enthält, folgen Sie zuerst den Anweisungen zum Verwalten statischer Dateien in der Flask-Dokumentation. Ein Beispiel für die Bereitstellung statischer Dateien in einer Flask-Anwendung finden Sie in der Beispielanwendung Flask auf GitHub.

Um statische Dateien direkt aus einer Route Ihrer Anwendung bereitzustellen, können Sie die send_from_directory-Methode verwenden:

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)

Eigenschaften von Containern

Wenn Sie in App Service bereitgestellt werden, werden Python-Apps in einem Linux Docker-Container ausgeführt, der im GitHub-Repository von App Service Python definiert ist. Sie finden Imagekonfigurationen in den versionsspezifischen Verzeichnissen.

Dieser Container verfügt über die folgenden Eigenschaften:

  • Apps werden mit dem Gunicorn WSGI-HTTP-Server mit den zusätzlichen Argumenten --bind=0.0.0.0 --timeout 600ausgeführt.

    • Sie können Konfigurationseinstellungen für Gunicorn bereitstellen, indem Sie den Startbefehl anpassen.

    • Um Ihre Web-App vor versehentlichen oder absichtlichen DDOS-Angriffen zu schützen, wird Gunicorn hinter einem Nginx-Reverseproxy ausgeführt, wie in der Bereitstellung von Gunicorn beschrieben.

  • Standardmäßig enthält das Basiscontainerimage nur das Flask-Webframework, aber der Container unterstützt auch andere Frameworks, die WSGI-konform und mit Python 3.6 oder höher kompatibel sind, z. B. Django.

  • Um andere Pakete wie Django zu installieren, erstellen Sie eine requirements.txt Datei im Stammverzeichnis Ihres Projekts, die Ihre direkten Abhängigkeiten angibt. App Service installiert diese Abhängigkeiten dann automatisch, wenn Sie Ihr Projekt bereitstellen.

    Die requirements.txt Datei muss sich im Projektstamm befinden, damit Abhängigkeiten installiert werden. Andernfalls wird vom Buildprozess ein Fehler der folgenden Art gemeldet: „setup.py oder requirements.txt nicht gefunden. pip-Installation wird nicht ausgeführt.“ Wenn dieser Fehler auftritt, sollten Sie den Speicherort Ihrer Anforderungsdatei überprüfen.

  • App Service definiert automatisch eine Umgebungsvariable mit dem Namen WEBSITE_HOSTNAME und der URL der Web-App, z. B. msdocs-hello-world.azurewebsites.net. Außerdem wird WEBSITE_SITE_NAME mit dem Namen Ihrer App definiert, z. B. msdocs-hello-world.

  • npm und Node.js sind im Container installiert, damit Sie Node-basierte Buildtools, z. B. yarn, ausführen können.

Startprozess des Containers

Beim Starten führt der Container vom Typ „App Service für Linux“ die folgenden Schritte aus:

  1. Verwenden Sie einen benutzerdefinierten Startbefehl, falls vorhanden.
  2. Überprüfen Sie, ob eine Django-App vorhanden ist, und starten Sie Gunicorn, wenn eine erkannt wird.
  3. Überprüfen Sie, ob eine Flask-App vorhanden ist, und starten Sie Gunicorn, wenn eine erkannt wird.
  4. Wenn keine andere App gefunden wird, können Sie eine Standard-App starten, die im Container integriert ist.

Die folgenden Abschnitte enthalten weitere Details zu den einzelnen Optionen.

Django-App

Für Django-Apps sucht App Service in Ihrem App-Code nach der Datei wsgi.py und führt dann mit dem folgenden Befehl Gunicorn aus:

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Wenn Sie eine spezifischere Kontrolle über den Startbefehl wünschen, verwenden Sie einen benutzerdefinierten Startbefehl, ersetzen Sie <module> den Namen des Ordners, der wsgi.py enthält, und fügen Sie ein --chdir Argument hinzu, wenn sich dieses Modul nicht im Projektstamm befindet. Wenn sich Ihr wsgi.py beispielsweise unter knboard/backend/config vom Projektstamm befindet, verwenden Sie die Argumente --chdir knboard/backend config.wsgi.

Um das Produktions-Logging zu aktivieren, fügen Sie die --access-logfile und --error-logfile Parameter hinzu, wie in den Beispielen für benutzerdefinierte Startbefehle gezeigt.

Flask-App

Bei Flask sucht der App-Dienst nach einer Datei mit dem Namen application.py oder app.py und startet Gunicorn wie folgt:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

Wenn Ihr Haupt-App-Modul in einer anderen Datei enthalten ist, verwenden Sie einen anderen Namen für das App-Objekt. Wenn Sie weitere Argumente für Gunicorn bereitstellen möchten, verwenden Sie einen benutzerdefinierten Startbefehl.

Standardverhalten

Wenn der App-Dienst keinen benutzerdefinierten Befehl, eine Django-App oder eine Flask-App findet, wird eine schreibgeschützte Standard-App ausgeführt, die sich im Ordner " opt/defaultsite " befindet und in der folgenden Abbildung angezeigt wird.

Wenn Sie Code bereitgestellt haben und die Standard-App weiterhin angezeigt wird, lesen Sie " Problembehandlung" – Die App wird nicht angezeigt.

Screenshot des standardmäßigen App-Diensts auf der Linux-Webseite.

Anpassen des Startbefehls

Sie können das Startverhalten des Containers steuern, indem Sie entweder einen benutzerdefinierten Startbefehl oder mehrere Befehle in einer Startbefehlsdatei bereitstellen. Eine Startbefehlsdatei kann einen beliebigen Namen haben, den Sie wählen, z. B. startup.sh, startup.cmd, startup.txt usw.

Für alle Befehle müssen relative Pfade zum Stammordner des Projekts verwendet werden.

Geben Sie einen Startbefehl oder eine Befehlsdatei wie folgt an:

  • Azure-Portal: Wählen Sie die Konfigurationsseite der App und dann " Allgemeine Einstellungen" aus. Platzieren Sie im Feld "Startbefehl " entweder den vollständigen Text des Startbefehls oder den Namen der Startbefehlsdatei. Wählen Sie dann "Speichern" aus, um die Änderungen anzuwenden. Weitere Informationen finden Sie unter Konfigurieren allgemeiner Einstellungen für Linux-Container.

  • Azure CLI: Verwenden Sie den Befehl "az webapp config set" mit dem --startup-file Parameter, um den Startbefehl oder die Datei festzulegen:

    az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

    Ersetzen Sie <custom-command> entweder durch den vollständigen Text Ihres Startbefehls oder durch den Namen Ihrer Startbefehlsdatei.

App Service ignoriert alle Fehler, die beim Verarbeiten eines benutzerdefinierten Startbefehls oder einer Befehlsdatei auftreten, und setzt den Startprozess dann fort, indem nach Django- und Flask-Apps gesucht wird. Falls das erwartete Verhalten nicht eintritt, sollten Sie überprüfen, ob Ihr Startbefehl bzw. die Datei fehlerfrei ist und ob zusammen mit Ihrem App-Code eine Startbefehlsdatei für App Service bereitgestellt wird. Sie können auch die Diagnoseprotokolle auf weitere Informationen überprüfen. Überprüfen Sie auch die Seite " Diagnostizieren und Lösen von Problemen " der App im Azure-Portal.

Beispiele für Startbefehle

  • Gunicorn-Argumente hinzugefügt: Im folgenden Beispiel wird das --workers=4 Argument zu einer Gunicorn-Befehlszeile zum Starten einer Django-App hinzugefügt:

    # <module-path> is the relative path to the folder that contains the module
# that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    Weitere Informationen finden Sie unter Running Gunicorn. Wenn Sie Autoskalierungsregeln verwenden, um Ihre Web-App hoch- und herunterzuskalieren, sollten Sie auch die Anzahl der Gunicorn-Worker dynamisch mithilfe der Umgebungsvariablen NUM_CORES in Ihrem Startbefehl festlegen, z. B.: --workers $((($NUM_CORES*2)+1)). Weitere Informationen zum Festlegen der empfohlenen Anzahl von Gunicorn-Mitarbeitern finden Sie in den Häufig gestellten Fragen zu Gunicorn.

  • Aktivieren Sie die Produktionsprotokollierung für Django: Fügen Sie die Argumente --access-logfile '-' und --error-logfile '-' der Befehlszeile hinzu.

    # '-' for the log files means stdout for --access-logfile and stderr for --error-logfile.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'

    Diese Protokolle werden im App Service-Protokolldatenstrom angezeigt.

    Weitere Informationen finden Sie unter Gunicorn-Protokollierung.

  • Benutzerdefiniertes Flask-Hauptmodul: Standardmäßig geht App Service davon aus, dass das Hauptmodul einer Flask-App application.py oder app.py ist. Falls für Ihr Hauptmodul ein anderer Name verwendet wird, müssen Sie den Startbefehl anpassen. Wenn Sie beispielsweise über eine Flask-App verfügen, deren Hauptmodul hello.py ist und das Flask-App-Objekt in dieser Datei benannt myappist, lautet der Befehl wie folgt:

    gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp

    Wenn Ihr Hauptmodul in einem Unterordner, z. B. website enthalten ist, können Sie diesen Ordner mit dem Argument --chdir angeben:

    gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp

  • Verwenden Sie einen Nicht-Gunicorn-Server: Um einen anderen Webserver wie aiohttp zu verwenden, verwenden Sie den entsprechenden Befehl als Startbefehl oder in der Startbefehlsdatei:

    python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func

Zugreifen auf App-Einstellungen als Umgebungsvariablen

App-Einstellungen sind Werte, die speziell für Ihre App in der Cloud gespeichert sind, wie unter Konfigurieren von App-Einstellungen beschrieben. Diese Einstellungen stehen Ihrem App-Code als Umgebungsvariablen zur Verfügung und können mithilfe des standardmäßigen os.environ-Musters darauf zugegriffen werden.

Wenn Sie beispielsweise eine App-Einstellung mit dem Namen DATABASE_SERVER erstellt haben, wird der Wert dieser Einstellung mit dem folgenden Code abgerufen:

db_server = os.environ['DATABASE_SERVER']

Erkennen einer HTTPS-Sitzung

In App Service erfolgt die TLS/SSL-Beendigung bei den Netzwerklastenausgleichsmodulen, sodass alle HTTPS-Anforderungen Ihre App als unverschlüsselte HTTP-Anforderungen erreichen. Wenn Ihre App-Logik überprüfen muss, ob Benutzeranforderungen verschlüsselt sind, können Sie dazu den Header X-Forwarded-Proto untersuchen.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

Gängige Webframeworks ermöglichen den Zugriff auf die Information X-Forwarded-* in Ihrem App-Standardmuster. In Django können Sie beispielsweise die SECURE_PROXY_SSL_HEADER verwenden, um Django anweisen, die X-Forwarded-Proto Kopfzeile zu verwenden.

Zugreifen auf Diagnoseprotokolle

Sie können auf die Konsolenprotokolle zugreifen, die aus dem Container generiert werden.

Führen Sie den folgenden Befehl aus, um die Containerprotokollierung zu aktivieren:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Ersetzen von <app-name> und <resource-group-name> durch Namen, die für Ihre Web-App geeignet sind.

Nachdem Sie die Containerprotokollierung aktiviert haben, führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Wenn Konsolenprotokolle nicht sofort angezeigt werden, überprüfen Sie es in 30 Sekunden erneut.

Wenn Sie das Protokollstreaming jederzeit beenden möchten, wählen Sie STRG+C aus.

Um über das Azure-Portal auf Protokolle zuzugreifen, wählen Sie denÜberwachungsprotokolldatenstrom> im linken Menü für Ihre App aus.

Zugriff auf Bereitstellungsprotokolle

Wenn Sie Ihren Code bereitstellen, führt App Service den weiter oben im Abschnitt "Anpassen der Buildautomatisierung" beschriebenen Buildprozess aus. Da der Build in seinem eigenen Container ausgeführt wird, werden Buildprotokolle getrennt von den Diagnoseprotokollen der App gespeichert.

Führen Sie die folgenden Schritte aus, um auf die Bereitstellungsprotokolle zuzugreifen:

  1. Wählen Sie im Azure-Portal für Ihre Web-App im linken Menü das Bereitstellungscenter>Bereitstellungscenter aus.
  2. Wählen Sie auf der Registerkarte "Protokolle " die Commit-ID für den letzten Commit aus.
  3. Wählen Sie auf der daraufhin angezeigten Seite " Protokolldetails " den Link " Protokolle anzeigen " aus, der neben "Ausführen des Oryx-Builds..." angezeigt wird.

Buildprobleme wie falsche Abhängigkeiten in requirements.txt und Fehler in Skripts vor oder nach dem Build werden in diesen Protokollen angezeigt. Fehler werden auch angezeigt, wenn Ihre Anforderungsdatei nicht requirements.txt benannt ist oder nicht im Stammordner Ihres Projekts angezeigt wird.

Öffnen einer SSH-Sitzung im Browser

Um eine direkte SSH-Sitzung mit Ihrem Container zu öffnen, sollte Ihre App ausgeführt werden.

Verwenden Sie den Befehl az webapp ssh .

Wenn Sie noch nicht authentifiziert sind, müssen Sie sich mit Ihrem Azure-Abonnement für die Verbindung authentifizieren. Nach der Authentifizierung wird im Browser eine Shell angezeigt, über die Sie Befehle innerhalb Ihres Containers ausführen können.

SSH-Verbindung

Hinweis

Alle Änderungen, die Sie außerhalb des /home Verzeichnisses vornehmen, werden im Container selbst gespeichert und bleiben nicht über einen App-Neustart hinaus bestehen.

Informationen zum Öffnen einer Remote-SSH-Sitzung von Ihrem lokalen Computer finden Sie unter Öffnen einer SSH-Sitzung über die Remoteshell.

Wenn Sie erfolgreich eine Verbindung mit der SSH-Sitzung hergestellt haben, sollte am unteren Rand des Fensters die Meldung „SSH-VERBINDUNG HERGESTELLT“ angezeigt werden. Wenn Fehler wie „SSH_CONNECTION_CLOSED“ angezeigt werden, oder eine Meldung, dass der Container neu gestartet wird, verhindert möglicherweise ein Fehler das Starten des App-Containers. Informationen zur Problembehandlung finden Sie in den Schritten zur Untersuchung möglicher Probleme.

URL-Umschreibungen

Bei der Bereitstellung von Python-Anwendungen in Azure App Service für Linux müssen Sie möglicherweise URL-Umschreibungen innerhalb Ihrer Anwendung behandeln. Dies ist besonders hilfreich, um sicherzustellen, dass bestimmte URL-Muster an die richtigen Endpunkte umgeleitet werden, ohne sich auf externe Webserverkonfigurationen zu verlassen. Für Flask-Anwendungen können URL-Prozessoren und benutzerdefinierte Middleware verwendet werden, um dies zu erreichen. In Django-Anwendungen ermöglicht der robuste URL-Verteiler eine effiziente Verwaltung von URL-Umschreibungen.

Problembehandlung

Im Allgemeinen besteht der erste Schritt bei der Problembehandlung in der Verwendung der App Service-Diagnose:

  1. Wählen Sie im Azure-Portal für Ihre Web-App im linken Menü "Diagnostizieren und Lösen von Problemen " aus.
  2. Wählen Sie Verfügbarkeit und Leistung aus.
  3. Überprüfen Sie die Informationen in den Optionen "Anwendungsprotokolle", "Containerabsturz" und "Containerprobleme ", in denen die häufigsten Probleme angezeigt werden.

Überprüfen Sie als Nächstes sowohl die Bereitstellungsprotokolle als auch die App-Protokolle auf Fehlermeldungen. Diese Protokolle identifizieren häufig bestimmte Probleme, die die App-Bereitstellung oder den App-Start verhindern können. Beispielsweise kann der Build fehlschlagen, wenn ihre requirements.txt Datei den falschen Dateinamen aufweist oder nicht im Projektstammordner vorhanden ist.

Die folgenden Abschnitte bieten Anleitungen zu spezifischen Problemen.

App wird nicht angezeigt

  • Die Standard-App wird angezeigt, nachdem Sie Ihren eigenen App-Code bereitgestellt haben. Die Standard-App wird angezeigt, da Sie entweder ihren App-Code nicht für App Service bereitgestellt haben, oder der App-Dienst konnte den App-Code nicht finden und stattdessen die Standard-App ausführen.

    • Starten Sie App Service neu, warten Sie 15 bis 20 Sekunden, und prüfen Sie die App dann erneut.

    • Verwenden Sie SSH , um eine direkte Verbindung mit dem App Service-Container herzustellen und zu überprüfen, ob Ihre Dateien unter "site/wwwroot" vorhanden sind. Wenn Ihre Dateien nicht vorhanden sind, führen Sie die folgenden Schritte aus:

      1. Erstellen Sie eine App-Einstellung namens SCM_DO_BUILD_DURING_DEPLOYMENT mit dem Wert 1, stellen Sie Ihren Code erneut bereit, warten Sie ein paar Minuten, und versuchen Sie dann noch mal, auf die App zuzugreifen. Weitere Informationen zum Erstellen von App-Einstellungen finden Sie unter Konfigurieren einer App Service-App im Azure-Portal.
      2. Überprüfen Sie Ihren Bereitstellungsprozess, überprüfen Sie die Bereitstellungsprotokolle, korrigieren Sie alle Fehler, und stellen Sie die App erneut zur Bereitstellung.

    • Wenn Ihre Dateien vorhanden sind, konnte App Service Ihre spezifische Startdatei nicht identifizieren. Überprüfen Sie, ob Ihre App wie erwartet für Django oder Flask strukturiert ist, oder verwenden Sie einen benutzerdefinierten Startbefehl.

  • Die Meldung "Dienst nicht verfügbar" wird im Browser angezeigt. Der Browser hat ein Timeout auf eine Antwort von App Service gewartet, was angibt, dass der App-Dienst den Gunicorn-Server gestartet hat, die App selbst jedoch nicht gestartet wurde. Diese Bedingung könnte darauf hindeuten, dass die Gunicorn-Argumente falsch sind oder dass ein Fehler im App-Code vorliegt.

    • Aktualisieren Sie den Browser, insbesondere, wenn Sie in Ihrem App Service-Plan die niedrigsten Tarife nutzen. Die App kann länger brauchen, um zu starten, wenn Sie z. B. die Free-Tarife verwenden, und sie reagiert erst wieder, nachdem Sie den Browser aktualisiert haben.

    • Überprüfen Sie, ob Ihre App wie erwartet für Django oder Flask strukturiert ist, oder verwenden Sie einen benutzerdefinierten Startbefehl.

    • Überprüfen Sie den App-Protokolldatenstrom auf Fehlermeldungen. In den Protokollen werden alle Fehler im App-Code angezeigt.

„setup.py“ oder „requirements.txt“ wurde nicht gefunden

  • Der Protokolldatenstrom zeigt "Setup.py oder requirements.txtkonnte nicht gefunden werden; Keine Pip-Installation ausgeführt.": Der Oryx-Buildprozess konnte ihre requirements.txt Datei nicht finden.

    • Stellen Sie eine Verbindung mit dem Container der Web-App über SSH her, und stellen Sie sicher, dass requirements.txt richtig benannt ist und direkt unter "site/wwwroot" vorhanden ist. Wenn die Datei nicht vorhanden ist, stellen Sie sicher, dass sie in Ihrem Repository vorhanden und in Ihre Bereitstellung eingebunden ist. Verschieben Sie sie in den Stamm, wenn sie in einem separaten Ordner enthalten ist.

ModuleNotFoundError beim Starten der App

Wenn Ihnen eine Fehlermeldung wie ModuleNotFoundError: No module named 'example' angezeigt wird, konnte Python beim Starten der Anwendung mindestens eines Ihrer Module nicht finden. Dieser Fehler tritt am häufigsten auf, wenn Sie Ihre virtuelle Umgebung mit Ihrem Code bereitstellen. Virtuelle Umgebungen sind nicht portierbar. Daher sollten sie nicht mit dem Anwendungscode bereitgestellt werden. Lassen Sie stattdessen Oryx eine virtuelle Umgebung erstellen, und installieren Sie Ihre Pakete in der Web-App, indem Sie die App-Einstellung SCM_DO_BUILD_DURING_DEPLOYMENT erstellen und sie auf 1 festlegen. Durch diese Einstellung wird Oryx gezwungen, Ihre Pakete zu installieren, wann immer Sie eine Bereitstellung in App Service durchführen. Weitere Informationen finden Sie in diesem Artikel zur Portabilität virtueller Umgebungen.

Die Datenbank ist gesperrt.

Wenn Sie versuchen, Datenbankmigrationen mit einer Django-App auszuführen, wird möglicherweise Folgendes angezeigt: „sqlite3. OperationalError: Die Datenbank ist gesperrt. Der Fehler weist darauf hin, dass Ihre Anwendung eine SQLite-Datenbank verwendet, für die standardmäßig Django konfiguriert ist, statt eine Clouddatenbank wie z. B. Azure Database for PostgreSQL.

Überprüfen Sie die DATABASES Variable in der settings.py-Datei der App, um sicherzustellen, dass Ihre App eine Clouddatenbank anstelle von SQLite verwendet.

Wenn dieser Fehler mit dem Beispiel im Lernprogramm auftritt: Bereitstellen einer Django-Web-App mit PostgreSQL, überprüfen Sie, ob Sie die Schritte unter "Verbindungseinstellungen überprüfen" abgeschlossen haben.

Andere Probleme

  • Kennwörter werden nicht in der SSH-Sitzung angezeigt, wenn sie eingegeben werden: Aus Sicherheitsgründen hält die SSH-Sitzung Ihr Kennwort beim Eingeben ausgeblendet. Die Zeichen werden jedoch aufgezeichnet, also geben Sie Ihr Kennwort wie gewohnt ein, und wählen Sie die EINGABETASTE aus, wenn Sie fertig sind.

  • Befehle in der SSH-Sitzung scheinen abgeschnitten zu sein: Der Editor führt möglicherweise keinen Zeilenumbruch für Befehle durch, sie sollten aber trotzdem ordnungsgemäß ausgeführt werden.

  • Statische Objekte werden nicht in einer Django-App angezeigt: Stellen Sie sicher, dass Sie das WhiteNoise-Modul aktiviert haben.

  • Sie sehen die Meldung "Kritische SSL-Verbindung erforderlich": Überprüfen Sie die Benutzernamen und Kennwörter, die in der App zum Zugriff auf Ressourcen (z. B. Datenbanken) verwendet werden.

Zugehöriger Inhalt