Sdílet prostřednictvím

Konfigurace aplikace v Pythonu pro Linux pro službu Aplikace Azure Service

Nasazení do Azure

Tento článek popisuje, jak Azure App Service spouští aplikace Pythonu, jak můžete migrovat existující aplikace do Azure a jak můžete přizpůsobit chování služby App Service, když potřebujete. Aplikace v Pythonu musí být nasazené se všemi požadovanými moduly pip .

Modul nasazení služby App Service automaticky aktivuje virtuální prostředí a nainstaluje závislosti z requirements.txtúložiště , pyproject.tomlnebo setup.py souboru, když nasadíte úložiště Git nebo když nasadíte balíček ZIPs povolenou automatizací sestavení.

Tento článek obsahuje klíčové koncepty a pokyny pro vývojáře v Pythonu, kteří používají integrovaný kontejner Linuxu ve službě App Service. Pokud jste službu App Service nikdy nepoužívali, nejprve pomocí kurzu PostgreSQL proveďte rychlý start Pythonu a Flask, Django nebo FastAPI .

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

Poznámka:

Linux je jedinou možností operačního systému pro spouštění aplikací v Pythonu ve službě App Service. Python ve Windows se už nepodporuje. Můžete ale vytvořit vlastní image kontejneru Windows a spustit ji ve službě App Service. Další informace najdete v tématu Použití vlastní image Dockeru.

Konfigurace verze Pythonu

  • Azure Portal: Na stránce Konfigurace použijte kartu Obecné nastavení, 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> názvy <app-name> , které jsou vhodné pro vaši webovou aplikaci.

    • Nastavte verzi Pythonu pomocí az webapp config set:

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

    • Zobrazení všech verzí Pythonu podporovaných ve službě App Service pomocí příkazu az webapp list-runtimes:

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

Nepodporovanou verzi Pythonu můžete spustit vytvořením vlastní image kontejneru. Další informace najdete v tématu Použití vlastní image Dockeru.

Co se stane se zastaralými runtimy ve službě App Service?

Zastaralé moduly runtime jsou zastaralá údržbou organizace nebo mají významná ohrožení zabezpečení. Proto se odeberou z vytváření a konfigurace stránek na portálu. Pokud je zastaralý modul runtime skrytý na portálu, všechny aplikace, které stále používají tento modul runtime, budou dál běžet.

Pokud chcete vytvořit aplikaci se zastaralou verzí modulu runtime, která se už na portálu nezobrazuje, použijte Azure CLI, šablonu ARM nebo Bicep. Tyto alternativy nasazení umožňují vytvářet zastaralé moduly runtime, které se odeberou z portálu, ale stále se podporují.

Pokud je modul runtime plně odebraný z platformy Služby App Service, obdrží vlastník předplatného Azure před odebráním e-mailové oznámení.

Přizpůsobte automatizaci sestavení

Poznámka:

Když se aplikace Pythonu nasadí s automatizací sestavení, obsah se nasadí do a obsluhuje z , nikoli v /tmp/<uid>části /home/site/wwwroot. K tomuto adresáři obsahu se dostanete pomocí APP_PATH proměnné prostředí. Všechny další soubory vytvořené za běhu byste měli zapsat do umístění /home nebo pomocí funkce Přineste si vlastní úložiště pro trvalost. Další informace o tomto chování najdete v tématu Změny sestavení Pythonu.

Když nasadíte aplikaci, provede systém sestavení app Service s názvem Oryx následující kroky, pokud je nastavení SCM_DO_BUILD_DURING_DEPLOYMENT aplikace nastavené na 1:

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

  2. Nainstalujte závislosti. Systém sestavení zkontroluje následující soubory v kořenovém adresáři projektu:

    • requirements.txt: Spouští pip install -r requirements.txt.
    • pyproject.toml s uv.lock: Používá uv.
    • pyproject.toml s poetry.lock: Používá poetry.
    • pyproject.toml: Používá poetry.
    • setup.py: Spouští pip install ..

    Poznámka:

    Pokud je pyproject.toml přítomen, ale uv.lock chybí, App Service ve výchozím nastavení používá Poetry, i když poetry.lock také chybí. Pokud chcete použít uv, musíte do nasazení zahrnout uv.lock .

    Pokud se žádný z těchto souborů nenajde, proces sestavení hlásí chybu "Nepodařilo se najít setup.py nebo requirements.txt; Nespouštět instalaci pipu."

  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 collectstaticpříkaz . Pokud je nastavení DISABLE_COLLECTSTATIC na true, tento krok se přeskočí.

  4. Pokud je tento krok zadaný v nastavení, spusťte vlastní skript po POST_BUILD_COMMAND sestavení. (Skript může znovu spouštět další skripty Pythonu a Node.js, příkazy pip a npm a nástroje založené na uzlech.)

