Konfigurace aplikace v Pythonu pro Linux pro Azure App Service

Tento článek popisuje, jak Azure App Service spouštět aplikace v Pythonu, jak migrovat stávající aplikace do Azure a jak přizpůsobit chování App Service v případě potřeby. Aplikace v Pythonu musí být nasazené se všemi požadovanými moduly pip .

Modul nasazení App Service automaticky aktivuje virtuální prostředí a spustí pip install -r requirements.txt se za vás, když nasadíte úložiště Git nebo balíček ZIPs povolenou automatizací sestavení.

Tato příručka obsahuje klíčové koncepty a pokyny pro vývojáře v Pythonu, kteří používají integrovaný kontejner Linuxu v App Service. Pokud jste Azure App Service nikdy nepoužívali, nejprve postupujte podle rychlého startu k Pythonu a kurzu Python s PostgreSQL.

Ke konfiguraci můžete použít Azure Portal nebo Azure CLI:

• Azure Portal použijte stránkuKonfiguracenastavení> aplikace, jak je popsáno v části Konfigurace aplikace App Service v Azure Portal.

• Azure CLI: Máte dvě možnosti.

  • Spouštění příkazů v Azure Cloud Shell
  • Spusťte příkazy místně instalací nejnovější verze Azure CLI a pak se přihlaste k Azure pomocí příkazu az login.

Konfigurace verze Pythonu

• Azure Portal: Použijte kartu Obecné nastavení na stránce Konfigurace, jak je popsáno v tématu Konfigurace obecných nastavení pro kontejnery Linuxu.

• Azure CLI:

  • Zobrazení aktuální verze Pythonu pomocí příkazu az webapp config show:

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

    Nahraďte <resource-group-name> a <app-name> názvy vhodnými pro vaši webovou aplikaci.

  • Nastavení verze Pythonu pomocí příkazu az webapp config set

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

  • Zobrazí všechny verze Pythonu podporované v Azure App Service pomocí příkazu az webapp list-runtimes:

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

Můžete spustit nepodporovanou verzi Pythonu tak, že místo toho vytvoříte vlastní image kontejneru. Další informace najdete v tématu věnovaném použití vlastní image Dockeru.

Přizpůsobení automatizace sestavení

systém sestavení App Service s názvem Oryx provede při nasazení aplikace následující kroky, pokud je nastavení SCM_DO_BUILD_DURING_DEPLOYMENT aplikace nastaveno na 1:

1. Pokud je to nastavení určené, spusťte vlastní skript před sestavením PRE_BUILD_COMMAND . (Skript může sám spouštět další skripty Pythonu a Node.js, příkazy pip a npm a nástroje založené na uzlech, jako je yarn, yarn install například a yarn build.)

2. Spusťte pip install -r requirements.txt. Soubor requirements.txt musí být v kořenové složce projektu. V opačném případě proces sestavení hlásí chybu: "Nelze najít setup.py nebo requirements.txt; Nejde spustit pip install."

3. Pokud se manage.py nachází v kořenovém adresáři úložiště (což označuje aplikaci Django), spusťte manage.py collectstatic. Pokud je truevšak nastavení nastaveno DISABLE_COLLECTSTATIC , tento krok se přeskočí.

4. Pokud je to nastavení určené POST_BUILD_COMMAND , spusťte vlastní skript po sestavení. (Skript opět může spouštět další skripty Pythonu a Node.js, příkazy pip a npm a nástroje založené na node.)

Ve výchozím nastavení PRE_BUILD_COMMANDjsou nastavení , POST_BUILD_COMMANDa DISABLE_COLLECTSTATIC prázdná.

• Pokud chcete při vytváření aplikací Django zakázat spouštění collectstatic, nastavte DISABLE_COLLECTSTATIC nastavení na true.

• Pokud chcete spouštět příkazy před sestavením, nastavte PRE_BUILD_COMMAND nastavení tak, aby obsahovalo příkaz, například echo Pre-build command, nebo cestu k souboru skriptu vzhledem ke kořenovému adresáři projektu, například scripts/prebuild.sh. Všechny příkazy musí používat relativní cesty ke kořenové složce projektu.

