Konfigurera en Linux Python-app för Azure App Service

Den här artikeln beskriver hur Azure App Service kör Python-appar, hur du kan migrera befintliga appar till Azure och hur du kan anpassa beteendet för App Service när det behövs. Python-appar måste distribueras med alla nödvändiga pip-moduler .

Den App Service distributionsmotorn aktiverar automatiskt en virtuell miljö och körs pip install -r requirements.txt åt dig när du distribuerar en Git-lagringsplats eller ett zip-paketmed byggautomatisering aktiverat.

Den här guiden innehåller viktiga begrepp och instruktioner för Python-utvecklare som använder en inbyggd Linux-container i App Service. Om du aldrig har använt Azure App Service följer du först python-snabbstarten och Python med PostgreSQL-självstudien.

Du kan använda antingen Azure Portal eller Azure CLI för konfiguration:

• Azure Portal använder du appensinställningskonfigurationssida> enligt beskrivningen i Konfigurera en App Service-app i Azure Portal.

• Azure CLI: du har två alternativ.

  • Kör kommandon i Azure Cloud Shell.
  • Kör kommandon lokalt genom att installera den senaste versionen av Azure CLI och logga sedan in på Azure med az login.

Konfigurera Python-version

• Azure Portal: Använd fliken Allmänna inställningar på sidan Konfiguration enligt beskrivningen i Konfigurera allmänna inställningar för Linux-containrar.

• Azure CLI:

  • Visa den aktuella Python-versionen med az webapp config show:

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

    Ersätt <resource-group-name> och <app-name> med de namn som är lämpliga för din webbapp.

  • Ange Python-versionen med az webapp config set

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

  • Visa alla Python-versioner som stöds i Azure App Service med az webapp list-runtimes:

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

Du kan köra en version av Python genom att skapa en egen containeravbildning i stället. Mer information finns i Använda anpassad Docker-avbildning.

Anpassa versionsautomatisering

App Service byggsystem, med namnet Oryx, utför följande steg när du distribuerar appen om appinställningen SCM_DO_BUILD_DURING_DEPLOYMENT är inställd på 1:

1. Kör ett anpassat förskapningsskript om det anges av inställningen PRE_BUILD_COMMAND . (Skriptet kan själv köra andra Python- och Node.js-skript, pip- och npm-kommandon och Node-baserade verktyg som yarn, yarn install till exempel och yarn build.)

2. Kör pip install -r requirements.txt. Den requirements.txt filen måste finnas i projektets rotmapp. Annars rapporterar byggprocessen felet: "Det gick inte att hitta setup.py eller requirements.txt. Kör inte pip install."

3. Om manage.py hittas i databasens rot (som anger en Django-app) kör du manage.py collectstatic. Men om inställningen DISABLE_COLLECTSTATIC är truehoppas det här steget över.

4. Kör anpassat skript efter bygget om det anges av inställningen POST_BUILD_COMMAND . (Återigen kan skriptet köra andra Python- och Node.js-skript, pip- och npm-kommandon och Node-baserade verktyg.)

Som standard PRE_BUILD_COMMANDär inställningarna , POST_BUILD_COMMANDoch DISABLE_COLLECTSTATIC tomma.

• Om du vill inaktivera körning av collectstatic när du skapar Django-appar anger du DISABLE_COLLECTSTATIC inställningen till true.

• Om du vill köra förhandsversionskommandon anger du PRE_BUILD_COMMAND att inställningen ska innehålla antingen ett kommando, till exempel echo Pre-build command, eller en sökväg till en skriptfil i förhållande till projektroten, till exempel scripts/prebuild.sh. Alla kommandon måste använda relativa sökvägar till projektrotmappen.

• Om du vill köra kommandon efter bygget POST_BUILD_COMMAND anger du att inställningen ska innehålla antingen ett kommando, till exempel echo Post-build command, eller en sökväg till en skriptfil i förhållande till projektroten, till exempel scripts/postbuild.sh. Alla kommandon måste använda relativa sökvägar till projektrotmappen.

Andra inställningar som anpassar versionsautomatisering finns i Oryx-konfiguration.

Information om hur du kommer åt bygg- och distributionsloggarna finns i Åtkomstdistributionsloggar.

Mer information om hur App Service kör och skapar Python-appar i Linux finns i Så identifierar och skapar Oryx Python-appar.