Ve výchozím nastavení jsou nastavení PRE_BUILD_COMMAND, POST_BUILD_COMMAND a DISABLE_COLLECTSTATIC prázdná.

  • Chcete-li zakázat spouštění collectstatic při vytváření aplikací Django, nastavte DISABLE_COLLECTSTATIC nastavení na truehodnotu .

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

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

Informace o dalších nastaveních, která přizpůsobují automatizaci sestavení, najdete v tématu Konfigurace Oryxu.

Informace o přístupu k protokolům sestavení a nasazení najdete v tématu Protokoly nasazení accessu.

Další informace o tom, jak App Service běží a vytváří aplikace v Pythonu v Linuxu, najdete v tématu Jak Oryx rozpozná a sestaví aplikace v Pythonu.

Poznámka:

Nastavení PRE_BUILD_SCRIPT_PATH a POST_BUILD_SCRIPT_PATH jsou identické s PRE_BUILD_COMMAND a POST_BUILD_COMMAND a jsou podporována pro účely kompatibility se staršími verzemi.

Nastavení s názvem SCM_DO_BUILD_DURING_DEPLOYMENT, pokud obsahuje true nebo 1, aktivuje sestavení Oryx, které se stane během nasazení. Nastavení je true při nasazování pomocí Gitu, příkazu Azure CLI az webapp up a editoru Visual Studio Code.

Poznámka:

Vždy používejte relativní cesty ve všech skriptech před sestavením a po sestavení, protože kontejner sestavení, ve kterém běží Oryx, se liší od kontejneru modulu runtime, ve kterém aplikace běží. Nikdy nespoléhejte na přesné umístění složky projektu aplikace v rámci kontejneru (například že je umístěna pod site/wwwroot).

Migrace existujících aplikací do Azure

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

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

    • Soubor závislostí (například requirements.txt, pyproject.toml nebo setup.py) musí být v kořenovém adresáři úložiště, pokud chcete, aby služba App Service automaticky nainstalovala potřebné balíčky.

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

  3. Prostředky služby App Service. Vytvořte skupinu prostředků, plán služby App Service a webovou aplikaci App Service pro hostování aplikace. Tyto prostředky můžete snadno vytvořit spuštěním příkazu az webapp upAzure CLI . Nebo můžete vytvářet a nasazovat prostředky, jak je znázorněno v kurzu Flask, Django nebo FastAPI s PostgreSQL. Názvy skupiny prostředků, plánu služby App Service a webové aplikace nahraďte názvy vhodnými pro vaši aplikaci.

  4. Proměnné prostředí. Pokud vaše aplikace vyžaduje nějaké proměnné prostředí, vytvořte ekvivalentní nastavení aplikace služby App Service. Tato nastavení služby App Service se vašemu kódu zobrazují jako proměnné prostředí, jak je popsáno v přístupu k proměnným prostředí.

  5. Spuštění aplikace Informace o tom, jak se app Service pokusí spustit aplikaci, najdete v části Proces spuštění kontejneru dále v tomto článku. Služba App Service ve výchozím nastavení používá webový server Gunicorn. Gunicorn musí být schopen najít objekt aplikace nebo wsgi.py složku. Pokud potřebujete, 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 nastavte průběžné nasazování z místního Gitu, jak je popsáno v článku Místní nasazení Gitu do služby Azure App Service.

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

Po dokončení těchto kroků byste měli být schopni zapsat změny do svého zdrojového úložiště a tyto aktualizace by měly být automaticky nasazeny do App Service.

Produkční nastavení pro aplikace Django

V produkčním prostředí, jako je App Service, by aplikace Django měly postupovat podle pokynů v kontrolním seznamu nasazení Django.

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

