Een Linux Python-app voor Azure App Service configureren

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 uitgevoerd pip install -r requirements.txt wanneer u een Git-opslagplaats implementeert of wanneer u een zip-pakket implementeert waarvoor buildautomatisering is ingeschakeld.

Dit artikel bevat belangrijke concepten en instructies voor Python-ontwikkelaars die gebruikmaken van een ingebouwde Linux-container in App Service. Als u App Service nog nooit hebt gebruikt, voltooit u eerst de Python-quickstart en Flask, Django of FastAPI met PostgreSQL.

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

• Azure Portal. Selecteer> in het linkerdeelvenster van de appinstellingen omgevingsvariabelen of Instellingenconfiguratie>, zoals beschreven in Een App Service-app configureren in Azure Portal.

• Azure CLI. U hebt twee opties.

  • Voer opdrachten uit in de Azure Cloud Shell.
  • Voer opdrachten lokaal uit door de nieuwste versie van de Azure CLI te installeren en u aan te melden bij Azure met behulp van az login.

De 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:

  • De huidige Python-versie weergeven met behulp van az webapp config show:

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

    Vervang en <resource-group-name> door <app-name> de namen die geschikt zijn voor uw web-app.

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

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

  • Alle Python-versies weergeven die worden ondersteund in App Service met behulp van az webapp list-runtimes:

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

U kunt een niet-ondersteunde versie van Python uitvoeren door uw eigen containerinstallatiekopieën te bouwen. Zie Een aangepaste Docker-installatiekopieën gebruiken voor meer informatie.

Wat gebeurt er met verouderde runtimes in App Service?

Verouderde runtimes worden afgeschaft door de onderhoudende organisatie of hebben aanzienlijke beveiligingsproblemen. Dienovereenkomstig worden ze verwijderd uit het maken en configureren van pagina's in de portal. Wanneer een verouderde runtime is verborgen in de portal, blijft elke app die die runtime gebruikt, nog steeds actief.

Als u een app wilt maken met een verouderde runtimeversie die niet meer wordt weergegeven in de portal, gebruikt u de Azure CLI, een ARM-sjabloon of Bicep. Met deze implementatiealternatieven kunt u afgeschafte runtimes maken die uit de portal worden verwijderd, maar die nog steeds worden ondersteund.

Als een runtime volledig is verwijderd uit het App Service-platform, ontvangt de eigenaar van uw Azure-abonnement een e-mailmelding voordat deze wordt verwijderd.

De automatisering van bouwbewerkingen aanpassen

Het App Service-buildsysteem, Oryx genoemd, 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 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 bestandrequirements.txt moet zich in de hoofdmap van het project bevinden. Als dat niet het is, meldt het buildproces de fout 'Kan setup.py of requirements.txtniet vinden; Pip-installatie wordt niet uitgevoerd.'

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

4. Voer een aangepast script na de build uit als die stap is opgegeven in 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 de uitvoering collectstatic wilt uitschakelen bij het bouwen van Django-apps, stelt u de DISABLE_COLLECTSTATIC instelling in op true.

• Wanneer u pre-build-opdrachten wilt uitvoeren, configureert u de PRE_BUILD_COMMAND instelling met een opdracht, zoals echo Pre-build command, of een pad naar een scriptbestand dat relatief is aan de hoofdmap van uw project, zoals scripts/prebuild.sh. Alle opdrachten moeten paden gebruiken die relatief zijn in de hoofdmap van het project.

• Om na de build opdrachten uit te voeren, stelt u de POST_BUILD_COMMAND instelling in om een opdracht te bevatten, zoals echo Post-build command, of een pad naar een scriptbestand, relatief aan de hoofdmap van uw project, zoals scripts/postbuild.sh. Alle opdrachten moeten paden gebruiken die relatief zijn ten opzichte van de hoofdmap van het project.

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

Zie access-implementatielogboeken voor informatie over het openen van 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.

Genereer requirements.txt uit pyproject.toml

Op dit moment biedt App Service geen rechtstreekse ondersteuning pyproject.tomlvoor . Als u hulpprogramma's zoals Poëzie of UV gebruikt, is de aanbevolen methode om een compatibel requirements.txt-bestand te genereren voordat deze in de hoofdmap van uw project wordt geïmplementeerd:

Poëzie gebruiken

Genereer requirements.txt met behulp van Poëzie met de exportinvoegtoepassing:

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

Uv gebruiken

Genereerrequirements.txt met behulp van uv:

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

Bestaande toepassingen migreren naar Azure

