Sdílet prostřednictvím

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

  • Článek

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

Nasazovací modul služby App Service automaticky aktivuje virtuální prostředí a spustí pip install -r requirements.txt se za vás při nasazení úložiště Git nebo balíčku ZIP s 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 ve službě App Service. Pokud jste nikdy nepoužívali službu Aplikace Azure Service, nejprve postupujte podle kurzu Rychlý start k Pythonu a Pythonu s PostgreSQL.

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 si ale vytvořit vlastní image kontejneru Windows a spustit ji ve službě App Service. Další informace najdete v tématu věnovaném použití vlastní image Dockeru.

Konfigurace verze Pythonu

  • Azure Portal: Na stránce Konfigurace použijte kartu Obecné nastavení, jak je popsáno v části 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 vhodné pro vaši webovou aplikaci a <app-name> nahraďte je názvy.

    • Nastavení verze Pythonu pomocí az webapp config set

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

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

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

Nepodporovanou verzi Pythonu můžete spustit 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í služby App Service s názvem Oryx provede při nasazení aplikace následující kroky, pokud je nastavení SCM_DO_BUILD_DURING_DEPLOYMENT aplikace nastavené na 1:

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

  2. Spusťte pip install -r requirements.txt. Soubor requirements.txt musí být v kořenové složce projektu. Jinak 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ě (označující aplikaci Django), spusťte manage.py collectstatic. Pokud je trueale DISABLE_COLLECTSTATIC toto nastavení , tento krok se přeskočí.

  4. Pokud je zadaný nastavením POST_BUILD_COMMAND , spusťte vlastní skript po 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 hodnoty PRE_BUILD_COMMAND, POST_BUILD_COMMANDa DISABLE_COLLECTSTATIC nastavení prázdné.

  • Pokud chcete zakázat spouštění collectstatic při sestavování 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 command, nebo cestu k souboru skriptu vzhledem k 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 spustit 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 k 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ůsobí automatizaci sestavení, najdete v tématu Konfigurace Oryxu.

Přístup 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 jsou POST_BUILD_SCRIPT_PATH identické PRE_BUILD_COMMAND POST_BUILD_COMMAND a podporují se pro starší účely.

Nastavení s názvem SCM_DO_BUILD_DURING_DEPLOYMENT, pokud obsahuje true nebo 1, aktivuje sestavení Oryx během nasazení. Toto nastavení platí při nasazování pomocí Gitu, příkazu az webapp upAzure CLI 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ěná pod webem nebo wwwroot).

Migrace existují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ě: 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í.

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

  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í vaší aplikace. Můžete to snadno provést 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: Nasazení webové aplikace v Pythonu (Django nebo Flask) pomocí PostgreSQL. Nahraďte názvy skupiny prostředků, plánu služby App Service a webové aplikace, aby byly pro vaši aplikaci vhodnější.

  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 proměnných prostředí accessu.

  5. Spuštění aplikace: Projděte si část Proces spuštění kontejneru dále v tomto článku a zjistěte, jak se app Service pokouší spustit vaši aplikaci. Služba 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 služby Aplikace Azure 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 Aplikace Azure 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 ke kontejneru připojit přes SSH. Příklad spuštění migrací databází Django najdete v tématu Kurz: Nasazení webové aplikace Django s PostgreSQL – generování schématu databáze.

    • Při použití průběžného 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ěchtokrokůch

Produkční nastavení pro aplikace Django

V produkčním prostředí, jako je služba Aplikace Azure Service, by aplikace Django měly postupovat podle kontrolního seznamu nasazení Django (djangoproject.com).

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ý kód" ve službě Azure Key Vault.
DEBUG Vytvořte DEBUG nastavení ve službě App Service s hodnotou 0 (false) a pak načtěte hodnotu 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 settings.py zahrnuli adresu URL ALLOWED_HOSTS 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 Azure 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 , aby /django-static/ 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 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 k místu, kde se spouští nástroj sestavení, FRONTEND_DIRjako je například 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ý usnadňuje obsluhu vlastních statických souborů v produkční aplikaci Django. Whitenoise konkrétně slouží k souborům, 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 MIDDLEWARE také seznamy 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ů 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 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 se spouští pomocí Serveru HTTP Gunicorn WSGI s použitím další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.

    • Kvůli ochraně webové aplikace před náhodnými nebo úmyslnými útoky DDOS se Gunicorn spouští za reverzním proxy serverem Nginx, jak je popsáno v tématu Nasazení Gunicornu (docs.gunicorn.org).

  • Ve výchozím nastavení obsahuje základní image kontejneru pouze webovou architekturu Flask, ale kontejner podporuje další architektury, které 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 projektu soubor requirements.txt , který určuje přímé závislosti. App Service pak tyto závislosti nainstaluje automaticky při nasazení projektu.

    Aby bylo možné nainstalovat závislosti, musí být soubor requirements.txt v kořenovém adresáři projektu. Jinak 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 s adresou URL webové aplikace, například msdocs-hello-world.azurewebsites.net. Definuje také WEBSITE_SITE_NAME název vaší aplikace, například msdocs-hello-world.

  • Npm a Node.js jsou nainstalované v 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 v případě zjištění spusťte 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

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 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 se například wsgi.py nachází 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 a --error-logfile parametry, jak je znázorněno v příkladech pro vlastní spouštěcí příkazy.

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 nebo chcete gunicornu zadat jiné 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 v Linuxu

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 nezobrazí.

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, startup.txt atd.

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

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

  • Azure Portal: Vyberte stránku Konfigurace aplikace a pak vyberte Obecné nastavení. Do pole Spouštěcí příkaz umístěte 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, zkontrolujte, jestli je spouštěcí příkaz nebo soubor 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 . Na webu Azure Portal se také podívejte na 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 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 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íků gunicornu 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í ve streamu protokolu služby App Service.

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

  • 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. 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ž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ým 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á pomocí standardního vzoru os.environ .

