Een Linux Python-app voor Azure App Service configureren

  • Artikel

In dit artikel wordt beschreven hoe Python-apps worden uitgevoerd in Azure App Service, hoe bestaande apps kunt migreren naar Azure en hoe u het gedrag van Azure App Service zo nodig kunt aanpassen. Python-apps moet worden geïmplementeerd met alle vereiste pip-modules.

De App Service-implementatie-engine activeert automatisch een virtuele omgeving en wordt voor u uitgevoerd pip install -r requirements.txt wanneer u een Git-opslagplaats of een zip-pakket implementeert waarvoor buildautomatisering is ingeschakeld.

In deze handleiding vindt u belangrijke concepten en instructies voor Python-ontwikkelaars die een ingebouwde Linux-container in App Service gebruiken. Als u Azure App Service nog nooit hebt gebruikt, moet u eerst de Python-quickstart en de zelfstudie Python met PostgreSQL volgen.

U kunt de Azure-portal of de Azure CLI gebruiken voor het configureren:

Notitie

Linux is de enige besturingssysteemoptie voor het uitvoeren van Python-apps in App Service. Python op Windows wordt niet meer ondersteund. U kunt echter uw eigen aangepaste Windows-containerinstallatiekopieën maken en deze uitvoeren in App Service. Voor meer informatie raadpleegt u Een aangepaste Docker-installatiekopie gebruiken.

Python-versie configureren

  • Azure-portal: gebruik het tabblad Algemene instellingen op de pagina Configuratie, zoals wordt beschreven in Algemene instellingen configureren voor Linux-containers.

  • Azure CLI:

    • Geef de huidige Python-versie weer met az webapp config show:

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

      Vervang <resource-group-name> en <app-name> door de namen die van toepassing zijn op uw web-app.

    • Stel de Python-versie in met az webapp config set

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

    • Geef alle Python-versies die worden ondersteund in Azure App Service weer met az webapp list-runtimes:

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

U kunt een niet-ondersteunde versie van Python uitvoeren door in plaats daarvan uw eigen containerinstallatiekopie te bouwen. Voor meer informatie raadpleegt u Een aangepaste Docker-installatiekopie gebruiken.

De automatisering van bouwbewerkingen aanpassen

