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.
Anteckning
Linux är det enda operativsystemet för att köra Python-appar i App Service. Python i Windows stöds inte längre. Du kan dock skapa en egen anpassad Windows-containeravbildning och köra den i App Service. Mer information finns i Använda anpassad Docker-avbildning.
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
:
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 ochyarn build
.)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."Om manage.py hittas i databasens rot (som anger en Django-app) kör du manage.py collectstatic. Men om inställningen
DISABLE_COLLECTSTATIC
ärtrue
hoppas det här steget över.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_COMMAND
och DISABLE_COLLECTSTATIC
tomma.
Om du vill inaktivera körning av collectstatic när du skapar Django-appar anger du
DISABLE_COLLECTSTATIC
inställningen tilltrue
.Om du vill köra förhandsversionskommandon anger du
PRE_BUILD_COMMAND
att inställningen ska innehålla antingen ett kommando, till exempelecho Pre-build command
, eller en sökväg till en skriptfil i förhållande till projektroten, till exempelscripts/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 exempelecho Post-build command
, eller en sökväg till en skriptfil i förhållande till projektroten, till exempelscripts/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.
Anteckning
PRE_BUILD_SCRIPT_PATH
Inställningarna och POST_BUILD_SCRIPT_PATH
är identiska PRE_BUILD_COMMAND
med och POST_BUILD_COMMAND
stöds i äldre syften.
En inställning med namnet SCM_DO_BUILD_DURING_DEPLOYMENT
, om den innehåller true
eller 1, utlöser en Oryx-version under distributionen. Inställningen är sann när du distribuerar med git, Azure CLI-kommandot az webapp up
och Visual Studio Code.
Anteckning
Använd alltid relativa sökvägar i alla för- och efterskapningsskript eftersom den byggcontainer där Oryx körs skiljer sig från den körningscontainer där appen körs. Förlita dig aldrig på den exakta placeringen av din appprojektmapp i containern (till exempel att den placeras under plats/wwwroot).
Migrera befintliga program till Azure
Befintliga webbprogram kan distribueras om till Azure på följande sätt:
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.
Databas: Om din app är beroende av en databas skapar du även nödvändiga resurser på Azure.
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.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.
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.
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.
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 .
Django-inställning | Instruktioner för Azure |
---|---|
SECRET_KEY |
Lagra värdet i en App Service inställning enligt beskrivningen i Åtkomstappinställningar som miljövariabler. Du kan alternativt lagra värdet som en "hemlighet" i Azure Key Vault. |
DEBUG |
Skapa en DEBUG inställning på App Service med värdet 0 (false) och läs sedan in värdet som en miljövariabel. I utvecklingsmiljön skapar du en DEBUG miljövariabel med värdet 1 (sant). |
ALLOWED_HOSTS |
I produktion kräver Django att du inkluderar appens URL i matrisen ALLOWED_HOSTS med settings.py. Du kan hämta den här URL:en vid körning med koden . os.environ['WEBSITE_HOSTNAME'] App Service ställer automatiskt in WEBSITE_HOSTNAME miljövariabeln till appens URL. |
DATABASES |
Definiera inställningar i App Service för databasanslutningen och läs in dem som miljövariabler för att fylla i DATABASES ordlistan. Du kan alternativt lagra värdena (särskilt användarnamnet och lösenordet) som Azure-Key Vault hemligheter. |
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:
Ö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
ochSTATIC_ROOT
variabler. Exempel:STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/") STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")
DJANGO_STATIC_URL
ochDJANGO_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 namnetdjango-static
kan du angeDJANGO_STATIC_URL
för att undvika att/django-static/
använda standardinställningen.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 Djangoscollectstatic
process hittar dem. Om du till exempel köryarn build
i klientdelsmappen och yarn genererar enbuild/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 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.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-variabelnSTATIC_ROOT
.Lägg till följande rad för Whitenoise i filen settings.py :
STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
Ändra
MIDDLEWARE
även och-listornaINSTALLED_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 exempelmsdocs-hello-world.azurewebsites.net
. Den definierarWEBSITE_SITE_NAME
också med namnet på din app, till exempelmsdocs-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:
- Använd ett anpassat startkommando om sådant tillhandahålls.
- Kontrollera om finns en Django-app, och starta Gunicorn för den om det finns.
- Kontrollera om finns en Flask-app, och starta Gunicorn för den om det finns.
- 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 GunicornAktivera 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_SERVER
hä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:
- På Azure Portal för webbappen väljer duDistributionsdistributionscenter> på den vänstra menyn.
- På fliken Loggar väljer du inchecknings-ID för den senaste incheckningen.
- 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.
Anteckning
Eventuella ändringar som du gör utanför katalogen /start lagras i själva containern och finns inte kvar om appen startas om.
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:
- I Azure Portal för webbappen väljer du Diagnostisera och lösa problem på den vänstra menyn.
- Välj Tillgänglighet och prestanda.
- 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:
- 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. - Granska distributionsprocessen, kontrollera distributionsloggarna, korrigera eventuella fel och distribuera om appen.
- Skapa en appinställning med namnet
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_DEPLOYMENT
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 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.