Migrera befintliga program till Azure

Befintliga webbprogram kan distribueras om till Azure på följande sätt:

1. Källlagringsplats: Behåll källkoden på en lämplig lagringsplats som GitHub, vilket gör att du kan konfigurera kontinuerlig distribution senare i den här processen.

   • Din requirements.txt-fil måste finnas i roten på lagringsplatsen för att App Service ska kunna installera nödvändiga paket automatiskt.

2. Databas: Om din app är beroende av en databas skapar du även nödvändiga resurser på Azure.

3. App service-resurser: Skapa en resursgrupp, App Service Plan och App Service webbapp som värd för ditt program. Du kan göra det enkelt genom att köra Azure CLI-kommandot az webapp up. Eller så kan du skapa och distribuera resurser enligt självstudie: Distribuera en Python-webbapp (Django eller Flask) med PostgreSQL. Ersätt namnen på resursgruppen, App Service Plan och webbappen för att vara mer lämplig för ditt program.

4. Miljövariabler: Om programmet kräver miljövariabler skapar du motsvarande App Service programinställningar. De här App Service inställningarna visas i koden som miljövariabler, enligt beskrivningen i Access-miljövariabler.

   • Databasanslutningar hanteras till exempel ofta via sådana inställningar, som du ser i Självstudie: Distribuera en Django-webbapp med PostgreSQL – verifiera anslutningsinställningar.
   • Se Produktionsinställningar för Django-appar för specifika inställningar för typiska Django-appar.

5. Appstart: Läs avsnittet Startprocess för containrar senare i den här artikeln för att förstå hur App Service försöker köra din app. App Service använder Gunicorn-webbservern som standard, som måste kunna hitta ditt appobjekt eller wsgi.py mapp. Om det behövs kan du anpassa startkommandot.

6. Kontinuerlig distribution: Konfigurera kontinuerlig distribution från GitHub Actions, Bitbucket eller Azure Repos enligt beskrivningen i artikeln Kontinuerlig distribution till Azure App Service. Eller konfigurera kontinuerlig distribution från lokal Git enligt beskrivningen i artikeln Lokal Git-distribution till Azure App Service.

7. Anpassade åtgärder: Om du vill utföra åtgärder i den App Service container som är värd för din app, till exempel Django-databasmigreringar, kan du ansluta till containern via SSH. Ett exempel på hur du kör Django-databasmigreringar finns i Självstudie: Distribuera en Django-webbapp med PostgreSQL – generera databasschema.

   • När du använder kontinuerlig distribution kan du utföra dessa åtgärder med hjälp av kommandon efter bygget enligt beskrivningen tidigare under Anpassa versionsautomatisering.

När de här stegen har slutförts bör du kunna checka in ändringar i källlagringsplatsen och få uppdateringarna automatiskt distribuerade till App Service.

Produktionsinställningar för Django-appar

För en produktionsmiljö som Azure App Service bör Django-appar följa Djangos checklista för distribution (djangoproject.com).

I följande tabell beskrivs de produktionsinställningar som är relevanta för Azure. De här inställningarna definieras i appens setting.py-fil .

Hantera statiska filer för Django-appar

Om django-webbappen innehåller statiska klientdelsfiler följer du först anvisningarna i Hantera statiska filer i Django-dokumentationen.

För App Service gör du sedan följande ändringar:

1. Överväg att använda miljövariabler (för lokal utveckling) och Appinställningar (när du distribuerar till molnet) för att dynamiskt ange Django STATIC_URL och STATIC_ROOT variabler. Exempel:

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

   DJANGO_STATIC_URL och DJANGO_STATIC_ROOT kan ändras efter behov för dina lokala miljöer och molnmiljöer. Om byggprocessen för dina statiska filer till exempel placerar dem i en mapp med namnet django-statickan du ange DJANGO_STATIC_URL för att undvika att /django-static/ använda standardinställningen.

2. Om du har ett förskapningsskript som genererar statiska filer i en annan mapp ska du inkludera mappen i Django-variabeln STATICFILES_DIRS så att Djangos collectstatic process hittar dem. Om du till exempel kör yarn build i klientdelsmappen och yarn genererar en build/static mapp som innehåller statiska filer, tar du med mappen på följande sätt:

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

   FRONTEND_DIRHär skapar du en sökväg till där ett byggverktyg som yarn körs. Du kan återigen använda en miljövariabel och appinställning efter behov.