het buildsysteem van App Service, Genaamd Oryx, voert de volgende stappen uit wanneer u uw app implementeert als de app-instelling SCM_DO_BUILD_DURING_DEPLOYMENT is ingesteld op 1:

  1. Voer een aangepast pre-buildscript uit als dit wordt opgegeven via de instelling PRE_BUILD_COMMAND. (Het script kan zelf andere Python- en Node.js-scripts, pip- en npm-opdrachten en op knooppunten gebaseerde hulpprogramma's uitvoeren, zoals yarn, yarn install bijvoorbeeld en yarn build.)

  2. Voer pip install -r requirements.txt uit. Het bestand requirements.txt moet aanwezig zijn in de hoofdmap van het project. Anders wordt de volgende fout gerapporteerd door het buildproces: Kan setup.py of requirements.txt niet vinden; PIP-installatie wordt niet uitgevoerd.

  3. Als manage.py wordt aangetroffen in de hoofdmap van de opslagplaats (wat aangeeft dat het een Django-app is), voert u manage.py collectstatic uit. Als de instelling DISABLE_COLLECTSTATIC echter true is, wordt deze stap overgeslagen.

  4. Voer een aangepast post-buildscript uit als dit wordt opgegeven via de instelling POST_BUILD_COMMAND. (Het script kan ook andere Python- en Node.js-scripts, pip- en npm-opdrachten en op knooppunten gebaseerde hulpprogramma's uitvoeren.)

De instellingen PRE_BUILD_COMMAND, POST_BUILD_COMMAND en DISABLE_COLLECTSTATIC zijn standaard leeg.

  • Als u het uitvoeren van collectstatic wilt uitschakelen bij het bouwen van Django-apps, stelt u de DISABLE_COLLECTSTATIC instelling in op true.

  • Als u pre-buildopdrachten wilt uitvoeren, moet de instelling PRE_BUILD_COMMAND een opdracht, zoals echo Pre-build command, of een pad naar een scriptbestand ten opzichte van de hoofdmap van het project, zoals scripts/prebuild.sh, bevatten. In alle opdrachten moeten relatieve paden naar de hoofdmap van het project worden gebruikt.

  • Als u post-buildopdrachten wilt uitvoeren, moet de instelling POST_BUILD_COMMAND een opdracht, zoals echo Post-build command, of een pad naar een scriptbestand ten opzichte van de hoofdmap van het project, zoals scripts/postbuild.sh, bevatten. In alle opdrachten moeten relatieve paden naar de hoofdmap van het project worden gebruikt.

Zie Oryx-configuratie voor andere instellingen voor het aanpassen van buildautomatisering.

Zie Toegang tot implementatielogboeken voor toegang tot de build- en implementatielogboeken.

Zie hoe Python-apps worden gedetecteerd en gebouwd met Oryx voor meer informatie over de manier waarop Python-apps door App Service worden uitgevoerd en gebouwd in Linux.

Notitie

De instellingen PRE_BUILD_SCRIPT_PATH en POST_BUILD_SCRIPT_PATH zijn gelijk aan PRE_BUILD_COMMAND en POST_BUILD_COMMAND, en worden ondersteund voor oudere versies.

Als een instelling met de naam SCM_DO_BUILD_DURING_DEPLOYMENTtrue of 1 bevat, wordt een Oryx-build geactiveerd tijdens de implementatie. De instelling is true (waar) wanneer u implementeert met behulp van Git, de Azure CLI-opdracht az webapp up en Visual Studio code.

Notitie

Gebruik altijd relatieve paden in alle pre- en post-buildscripts, omdat de buildcontainer waarin Oryx wordt uitgevoerd, een andere container is dan de runtimecontainer waarin de app wordt uitgevoerd. Vertrouw er nooit op dat de app-projectmap exact binnen de container wordt geplaatst (bijvoorbeeld onder site/wwwroot).

Bestaande toepassingen migreren naar Azure

Bestaande webtoepassingen kunnen als volgt opnieuw worden geïmplementeerd in Azure:

  1. Bronopslagplaats: Onderhoud uw broncode in een geschikte opslagplaats zoals GitHub, zodat u later in dit proces doorlopende implementatie kunt instellen.

    • Het bestand requirements.txt moet zich in de hoofdmap van uw opslagplaats voor App Service bevinden, zodat de benodigde pakketten automatisch kunnen worden geïnstalleerd.

  2. Database: als uw app afhankelijk is van een database, maakt u ook de benodigde resources in Azure.

  3. App Service-resources: Maak een resourcegroep, een App Service-plan en een App Service-web-app om uw toepassing te hosten. U kunt dit eenvoudig doen door de Azure CLI-opdracht az webapp upuit te voeren. U kunt ook resources maken en implementeren zoals weergegeven in Zelfstudie: Een Python-web-app (Django of Flask) implementeren met PostgreSQL. Vervang de namen van de resourcegroep, het App Service plan en de web-app in waarden die geschikt zijn voor uw toepassing.

  4. Omgevingsvariabelen: Als voor uw toepassing omgevingsvariabelen zijn vereist, maakt u gelijkwaardige App Service-toepassingsinstellingen. Deze App Service-instellingen worden weergegeven in uw code als omgevingsvariabelen, zoals wordt beschreven in Omgevingsvariabelen voor toegang.

  5. App-opstartproces: Raadpleeg de sectie Opstartproces met container verderop in dit artikel voor meer informatie over hoe App Service probeert om uw app uit te voeren. App Service maakt standaard gebruik van de Gunicorn-webserver, die de map met uw app-object of wsgi.py moet kunnen vinden. U kunt zo nodig de opstartopdracht aanpassen.

  6. Continue implementatie: stel continue implementatie in vanuit GitHub Actions, Bitbucket of Azure-opslagplaatsen, zoals beschreven in het artikel Continue implementatie naar Azure App Service. U kunt ook continue implementatie vanuit lokale Git instellen, zoals beschreven in het artikel Lokale Git-implementatie naar Azure App Service.

  7. Aangepaste acties: Als u acties wilt uitvoeren in de App Service-container die als host fungeert voor uw app, zoals Django-databasemigraties, kunt u verbinding maken met de container via SSH. Zie Zelfstudie: Een Django-web-app implementeren met PostgreSQL - databaseschema genereren voor een voorbeeld van het uitvoeren van Django-databasemigraties.

Als deze stappen zijn voltooid, kunt u wijzigingen in uw bronopslagplaats doorvoeren en deze updates automatisch implementeren in App Service.

Productie-instellingen voor Django-apps

Voor een productie omgeving, zoals Azure App Service, moeten Django-apps voldoen aan de controlelijst voor implementatie van Django (djangoproject.com).

In de volgende tabel vindt u een beschrijving van de relevante productie-instellingen voor Azure. Deze instellingen worden gedefinieerd in het bestand setting.py van de app.

Django-instelling Instructies voor Azure
SECRET_KEY Sla de waarde op in een App Service-instelling, zoals wordt beschreven op App-instellingen openen als omgevingsvariabelen. U kunt de waarde ook opslaan als een 'geheim' in Azure Key Vault.
DEBUG Maak een DEBUG-instelling op App Service met de waarde 0 (false) en laad de waarde als een omgevingsvariabele. Maak in uw ontwikkelomgeving een DEBUG-omgevingsvariabele met de waarde 1 (niet waar).
ALLOWED_HOSTS In een productieomgeving is voor Django vereist dat u de URL van de app opneemt in de ALLOWED_HOSTS-matrix van settings.py. U kunt deze URL tijdens runtime ophalen met de code, os.environ['WEBSITE_HOSTNAME']. App Service stelt de omgevingsvariabele WEBSITE_HOSTNAME automatisch in op de URL van de app.
DATABASES Definieer instellingen in App Service voor de databaseverbinding en laad deze als omgevingsvariabelen om de woordenlijst DATABASES in te vullen. U kunt de waarden (met name de gebruikersnaam en het wachtwoord) ook opslaan als Azure Key Vault-geheimen.

Statische bestanden serveren voor Django-apps

Als uw Django-web-app statische front-endbestanden bevat, volgt u eerst de instructies in Statische bestanden beheren in de Django-documentatie.

Voor App Service voert u vervolgens de volgende wijzigingen aan:

  1. Overweeg omgevingsvariabelen (voor lokale ontwikkeling) en App-instellingen (bij implementatie in de cloud) te gebruiken om de Django STATIC_URL en STATIC_ROOT variabelen dynamisch in te stellen. Bijvoorbeeld:

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

    DJANGO_STATIC_URL en DJANGO_STATIC_ROOT kunnen indien nodig worden gewijzigd voor uw lokale en cloudomgevingen. Als het buildproces voor uw statische bestanden ze bijvoorbeeld in een map met de naam django-staticplaatst, kunt u instellen DJANGO_STATIC_URL op /django-static/ om het gebruik van de standaardwaarde te voorkomen.

  2. Als u een pre-buildscript hebt waarmee statische bestanden in een andere map worden gegenereerd, neemt u die map op in de Django-variabele STATICFILES_DIRS , zodat het proces van collectstatic Django ze vindt. Als u bijvoorbeeld uitvoert yarn build in uw front-endmap en yarn een build/static map genereert met statische bestanden, neemt u die map als volgt op:

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

    Hier, FRONTEND_DIR, om een pad te bouwen naar waar een build-hulpprogramma zoals yarn wordt uitgevoerd. U kunt opnieuw een omgevingsvariabele en app-instelling naar wens gebruiken.

  3. Voeg toe whitenoise aan uw requirements.txt-bestand . Whitenoise (whitenoise.evans.io) is een Python-pakket waarmee een Django-productie-app eenvoudig zijn eigen statische bestanden kan leveren. Whitenoise dient specifiek voor de bestanden die zijn gevonden in de map die is opgegeven door de Django-variabele STATIC_ROOT .

  4. Voeg in uw settings.py-bestand de volgende regel toe voor Whitenoise:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Wijzig ook de MIDDLEWARE lijsten en INSTALLED_APPS zodat Whitenoise wordt opgenomen:

    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
]

Statische bestanden leveren voor Flask-apps

Als uw Flask-web-app statische front-endbestanden bevat, volgt u eerst de instructies voor het beheren van statische bestanden in de Flask-documentatie. Voor een voorbeeld van het leveren van statische bestanden in een Flask-toepassing raadpleegt u de snelstart voorbeeld flask-toepassing op GitHub.

Als u statische bestanden rechtstreeks vanuit een route in uw toepassing wilt verwerken, kunt u de send_from_directory methode gebruiken:

from flask import send_from_directory

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

Containerkenmerken

Python-apps die zijn geïmplementeerd in App Service worden uitgevoerd binnen een Docker-container voor Linux die is gedefinieerd in de GitHub-opslagplaats voor App Service Python. U vindt de afbeeldingsconfiguraties binnen de versiespecifieke mappen.

Deze container heeft de volgende kenmerken:

  • Apps worden uitgevoerd met behulp van de Gunicorn WSGI HTTP-server, met behulp van de extra argumenten --bind=0.0.0.0 --timeout 600.

    • U kunt configuratie-instellingen voor Gunicorn opgeven door de opstartopdracht aan te passen.

    • Als u uw web-app wilt beveiligen tegen onbedoelde of opzettelijke DDOS-aanvallen, wordt Gunicorn uitgevoerd achter een omgekeerde Nginx-proxy, zoals beschreven in Deploy Gunicorn (Gunicorn implementeren, docs.gunicorn.org).

  • Standaard bevat de basiscontainerinstallatiekopie alleen het Flask-webframework, maar de container ondersteunt andere frameworks die voldoen aan WSGI en compatibel zijn met Python 3.6+, zoals Django.

  • Als u andere pakketten wilt installeren, zoals Django, maakt u een requirements.txt-bestand in de hoofdmap van uw project waarin uw directe afhankelijkheden worden opgegeven. App Service installeert die afhankelijkheden vervolgens automatisch wanneer u het project implementeert.

    Het bestand requirements.txtmoet zich in de hoofdmap van het project bevinden om de afhankelijkheden te installeren. Anders meldt het buildproces de fout: 'Kan setup.py of requirements.txt niet vinden; Pip-installatie wordt niet uitgevoerd.' Als deze fout optreedt, controleert u de locatie van het vereistenbestand.

  • App Service definieert automatisch een omgevingsvariabele met de naam WEBSITE_HOSTNAME met de URL van de web-app, bijvoorbeeld msdocs-hello-world.azurewebsites.net. App Service definieert ook WEBSITE_SITE_NAME met de naam van uw app, zoals msdocs-hello-world.

  • npm en Node.js worden geïnstalleerd in de container, zodat u op knooppunten gebaseerde buildhulpprogramma's, zoals yarn, kunt uitvoeren.

Opstartproces met container

Tijdens het opstarten voert de App Service met Linux-container de volgende stappen uit:

  1. Gebruik een aangepaste opstartopdracht als deze er is.
  2. Controleer of er een Django-app bestaat en start Gunicorn voor deze app als de app is gedetecteerd.
  3. Controleer of er een Flask-app bestaat en start Gunicorn voor deze app als de app is gedetecteerd.
  4. Als er geen andere app wordt gevonden, start u een standaard-app die is ingebouwd in de container.

De volgende secties bevatten extra details voor elke optie.

Django-app

Voor Django-apps zoekt App Service in uw app-code naar een bestand met de naam wsgi.py. Daarna wordt Gunicorn uitgevoerd met de volgende opdracht:

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

Als u specifiekere controle wilt over de opstartopdracht, gebruikt u een aangepaste opstartopdracht, vervangt u door <module> de naam van de map die wsgi.py bevat en voegt u een --chdir argument toe als die module zich niet in de hoofdmap van het project bevindt. Als wsgi.py zich bijvoorbeeld bevindt onder knboard/backend/config in de hoofdmap van het project, gebruikt u de argumenten --chdir knboard/backend config.wsgi.

Als u productielogboekregistratie wilt inschakelen, voegt u de parameters --access-logfile en --error-logfile toe, zoals wordt weer gegeven in de voorbeelden voor aangepaste opstartopdrachten.

Flask-app

Voor Flask zoekt App Service naar een bestand met de naam application.py of app.py en wordt Gunicorn als volgt gestart:

# 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

Als de hoofd-app-module zich in een ander bestand bevindt, gebruikt u een andere naam voor het app-object of als u andere argumenten wilt opgeven voor Gunicorn, gebruikt u een aangepaste opstartopdracht.

Standaardgedrag

Als de App Service geen aangepaste opdracht, Django-app of Flask-app vindt, wordt er een standaard alleen-lezen-app uitgevoerd. Deze bevindt zich in de map opt/defaultsite en wordt in de volgende afbeelding weergegeven.

Als u code hebt geïmplementeerd en nog steeds de standaard-app ziet, raadpleegt u Probleemoplossing: de app wordt niet weergegeven.

Schermopname van de standaard App Service op Linux webpagina.

Als u een geïmplementeerde app verwacht te zien in plaats van de standaard-app, raadpleegt u Probleemoplossing: de app wordt niet weergegeven.

Opstartopdracht aanpassen

U kunt het opstartgedrag van de container beheren door een aangepaste opstartopdracht of meerdere opdrachten in een opstartopdrachtbestand op te geven. U kunt elke gewenste naam voor het opstartopdrachtbestand gebruiken, zoals startup.sh, startup.cmd, startup.txt, enzovoort.

In alle opdrachten moeten relatieve paden naar de hoofdmap van het project worden gebruikt.

Een opstartopdracht of opdrachtbestand opgeven:

  • Azure-portal: selecteer de configuratiepagina van de app en selecteer vervolgens Algemene instellingen. Geef de volledige tekst van de opstartopdracht of de naam van uw opstartopdrachtbestand op in het veld Opstartopdracht. Selecteer vervolgens Opslaan om de wijzigingen toe te passen. Zie Algemene instellingen configureren voor Linux-containers.

  • Azure CLI: gebruik de opdracht az webapp config set met de parameter --startup-file om de opstartopdracht of het opstartbestand in te stellen:

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

    Vervang <custom-command> door de volledige tekst van de opstartopdracht of de naam van uw opstartopdrachtbestand.

App Service negeert eventuele fouten die optreden tijdens de verwerking van een aangepaste opstartopdracht of opstartopdrachtbestand, en vervolgt het opstartproces door te zoeken naar Django- en Flask-apps. Als u het verwachte gedrag niet ziet, controleert u of uw opstartopdracht of -bestand foutloos is en of er een opstartopdrachtbestand is geïmplementeerd in App Service samen met uw app-code. U kunt ook de diagnostische logboeken controleren voor meer informatie. Controleer ook de pagina Problemen vaststellen en oplossen van de app in de Azure-portal.

Voorbeelden van opstartopdrachten

  • Gunicorn argumenten toegevoegd: In het volgende voorbeeld wordt --workers=4 toegevoegd aan een Gunicorn-opdrachtregel voor het starten van een Django-app:

    # <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

    Zie voor meer informatie Running Gunicorn (Gunicorn uitvoeren, docs.gunicorn.org). Als u regels voor automatisch schalen gebruikt om uw web-app omhoog en omlaag te schalen, moet u ook het aantal gunicorn-werkrollen dynamisch instellen met behulp van de NUM_CORES omgevingsvariabele in uw opstartopdracht, bijvoorbeeld: --workers $((($NUM_CORES*2)+1)). Zie de Veelgestelde vragen over Gunicorn voor meer informatie over het instellen van het aanbevolen aantal gunicorn-werknemers

  • Productielogboekregistratie inschakelen voor Django: Voeg de argumenten --access-logfile '-' en --error-logfile '-' toe aan de opdrachtregel:

    # '-' 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 '-'

    Deze logboeken worden weergegeven in de App Service-logboekstroom.

    Zie Gunicorn logging (Gunicorn-logboekregistratie, docs.gunicorn.org).

  • Aangepaste Flask-hoofdmodule: standaard wordt in App Service ervan uitgegaan dat de hoofdmodule van een Flask-app application.py of app.py is. Als uw hoofdmodule een andere naam heeft, moet u de opstartopdracht aanpassen. Als u bijvoorbeeld een Flask-app hebt waarvan hello.py de belangrijkste module is, en het Flask-app-object in dit bestand heet myapp, ziet de opdracht er als volgt uit:

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

    Als de belangrijkste module zich in een submap bevindt, zoals website, geeft u deze map op met het argument --chdir:

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

  • Een niet-Gunicorn-server gebruiken: Als u een andere webserver wilt gebruiken, zoals aiohttp, gebruikt u de juiste opdracht als opstartopdracht of in het opstartopdrachtbestand:

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

App-instellingen openen als omgevingsvariabelen

App-instellingen zijn waarden die specifiek voor uw app in de cloud zijn opgeslagen, zoals wordt beschreven in App-instellingen configureren. Deze instellingen zijn beschikbaar voor uw app-code als omgevingsvariabelen en worden geopend met behulp van het standaardpatroon os.environ.

Als u bijvoorbeeld een app-instelling met de naam DATABASE_SERVER hebt gemaakt, wordt de waarde van die instelling opgehaald met de volgende code:

db_server = os.environ['DATABASE_SERVER']

HTTPS-sessie detecteren

In App Service vindt TLS/SSL-beëindiging (wikipedia.org) plaats bij de netwerktaakverdelers, zodat alle HTTPS-aanvragen uw app bereiken als niet-versleutelde HTTP-aanvragen. Inspecteer de header X-Forwarded-Proto als de app-logica moet controleren of de aanvragen van gebruikers al dan niet zijn versleuteld.

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

Populaire webframeworks bieden toegang tot de X-Forwarded-*-informatie in het patroon van de standaard-app. In Django kunt u bijvoorbeeld de SECURE_PROXY_SSL_HEADER gebruiken om Django te laten weten dat de X-Forwarded-Proto header moet worden gebruikt.

Toegang tot diagnostische logboeken

U hebt vanuit de container toegang tot de consolelogboeken.

Schakel eerst logboekregistratie voor containers in door de volgende opdracht uit te voeren:

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

Vervang <app-name> en <resource-group-name> door de namen die van toepassing zijn op uw web-app.

Zodra logboekregistratie is ingeschakeld, voert u de volgende opdracht uit om de logboekstream te zien:

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

Als u de consolelogboeken niet meteen ziet, probeert u het opnieuw na 30 seconden.

U kunt op elk gewenst moment stoppen met logboekstreaming door Ctrl+C te typen.

U kunt ook de logboekbestanden in een browser inspecteren op https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Als u logboeken wilt openen via de Azure-portal, selecteert u Bewaking>Logboekstream in het menu aan de linkerkant van uw app.

Toegang tot implementatielogboeken

Wanneer u uw code implementeert, voert App Service het buildproces uit dat eerder in de sectie Automatisering van de build aanpassen is beschreven. Omdat de build in een eigen container wordt uitgevoerd, worden buildlogboeken afzonderlijk van de diagnostische logboeken van de app opgeslagen.

Gebruik de volgende stappen om toegang te krijgen tot de implementatielogboeken:

  1. Selecteer in het Azure Portal voor uw web-appImplementatie-implementatiecentrum> in het menu links.
  2. Selecteer op het tabblad Logboeken de doorvoer-id voor de meest recente doorvoer.
  3. Op de weergegeven pagina Logboekdetails selecteert u de koppeling Logboeken weergeven... die naast 'Oryx-build uitvoeren...' wordt weergegeven.

Buildproblemen zoals onjuiste afhankelijkheden in requirements.txt en fouten in scripts van vóór of na de build-compilatie worden in deze logboeken weergegeven. Er worden ook fouten weergegeven als uw vereistenbestand niet precies de naamrequirements.txt heeft of niet wordt weergegeven in de hoofdmap van uw project.

SSH-sessie in de browser openen

Als u een directe SSH-sessie opent met uw container, moet uw app worden uitgevoerd.

Plak de volgende URL in uw browser en vervang <app-name> door de naam van uw app:

https://<app-name>.scm.azurewebsites.net/webssh/host

Als u nog niet bent geverifieerd moet u zich verifiëren met uw Azure-abonnement om verbinding te maken. Nadat u bent geverifieerd, ziet u een shell in de browser waarin u opdrachten binnen uw container kunt uitvoeren.

SSH-verbinding

Notitie

Wijzigingen die u buiten de map /home aanbrengt, worden in de container zelf opgeslagen en blijven niet behouden na het opnieuw opstarten van de app.

Als u een externe SSH-sessie wilt openen vanaf uw lokale machine, raadpleegt u SSH-sessie openen vanaf een externe shell.

Wanneer u verbinding hebt gemaakt met de SSH-sessie, ziet u het bericht 'SSH CONNECTION ESTABLISHED' onderaan het venster. Als er fouten worden weergegeven zoals 'SSH_CONNECTION_CLOSED' of een bericht dat de container opnieuw wordt gestart, kan een dergelijke fout voorkomen dat de app-container wordt gestart. Zie Probleemoplossing voor stappen om mogelijke problemen te onderzoeken.

Problemen oplossen

In het algemeen is de eerste stap bij probleemoplossing het gebruik van diagnostische gegevens van App Service:

  1. Selecteer in het Azure Portal voor uw web-app problemen vaststellen en oplossen in het linkermenu.
  2. Selecteer Beschikbaarheid en prestaties.
  3. Bekijk de informatie in de opties Toepassingslogboeken, Containercrash en Containerproblemen , waar de meest voorkomende problemen worden weergegeven.

Controleer vervolgens de Implementatielogboeken en de app-logboeken op eventuele foutberichten. In deze logboeken worden vaak specifieke problemen vastgesteld die de implementatie of het starten van apps kunnen voorkomen. De build kan bijvoorbeeld mislukken als uw bestand requirement.txt de verkeerde bestandsnaam heeft of niet aanwezig is in de hoofdmap van het project.

De volgende secties bieden richtlijnen voor specifieke problemen.

De app wordt niet weergegeven

  • U ziet de standaard-app nadat de code van uw eigen app is toegepast. De standaard-app wordt weergegeven omdat u de code van uw app niet hebt toegepast op App Service, of omdat App Service uw app-code niet heeft kunnen vinden en daarom de standaard-app heeft uitgevoerd.

    • Start de App Service opnieuw op en wacht 15-20 seconden voordat u de app opnieuw controleert.

    • Gebruik SSH om rechtstreeks verbinding te maken met de App Service-container en controleer of uw bestanden in site/wwwroot staan. Als uw bestanden niet bestaan, gebruikt u de volgende stappen:

      1. Maak een app-instelling met de naam SCM_DO_BUILD_DURING_DEPLOYMENT met de waarde 1, implementeer uw code opnieuw, wacht enkele minuten en probeer vervolgens opnieuw toegang te krijgen tot de app. Zie Een App Service-app configureren in Azure Portal voor meer informatie over het maken van app-instellingen.
      2. Controleer uw implementatieproces, controleer de implementatielogboeken, corrigeer eventuele fouten en implementeer de app opnieuw.

    • Als uw bestanden bestaan, heeft App Service uw specifieke opstartbestand niet kunnen identificeren. Controleer of de app is gestructureerd zoals App Service dat verwacht voor Django of Flask, of gebruik een aangepaste opstartopdracht.

  • U ziet het bericht 'Service niet beschikbaar' in de browser. Er is een time-out opgetreden in de browser voor het wachten op een reactie van App Service, wat aangeeft dat App Service de Gunicorn-server heeft gestart, maar dat de app zelf niet is gestart. Dit probleem kan erop duiden dat de Gunicorn-argumenten onjuist zijn of dat er een fout is opgetreden in de app-code.

    • Vernieuw de browser, met name als u gebruikmaakt van de laagste prijscategorieën in uw App Service-plan. Het is bijvoorbeeld mogelijk dat het opstarten van de app langer duurt wanneer gebruik wordt gemaakt van de gratis prijscategorie en reageert na het vernieuwen van de browser.

    • Controleer of de app is gestructureerd zoals App Service dat verwacht voor Django of Flask, of gebruik een aangepaste opstartopdracht.

    • Controleer de logboekstream van de app op eventuele foutberichten. In de logboeken worden eventuele fouten in de app-code weergegeven.

Kan setup.py of requirements.txt niet vinden

  • De logboekstream bevat 'Kan setup.py of requirements.txt niet vinden; PIP-installatie wordt niet uitgevoerd.' : Het bestand requirements.txt is niet gevonden door het Oryx-bouwproces.

    • Maak verbinding met de container van de web-app via SSH en controleer of de naam requirements.txt correct is en zich direct onder site/wwwroot bevindt. Als dat niet het geval is, moet u ervoor zorgen dat het bestand in uw opslagplaats staat en deel uitmaakt van uw implementatie. Als het zich in een afzonderlijke map bevindt, verplaatst u het naar de hoofdmap.

ModuleNotFoundError wanneer de app wordt gestart

Als u een fout ziet zoals ModuleNotFoundError: No module named 'example', kan Python een of meer modules niet vinden toen de toepassing werd gestart. Deze fout treedt meestal op als u uw virtuele omgeving implementeert met uw code. Virtuele omgevingen zijn niet overdraagbaar, dus een virtuele omgeving mag niet worden geïmplementeerd met uw toepassingscode. Laat Oryx in plaats daarvan een virtuele omgeving maken en uw pakketten in de web-app installeren door een app-instelling te maken, SCM_DO_BUILD_DURING_DEPLOYMENT, en deze in te stellen op 1. Deze instelling dwingt Oryx af om uw pakketten te installeren wanneer u implementeert op App Service. Zie dit artikel over de draagbaarheid van virtuele omgevingen voor meer informatie.

Database is vergrendeld

Wanneer u probeert databasemigraties uit te voeren met een Django-app, ziet u mogelijk 'sqlite3. OperationalError: database is vergrendeld.' De fout geeft aan dat uw toepassing gebruikmaakt van een SQLite-database waarvoor Django standaard is geconfigureerd in plaats van een clouddatabase zoals PostgreSQL voor Azure.

Controleer de DATABASES variabele in het settings.py-bestand van de app om ervoor te zorgen dat uw app een clouddatabase gebruikt in plaats van SQLite.

Als u deze fout krijgt met het voorbeeld in Zelfstudie: Een Django-web-app implementeren met PostgreSQL, controleert u of u de stappen in Verbindingsinstellingen verifiëren hebt voltooid.

Overige problemen

  • Wachtwoorden worden niet weergegeven in de SSH-sessie wanneer deze wordt getypt: om veiligheidsredenen houdt de SSH-sessie uw wachtwoord verborgen wanneer u typt. De tekens worden echter vastgelegd, dus typ uw wachtwoord zoals gebruikelijk en druk op Enter wanneer u klaar bent.

  • Opdrachten in de SSH-sessie worden afgekapt weergegeven: De editor mag geen opdrachten met regelafbreking bevatten, maar ze moeten wel goed worden uitgevoerd.

  • Statische assets worden niet weergegeven in een Django-app: Zorg ervoor dat u de whitenoise-module hebt ingeschakeld

  • U ziet het bericht 'Fatal: SSL connection is required' : Controleer alle gebruikersnamen en wachtwoorden die worden gebruikt voor toegang tot bronnen (zoals databases) vanuit de app.

Meer bronnen