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 när du distribuerar en Git-lagringsplats eller när du distribuerar ett zip-paketmed build automation aktiverat.

Den här artikeln 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 App Service slutför du först python-snabbstarten och självstudiekursen Flask, Django eller FastAPI med PostgreSQL.

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

• Azure-portalen. I appens vänstra fönster väljer du Inställningar>Miljövariabler eller Konfiguration av inställningar> enligt beskrivningen i Konfigurera en App Service-app i Azure-portalen.

• 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 in på Azure med az login.

Konfigurera Python-versionen

• Azure-portalen: 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 App Service med az webapp list-runtimes:

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

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

Vad händer med inaktuella körmiljöer i App Service?

Inaktuella körningar är inaktuella av organisationens underhåll eller har betydande sårbarheter. Därför tas de bort från skapa och konfigurera sidor i portalen. När den inaktuella runtime-miljön är dold från portalen, fortsätter alla appar som fortfarande använder den att köras.

Om du vill skapa en app med en inaktuell körningsversion som inte längre visas på portalen använder du Azure CLI, en ARM-mall eller Bicep. Med de här distributionsalternativen kan du skapa inaktuella körningar som tas bort från portalen men som fortfarande stöds.

Om en runtime tas bort helt från App Service-plattformen får ägaren till din Azure-prenumeration ett e-postmeddelande innan borttagningen.

Anpassa byggautomatisering