3. Lägg till whitenoise i filenrequirements.txt . Whitenoise (whitenoise.evans.io) är ett Python-paket som gör det enkelt för en Django-produktionsapp att hantera sina egna statiska filer. Whitenoise hanterar specifikt de filer som finns i mappen som anges av Django-variabeln STATIC_ROOT .

4. Lägg till följande rad för Whitenoise i filen settings.py :

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. Ändra MIDDLEWARE även och-listorna INSTALLED_APPS så att de inkluderar Whitenoise:

   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
   ]
   

Hantera statiska filer för Flask-appar

Om flaskwebbappen innehåller statiska klientdelsfiler följer du först anvisningarna för att hantera statiska filer i Flask-dokumentationen. Ett exempel på hur du hanterar statiska filer i ett Flask-program finns i snabbstartsexemplet flaskprogram på GitHub.

Om du vill hantera statiska filer direkt från en väg i ditt program kan du använda send_from_directory metoden:

from flask import send_from_directory

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

Containeregenskaper

När python-appar distribueras till App Service körs de i en Linux Docker-container som definieras i App Service Python GitHub-lagringsplats. Du hittar avbildningskonfigurationerna i de versionsspecifika katalogerna.

Den här containern har följande egenskaper:

• Appar körs med hjälp av Gunicorn WSGI HTTP Server med hjälp av de extra argumenten --bind=0.0.0.0 --timeout 600.

  • Du kan ange konfigurationsinställningar för Gunicorn genom att anpassa startkommandot.

  • För att skydda din webbapp mot oavsiktliga eller avsiktliga DDOS-attacker körs Gunicorn bakom en omvänd Nginx-proxy enligt beskrivningen i Distribuera Gunicorn (docs.gunicorn.org).

• Som standard innehåller bascontaineravbildningen endast Flask-webbramverket, men containern stöder andra ramverk som är WSGI-kompatibla och kompatibla med Python 3.6+, till exempel Django.

• Om du vill installera andra paket, till exempel Django, skapar du en requirements.txt fil i roten för projektet som anger dina direkta beroenden. App Service installerar sedan dessa beroenden automatiskt när du distribuerar projektet.

  Den requirements.txt filen måste finnas i projektroten för att beroenden ska installeras. Annars rapporterar byggprocessen felet: "Det gick inte att hitta setup.py eller requirements.txt. Kör inte pip install." Om det här felet uppstår kontrollerar du platsen för din kravfil.

• App Service definierar automatiskt en miljövariabel med namnet WEBSITE_HOSTNAME med webbappens URL, till exempel msdocs-hello-world.azurewebsites.net. Den definierar WEBSITE_SITE_NAME också med namnet på din app, till exempel msdocs-hello-world.

• npm och Node.js installeras i containern så att du kan köra Node-baserade byggverktyg, till exempel yarn.

Startprocessen för container

Under starten kör App Service i Linux-containern följande steg:

1. Använd ett anpassat startkommando om sådant tillhandahålls.
2. Kontrollera om finns en Django-app, och starta Gunicorn för den om det finns.
3. Kontrollera om finns en Flask-app, och starta Gunicorn för den om det finns.
4. Om ingen annan app hittas startar du en standardapp som är inbyggd i containern.

Följande avsnitt innehåller extra information för varje alternativ.

Django-app

För Django-appar letar App Service efter en fil med namnet wsgi.py i din appkod och kör sedan Gunicorn med hjälp av följande kommando:

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

Om du vill ha mer specifik kontroll över startkommandot använder du ett anpassat startkommando, ersätter <module> med namnet på mappen som innehåller wsgi.py och lägger till ett --chdir argument om modulen inte finns i projektroten. Om din wsgi.py till exempel finns under knboard/backend/config från projektroten använder du argumenten --chdir knboard/backend config.wsgi.

Om du vill aktivera produktionsloggning lägger du till parametrarna --access-logfile och --error-logfile enligt exemplen för anpassade startkommandon.

Flask-app

För Flask letar App Service efter en fil med namnet application.py eller app.py och startar Gunicorn enligt följande:

# 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

Om din huvudappmodul finns i en annan fil använder du ett annat namn för appobjektet, eller om du vill ange andra argument för Gunicorn, använder du ett anpassat startkommando.

