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 Bereitstellungsmodul des App Service aktiviert automatisch eine virtuelle Umgebung und installiert Abhängigkeiten aus einer requirements.txt, pyproject.toml oder setup.py Datei, wenn Sie ein Git-Repository oder ein ZIP-Paketmit aktivierter Buildautomatisierung bereitstellen.

Dieser Artikel enthält wichtige Konzepte und Anleitungen für Python-Entwickler, die in App Service einen integrierten Linux-Container verwenden. Falls Sie App Service noch nicht verwendet haben, ist es ratsam, zunächst den Python-Schnellstart und ein Tutorial für Flask, Django oder FastAPI mit PostgreSQL durchzuarbeiten.

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

  • Azure-Portal. Wählen Sie im linken Bereich der App Einstellungen>Umgebungsvariablen oder Einstellungen>Konfiguration aus, wie unter Konfigurieren einer App Service-App im Azure-Portal beschrieben.

  • Azure-Befehlszeilenschnittstelle. Sie haben zwei Möglichkeiten.

    • Führen Sie Befehle in der Azure Cloud Shell aus.
    • Führen Sie Befehle lokal aus, indem Sie die aktuelle Version der Azure CLI installieren und sich dann mit dem Befehl 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-Image.

Konfigurieren der Python-Version

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

  • Azure CLI:

    • Zeigen Sie die aktuelle Python-Version mithilfe von az webapp config show an:

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

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

    • Legen Sie die Python-Version mithilfe von az webapp config set fest:

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

    • Zeigen Sie alle in Azure App Service unterstützten Python-Versionen mithilfe von az webapp list-runtimes an:

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

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

Was geschieht mit veralteten Laufzeiten in App Service?

Veraltete Laufzeiten sind von der Aufrechterhaltungsorganisation veraltet oder weisen erhebliche Sicherheitsrisiken auf. 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, eine ARM-Vorlage oder Bicep. Mit diesen Bereitstellungsalternativen können Sie veraltete Laufzeiten erstellen, die aus dem Portal entfernt werden, 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 Buildautomatisierung bereitgestellt werden, werden Inhalte unter und aus /tmp/<uid> und nicht unter /home/site/wwwroot bereitgestellt. Sie können mithilfe der Umgebungsvariable APP_PATH auf dieses Inhaltsverzeichnis zugreifen. Aus Persistenzgründen sollten Sie alle zusätzlichen Dateien, die zur Laufzeit erstellt wurden, an einen Speicherort unter /home oder mithilfe von Bring Your Own Storage schreiben. Weitere Informationen zu diesem Verhalten finden Sie unter Python-Buildänderungen.

Mit dem Buildsystem von App Service (Bezeichnung: Oryx) werden beim Bereitstellen die folgenden Schritte ausgeführt, 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. Installieren Sie Abhängigkeiten. Das Buildsystem überprüft die folgenden Dateien im Projektstamm:

    • requirements.txt: Führt pip install -r requirements.txt aus.
    • pyproject.toml mit uv.lock: Verwendet uv.
    • pyproject.toml mit poetry.lock: Verwendet poetry.
    • pyproject.toml: Verwendet poetry.
    • setup.py: Führt pip install . aus.

    Hinweis

    Wenn pyproject.toml vorhanden ist, aber uv.lock fehlt, verwendet der App-Dienst standardmäßig Poesie, auch wenn "poetry.lock " ebenfalls fehlt. Um uv zu verwenden, müssen Sie uv.lock in Ihre Bereitstellung einbeziehen.

    Wenn keine dieser Dateien gefunden wird, meldet der Buildprozess den Fehler "Setup.py oder requirements.txtkonnte nicht gefunden werden; Es wird keine Pip-Installation ausgeführt."

  3. Wenn manage.py im Stammverzeichnis des Repositorys gefunden wird (was auf eine Django-App hinweist), 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 Postbuildskript aus, sofern dies 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 Pfade verwendet werden, die zum Stammordner des Projekts relativ sind.

  • 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 Pfade verwendet werden, die zum Stammordner des Projekts relativ sind.