• Pokud chcete spouštět příkazy po sestavení, nastavte POST_BUILD_COMMAND nastavení tak, aby obsahovalo příkaz, například echo Post-build command, nebo cestu k souboru skriptu vzhledem ke kořenovému adresáři projektu, například scripts/postbuild.sh. Všechny příkazy musí používat relativní cesty ke kořenové složce projektu.

Další nastavení, která přizpůsobují automatizaci sestavení, najdete v tématu Konfigurace nástroje Oryx.

Přístup k protokolům sestavení a nasazení najdete v tématu Přístup k protokolům nasazení.

Další informace o tom, jak App Service spouštět a sestavovat aplikace Pythonu v Linuxu, najdete v tématu Jak Oryx detekuje a sestavuje aplikace v Pythonu.

Migrace stávajících aplikací do Azure

Existující webové aplikace je možné do Azure znovu nasadit následujícím způsobem:

1. Zdrojové úložiště: Zdrojový kód uchovávejte ve vhodném úložišti, jako je GitHub, což vám umožní nastavit průběžné nasazování později v tomto procesu.

   • Soubor requirements.txt musí být v kořenovém adresáři úložiště, aby App Service automaticky nainstalovali potřebné balíčky.

2. Databáze: Pokud vaše aplikace závisí na databázi, vytvořte potřebné prostředky také v Azure.

3. Prostředky služby App Service: Vytvořte skupinu prostředků, App Service Plán a App Service webovou aplikaci pro hostování vaší aplikace. Můžete to snadno provést spuštěním příkazu az webapp upAzure CLI . Nebo můžete vytvořit a nasadit prostředky, jak je znázorněno v kurzu Nasazení webové aplikace v Pythonu (Django nebo Flask) pomocí PostgreSQL. Nahraďte názvy skupiny prostředků, App Service Plán a webovou aplikaci tak, aby byly vhodnější pro vaši aplikaci.

4. Proměnné prostředí: Pokud vaše aplikace vyžaduje nějaké proměnné prostředí, vytvořte ekvivalentní App Service nastavení aplikace. Tato App Service nastavení se vašemu kódu zobrazí jako proměnné prostředí, jak je popsáno v tématu Proměnné prostředí Accessu.

   • Například připojení k databázi se často spravují prostřednictvím takových nastavení, jak je znázorněno v kurzu Nasazení webové aplikace Django pomocí PostgreSQL – ověření nastavení připojení.
   • Konkrétní nastavení pro typické aplikace Django najdete v tématu Produkční nastavení aplikací Django .

5. Spuštění aplikace: Projděte si část Proces spuštění kontejneru dále v tomto článku, abyste pochopili, jak App Service pokusí spustit vaši aplikaci. App Service ve výchozím nastavení používá webový server Gunicorn, který musí být schopen najít objekt aplikace nebo wsgi.py složku. V případě potřeby můžete přizpůsobit spouštěcí příkaz.

6. Průběžné nasazování: Nastavte průběžné nasazování z GitHub Actions, Bitbucketu nebo Azure Repos, jak je popsáno v článku Průběžné nasazování do Azure App Service. Nebo můžete nastavit průběžné nasazování z místního Gitu, jak je popsáno v článku Místní nasazení Gitu do Azure App Service.

7. Vlastní akce: Pokud chcete provádět akce v rámci kontejneru App Service, který hostuje vaši aplikaci, jako jsou migrace databází Django, můžete se ke kontejneru připojit přes SSH. Příklad spuštění migrace databází Django najdete v tématu Kurz: Nasazení webové aplikace Django pomocí PostgreSQL – generování schématu databáze.

   • Pokud používáte průběžné nasazování, můžete tyto akce provádět pomocí příkazů po sestavení, jak je popsáno výše v části Přizpůsobení automatizace sestavení.

Po dokončení těchto kroků byste měli být schopni potvrdit změny ve zdrojovém úložišti a mít tyto aktualizace automaticky nasazené do App Service.

Produkční nastavení pro aplikace Django

V produkčním prostředí, jako je Azure App Service, by se aplikace Django měly řídit kontrolním seznamem nasazení Django (djangoproject.com).

Následující tabulka popisuje produkční nastavení, která jsou relevantní pro Azure. Tato nastavení jsou definovaná v souboru setting.py aplikace.

Obsluha statických souborů pro aplikace Django

Pokud vaše webová aplikace Django obsahuje statické front-endové soubory, postupujte nejprve podle pokynů ke správě statických souborů v dokumentaci k Djangu.

