Delen via

Een Linux Python-app voor Azure App Service configureren

  • Artikel

In dit artikel wordt beschreven hoe Azure-app Service Python-apps uitvoert, hoe u bestaande apps naar Azure kunt migreren en hoe u het gedrag van App Service kunt aanpassen wanneer dat nodig is. 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 implementeert of wanneer u 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 in Windows wordt niet meer ondersteund. U kunt echter uw eigen aangepaste Windows-containerinstallatiekopieën bouwen en 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 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, Oryx genaamd, voert de volgende stappen uit wanneer u uw app implementeert, als de app-instelling SCM_DO_BUILD_DURING_DEPLOYMENT is ingesteld 1op:

  1. Voer een aangepast pre-buildscript uit als deze stap is opgegeven door de PRE_BUILD_COMMAND instelling. (Het script kan zelf andere Python- en Node.js-scripts, pip- en NPM-opdrachten uitvoeren, en hulpprogramma's op basis van Node, 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 rapporteert het buildproces de fout: '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 script na de build uit als deze stap is opgegeven door de POST_BUILD_COMMAND instelling. (Opnieuw kan het script andere Python- en Node.js-scripts, pip- en npm-opdrachten en hulpprogramma's op basis van Node 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-build-opdrachten wilt uitvoeren, stelt u de PRE_BUILD_COMMAND instelling in op 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. In alle opdrachten moeten relatieve paden naar de hoofdmap van het project worden gebruikt.

  • Als u opdrachten na de build wilt uitvoeren, stelt u de POST_BUILD_COMMAND instelling in op 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. 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.

Een instelling met de naam SCM_DO_BUILD_DURING_DEPLOYMENT, als deze een Oryx-build bevat of 1activeert true die tijdens de implementatie plaatsvindt. De instelling is true wanneer u implementeert met behulp van Git, de Azure CLI-opdracht az webapp upen 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, waarmee u later in dit proces continue 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 wordt 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 zodat deze geschikter zijn voor uw toepassing.

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

  5. App opstarten: bekijk het gedeelte Container opstarten verderop in dit artikel om te begrijpen hoe App Service probeert 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. Als dat nodig is, kunt u de opstartopdracht aanpassen.

  6. Continue implementatie: continue implementatie vanuit GitHub Actions, Bitbucket of Azure-opslagplaatsen instellen zoals beschreven in het artikel Continue implementatie naar Azure-app Service. Of stel continue implementatie vanuit Lokale Git in 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 productieomgeving zoals Azure-app Service moeten Django-apps de controlelijst voor implementatie van Django volgen.

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 productie vereist Django 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 leveren voor Django-apps

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

Voor App Service voert u vervolgens de volgende wijzigingen aan:

  1. Overweeg het gebruik van omgevingsvariabelen (voor lokale ontwikkeling) en app-instellingen (bij implementatie in de cloud) om de Django STATIC_URL en STATIC_ROOT variabelen dynamisch in te stellen. Voorbeeld:

    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 kan indien nodig worden gewijzigd voor uw lokale en cloudomgevingen. Als het buildproces voor uw statische bestanden deze bijvoorbeeld in een map met de naam django-staticplaatst, kunt u instellen DJANGO_STATIC_URL om /django-static/ te voorkomen dat de standaardinstelling wordt gebruikt.

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

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

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

  3. Voeg dit toe whitenoise aan het requirements.txt-bestand . WhiteNoise (whitenoise.evans.io) is een Python-pakket dat het eenvoudig maakt voor een Django-productie-app om zijn eigen statische bestanden te bedienen. WhiteNoise dient specifiek die 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 lijsten om WhiteNoise op te nemen:

    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. Zie de Flask-voorbeeldtoepassing op GitHub voor een voorbeeld van het leveren van statische bestanden in een Flask-toepassing.

Als u statische bestanden rechtstreeks vanuit een route in uw toepassing wilt leveren, 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.

    • Om uw web-app te beschermen tegen onbedoelde of opzettelijke DDOS-aanvallen, wordt Gunicorn uitgevoerd achter een omgekeerde Nginx-proxy, zoals beschreven in Deploying Gunicorn.

  • 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, zoals Django, wilt installeren, maakt u een requirements.txt-bestand in de hoofdmap van uw project waarmee uw directe afhankelijkheden worden opgegeven. App Service installeert die afhankelijkheden vervolgens automatisch wanneer u het project implementeert.

    Het bestand requirements.txt moet zich in de hoofdmap van het project bevinden om de afhankelijkheden te installeren. Anders rapporteert 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 uw 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 buildhulpprogramma's op basis van Node, 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 is opgegeven.
  2. Controleer of er een Django-app bestaat en start Gunicorn als er een is gedetecteerd.
  3. Controleer of er een Flask-app bestaat en start Gunicorn als er een 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 <module> u 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. 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 standaardwebpagina App Service op Linux.

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 de opstartopdracht of het 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 het --workers=4 argument 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 Running Gunicorn voor meer informatie. Als u regels voor automatisch schalen gebruikt om uw web-app omhoog en omlaag te schalen, moet u ook dynamisch het aantal Gunicorn-werkrollen 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.

  • Schakel productielogboekregistratie in voor Django: Voeg de --access-logfile '-' en --error-logfile '-' argumenten 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-logboekregistratie voor meer informatie.

  • Aangepaste Flask-hoofdmodule: Standaard wordt in App Service ervan uitgegaan dat de hoofdmodule van een Flask-app is application.py of app.py. 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

  • Gebruik een niet-Gunicorn-server: Als u een andere webserver wilt gebruiken, zoals aiohttp, gebruikt u de juiste opdracht als de 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 zijn opgeslagen in de cloud voor uw app, zoals 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 hebt gemaakt met de naam DATABASE_SERVER, haalt de volgende code de waarde van die instelling op:

db_server = os.environ['DATABASE_SERVER']

HTTPS-sessie detecteren

In App Service vindt TLS/SSL-beëindiging 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 vertellen de X-Forwarded-Proto header te gebruiken.

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 de Azure-portal voor uw web-app implementatiecentrum> in het menu links.
  2. Selecteer op het tabblad Logboeken de doorvoer-id voor de meest recente doorvoer.
  3. Selecteer op de pagina Logboekdetails die wordt weergegeven de koppeling Logboeken weergeven die wordt weergegeven naast 'Running oryx build...'.

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 de naam requirements.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 u fouten ziet zoals 'SSH_CONNECTION_CLOSED' of een bericht dat de container opnieuw wordt opgestart, kan een fout verhinderen dat de app-container wordt gestart. Zie Probleemoplossing voor stappen om mogelijke problemen te onderzoeken.

URL-herschrijven

Wanneer u Python-toepassingen implementeert in Azure-app Service voor Linux, moet u mogelijk URL-herschrijven in uw toepassing afhandelen. Dit is met name handig om ervoor te zorgen dat specifieke URL-patronen worden omgeleid naar de juiste eindpunten zonder te vertrouwen op externe webserverconfiguraties. Voor Flask-toepassingen kunnen URL-processors en aangepaste middleware worden gebruikt om dit te bereiken. In Django-toepassingen biedt de robuuste URL-dispatcher efficiënt beheer van URL-herschrijven.

Probleemoplossing

Over het algemeen is de eerste stap bij het oplossen van problemen het gebruik van Diagnostische gegevens van App Service:

  1. Selecteer in Azure Portal voor uw web-app problemen vaststellen en oplossen in het menu links.
  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 bevatten 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 die wacht op een reactie van App Service, wat aangeeft dat App Service de Gunicorn-server heeft gestart, maar 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 de laagste prijscategorieën in uw App Service-abonnement gebruikt. Het kan langer duren voordat de app wordt opgestart wanneer u bijvoorbeeld gratis lagen gebruikt en reageert nadat u de browser hebt vernieuwd.

    • 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 toont 'Kan setup.py of requirements.txt niet vinden; Pip-installatie wordt niet uitgevoerd.": het Oryx-buildproces kan uw requirements.txt-bestand niet vinden.

    • 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 het bestand niet bestaat, controleert u of het bestand in uw opslagplaats bestaat en is opgenomen in uw implementatie. Als het zich in een afzonderlijke map bevindt, verplaatst u het naar de hoofdmap.

ModuleNotFoundError wanneer de app wordt gestart

Als er een fout wordt weergegeven zoals ModuleNotFoundError: No module named 'example', kan Python een of meer van uw 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 draagbaar, 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 SCM_DO_BUILD_DURING_DEPLOYMENTte maken en in te stellen op 1. Met deze instelling wordt Oryx gedwongen uw pakketten te installeren wanneer u implementeert in 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 een SQLite-database gebruikt, waarvoor Django standaard is geconfigureerd, in plaats van een clouddatabase zoals Azure Database for PostgreSQL te gebruiken.

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 ze worden getypt: Om veiligheidsredenen blijft uw wachtwoord verborgen tijdens het typen door de SSH-sessie. De tekens worden echter vastgelegd, dus typ uw wachtwoord zoals gebruikelijk en selecteer Enter wanneer u klaar bent.

  • Opdrachten in de SSH-sessie lijken te worden afgekapt: de editor bevat mogelijk geen tekstterugloopopdrachten, maar ze moeten nog steeds correct 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 resources (zoals databases) vanuit de app.

Gerelateerde inhoud