Informationen zu anderen Einstellungen zum Anpassen der Buildautomatisierung finden Sie unter Oryx-Konfiguration.

Informationen zum Zugreifen auf die Build- und Bereitstellungsprotokolle finden Sie unter Zugriff auf Bereitstellungsprotokolle.

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").

Migrieren von vorhandenen Anwendungen zu Azure

Sie können vorhandene Webanwendungen in Azure wie folgt erneut bereitstellen:

  1. Quellrepository: Verwalten Sie Ihren Quellcode in einem geeigneten Repository wie GitHub, damit Sie zu einem späteren Zeitpunkt dieses Prozesses Continuous Deployment einrichten können.

    • Ihre Abhängigkeitsdatei (z. B. requirements.txt, pyproject.toml oder setup.py) muss sich im Stammverzeichnis Ihres Repositorys befinden, wenn Der App-Dienst die erforderlichen Pakete automatisch installieren soll.

  2. Datenbank: Falls Ihre App von einer Datenbank abhängig ist, müssen die erforderlichen Ressourcen auch in Azure erstellt werden.

  3. App Service-Ressourcen: Erstellen Sie eine Ressourcengruppe, einen App Service-Plan und eine App Service-Web-App zum Hosten Ihrer Anwendung. Sie können diese Ressourcen einfach erstellen, indem Sie den Azure CLI-Befehl az webapp upausführen. Sie können Ressourcen auch wie im Tutorial für 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 geeignet sind.

  4. Umgebungsvariablen Falls für Ihre Anwendung Umgebungsvariablen benötigt werden, müssen Sie entsprechende App Service-Anwendungseinstellungen erstellen. Diese App Service-Einstellungen werden ihrem Code als Umgebungsvariablen angezeigt, wie in Access-Umgebungsvariablen beschrieben.

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

  6. Kontinuierliche Bereitstellung: Richten Sie Continuous Deployment über GitHub Actions, Bitbucket oder Azure Repos ein, wie im Artikel Continuous Deployment in Azure App Service beschrieben. Oder richten Sie Continuous Deployment über lokales Git ein, wie im Artikel Lokale Git-Bereitstellung in Azure App Service beschrieben.

  7. Benutzerdefinierte Aktionen: Zum Durchführen von Aktionen in dem App Service-Container, der Ihre App hostet, z. B. Django-Datenbankmigrationen, können Sie eine Verbindung mit dem Container per SSH herstellen. Ein Beispiel für die Ausführung von Django-Datenbankmigrationen finden Sie unter Tutorial: Bereitstellen einer Django-Web-App mit PostgreSQL in Azure.

    • Bei Verwendung von Continuous Deployment können Sie diese Aktionen mit Postbuildbefehlen durchführen, wie weiter oben im Abschnitt Anpassen der Buildautomatisierung 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 App Service sollten Django-Apps dem Leitfaden in der Bereitstellungsprüfliste 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 dies unter Zugreifen auf App-Einstellungen als Umgebungsvariablen beschrieben ist. 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 mithilfe des Codes 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 diese Werte (vor allem den Benutzernamen und das Kennwort) als Key Vault-Geheimnisse 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 den Ordner build/static mit statischen Dateien generiert, fügen Sie diesen Ordner wie folgt ein:

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

    FRONTEND_DIR wird in diesem Code 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 die Dateien aus dem Ordner bereit, der mit der Django-Variablen STATIC_ROOT angegeben wurde.

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

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Ändern Sie 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, befolgen Sie zunächst die Anleitung in der Flask-Dokumentation zum Thema Verwalten von statischen Dateien. 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 die Imagekonfigurationen in den versionsspezifischen Verzeichnissen.