Pro App Service proveďte následující změny:

1. Zvažte použití proměnných prostředí (pro místní vývoj) a Nastavení aplikace (při nasazování do cloudu) k dynamickému nastavení django STATIC_URL a STATIC_ROOT proměnných. Příklad:

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

   DJANGO_STATIC_URL a DJANGO_STATIC_ROOT se dají podle potřeby změnit pro vaše místní a cloudová prostředí. Pokud je například proces sestavení statických souborů umístí do složky s názvem django-static, můžete nastavit DJANGO_STATIC_URL na /django-static/ hodnotu , abyste se vyhnuli použití výchozího nastavení.

2. Pokud máte skript před sestavením, který generuje statické soubory v jiné složce, zahrňte tuto složku do proměnné Django STATICFILES_DIRS , aby je proces Django collectstatic najde. Pokud například spustíte příkaz yarn build ve front-endové složce a yarn vygeneruje build/static složku obsahující statické soubory, zahrňte tuto složku následujícím způsobem:

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

   Tady můžete vytvořit cestu, na které se spustí nástroj sestavení, FRONTEND_DIRjako je yarn. Podle potřeby můžete znovu použít proměnnou prostředí a nastavení aplikace.

3. Přidejte whitenoise do souboru requirements.txt . Whitenoise (whitenoise.evans.io) je balíček Pythonu, který produkční aplikaci Django usnadňuje obsluhu vlastních statických souborů. Whitenoise konkrétně slouží těm souborům, které se nacházejí ve složce určené proměnnou Django STATIC_ROOT .

4. Do souboru settings.py přidejte následující řádek pro Whitenoise:

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. Upravte MIDDLEWARE také seznamy a INSTALLED_APPS tak, aby zahrnovaly 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
   ]
   

Obsluha statických souborů pro aplikace Flask

Pokud webová aplikace Flask obsahuje statické front-endové soubory, nejprve postupujte podle pokynů ke správě statických souborů v dokumentaci k Flasku. Příklad obsluhy statických souborů v aplikaci Flask najdete v ukázkové aplikaci Flask pro rychlý start na GitHubu.

Pokud chcete obsluhovat statické soubory přímo z trasy ve vaší aplikaci, můžete použít metodu send_from_directory :

from flask import send_from_directory

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

Vlastnosti kontejneru

Po nasazení do App Service běží aplikace Pythonu v kontejneru Dockeru s Linuxem, který je definovaný v úložišti App Service Python GitHub. Konfigurace imagí najdete v adresářích specifických pro konkrétní verzi.

Tento kontejner má následující vlastnosti:

• Aplikace se spouští pomocí serveru GUNICORN WSGI HTTP s použitím dodatečných argumentů --bind=0.0.0.0 --timeout 600.

  • Nastavení konfigurace pro Gunicorn můžete zadat přizpůsobením spouštěcího příkazu.

  • Aby byla vaše webová aplikace chráněna před náhodnými nebo úmyslným útoky DDOS, je Gunicorn spuštěn za reverzním proxy serverem Nginx, jak je popsáno v článku Nasazení Gunicornu (docs.gunicorn.org).

• Základní image kontejneru ve výchozím nastavení zahrnuje pouze webové rozhraní Flask, ale kontejner podporuje další architektury, které jsou kompatibilní s WSGI a jsou kompatibilní s Pythonem 3.6 nebo novějším, například Django.

• Pokud chcete nainstalovat další balíčky, například Django, vytvořte v kořenovém adresáři projekturequirements.txt soubor, který určuje vaše přímé závislosti. App Service pak tyto závislosti automaticky nainstaluje při nasazení projektu.

  Aby se závislosti nainstalovaly, musí být soubor requirements.txt v kořenovém adresáři projektu. V opačném případě proces sestavení hlásí chybu: "Nepodařilo se najít setup.py nebo requirements.txt; Nejde spustit pip install." Pokud k této chybě dojde, zkontrolujte umístění souboru s požadavky.

• App Service automaticky definuje proměnnou prostředí s názvem WEBSITE_HOSTNAME s adresou URL webové aplikace, například msdocs-hello-world.azurewebsites.net. Definuje se také WEBSITE_SITE_NAME s názvem vaší aplikace, například msdocs-hello-world.