Standardbeteende

Om App Service inte hittar något anpassat kommando, en Django-app eller en Flask-app kör den en skrivskyddad standardapp i mappen opt/defaultsite och visas i följande bild.

Om du har distribuerat kod och fortfarande ser standardappen läser du Felsökning – Appen visas inte.

Om du förväntar dig att se en distribuerad app i stället för standardappen kan du läsa Felsöka – appen visas inte.

Anpassa startkommando

Du kan styra containerns startbeteende genom att antingen tillhandahålla ett anpassat startkommando eller flera kommandon i en startkommandofil. En startkommandofil kan använda det namn du väljer, till exempel startup.sh, startup.cmd, startup.txtoch så vidare.

Alla kommandon måste använda relativa sökvägar till projektrotmappen.

Så här anger du ett startkommando eller en kommandofil:

• Azure Portal: välj appens konfigurationssida och välj sedan Allmänna inställningar. I fältet Startkommando placerar du antingen den fullständiga texten i startkommandot eller namnet på startkommandofilen. Välj sedan Spara för att tillämpa ändringarna. Se Konfigurera allmänna inställningar för Linux-containrar.

• Azure CLI: Använd kommandot az webapp config set med parametern --startup-file för att ange startkommandot eller filen:

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

  Ersätt <custom-command> med antingen den fullständiga texten i startkommandot eller namnet på startkommandofilen.

App Service ignorerar eventuella fel som inträffar vid bearbetning av ett anpassat startkommando eller en anpassad startfil, fortsätter sedan startprocessen genom att leta efter Django- och Flask-appar. Om du inte ser det beteende du förväntar dig kontrollerar du att startkommandot eller filen är felfri och att en startkommandofil distribueras till App Service tillsammans med din appkod. Du kan också kontrollera diagnostikloggarna för mer information. Kontrollera även appens sida Diagnostisera och lösa problem på Azure Portal.

Exempel på startkommandon

• Lade till Gunicorn-argument: I följande exempel läggs --workers=4 till i en Gunicorn-kommandorad för att starta en 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
  

  Mer information finns i Köra Gunicorn (docs.gunicorn.org). Om du använder regler för automatisk skalning för att skala upp och ned webbappen bör du också dynamiskt ange antalet gunicorn-arbetare med hjälp NUM_CORES av miljövariabeln i startkommandot, till exempel: --workers $((($NUM_CORES*2)+1)). Mer information om hur du anger det rekommenderade antalet gunicorn-arbetare finns i Vanliga frågor och svar om Gunicorn

• Aktivera produktionsloggning för Django: Lägg till argumenten --access-logfile '-' och --error-logfile '-' på kommandoraden:

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

  Dessa loggar visas i App Service loggströmmen.

  Mer information finns i Gunicorn-loggning (docs.gunicorn.org).

• Anpassad Flask-huvudmodul: Som standard förutsätter App Service att en Flask-apps huvudmodul är application.py eller app.py. Om huvudmodulen använder ett annat namn måste du anpassa startkommandot. Om du till exempel har en Flask-app vars huvudmodul är hello.py och Flask-appobjektet i den filen heter myapp blir kommandot följande:

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

  Om din huvudmodul är i en undermapp, till exempel website, anger du den mappen med argumentet --chdir:

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

• Använd en icke-Gunicorn-server: Om du vill använda en annan webbserver, till exempel aiohttp, använder du lämpligt kommando som startkommando eller i startkommandofilen:

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

Åtkomst till appinställningar som miljövariabler

Appinställningar är värden som lagras i molnet specifikt för din app enligt beskrivningen i Konfigurera appinställningar. De här inställningarna är tillgängliga för din appkod som miljövariabler och används med standardmönstret os.environ .

Om du till exempel har skapat appinställningen med namnet DATABASE_SERVERhämtar följande kod inställningens värde:

db_server = os.environ['DATABASE_SERVER']

Identifiera HTTPS-sessionen

I App Service sker TLS/SSL-avslutning (wikipedia.org) hos nätverkslastbalanserarna, så alla HTTPS-begäranden når din app som okrypterade HTTP-begäranden. Om din applogik behöver kontrollera om användarbegäranden är krypterade eller inte kan du kontrollera X-Forwarded-Proto-rubriken.

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