Dieser Container verfügt über die folgenden Eigenschaften:

  • Apps werden vom Gunicorn WSGI-HTTP-Server mit den zusätzlichen Argumenten --bind=0.0.0.0 --timeout 600 ausgefü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 unter Bereitstellen 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 und höher kompatibel sind, z. B. Django.

  • Um andere Pakete wie Django zu installieren, erstellen Sie eine requirements.txt, pyproject.toml oder setup.py 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 Abhängigkeitsdatei muss sich im Projektstammverzeichnis befinden, sonst werden die Abhängigkeiten nicht installiert. Befindet sich diese Datei nicht im Projektstamm, 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, überprüfen Sie den Speicherort Ihrer Anforderungsdatei.

  • App Service definiert automatisch eine Umgebungsvariable mit dem Namen WEBSITE_HOSTNAME, die die URL der Web-App enthält, z. B. msdocs-hello-world.azurewebsites.net. Außerdem wird das WEBSITE_SITE_NAME-Element definiert, das den Namen Ihrer App enthält, z. B. msdocs-hello-world.

  • npm und Node.js werden 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 einer Datei namens 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.

Fügen Sie zum Aktivieren der Produktionsprotokollierung die Parameter --access-logfile und --error-logfile so hinzu, wie dies in den Beispielen für benutzerdefinierte Startbefehle veranschaulicht wird.

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 App Service keinen benutzerdefinierten Befehl und keine Django-App oder Flask-App findet, wird eine schreibgeschützte Standard-App ausgeführt, die sich im Ordner opt/defaultsite befindet (siehe folgende Abbildung).

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. Für eine Datei mit Startbefehlen können Sie einen beliebigen Namen wählen, z. B. startup.sh, startup.cmd oder startup.txt.

Für alle Befehle müssen Pfade verwendet werden, die zum Stammordner des Projekts relativ sind.

Geben Sie einen Startbefehl oder eine Befehlsdatei wie folgt an:

  • Azure-Portal. Wählen Sie unter Einstellungen im linken Bereich der App-Seite Konfiguration und dann Allgemeine Einstellungen aus. Geben Sie im Feld Startbefehl entweder den vollständigen Text Ihres Startbefehls oder den Namen Ihrer Startbefehlsdatei an. Wählen Sie dann "Speichern" aus, um die Änderungen anzuwenden. Weitere Informationen finden Sie unter Konfigurieren allgemeiner Einstellungen für Linux-Container.

  • Azure-Befehlszeilenschnittstelle. Verwenden Sie den Befehl az webapp config set mit dem Parameter --startup-file, um den Startbefehl bzw. 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 Startdatei 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. Außerdem können Sie die Seite Diagnose und Problembehandlung der App im Azure-Portal überprüfen.

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 that contains 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. Beispiel: --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 lautet, und das Flask-App-Objekt in dieser Datei den Namen myapp hat, 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, geben Sie diesen Ordner mit dem Argument --chdir an:

    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 in der Cloud speziell für Ihre App gespeichert werden, wie unter Konfigurieren von App-Einstellungen beschrieben. Diese Einstellungen sind für Ihren App-Code als Umgebungsvariablen verfügbar, und der Zugriff darauf erfolgt mit dem Standardmuster os.environ.

Wenn Sie beispielsweise eine App-Einstellung mit dem Namen DATABASE_SERVER erstellen, 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, überprüfen Sie dazu den X-Forwarded-Proto-Header:

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 SECURE_PROXY_SSL_HEADER verwenden, um Django so zu konfigurieren, dass der X-Forwarded-Proto-Header verwendet wird.

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 Sie den <app-name>-Wert und den <resource-group-name>-Wert 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, verwenden Sie die Tastenkombination STRG+C.

Um auf Protokolle im Azure-Portal zuzugreifen, wählen Sie im linken Bereich für Ihre App Überwachung>Protokolldatenstrom aus.

Zugriff auf Bereitstellungsprotokolle

Wenn Sie Ihren Code bereitstellen, führt App Service den Buildprozess aus, der weiter oben im Abschnitt Anpassen der Buildautomatisierung beschrieben wird. 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 auf der Seite für Ihre Web-App im linken Bereich Bereitstellung>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 angezeigten Seite Protokolldetails den Link Protokolle anzeigen aus, der neben Oryx-Build wird ausgeführt angezeigt wird.