• v kontejneru jsou nainstalované npm a Node.js, takže můžete spustit nástroje sestavení založené na uzlech, jako je yarn.

Proces spuštění kontejneru

V průběhu spuštění služba App Service v kontejneru Linuxu spustí následující kroky:

1. Pokud je k dispozici , použijte vlastní spouštěcí příkaz.
2. Zkontrolujte, jestli existuje aplikace Django, a pokud ji zjistíte, spusťte gunicorn.
3. Zkontrolujte, jestli existuje aplikace Flask, a pokud ji zjistíte, spusťte gunicorn.
4. Pokud se žádná další aplikace nenajde, následuje spuštění výchozí aplikace sestavené do kontejneru.

Následující části obsahují další podrobnosti o jednotlivých možnostech.

Aplikace Django

Služba App Service hledá pro aplikace Django soubory se jménem wsgi.py v kódu aplikace. Pak spustí server Gunicorn s použitím následujícího příkazu:

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

Pokud chcete mít konkrétnější kontrolu nad spouštěcím příkazem, použijte vlastní spouštěcí příkaz, nahraďte <module> názvem složky, která obsahuje wsgi.py, a přidejte --chdir argument, pokud modul není v kořenovém adresáři projektu. Pokud se například váš wsgi.py nachází v části knboard/backend/config z kořenového adresáře projektu, použijte argumenty --chdir knboard/backend config.wsgi.

Pokud chcete povolit protokolování produkčního --access-logfile prostředí, přidejte parametry a --error-logfile , jak je znázorněno v příkladech pro vlastní spouštěcí příkazy.

Aplikace Flask

Pro Flask App Service vyhledá soubor s názvem application.py nebo app.py a spustí Gunicorn následujícím způsobem:

# 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

Pokud je hlavní modul aplikace obsažen v jiném souboru, použijte jiný název objektu aplikace nebo chcete gunicornu zadat další argumenty, použijte vlastní spouštěcí příkaz.

Výchozí chování

Pokud App Service nenajde vlastní příkaz, aplikaci Django nebo flask, spustí výchozí aplikaci jen pro čtení, která se nachází ve složce opt/defaultsite a je zobrazená na následujícím obrázku.

Pokud jste nasadili kód a stále vidíte výchozí aplikaci, přečtěte si téma Řešení potíží – aplikace se nezobrazuje.

Pokud očekáváte, že se místo výchozí aplikace zobrazí nasazená aplikace, přečtěte si téma Řešení potíží – Aplikace se nezobrazuje.

Přizpůsobení spouštěcího příkazu

Chování kontejneru při spuštění můžete řídit zadáním vlastního spouštěcího příkazu nebo více příkazů v souboru spouštěcích příkazů. Spouštěcí příkazový soubor může používat libovolný název, například startup.sh, startup.cmd,startup.txtatd.

Všechny příkazy musí používat relativní cesty ke kořenové složce projektu.

Určení spouštěcího příkazu nebo souboru příkazů:

• Azure Portal: Vyberte stránku Konfigurace aplikace a pak vyberte Obecná nastavení. Do pole Spouštěcí příkaz umístěte buď celý text spouštěcího příkazu, nebo název souboru spouštěcího příkazu. Pak vyberte Uložit , aby se změny použily. Viz Konfigurace obecných nastavení pro kontejnery Linuxu.

• Azure CLI: Pomocí příkazu az webapp config set s parametrem --startup-file nastavte spouštěcí příkaz nebo soubor:

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

  Nahraďte <custom-command> buď úplným textem spouštěcího příkazu, nebo názvem souboru spouštěcího příkazu.

App Service ignoruje všechny chyby, ke kterým dochází při zpracování vlastního spouštěcího příkazu nebo souboru, a pak pokračuje v procesu spouštění vyhledáním aplikací Django a Flask. Pokud nevidíte očekávané chování, zkontrolujte, jestli je spouštěcí příkaz nebo soubor bez chyb a jestli je soubor spouštěcího příkazu nasazený do App Service spolu s kódem aplikace. Další informace najdete také v diagnostických protokolech . Podívejte se také na stránku Diagnostika a řešení problémů aplikace na Azure Portal.

Příklady spouštěcích příkazů