U kunt bestaande webtoepassingen als volgt opnieuw implementeren in Azure:

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

   • Uw requirements.txt-bestand moet zich in de hoofdmap van uw opslagplaats bevindt als u wilt dat App Service automatisch de benodigde pakketten installeert.

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 deze resources eenvoudig maken door de Azure CLI-opdracht az webapp upuit te voeren. U kunt ook resources maken en implementeren, zoals wordt weergegeven in de zelfstudie Flask, Django of FastAPI met PostgreSQL. Vervang de namen van de resourcegroep, het App Service-plan en de web-app door namen 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 als omgevingsvariabelen, zoals beschreven in Access-omgevingsvariabelen.

   • Databaseverbindingen worden bijvoorbeeld vaak beheerd via dergelijke instellingen, zoals wordt weergegeven in zelfstudie: Een Django-web-app implementeren met PostgreSQL - verbindingsinstellingen verifiëren.
   • Zie Productie-instellingen voor Django-apps voor specifieke instellingen voor typische Django-apps.

5. App opstarten. Lees het gedeelte Container opstarten verderop in dit artikel voor informatie over hoe App Service uw app probeert uit te voeren. App Service maakt standaard gebruik van de Gunicorn-webserver. Gunicorn moet uw app-object of wsgi.py map kunnen vinden. Als dat nodig is, kunt u de opstartopdracht aanpassen.

6. Continue implementatie. Stel continue implementatie vanuit GitHub Actions, Bitbucket of Azure-opslagplaatsen in 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 met behulp van SSH. Zie Zelfstudie: Een Django-web-app implementeren met PostgreSQL voor een voorbeeld van het uitvoeren van Django-databasemigraties.

   • Wanneer u continue implementatie gebruikt, kunt u deze acties uitvoeren met behulp van opdrachten na de build, zoals eerder beschreven in de sectie Build automation aanpassen .

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 App Service moeten Django-apps de richtlijnen volgen in de controlelijst voor implementatie van Django.

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.

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 deze instellen DJANGO_STATIC_URL/django-static/ om 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 STATICFILES_DIRS Django collectstatic 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 op zoals hier wordt weergegeven:

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

   In deze code FRONTEND_DIR wordt gebruikt om een pad te bouwen naar waar een build-hulpprogramma zoals Yarn wordt uitgevoerd. U kunt desgewenst opnieuw een omgevingsvariabele en app-instelling 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 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 de MIDDLEWARE 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 installatiekopieën in de versiespecifieke mappen.

Deze container heeft de volgende kenmerken:

• Apps worden uitgevoerd door de Gunicorn WSGI HTTP-server met 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ën alleen het Flask-webframework, maar de container ondersteunt andere frameworks die compatibel zijn met WSGI en compatibel zijn met Python 3.6 en hoger, 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 requirements.txt-bestand moet zich in de hoofdmap van het project of afhankelijkheden hebben, worden niet geïnstalleerd. Als dit bestand zich niet in de hoofdmap bevindt, meldt het buildproces de fout 'Kan setup.py of requirements.txtniet 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 die de URL van de web-app bevat, zoals msdocs-hello-world.azurewebsites.net. Het definieert WEBSITE_SITE_NAMEook , dat de naam van uw app bevat, 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 ervoor 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 naar een bestand met de naam wsgi.py in uw app-code en voert Gunicorn uit met behulp van 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 --access-logfile en --error-logfile parameters toe, zoals wordt weergegeven 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, die zich in de map opt/defaultsite bevindt en wordt weergegeven in de volgende afbeelding.

Als u code hebt geïmplementeerd en nog steeds de standaard-app ziet, 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. Een opstartopdrachtbestand kan elke gewenste naam gebruiken, zoals startup.sh, startup.cmd of startup.txt.

Alle opdrachten moeten paden gebruiken die relatief zijn ten opzichte van de hoofdmap van het project.

Een opstartopdracht of opdrachtbestand opgeven:

• Azure Portal. Selecteer Configuratie onder Instellingen in het linkerdeelvenster van de pagina van de app en selecteer vervolgens Algemene instellingen. Voer in het vak Opstartopdracht de volledige tekst van de opstartopdracht of de naam van het opstartopdrachtbestand in. 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 --startup-file parameter om de opstartopdracht of het bestand 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 bij het verwerken van een aangepaste opstartopdracht of -bestand en vervolgt vervolgens 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. En u kunt de pagina Problemen vaststellen en oplossen in Azure Portal controleren en oplossen.

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 that contains 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 gebruikt, moet u de opstartopdracht aanpassen. Als u bijvoorbeeld een Flask-app hebt waarvan de hoofdmodule is hello.py en het Flask-app-object in dat bestand de naam myapp heeft, is dit de opdracht:

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

  Als uw hoofdmodule zich in een submap bevindt, zoals website, geeft u die map op met het --chdir argument:

  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
  

Toegang tot app-instellingen via 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 toegankelijk via het standaard os.environ-patroon .