Buildprobleme, z. B. falsche Abhängigkeiten in Ihrer Abhängigkeitsdatei und Fehler in Vorabbuild- oder Postbuildskripts, werden in diesen Protokollen angezeigt. Fehler werden auch angezeigt, wenn ihre Abhängigkeitsdatei nicht im Stammordner Des Projekts gefunden wird.

Öffnen einer SSH-Sitzung in einem Browser

Wenn Sie eine direkte SSH-Sitzung mit Ihrem Container öffnen möchten, sollte Ihre App ausgeführt werden.

Verwenden Sie den Befehl az webapp ssh .

Wenn Sie nicht authentifiziert sind, müssen Sie sich mit Ihrem Azure-Abonnement authentifizieren, um eine Verbindung herzustellen. Wenn Sie authentifiziert sind, wird eine In-Browser-Shell angezeigt, in der Sie Befehle in Ihrem Container 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 angezeigt wird, dass der Container neu gestartet wird, verhindert möglicherweise ein Fehler das Starten des App-Containers. Informationen zum Untersuchen möglicher Probleme finden Sie unter Problembehandlung.

URL-Umschreibungen

Bei der Bereitstellung von Python-Anwendungen in App Service für Linux müssen Sie möglicherweise URL-Umschreibungen innerhalb Ihrer Anwendung behandeln. Diese Methode 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 Sie URL-Prozessoren und benutzerdefinierte Middleware verwenden, um dies zu erreichen. In Django-Anwendungen ermöglicht der URL-Dispatcher 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 auf der Seite für Ihre Web-App im linken Bereich Probleme diagnostizieren und beheben aus.
  2. Wählen Sie Verfügbarkeit und Leistung aus.
  3. Überprüfen Sie die Informationen unter Anwendungsprotokolle, Containerabsturzund Containerprobleme daraufhin, wo 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. Der Build kann z. B. fehlschlagen, wenn Ihre Abhängigkeitsdatei nicht im Projekt-Root-Verzeichnis 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 in App Service bereitgestellt haben oder App Service Ihren App-Code nicht finden konnte und stattdessen die Standard-App ausgeführt hat.

    • Starten Sie die App neu, warten Sie 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 Startdatei nicht identifizieren. Stellen Sie sicher, dass Ihre App so strukturiert ist, wie App Service dies für Django oder Flask erwartet, oder verwenden Sie einen benutzerdefinierten Startbefehl.

  • Die Meldung „Dienst nicht verfügbar“ wird im Browser angezeigt. Timeout des Browsers beim Warten auf eine Antwort von App Service. Dies weist darauf hin, dass App Service 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. Das Starten der App kann länger dauern, wenn Sie z. B. Free-Tarife verwenden, und sie reagiert erst wieder, nachdem Sie den Browser aktualisiert haben.

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

    • Untersuchen 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; Es wird keine Pip-Installation ausgeführt." Der Oryx-Buildprozess konnte ihre requirements.txt, pyproject.toml oder setup.py Datei nicht finden.

    • Stellen Sie eine Verbindung mit dem Container der Web-App über SSH her, und stellen Sie sicher, dass Ihre Abhängigkeitsdatei 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 eine Fehlermeldung wie ModuleNotFoundError: No module named 'example' angezeigt wird, konnte Python beim Starten der Anwendung mindestens eins 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 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, geben Sie also Ihr Kennwort wie gewohnt ein, und wählen Sie zum Abschluss die EINGABETASTE aus.

  • 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 in einer Django-App nicht angezeigt: Stellen Sie sicher, dass Sie das WhiteNoise-Modul aktiviert haben.

  • Die Meldung „Schwerwiegende SSL-Verbindung ist erforderlich“ wird angezeigt: Überprüfen Sie alle Benutzernamen und Kennwörter, die für den Zugriff auf Ressourcen (z. B. Datenbanken) innerhalb der App verwendet werden.

Zugehöriger Inhalt

  • Last updated on