• Přidání argumentů Gunicorn: Následující příklad přidá --workers=4 příkazový řádek Gunicorn pro spuštění aplikace Django:

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

  Další informace najdete v Running Gunicorn (Spuštění serveru Gunicorn) (docs.gunicorn.org). Pokud ke škálování webové aplikace používáte pravidla automatického škálování, měli byste také dynamicky nastavit počet pracovních procesů gunicorn pomocí NUM_CORES proměnné prostředí ve spouštěcím příkazu, například : --workers $((($NUM_CORES*2)+1)). Další informace o nastavení doporučeného počtu pracovníků gunicorn najdete v nejčastějších dotazech ke Gunicornu.

• Povolit protokolování produkčního prostředí pro Django: Přidejte --access-logfile '-' argumenty a --error-logfile '-' do příkazového řádku:

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

  Tyto protokoly se zobrazí ve streamu protokolu App Service.

  Další informace najdete v tématu Protokolování gunicornu (docs.gunicorn.org).

• Vlastní hlavní modul Flask: Ve výchozím nastavení App Service předpokládá, že hlavní modul aplikace Flask je application.py nebo app.py. Pokud hlavní modul používá jiný název, musíte přizpůsobit spouštěcí příkaz. Například pokud je hlavní modul aplikace Flask hello.py a objekt aplikace Flask v tomto souboru se jmenuje myapp, vypadá příkaz takto:

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

  Pokud je hlavní modul v podsložce, například website, zadejte tuto složku pomocí argumentu --chdir:

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

• Použití jiného serveru než Gunicorn: Pokud chcete použít jiný webový server, například aiohttp, použijte příslušný příkaz jako spouštěcí příkaz nebo v souboru spouštěcího příkazu:

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

Přístup k nastavení aplikace jako proměnným prostředí

Nastavení aplikace jsou hodnoty uložené v cloudu speciálně pro vaši aplikaci, jak je popsáno v tématu Konfigurace nastavení aplikace. Tato nastavení jsou pro kód aplikace dostupná jako proměnné prostředí a přístupná pomocí standardního vzoru os.environ .

Pokud jste například vytvořili nastavení aplikace s názvem DATABASE_SERVER, načte následující kód hodnotu tohoto nastavení:

db_server = os.environ['DATABASE_SERVER']

Detekce relace HTTPS

V App Service dochází k ukončení protokolu TLS/SSL (wikipedia.org) v nástrojích pro vyrovnávání zatížení sítě, takže všechny požadavky HTTPS se dostanou do vaší aplikace jako nešifrované požadavky HTTP. Pokud logika aplikace potřebuje zkontrolovat, jestli jsou požadavky uživatelů šifrované, zkontrolujte hlavičku X-Forwarded-Proto .

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

Oblíbené webové architektury umožňují přístup k informacím X-Forwarded-* ve standardním vzoru aplikace. Například v Djangu můžete pomocí SECURE_PROXY_SSL_HEADER nastavit, aby django použil hlavičku X-Forwarded-Proto .

Přístup k diagnostickým protokolům

Můžete získat přístup k protokolům konzoly vygenerovaným uvnitř kontejneru.

Nejprve zapněte protokolování kontejneru spuštěním následujícího příkazu:

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

Nahraďte <app-name> a <resource-group-name> názvy vhodnými pro vaši webovou aplikaci.

Jakmile je protokolování kontejneru zapnuté, spuštěním následujícího příkazu zobrazte stream protokolu:

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

Pokud nevidíte protokoly konzoly okamžitě, podívejte se znovu za 30 sekund.

Pokud chcete streamování protokolů kdykoli zastavit, zadejte Ctrl+C.

Soubory protokolu můžete také zkontrolovat v prohlížeči na adrese https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Pokud chcete získat přístup k protokolům prostřednictvím Azure Portal, vyberte Streamprotokolůmonitorování> v nabídce na levé straně vaší aplikace.

Přístup k protokolům nasazení

Když nasadíte kód, App Service provede proces sestavení popsaný výše v části Přizpůsobení automatizace sestavení. Vzhledem k tomu, že sestavení běží ve vlastním kontejneru, protokoly sestavení se ukládají odděleně od diagnostických protokolů aplikace.

Pro přístup k protokolům nasazení použijte následující postup:

1. Na Azure Portal pro vaši webovou aplikaci vyberte v nabídce vlevo Deployment>Deployment Center.
2. Na kartě Protokoly vyberte ID potvrzení pro nejnovější potvrzení.
3. Na stránce Podrobnosti protokolu , která se zobrazí, vyberte odkaz Zobrazit protokoly... , který se zobrazí vedle položky Spuštěný build Oryx.

V těchto protokolech se zobrazí problémy se sestavením, jako jsou nesprávné závislosti v requirements.txt a chyby ve skriptech před sestavením nebo po sestavení. Chyby se zobrazí také v případě, že soubor s požadavky nemá přesný název requirements.txt nebo se nezobrazuje v kořenové složce projektu.

Otevření relace SSH v prohlížeči

Pokud chcete otevřít přímou relaci SSH s kontejnerem, vaše aplikace by měla být spuštěná.

Vložte následující adresu URL do vašeho prohlížeče a <app-name> nahraďte názvem vaší aplikace:

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

Pokud ještě nejste ověření, budete se muset ověřit s vaším předplatným Azure, abyste se mohli připojit. Po ověření se vám zobrazí prostředí prohlížeče, ve kterém můžete spouště příkazy uvnitř vašeho kontejneru.

Pokud chcete otevřít vzdálenou relaci SSH z místního počítače, projděte si téma věnované otevření relace SSH ze vzdáleného prostředí.

Po úspěšném připojení k relaci SSH by se v dolní části okna měla zobrazit zpráva o navázání připojení SSH. Pokud se zobrazí chyby jako "SSH_CONNECTION_CLOSED" nebo zpráva, že se kontejner restartuje, může chyba bránit spuštění kontejneru aplikace. Postup pro prozkoumání možných problémů najdete v tématu Řešení potíží.

Řešení potíží

Obecně platí, že prvním krokem při řešení potíží je použití diagnostiky App Service:

1. V Azure Portal pro vaši webovou aplikaci vyberte v nabídce vlevo diagnostikovat a řešit problémy.
2. Vyberte Dostupnost a výkon.
3. Prozkoumejte informace v možnostech Protokoly aplikací, Selhání kontejneru a Problémy s kontejnerem , kde se zobrazí nejběžnější problémy.

Dále zkontrolujte protokoly nasazení i protokoly aplikací , jestli neobsahují chybové zprávy. Tyto protokoly často identifikují konkrétní problémy, které můžou bránit nasazení nebo spuštění aplikace. Sestavení může selhat například v případě, že soubor requirements.txt má nesprávný název souboru nebo se nenachází v kořenové složce projektu.

Následující části obsahují pokyny pro konkrétní problémy.

• Aplikace se nezobrazuje – zobrazí se výchozí aplikace.
• Aplikace se nezobrazuje – zpráva o nedostupnosti služby
• Nelze najít setup.py nebo requirements.txt.
• ModuleNotFoundError při spuštění
• Databáze je uzamčená.
• Hesla se při zadání nezobrazují v relaci SSH
• Zdá se, že příkazy v relaci SSH jsou oříznuté
• Statické prostředky se nezobrazují v aplikaci Django
• Vyžaduje se závažné připojení SSL.

Aplikace se nezobrazuje

• Výchozí aplikaci uvidíte po nasazení kódu vlastní aplikace. Výchozí aplikace se zobrazí, protože jste buď nenasadili kód aplikace do App Service, nebo App Service kód aplikace nenašli a místo toho spustili výchozí aplikaci.

  • Restartujte službu App Service, počkejte 15-20 sekund a znovu zkontrolujte aplikaci.

  • Pomocí SSH se připojte přímo ke kontejneru App Service a ověřte, že vaše soubory existují ve složce site/wwwroot. Pokud vaše soubory neexistují, postupujte následovně:

    1. Vytvořte nastavení aplikace s názvem SCM_DO_BUILD_DURING_DEPLOYMENT s hodnotou 1, znovu nasaďte kód, počkejte několik minut a pak se znovu pokuste o přístup k aplikaci. Další informace o vytváření nastavení aplikace najdete v tématu Konfigurace aplikace App Service v Azure Portal.
    2. Zkontrolujte proces nasazení, zkontrolujte protokoly nasazení, opravte případné chyby a nasaďte aplikaci znovu.

  • Pokud soubory existují, neidentifikovala služba App Service konkrétní spouštěcí soubor. Zkontrolujte, že má aplikace strukturu, kterou služba App Service očekává u aplikací Django nebo Flask, nebo použijte vlastní spouštěcí příkaz.