Med populära ramverk får du åtkomst till X-Forwarded-* information i standardappens mönster. I Django kan du till exempel använda SECURE_PROXY_SSL_HEADER för att be Django att använda X-Forwarded-Proto rubriken.

Få åtkomst till diagnostikloggar

Du kan komma åt konsolloggarna som genereras inifrån containern.

Aktivera först containerloggning genom att köra följande kommando:

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

Ersätt <app-name> och <resource-group-name> med de namn som är lämpliga för din webbapp.

När containerloggning har aktiverats kör du följande kommando för att visa loggströmmen:

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

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Om du vill stoppa loggströmningen när som helst skriver du Ctrl+C.

Du kan också granska loggfilerna i en webbläsare på https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Om du vill komma åt loggar via Azure Portal väljer du Övervakningsloggström> på menyn till vänster för din app.

Komma åt distributionsloggar

När du distribuerar koden utför App Service byggprocessen som beskrevs tidigare i avsnittet Anpassa versionsautomatisering. Eftersom bygget körs i en egen container lagras byggloggarna separat från appens diagnostikloggar.

Använd följande steg för att komma åt distributionsloggarna:

1. På Azure Portal för webbappen väljer duDistributionsdistributionscenter> på den vänstra menyn.
2. På fliken Loggar väljer du inchecknings-ID för den senaste incheckningen.
3. På sidan Logginformation som visas väljer du länken Visa loggar... som visas bredvid "Running oryx build...".

Skapa problem som felaktiga beroenden i requirements.txt och fel i för- eller efterskapningsskript visas i dessa loggar. Fel visas också om kravfilen inte precis heter requirements.txt eller inte visas i rotmappen för projektet.

Öppna en SSH-session i webbläsaren

Om du ska öppna en SSH-direktsession med din container måste appen vara igång.

Klistra in följande URL i webbläsaren och ersätt <app-name> med namnet på appen:

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

Om du inte redan har autentiserats måste du autentisera dig med din Azure-prenumeration för att kunna ansluta. När autentiseringen är klar visas ett gränssnitt i webbläsaren där du kan köra kommandon i containern.

Om du vill öppna en SSH-fjärrsession från den lokala datorn, kan du läsa mer i Öppna SSH-session från fjärrgränssnitt.

När du har anslutit till SSH-sessionen bör du se meddelandet "SSH CONNECTION ESTABLISHED" längst ned i fönstret. Om du ser fel som "SSH_CONNECTION_CLOSED" eller ett meddelande om att containern startas om kan ett fel hindra appcontainern från att starta. Se Felsökning för steg för att undersöka möjliga problem.

Felsökning

I allmänhet är det första steget i felsökningen att använda App Service Diagnostik:

1. I Azure Portal för webbappen väljer du Diagnostisera och lösa problem på den vänstra menyn.
2. Välj Tillgänglighet och prestanda.
3. Granska informationen i alternativen Programloggar, Containerkrasch och Containerproblem , där de vanligaste problemen visas.

Granska sedan både distributionsloggarna och apploggarna efter eventuella felmeddelanden. Dessa loggar identifierar ofta specifika problem som kan förhindra appdistribution eller appstart. Bygget kan till exempel misslyckas om dinrequirements.txt-fil har fel filnamn eller inte finns i projektrotmappen.

Följande avsnitt innehåller vägledning för specifika problem.

• Appen visas inte – standardappen visas
• Appen visas inte – meddelandet "tjänsten är inte tillgänglig"
• Det gick inte att hitta setup.py eller requirements.txt
• ModuleNotFoundError vid start
• Databasen är låst
• Lösenord visas inte i SSH-sessionen när de skrivs
• Kommandon i SSH-sessionen verkar vara avskurna
• Statiska tillgångar visas inte i en Django-app
• Dödlig SSL-anslutning krävs

Appen visas inte