Pokud jste například vytvořili 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 (wikipedia.org) v nástrojích pro vyrovnávání zatížení sítě, takže všechny požadavky HTTPS se dostanou k vaší aplikaci jako nešifrované požadavky HTTP. Pokud logika vaší aplikace potřebuje zkontrolovat, jestli jsou požadavky uživatelů šifrované, nebo ne, 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 standardním vzoru aplikace. Například v Django můžete použít SECURE_PROXY_SSL_HEADER k tomu, aby Django použil hlavičku X-Forwarded-Proto .

Přístup k diagnostickým protokolům

Přístup k protokolům konzoly vygenerovaným z 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> názvy vhodné pro vaši webovou aplikaci a <resource-group-name> nahraďte je názvy.

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 webu Azure Portal, v nabídce na levé straně aplikace vyberte Stream protokolu monitorování>.

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 webu Azure Portal pro vaši webovou aplikaci vyberte v nabídce vlevo 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 možnosti Spuštěno sestavení oryx....

V těchtoprotokolch requirements.txt ch Chyby se zobrazí také v případě, že soubor požadavků není přesně pojmenovaný 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.

Připojení SSH

Poznámka:

Všechny změny provedené mimo adresář /home se uloží ve vlastním kontejneru a po restartování aplikace se neuchovají.

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í.

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, jako je SSH_CONNECTION_CLOSED nebo zpráva, že se kontejner restartuje, může se stát, že kontejner aplikace nemůže spustit. Prošetřová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ě Aplikace Azure Service pro Linux možná budete muset zpracovat přepisy adres URL ve vaší aplikaci. To je užitečné zejména 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 je možné k tomu použít procesory ADRES URL a vlastní middleware. V aplikacích Django umožňuje robustní dispečer adres URL 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 webu Azure Portal pro vaši webovou aplikaci v nabídce vlevo vyberte Diagnostikovat a řešit problémy .
  2. Vyberte Dostupnost a výkon.
  3. Projděte si informace v možnostech Protokoly aplikací, Chybové ukončení kontejneru a Problémy s kontejnery, kde se zobrazí nejběžnější problémy.

Dále zkontrolujte protokoly nasazení i protokoly aplikace, kde se zobrazí chybové zprávy. 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 má váš soubor requirements.txt nesprávný název souboru nebo 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 se službě App Service nepodařilo najít kód aplikace a místo toho spustit 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 služby App Service a ověřte, že vaše soubory existují v rámci webu nebo wwwroot. Pokud vaše soubory neexistují, postupujte následovně:

      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 zkuste aplikaci znovu otevřít. 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 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. V prohlížeči vypršel časový limit čekání na odpověď služby App Service, která značí, ž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 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 stream protokolu aplikace a zkontrolujte případné chybové zprávy. V protokolech se v kódu aplikace zobrazí všechny chyby.

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

  • Datový proud protokolu ukazuje, že se nepodařilo najít setup.py nebo requirements.txt; Nespouštět instalaci pip.": Proces sestavení Oryx se nepodařilo najít váš requirements.txt soubor.

    • Připojte se ke kontejneru webové aplikace přes SSH a ověřte, že requirements.txt je správně pojmenovaná a existuje přímo pod webem nebo wwwroot. Pokud neexistuje, vytvořte web, aby soubor existoval 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í podobná chyba ModuleNotFoundError: No module named 'example', Python při spuštění aplikace nemůže 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í s 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 při každém nasazení do služby 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í migrací databází 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 ne pomocí cloudové databáze, jako je PostgreSQL pro Azure.

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í, proto zadejte heslo obvyklým způsobem a po dokončení stiskněte Enter .

  • Zdá se, že příkazy v relaci SSH jsou oříznuté: Editor nemusí být příkazy pro zabalení 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 "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 (jako jsou databáze) z aplikace.

Další materiály