Als u bijvoorbeeld een app-instelling maakt 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. Als uw app-logica moet controleren of de gebruikersaanvragen zijn versleuteld, controleert u de X-Forwarded-Proto header:

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

Met populaire webframeworks kunt u toegang krijgen tot de X-Forwarded-* informatie in uw standaard-app-patroon. In Django kunt u bijvoorbeeld SECURE_PROXY_SSL_HEADER gebruiken om Django te configureren voor het gebruik van de X-Forwarded-Proto header.

Toegang tot diagnostische logboeken

U hebt toegang tot de consolelogboeken die worden gegenereerd vanuit de container.

Voer de volgende opdracht uit om containerlogboekregistratie in te schakelen:

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

Vervang <app-name> en <resource-group-name> door namen die geschikt zijn voor uw webapplicatie.

Nadat u containerlogboekregistratie hebt 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 consolelogboeken niet onmiddellijk worden weergegeven, controleert u het na 30 seconden opnieuw.

Om de logstroom op elk moment te stoppen, selecteer Ctrl+C.

Als u logboeken in Azure Portal wilt openen, selecteert u> in het linkerdeelvenster voor uw app.

Toegang tot implementatielogboeken

Wanneer u uw code implementeert, voert App Service het buildproces uit dat eerder is beschreven, in de sectie Buildautomatisering aanpassen . 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 implementatiecentrum> in het linkerdeelvenster op de azure-portalpagina voor uw web-app.
2. Selecteer op het tabblad Logboeken de doorvoer-id voor de meest recente doorvoer.
3. Selecteer op de pagina Met logboekdetails die wordt weergegeven de koppeling Logboeken weergeven die wordt weergegeven naast de build van Running oryx.

Buildproblemen, zoals onjuiste afhankelijkheden in requirements.txt en fouten in pre-build- of post-buildscripts, worden weergegeven in deze logboeken. 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 openen in een browser

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

Gebruik de opdracht az webapp ssh .

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

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 waarin wordt aangegeven dat de container opnieuw wordt opgestart, kan een fout verhinderen dat de app-container wordt gestart. Zie Probleemoplossing voor informatie over het onderzoeken van mogelijke problemen.

URL-aanpassingen

Bij het implementeren van Python-toepassingen in App Service voor Linux moet u mogelijk URL-herschrijven in uw toepassing afhandelen. Deze methode 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 kunt u URL-processors en aangepaste middleware gebruiken om dit te bereiken. In Django-toepassingen zorgt de URL-dispatcher voor efficiënt beheer van URL-herschrijven.

Probleemoplossingsproces

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

1. Selecteer op de azure-portalpagina voor uw web-app de optie Problemen vaststellen en oplossen in het linkerdeelvenster.
2. Selecteer Beschikbaarheid en prestaties.
3. Bekijk de informatie in 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 requirements.txt bestand 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 - de standaard-app wordt weergegeven
• De app wordt niet weergegeven - bericht 'Service niet beschikbaar'
• Kan setup.py of requirements.txt niet vinden
• ModuleNotFoundError bij het opstarten
• Database is geblokkeerd
• Wachtwoorden worden niet weergegeven in SSH-sessies wanneer deze worden getypt
• Opdrachten in de SSH-sessie lijken afgebroken te zijn
• Statische assets worden niet weergegeven in een Django-app
• Fataal: SSL-verbinding is vereist

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 uw app-code niet hebt geïmplementeerd in App Service of omdat App Service uw app-code niet kan vinden en de standaard-app heeft uitgevoerd.

  • Start de app opnieuw op, wacht 20 seconden en controleer de app opnieuw.

  • 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, voert u de volgende stappen uit:

    1. Maak een app-instelling met de naam SCM_DO_BUILD_DURING_DEPLOYMENT met de waarde , 1implementeer de code opnieuw, wacht enkele minuten en probeer de app opnieuw te openen. 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, kon App Service uw opstartbestand niet identificeren. Zorg ervoor dat uw app is gestructureerd zoals App Service 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. Dit geeft aan dat App Service de Gunicorn-server heeft gestart, maar dat de app zelf niet is gestart. Deze voorwaarde kan erop wijzen 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 uw app is gestructureerd zoals App Service verwacht voor Django of Flask, of gebruik een aangepaste opstartopdracht.

  • Bekijk de logboekstream van de app voor 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.txtniet 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 u een fout ziet 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 om 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 afgebroken: de editor ondersteunt mogelijk geen tekstomloop, 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

• Zelfstudie: Flask-app met PostgreSQL
• Zelfstudie: Django-app met PostgreSQL
• Zelfstudie: FastAPI-app met PostgreSQL
• Zelfstudie: Implementeren vanuit een privécontaineropslagplaats
• Veelgestelde vragen over App Service op Linux
• Naslaginformatie over omgevingsvariabelen en app-instellingen