Nastavení Django Pokyny pro Azure
SECRET_KEY Uložte hodnotu v nastavení služby App Service, jak je popsáno v nastavení aplikace pro Access jako proměnné prostředí. Hodnotu můžete uložit jako tajný klíč ve službě Azure Key Vault.
DEBUG Vytvořte DEBUG nastavení ve službě App Service s hodnotou 0 (false) a pak ji načtěte jako proměnnou prostředí. Ve vývojovém prostředí vytvořte proměnnou DEBUG prostředí s hodnotou 1 (true).
ALLOWED_HOSTS V produkčním prostředí vyžaduje Django, abyste do pole ALLOWED_HOSTS zahrnuli adresu URL aplikace. Tuto adresu URL můžete načíst za běhu pomocí kódu os.environ['WEBSITE_HOSTNAME']. App Service automaticky nastaví proměnnou WEBSITE_HOSTNAME prostředí na adresu URL aplikace.
DATABASES Definujte nastavení ve službě App Service pro připojení k databázi a načtěte je jako proměnné prostředí pro naplnění slovníku DATABASES . Hodnoty (zejména uživatelské jméno a heslo) můžete uložit jako tajné kódy služby Key Vault.

Obsluha statických souborů pro aplikace Django

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

V případě služby App Service pak provedete následující úpravy:

  1. Zvažte použití proměnných prostředí (pro místní vývoj) a nastavení aplikací (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 podle potřeby je možné změnit pro vaše místní a cloudová prostředí. Pokud je například proces sestavení pro statické soubory umístí do složky s názvem django-static, můžete nastavit DJANGO_STATIC_URL , /django-static/ aby se zabránilo 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 yarn build front-endovou složku a Yarn vygeneruje build/static složku obsahující statické soubory, zahrňte tuto složku, jak je znázorněno tady:

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

    V tomto kódu se používá k sestavení cesty k místu, kde se spouští nástroj sestavení, FRONTEND_DIR jako je Yarn. Pokud chcete, 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ý usnadňuje obsluhu vlastních statických souborů v produkční aplikaci Django. WhiteNoise obsluhuje soubory, které jsou nalezeny 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 seznamy MIDDLEWARE tak INSTALLED_APPS , 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 vaše webová aplikace Flask obsahuje statické front-endové soubory, nejprve postupujte podle pokynů při správě statických souborů v dokumentaci k Flasku. Příklad obsluhy statických souborů v aplikaci Flask najdete v ukázkové aplikaci Flask na GitHubu.

Pokud chcete obsluhovat statické soubory přímo ze trasy ve vaší aplikaci, můžete použít tuto 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 služby App Service se aplikace Pythonu spouštějí v kontejneru Dockeru pro Linux, který je definovaný v úložišti GitHub v Pythonu služby App Service. Konfigurace imagí najdete v adresářích specifických pro verzi.

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

  • Aplikace jsou spuštěny Gunicorn WSGI HTTP Server s dodatečnými argumenty --bind=0.0.0.0 --timeout 600.

  • Ve výchozím nastavení obsahuje základní image kontejneru pouze webovou architekturu Flask, ale kontejner podporuje i jiné architektury, které jsou kompatibilní se službou WSGI a kompatibilní s Pythonem 3.6 a novějším, například Django.

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

    Soubor závislostí musí být v kořenovém adresáři projektu nebo nebudou nainstalovány závislosti. Pokud tento soubor není v kořenovém adresáři, proces sestavení hlásí chybu "Nepodařilo se najít setup.py nebo requirements.txt; Nespouštět instalaci pipu." Pokud k této chybě dojde, zkontrolujte umístění souboru požadavků.

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

  • Npm a Node.js se instalují do kontejneru, takže můžete spouštět nástroje sestavení založené na uzlu, jako je například 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 existenci aplikace Django a pokud se zjistí, spusťte pro ni Gunicorn.
  3. Zkontrolujte existenci aplikace Flask a pokud se zjistí, spusťte pro ni 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

V případě aplikací Django vyhledá App Service soubor s názvem wsgi.py v kódu vaší aplikace a pak pomocí následujícího příkazu spustí Gunicorn:

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

Pokud chcete 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 tento modul není v kořenovém adresáři projektu. Pokud je například váš wsgi.py umístěn pod knboard, back-end/config z kořenového adresáře projektu, použijte argumenty --chdir knboard/backend config.wsgi.

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

Aplikace Flask

App Service pro Flask 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. Pokud chcete gunicornu poskytnout další argumenty, použijte vlastní spouštěcí příkaz.

Výchozí chování

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

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

Snímek obrazovky s výchozí webovou stránkou App Service na Linuxu

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 několika příkazů v souboru spouštěcího příkazu. Spouštěcí soubor příkazu může použít jakýkoli název, například startup.sh, startup.cmd nebo startup.txt.

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

Zadání spouštěcího příkazu nebo souboru příkazu:

  • Azure Portal. V části Nastavení v levém podokně stránky aplikace vyberte Konfigurace a pak vyberte Obecné nastavení. Do pole Spouštěcí příkaz zadejte celý text spouštěcího příkazu nebo název spouštěcího souboru příkazu. Potom 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> úplným textem spouštěcího příkazu nebo názvem spouštěcího souboru 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 spuštění hledáním aplikací Django a Flask. Pokud očekávané chování nevidíte, ověřte, že spouštěcí příkaz nebo soubor jsou bez chyb a že se soubor spouštěcího příkazu nasadí do služby App Service spolu s kódem vaší aplikace. Další informace najdete také v diagnostických protokolech . A na webu Azure Portal můžete zkontrolovat stránku Diagnostika a řešení problémů aplikace.

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

  • Přidání argumentů Gunicorn: Následující příklad přidá --workers=4 argument do příkazového řádku 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 that contains wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    Další informace najdete v tématu Spuštění Gunicornu. 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ů gunicornu najdete v nejčastějších dotazech ke gunicornu.

  • Povolení produkčního protokolování pro Django: Přidejte argumenty --access-logfile '-'--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í v protokolovém toku služby App Service.

    Další informace viz Gunicorn logování.

  • Vlastní hlavní modul Flask: Služba App Service ve výchozím nastavení 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. Pokud máte například aplikaci Flask, jejíž hlavní modul je hello.py a objekt aplikace Flask v tomto souboru má název myapp, jedná se o příkaz:

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

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

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

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

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

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

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

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

db_server = os.environ['DATABASE_SERVER']

Zjištění relace HTTPS

Ve službě App Service dochází k ukončení protokolu TLS/SSL v nástrojích pro vyrovnávání zatížení sítě, takže všechny požadavky HTTPS dosáhnou vaší aplikace jako nešifrované požadavky HTTP. Pokud logika vaší aplikace potřebuje zkontrolovat, jestli jsou požadavky uživatelů zaš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 X-Forwarded-* informacím ve vašem standardním vzoru aplikace. Například v Django můžete použít SECURE_PROXY_SSL_HEADER ke konfiguraci Django tak, aby používala hlavičku X-Forwarded-Proto .

Přístup k diagnostickým protokolům

Můžete získat přístup k protokolům konzoly, které se generují z kontejneru.

Protokolování kontejneru zapnete 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 hodnoty <app-name> a <resource-group-name> názvy, které jsou vhodné pro vaši webovou aplikaci.

Po zapnutí protokolování kontejneru spusťte následující příkaz, abyste viděli stream protokolu:

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

Pokud se protokoly konzoly nezobrazí okamžitě, zkontrolujte to znovu za 30 sekund.

Pokud chcete streamování protokolů kdykoli zastavit, použijte klávesovou zkratku Ctrl+C.

Pokud chcete získat přístup k protokolům na webu Azure Portal, vybertestream protokolu> v levém podokně 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 se sestavení spouští ve vlastním kontejneru, ukládají se protokoly sestavení odděleně od diagnostických protokolů aplikace.

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

  1. Na stránce webu Azure Portal pro webovou aplikaci vyberte v levém podokněCentrum nasazení>.
  2. Na kartě Protokoly vyberte ID potvrzení pro poslední potvrzení.
  3. Na stránce s podrobnostmi protokolu , která se zobrazí, vyberte odkaz Zobrazit protokoly , který se zobrazí vedle sestavení Spuštěno oryx.

V těchto protokolech se zobrazí problémy se sestavením, jako jsou nesprávné závislosti v souboru závislostí a chyby ve skriptech před sestavením nebo po sestavení. Chyby se zobrazí také v případě, že se váš soubor závislostí nenajde v kořenové složce projektu.

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

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

Použijte příkaz az webapp ssh .

Pokud nejste ověřeni, musíte se ověřit ve svém předplatném Azure, abyste se mohli připojit. Po ověření se zobrazí prostředí v prohlížeči, ve kterém můžete spouštět příkazy v kontejneru.

Připojení SSH

Poznámka:

Všechny změny, které uděláte mimo /home adresář, se uloží do samotného kontejneru a nezachovají se za restartováním aplikace.

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

Když jste úspěšně připojeni k relaci SSH, měla by se v dolní části okna zobrazit zpráva PŘIPOJENÍ SSH NAVÁZÁNO. Pokud se zobrazí chyby typu "SSH_CONNECTION_CLOSED" nebo zpráva s oznámením, že se kontejner restartuje, může se stát, že kontejner aplikace nebude spuštěný. Informace o zkoumání možných problémů najdete v tématu Řešení potíží .

Přepsání adresy URL

Při nasazování aplikací Pythonu ve službě App Service pro Linux možná budete muset zpracovat přepisy adres URL v rámci vaší aplikace. Tato metoda je zvláště užitečná pro zajištění přesměrování konkrétních vzorů adres URL na správné koncové body bez nutnosti spoléhat se na konfigurace externího webového serveru. Pro aplikace Flask můžete k tomu použít procesory ADRES URL a vlastní middleware. V aplikacích Django dispečer adres URL umožňuje efektivní správu přepisů adres URL.

Řešení problému

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

  1. Na stránce webu Azure Portal pro vaši webovou aplikaci vyberte v levém podokně Diagnostikovat a řešit problémy .
  2. Vyberte Dostupnost a výkon.
  3. Projděte si informace v protokolech aplikací, chybových ukončeních kontejneru a problémech s kontejnery, kde se zobrazují nejběžnější problémy.

Dále zkontrolujte protokoly nasazení i protokoly aplikace kvůli případným chybovým zprávám. Tyto protokoly často identifikují konkrétní problémy, které můžou bránit nasazení aplikace nebo spuštění aplikace. Sestavení může například selhat, pokud soubor závislostí není v kořenové složce projektu.

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

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 služby App Service, nebo protože se službě App Service nepodařilo najít kód aplikace a spustit výchozí aplikaci.

    • Restartujte aplikaci, počkejte 20 sekund a pak aplikaci znovu zkontrolujte.

    • Pomocí SSH se připojte přímo ke kontejneru App Service a ověřte, že vaše soubory existují v adresáři site/wwwroot. Pokud vaše soubory neexistují, proveďte následující kroky:

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

    • Pokud vaše soubory existují, služba App Service nemohla identifikovat spouštěcí soubor. Ujistěte se, že je vaše aplikace strukturovaná podle očekávání služby App Service pro 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. Vypršel časový limit prohlížeče, který čeká na odpověď ze služby App Service. To znamená, že Služba App Service spustila server Gunicorn, ale samotná aplikace se nespustila. Tato podmínka může znamenat, že argumenty Gunicorn jsou nesprávné nebo že kód aplikace obsahuje chybu.

    • Aktualizujte prohlížeč, zejména pokud v plánu služby App Service používáte nejnižší cenové úrovně. Spuštění aplikace může trvat delší dobu, když například používáte úrovně Free a po aktualizaci prohlížeče se začnou reagovat.

    • Ověřte, že je vaše aplikace strukturovaná podle očekávání služby App Service pro Django nebo Flask, nebo použijte vlastní spouštěcí příkaz.

    • Zkontrolujte stream protokolu aplikace a vyhledejte chybové zprávy. V protokolech se v kódu aplikace zobrazí všechny chyby.

Nepodařilo se najít setup.py nebo requirements.txt

  • Protokolový proud ukazuje, že se nepodařilo najít setup.py nebo requirements.txt; Instalace pip nebyla spuštěna." Proces sestavení Oryx se nepodařilo najít váš soubor requirements.txt, pyproject.toml nebo setup.py.

    • Připojte se ke kontejneru webové aplikace přes SSH a ověřte, že je soubor závislostí správně pojmenován a nachází se přímo pod site/wwwroot. Pokud neexistuje, ujistěte se, že soubor 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 při spuštění aplikace zobrazí chyba typu ModuleNotFoundError: No module named 'example', Python nenašel jeden nebo více modulů. K této chybě nejčastěji dochází v případě, že nasadíte virtuální prostředí s vaším kódem. Virtuální prostředí nejsou přenosná, takže virtuální prostředí by se nemělo nasazovat s kódem vaší aplikace. Místo toho nechte Oryx vytvořit virtuální prostředí a nainstalovat balíčky do webové aplikace vytvořením nastavení SCM_DO_BUILD_DURING_DEPLOYMENTaplikace a nastavením na 1. Toto nastavení vynutí, aby Oryx nainstaloval balíčky pokaždé, když nasadíte do služby App Service. Další informace najdete v tomto článku o přenositelnosti virtuálních prostředí.

Databáze je uzamčená.

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

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

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

Další problémy

  • Hesla se při psaní nezobrazují v relaci SSH: Z bezpečnostních důvodů relace SSH uchovává vaše heslo při psaní skryté. Tyto znaky se ale zaznamenávají, takže zadejte heslo obvyklým způsobem a až budete hotovi, vyberte Enter .

  • Zdá se, že příkazy v relaci SSH jsou oříznuté: Editor nemusí zalamovat příkazy, 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 "Závažné připojení SSL je povinné": 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.

Související obsah

  • Last updated on