• V prohlížeči se zobrazí zpráva Služba není k dispozici. Prohlížeč vypršel časový limit čekání na odpověď z App Service, což značí, že App Service spustil server Gunicorn, ale aplikace samotná se nespustila. Tato podmínka může znamenat, že argumenty Gunicorn jsou nesprávné nebo že kód aplikace obsahuje chybu.

  • Aktualizujte okno prohlížeče, zejména v případě, že používáte nejnižší cenové úrovně v Plánu služby App Service. Aplikace se může spouštět pomaleji (když používáte například úrovně free) a po aktualizaci okna prohlížeče začne znovu odpovídat.

  • Zkontrolujte, že má aplikace strukturu, kterou služba App Service očekává u aplikací Django nebo Flask, nebo použijte vlastní spouštěcí příkaz.

  • Zkontrolujte , že stream protokolu aplikace nemá žádné chybové zprávy. V protokolech se zobrazí všechny chyby v kódu aplikace.

Nelze najít setup.py nebo requirements.txt

• Datový proud protokolu zobrazí "Nelze najít setup.py nebo requirements.txt; Nejde spustit pip install.": Procesu sestavení Oryx se nepodařilo najít soubor requirements.txt .

  • Připojte se ke kontejneru webové aplikace přes SSH a ověřte, že requirements.txt má správný název a existuje přímo na webu/wwwroot. Pokud neexistuje, nastavte web na soubor, který existuje ve vašem úložišti a je součástí vašeho nasazení. Pokud existuje v samostatné složce, přesuňte ji do kořenového adresáře.

ModuleNotFoundError při spuštění aplikace

Pokud se zobrazí chyba typu ModuleNotFoundError: No module named 'example', Python při spuštění aplikace nemohl najít jeden nebo více modulů. K této chybě nejčastěji dochází v případě, že nasadíte virtuální prostředí pomocí kódu. Virtuální prostředí nejsou přenosná, takže by se nemělo nasazovat s kódem vaší aplikace. Místo toho nechejte oryx vytvořit virtuální prostředí a nainstalovat balíčky do webové aplikace tak, SCM_DO_BUILD_DURING_DEPLOYMENTže vytvoří nastavení aplikace a nastaví ho na 1. Toto nastavení vynutí, aby oryx nainstaloval balíčky pokaždé, když nasadíte App Service. Další informace najdete v tomto článku o přenositelnosti virtuálního prostředí.

Databáze je uzamčená.

Při pokusu o spuštění migrace databází pomocí aplikace Django se může zobrazit zpráva sqlite3. OperationalError: Databáze je uzamčená. Tato chyba značí, že vaše aplikace používá databázi SQLite, pro kterou je ve výchozím nastavení nakonfigurovaný Django, a nepoužívá cloudovou databázi, jako je PostgreSQL for Azure.

Zkontrolujte proměnnou DATABASES v souboru settings.py aplikace a ujistěte se, že vaše aplikace místo SQLite používá cloudovou databázi.

Pokud u ukázky v kurzu Nasazení webové aplikace Django s PostgreSQL dochází k této chybě, zkontrolujte, že jste dokončili kroky v části Ověření nastavení připojení.

Další problémy

• Hesla se při zadání nezobrazují v relaci SSH: Z bezpečnostních důvodů relace SSH při psaní heslo skryje. Znaky se ale zaznamenají, takže zadejte heslo jako obvykle a po dokončení stiskněte Klávesu Enter .

• Zdá se, že příkazy v relaci SSH jsou oříznuté: Editor nemusí být příkazy pro obtékání slov, ale přesto by měly běžet správně.

• Statické prostředky se nezobrazují v aplikaci Django: Ujistěte se, že jste povolili modul whitenoise.

• Zobrazí se zpráva "Vyžaduje se závažné připojení SSL": Zkontrolujte všechna uživatelská jména a hesla používaná pro přístup k prostředkům (například databázím) z aplikace.

Další zdroje informací

• Kurz: Aplikace v Pythonu s PostgreSQL
• Kurz: Nasazení z privátního úložiště kontejneru
• Nejčastější dotazy k App Service v Linuxu
• Referenční informace k proměnným prostředí a nastavením aplikací