• Du ser standardappen när du har distribuerat din egen appkod. Standardappen visas eftersom du antingen inte har distribuerat din appkod till App Service eller App Service inte kunde hitta din appkod och körde standardappen i stället.

  • Starta om App Service, vänta 15–20 sekunder och kontrollera appen igen.

  • Använd SSH för att ansluta direkt till App Service-containern och kontrollera att filerna finns under site/wwwroot. Om filerna inte finns använder du följande steg:

    1. Skapa en appinställning med namnet SCM_DO_BUILD_DURING_DEPLOYMENT med värdet 1, distribuera om koden, vänta några minuter och försök sedan komma åt appen igen. Mer information om hur du skapar appinställningar finns i Konfigurera en App Service app i Azure Portal.
    2. Granska distributionsprocessen, kontrollera distributionsloggarna, korrigera eventuella fel och distribuera om appen.

  • Om filerna finns kunde App Service inte identifiera din specifika startfil. Kontrollera att din app är strukturerad som App Service förväntar sig för Django eller Flask, eller använd ett anpassat startkommando.

• Meddelandet "Tjänsten är inte tillgänglig" visas i webbläsaren. Webbläsaren har överskriden tidsgräns i väntan på svar från App Service, vilket indikerar att App Service startade Gunicorn-servern, men själva appen startade inte. Det här villkoret kan tyda på att Gunicorn-argumenten är felaktiga eller att det finns ett fel i appkoden.

  • Uppdatera webbläsaren, särskilt om du använder de lägsta prisnivåerna i din App Service-plan. Till exempel kan appen ta längre tid att starta om du använder de kostnadsfria nivåerna och blir tillgänglig när du uppdaterar webbläsaren.

  • Kontrollera att din app är strukturerad som App Service förväntar sig för Django eller Flask, eller använd ett anpassat startkommando.

  • Undersök apploggströmmen efter eventuella felmeddelanden. Loggarna visar eventuella fel i appkoden.

Det gick inte att hitta setup.py eller requirements.txt

• Loggströmmen visar "Det gick inte att hitta setup.py eller requirements.txt. Kör inte pip install.": Oryx-kompileringsprocessen kunde inte hitta dinrequirements.txt-fil .

  • Anslut till webbappens container via SSH och kontrollera att requirements.txt är korrekt namngiven och finns direkt under site/wwwroot. Om den inte finns gör du så att platsen som filen finns på din lagringsplats och ingår i distributionen. Om den finns i en separat mapp flyttar du den till roten.

ModuleNotFoundError när appen startar

Om du ser ett fel som ModuleNotFoundError: No module named 'example', kunde Python inte hitta en eller flera av dina moduler när programmet startade. Det här felet uppstår oftast om du distribuerar din virtuella miljö med din kod. Virtuella miljöer är inte portabla, så en virtuell miljö bör inte distribueras med programkoden. Låt i stället Oryx skapa en virtuell miljö och installera dina paket i webbappen genom att skapa en appinställning och SCM_DO_BUILD_DURING_DEPLOYMENTställa in den på 1. Den här inställningen tvingar Oryx att installera dina paket när du distribuerar till App Service. Mer information finns i den här artikeln om portabilitet för virtuella miljöer.

Databasen är låst

När du försöker köra databasmigreringar med en Django-app kan du se "sqlite3. OperationalError: databasen är låst." Felet anger att ditt program använder en SQLite-databas för vilken Django konfigureras som standard i stället för att använda en molndatabas som PostgreSQL för Azure.

Kontrollera variabeln DATABASES i appens settings.py-fil för att se till att din app använder en molndatabas i stället för SQLite.

Om du stöter på det här felet med exemplet i Självstudie: Distribuera en Django-webbapp med PostgreSQL kontrollerar du att du har slutfört stegen i Verifiera anslutningsinställningar.

Andra problem

• Lösenord visas inte i SSH-sessionen när de skrivs: Av säkerhetsskäl håller SSH-sessionen ditt lösenord dolt när du skriver. Tecknen spelas dock in, så skriv ditt lösenord som vanligt och tryck på Retur när du är klar.

• Kommandon i SSH-sessionen verkar vara avskurna: Redigeringsprogrammet kanske inte är ordhanteringskommandon, men de bör fortfarande köras korrekt.

• Statiska tillgångar visas inte i en Django-app: Kontrollera att du har aktiverat whitenoise-modulen

• Du ser meddelandet "Fatal SSL Connection is Required": Kontrollera användarnamn och lösenord som används för att komma åt resurser (till exempel databaser) inifrån appen.

Fler resurser

• Självstudie: Python-app med PostgreSQL
• Självstudie: Distribuera från en privat containerlagringsplats
• Vanliga frågor och svar om App Service på Linux
• Referens för miljövariabler och appinställningar