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 du behöver. Python-appar måste distribueras med alla nödvändiga pip-moduler .

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 när du distribuerar ett zip-paket med versionsautomatisering 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 självstudiekursen Python-snabbstart och Python med PostgreSQL.

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

• Azure Portal använder du appens instä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 Services byggsystem, som kallas Oryx, utför följande steg när du distribuerar din app, om appinställningen SCM_DO_BUILD_DURING_DEPLOYMENT är inställd på 1:

1. Kör ett anpassat förskapningsskript om det steget 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 roten på lagringsplatsen (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 ett anpassat skript efter bygget om det steget anges av inställningen POST_BUILD_COMMAND . (Skriptet kan återigen 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 inställningen DISABLE_COLLECTSTATIC 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 Hur Oryx identifierar och skapar 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 i Azure.

3. App service-resurser: Skapa en resursgrupp, App Service-plan och App Service-webbapp som värd för ditt program. Du kan enkelt göra detta 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-planen och webbappen så att de passar bättre för ditt program.

4. Miljövariabler: Om programmet kräver några 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 container 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 som standard Gunicorn-webbservern, som måste kunna hitta ditt appobjekt eller wsgi.py mapp. Om du behöver det 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. Du kan också 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 App Service-containern 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.

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 för att 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. Till 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 ställa in DJANGO_STATIC_URL på /django-static/ för att undvika att använda standardvärdet.

2. Om du har ett fördefinieringsskript 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_DIR Här används för att skapa 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 filen requirements.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. I filen settings.py lägger du till följande rad för WhiteNoise:

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. Ändra MIDDLEWARE också listorna och INSTALLED_APPS så att de innehåller 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 Flask-exempelprogrammet 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 de distribueras till App Service körs Python-appar i en Linux Docker-container som definieras i App Service Python GitHub-lagringsplatsen. 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.

• 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 även 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 det finns ett.
2. Kontrollera om det finns en Django-app och starta Gunicorn för den om en identifieras.
3. Kontrollera om det finns en Flask-app och starta Gunicorn för den om en identifieras.
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 huvudappmodulen finns i en annan fil använder du ett annat namn för appobjektet. 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 som finns 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.

Anpassa startkommando

Du kan styra containerns startbeteende genom att antingen ange 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.txt och 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 uppstår vid bearbetning av ett anpassat startkommando eller en fil och fortsätter sedan sin startprocess 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 argumentet 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. 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.

• Custom 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 en appinställning 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 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 huvudet.

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.

Åtkomst till 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 du Distributionsdistributionscenter> 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...".

Byggproblem som felaktiga beroenden i requirements.txt och fel i skript före eller efter bygget visas i dessa loggar. Fel visas också om kravfilen inte 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.

URL-omskrivningar

När du distribuerar Python-program i Azure App Service för Linux kan du behöva hantera URL-omskrivningar i ditt program. Detta är särskilt användbart för att se till att specifika URL-mönster omdirigeras till rätt slutpunkter utan att förlita sig på externa webbserverkonfigurationer. För Flask-program kan URL-processorer och anpassade mellanprogram användas för att uppnå detta. I Django-program möjliggör den robusta URL-avsändaren effektiv hantering av URL-omskrivningar.

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 för eventuella felmeddelanden. Dessa loggar identifierar ofta specifika problem som kan förhindra appdistribution eller appstart. Bygget kan till exempel misslyckas om din requirements.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 så kunde Inte App Service 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 på det sätt 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 för att vänta på ett 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. Det kan ta längre tid att starta appen när du till exempel använder kostnadsfria nivåer och blir dynamisk när du har uppdaterat webbläsaren.

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

  • Granska 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 din requirements.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 kontrollerar du att filen finns på lagringsplatsen och ingår i distributionen. Om den finns i en separat mapp flyttar du den till roten.

ModuleNotFoundError när appen startas

Om du ser ett fel som ModuleNotFoundError: No module named 'example', kunde Python inte hitta en eller flera av dina moduler när programmet startades. Det här felet inträffar 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 paketen i webbappen genom att skapa en appinställning SCM_DO_BUILD_DURING_DEPLOYMENToch stä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 virtuell miljö.

Databasen är låst

När du försöker köra databasmigreringar med en Django-app kanske du ser "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 Azure Database for PostgreSQL.

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 registreras dock, så skriv ditt lösenord som vanligt och välj Retur när du är klar.

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

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

• Meddelandet "Dödlig SSL-anslutning krävs" visas: Kontrollera eventuella användarnamn och lösenord som används för att komma åt resurser (till exempel databaser) inifrån appen.

Relaterat innehåll

• 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