App Service-byggsystemet, 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. Om det inte är det 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 (vilket 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 i 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 är PRE_BUILD_COMMAND, POST_BUILD_COMMAND och DISABLE_COLLECTSTATIC inställningarna tomma.

• Om du vill inaktivera körning 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 sökvägar som är relativa för 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 sökvägar som är relativa till projektrotmappen.

Information om andra inställningar som anpassar versionsautomatisering finns i Oryx-konfiguration.

Information om hur du kommer åt bygg- och distributionsloggarna finns i Åtkomst till distributionsloggar.

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

Generera requirements.txt från pyproject.toml

App Service stöder pyproject.tomlför närvarande inte direkt . Om du använder verktyg som Poetry eller uv är den rekommenderade metoden att generera en kompatibel requirements.txt fil före distributionen i projektets rot:

Använda poesi

Generera requirements.txt med hjälp av Poetry med export-plugin-programmet:

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

Använda uv

Generera requirements.txt med hjälp av uv:

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

Migrera befintliga program till Azure

Du kan distribuera om befintliga webbprogram till Azure på följande sätt:

1. Källlagringsplats. Behåll källkoden på en lämplig lagringsplats, till exempel GitHub, som 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 om du vill att App Service ska 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 skapa dessa resurser genom att köra Azure CLI-kommandot az webapp up. Eller så kan du skapa och distribuera resurser som du ser i självstudien Flask, Django eller FastAPI med PostgreSQL. Ersätt namnen på resursgruppen, App Service-planen och webbappen med namn som är lämpliga för ditt program.

4. Miljövariabler. Om ditt program 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. Mer information om hur App Service försöker köra appen finns i avsnittet Startprocess för container senare i den här artikeln. App Service använder gunicorn-webbservern som standard. Gunicorn 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. 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 App Service-containern som är värd för din app, till exempel Django-databasmigreringar, kan du ansluta till containern med hjälp av SSH. Ett exempel på hur du kör Django-databasmigreringar finns i Självstudie: Distribuera en Django-webbapp med PostgreSQL.

   • När du använder kontinuerlig distribution kan du utföra dessa åtgärder med hjälp av kommandon efter bygget, enligt beskrivningen tidigare i avsnittet 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 App Service bör Django-appar följa riktlinjerna i 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 till exempel byggprocessen för dina statiska filer placerar dem i en mapp med namnet django-statickan du ange DJANGO_STATIC_URL till /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 den mappen som du ser här:

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

   I den här koden FRONTEND_DIR används för att skapa en sökväg till där ett byggverktyg som Yarn körs. Du kan använda en miljövariabel och appinställning igen om du vill.

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 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. MIDDLEWARE Ändra listorna och 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 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 av Gunicorn WSGI HTTP Server med 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 och senare, 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, annars installeras inte beroenden. Om den här filen inte finns i roten 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 som innehåller webbappens URL, till exempel msdocs-hello-world.azurewebsites.net. Den definierar WEBSITE_SITE_NAMEockså , som innehåller 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 på följande sätt:

# 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 eller startup.txt.

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

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

• Azure-portalen. Under Inställningar i den vänstra rutan på appens sida väljer du Konfiguration och sedan Allmänna inställningar. I rutan Startkommando anger 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. Och du kan kontrollera appens sida Diagnostisera och lösa problem på Azure-portalen.

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 that contains 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 autoskalning 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 filen heter myapp, är det här kommandot:

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

  Om huvudmodulen finns i en undermapp, till exempel webbplats, anger du mappen med --chdir argumentet :

  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 nås via standardmönstret os.environ .

Om du till exempel skapar 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 kontrollerar du 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 webbramverk kan du komma åt X-Forwarded-* informationen i ditt standardappmönster. I Django kan du till exempel använda SECURE_PROXY_SSL_HEADER för att konfigurera Django att använda X-Forwarded-Proto huvudet.

Få åtkomst till diagnostikloggar

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

Om du vill aktivera containerloggning kör du 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 namn som är lämpliga för din webbapp.

När du har aktiverat containerloggning kör du följande kommando för att se loggströmmen:

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

Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.

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

Om du vill komma åt loggar i Azure-portalen väljer du Övervakningsloggström> i det vänstra fönstret för din app.

Åtkomst till distributionsloggar

När du distribuerar koden utför App Service den byggprocess 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å sidan Azure-portalen för webbappen väljer duDistributionsdistributionscenter> i det vänstra fönstret.
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 (Visa loggar som visas bredvid Running oryx build).

Byggproblem, till exempel felaktiga beroenden i requirements.txt och fel i för- eller efterskapningsskript, visas i dessa loggar. Fel visas också om kravfilen inte heter requirements.txt eller inte visas i rotmappen för projektet.

Öppna SSH-session i en webbläsare

Om du vill öppna en direkt SSH-session med containern bör appen köras.

Använd kommandot az webapp ssh .

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

Information om hur du öppnar en fjärr-SSH-session från den lokala datorn finns i Öppna SSH-session från fjärrgränssnittet.

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. Mer information om hur du undersöker möjliga problem finns i Felsökning .

URL-omskrivningar

När du distribuerar Python-program i App Service för Linux kan du behöva hantera URL-omskrivningar i ditt program. Den här metoden är särskilt användbar för att säkerställa att specifika URL-mönster omdirigeras till rätt slutpunkter utan att förlita sig på externa webbserverkonfigurationer. För Flask-program kan du använda URL-processorer och anpassade mellanprogram för att uppnå detta. I Django-program möjliggör 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. På sidan Azure-portalen för din webbapp väljer du Diagnostisera och lösa problem i den vänstra rutan.
2. Välj Tillgänglighet och prestanda.
3. Granska informationen i programloggar, containerkrascher 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 uppstart
• 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 appkoden till App Service eller för att App Service inte kunde hitta din appkod och körde standardappen i stället.

  • Starta om appen, vänta 20 sekunder och kontrollera sedan 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 utför 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-portalen.
    2. Granska distributionsprocessen, kontrollera distributionsloggarna, korrigera eventuella fel och distribuera om appen.

  • Om dina filer finns kunde App Service inte identifiera startfilen. 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. Tidsgränsen för webbläsaren var att vänta på ett svar från App Service. Detta indikerar att App Service startade Gunicorn-servern men att själva appen inte startades. 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 som App Service förväntar sig för Django eller Flask, eller använd ett anpassat startkommando.

  • Granska apploggströmmen efter 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 säkerställa att appen 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 lösenordet 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: Flask-app med PostgreSQL
• Självstudie: Django-app med PostgreSQL
• Självstudie: FastAPI-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