Megosztás a következőn keresztül:

Linux Python-alkalmazás konfigurálása Azure-alkalmazás szolgáltatáshoz

Üzembe helyezés az Azure-ban

Ez a cikk bemutatja, hogyan futtatja a Azure-alkalmazás Szolgáltatás a Python-alkalmazásokat, hogyan migrálhatja a meglévő alkalmazásokat az Azure-ba, és hogyan szabhatja testre az App Service viselkedését szükség esetén. A Python-alkalmazásokat az összes szükséges pipmodullal együtt kell üzembe helyezni.

Az App Service üzembehelyezési motorja automatikusan aktivál egy virtuális környezetet, és függőségeket telepít egy requirements.txt, vagy pyproject.tomlsetup.py fájlból egy Git-adattár üzembe helyezésekor, illetve egy zip-csomag üzembe helyezésekor, amelyen engedélyezve van a buildautomatizálás.

Ez a cikk alapvető fogalmakat és utasításokat tartalmaz az App Service-ben beépített Linux-tárolót használó Python-fejlesztők számára. Ha még soha nem használta az App Service-t, először végezze el a Python rövid útmutatóját és a Flask, a Django vagy a FastAPI használatát a PostgreSQL-oktatóanyaggal.

A konfigurációhoz használhatja az Azure Portalt vagy az Azure CLI-t:

Feljegyzés

A Python-alkalmazások App Service-ben való futtatásához a Linux az egyetlen operációsrendszer-beállítás. A Python windowsos használata már nem támogatott. Létrehozhat azonban saját egyéni Windows-tárolórendszerképet, és futtathatja azt az App Service-ben. További információ: Egyéni Docker-rendszerkép használata.

A Python-verzió konfigurálása

  • Azure Portal: Használja a Konfiguráció lap Általános beállítások lapját a Linux-tárolók általános beállításainak konfigurálása című cikkben leírtak szerint.

  • Azure CLI:

    • Az aktuális Python-verzió megjelenítése az az webapp config show használatával:

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

      Cserélje le és <resource-group-name> írja be <app-name> a webalkalmazásnak megfelelő neveket.

    • Állítsa be a Python-verziót az az webapp config set használatával:

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

    • Az App Service-ben támogatott összes Python-verzió megjelenítése az az webapp list-runtimes használatával:

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

A Python nem támogatott verzióját saját tárolórendszerkép létrehozásával futtathatja. További információ: Egyéni Docker-rendszerkép használata.

Mi történik az elavult futtatókörnyezetekkel az App Service-ben?

Az elavult futtatókörnyezeteket a karbantartó szervezet elavulttá vagy jelentős biztonsági résekkel rendelkezik. Ennek megfelelően el lesznek távolítva a portál lapjainak létrehozása és konfigurálása során. Ha egy elavult futtatókörnyezet el van rejtve a portálon, a futtatókörnyezetet még használó alkalmazások továbbra is futnak.

Ha olyan alkalmazást szeretne létrehozni, amely a portálon már nem látható elavult futtatókörnyezeti verzióval rendelkezik, használja az Azure CLI-t, egy ARM-sablont vagy a Bicep-et. Ezek az üzembe helyezési alternatívák lehetővé teszik elavult futtatókörnyezetek létrehozását, amelyek a portálról törlődnek, de továbbra is támogatottak.

Ha egy futtatókörnyezet teljesen el lett távolítva az App Service-platformról, az Azure-előfizetés tulajdonosa e-mailben értesítést kap az eltávolítás előtt.

Testreszabott építési automatizálás

Feljegyzés

A Python-alkalmazások buildautomatizálással történő üzembe helyezésekor a tartalom nem az alatt, hanem a következőből /tmp/<uid>lesz üzembe helyezve és kiszolgálva /home/site/wwwroot: . Ezt a tartalomkönyvtárat a környezeti változó használatával érheti APP_PATH el. A futtatókörnyezetben létrehozott további fájlokat olyan helyre /home kell írnia, amely a Saját tárterület használata alatt vagy használatával történik az adatmegőrzéshez. Erről a viselkedésről további információt a Python buildmódosításai című témakörben talál.

Az App Service Oryx nevű buildelési rendszere az alábbi lépéseket hajtja végre az alkalmazás üzembe helyezésekor, ha az alkalmazás beállítása SCM_DO_BUILD_DURING_DEPLOYMENT a következőre 1van állítva:

  1. Ha ezt a lépést a PRE_BUILD_COMMAND beállítás határozza meg, futtasson egy egyéni előre meghatározott szkriptet. (A szkript maga is futtathat más Python- és Node.js szkripteket, pip- és npm-parancsokat, valamint csomópontalapú eszközöket, például yarn install a Yarnt és yarn build.)

  2. Telepítse a függőségeket. A buildelési rendszer a következő fájlokat ellenőrzi a projekt gyökérkönyvtárában:

    • requirements.txt: Futtat.pip install -r requirements.txt
    • pyproject.tomluv.lock: Használja uv.
    • pyproject.toml a poetry.lock: használja poetry.
    • pyproject.toml: Használja poetry.
    • setup.py: Fut pip install ..

    Feljegyzés

    Ha a pyproject.toml jelen van, de az uv.lock hiányzik, az App Service alapértelmezés szerint a Poetryt használja, még akkor is, ha a poetry.lock is hiányzik. A uv használatához az uv.lock-ot be kell vonni az üzembe helyezés során.

    Ha egyik fájl sem található, a buildelési folyamat a következő hibaüzenetet jelenti: "Nem található setup.py vagy requirements.txt; Nem futtatja a pip telepítését."

  3. Ha manage.py található az adattár gyökerében (amely django-alkalmazást jelez), futtassa a parancsot manage.py collectstatic. Ha azonban a DISABLE_COLLECTSTATIC beállítás az true, a rendszer kihagyja ezt a lépést.

  4. Futtasson egy egyéni, buildelés utáni szkriptet, ha a lépés meg van adva a POST_BUILD_COMMAND beállításban. (A szkript más Python- és Node.js-szkripteket, pip- és npm-parancsokat, valamint csomópontalapú eszközöket is futtathat.)

Alapértelmezés szerint a , PRE_BUILD_COMMANDés POST_BUILD_COMMAND a DISABLE_COLLECTSTATICbeállítások üresek.

  • Ha le szeretné tiltani a Futtatás funkciót collectstatic a Django-alkalmazások létrehozásakor, állítsa be a beállítást a DISABLE_COLLECTSTATIC következőre true: .

  • Az előzetes buildelési parancsok futtatásához állítsa be a PRE_BUILD_COMMAND beállítást úgy, hogy egy parancsot tartalmazzon, mint például echo Pre-build command, vagy a projekt gyökeréhez képest egy szkriptfájl elérési útját, mint például scripts/prebuild.sh. Minden parancsnak olyan elérési utakat kell használnia, amelyek relatívek a projekt gyökérmappájában.

  • A buildelés utáni parancsok futtatásához állítsa be a POST_BUILD_COMMAND beállítást úgy, hogy tartalmazzon egy parancsot, például echo Post-build command, vagy a projekt gyökeréhez viszonyítottan egy szkriptfájl elérési útját, például scripts/postbuild.sh. Minden parancsnak a projekt gyökérmappához viszonyított elérési utakat kell használnia.

A buildautomatizálást testre szabó egyéb beállításokról további információt az Oryx-konfigurációban talál.

A buildelési és üzembehelyezési naplók eléréséről az Access üzembe helyezési naplóiban talál további információt.

További információ arról, hogy az App Service hogyan futtatja és fejleszti a Python-alkalmazásokat Linuxon, olvassa el , hogyan észleli és fejleszti az Oryx a Python-alkalmazásokat.

Feljegyzés

A PRE_BUILD_SCRIPT_PATH és a POST_BUILD_SCRIPT_PATH beállítások megegyeznek a PRE_BUILD_COMMAND és a POST_BUILD_COMMAND beállításokkal, és történeti célokra támogatottak.

Egy névvel ellátott SCM_DO_BUILD_DURING_DEPLOYMENTbeállítás, ha tartalmazza true vagy 1, elindít egy Oryx-buildet, amely az üzembe helyezés során történik. A beállítás a Git, az Azure CLI parancs trueés a Visual Studio Code használatával történő üzembe helyezéskor történikaz webapp up.

Feljegyzés

Mindig használjon relatív elérési utakat az összes összeállítás előtti és utáni szkriptben, mert az a buildtároló, amelyben az Oryx fut, eltér attól a futtatókörnyezeti tárolótól, amelyben az alkalmazás fut. Soha ne támaszkodjon az alkalmazásprojekt mappájának pontos elhelyezésére a tárolóban (például a webhely/wwwroot alatt).

Meglévő alkalmazások migrálása az Azure-ba

A meglévő webalkalmazásokat az alábbiak szerint helyezheti üzembe újra az Azure-ban:

  1. Forrásadattár. Tartsa karban a forráskódot egy megfelelő adattárban, például a GitHubon, amely lehetővé teszi a folyamatos üzembe helyezés beállítását a folyamat későbbi szakaszában.

    • A függőségi fájlnak (például requirements.txt, pyproject.toml vagy setup.py) az adattár gyökerénél kell lennie, ha azt szeretné, hogy az App Service automatikusan telepítse a szükséges csomagokat.

  2. Adatbázis. Ha az alkalmazás adatbázistól függ, hozza létre a szükséges erőforrásokat az Azure-ban is.

  3. App Service-erőforrások. Hozzon létre egy erőforráscsoportot, App Service-csomagot és App Service-webalkalmazást az alkalmazás üzemeltetéséhez. Ezeket az erőforrásokat egyszerűen létrehozhatja az Azure CLI parancs futtatásával az webapp up. Vagy létrehozhat és üzembe helyezhet erőforrásokat a Flask, a Django vagy a FastAPI postgreSQL-oktatóanyagában látható módon. Cserélje le az erőforráscsoport, az App Service-csomag és a webalkalmazás nevét az alkalmazásnak megfelelő nevekre.

  4. Környezeti változók. Ha az alkalmazáshoz környezeti változók szükségesek, hozzon létre egyenértékű App Service-alkalmazásbeállításokat. Ezek az App Service-beállítások környezeti változókként jelennek meg a kódban az Access környezeti változóiban leírtak szerint.

  5. Alkalmazás indítása. Tekintse át a cikk későbbi, tárolóindítási folyamatát ismertető szakaszt, amelyből megtudhatja, hogyan próbálja meg az App Service futtatni az alkalmazást. Az App Service alapértelmezés szerint a Gunicorn webkiszolgálót használja. A Gunicornnak képesnek kell lennie megtalálni az alkalmazásobjektumot vagy wsgi.py mappát. Szükség esetén testre szabhatja az indítási parancsot.

  6. Folyamatos üzembe helyezés. Állítsa be a folyamatos üzembe helyezést a GitHub Actionsből, a Bitbucketből vagy az Azure-adattárakból a Folyamatos üzembe helyezés az Azure App Service-ben című cikkben leírtak szerint. Vagy állítsa be a folyamatos üzembe helyezést a helyi Gitből a Helyi Git-üzembe helyezés az Azure App Service-ben című cikkben leírtak szerint.

  7. Egyéni műveletek. Az alkalmazást üzemeltető App Service-tárolón belüli műveletek ( például Django-adatbázisok áttelepítése) végrehajtásához SSH használatával csatlakozhat a tárolóhoz. A Django-adatbázisok migrálásának futtatására példa : Oktatóanyag: Django-webalkalmazás üzembe helyezése a PostgreSQL-lel.

    • A folyamatos üzembe helyezés használatakor ezeket a műveleteket a buildelés utáni parancsok használatával hajthatja végre, a build automatizálásának testreszabása szakaszban leírtak szerint.

Ezeknek a lépéseknek a végrehajtásával végre kell tudnia véglegesíteni a módosításokat a forrásadattárban, és ezeket a frissítéseket automatikusan üzembe kell helyeznie az App Service-ben.

A Django-alkalmazások gyártási beállításai

Az olyan éles környezetben, mint az App Service, a Django-alkalmazásoknak a Django üzembe helyezési ellenőrzőlistájában szereplő útmutatást kell követnie.

Az alábbi táblázat az Azure-ra vonatkozó gyártási beállításokat ismerteti. Ezek a beállítások az alkalmazás setting.py fájljában vannak definiálva.

Django beállítás Utasítások az Azure-hoz
SECRET_KEY Tárolja az értéket egy App Service-beállításban, az Access alkalmazásbeállításokban környezeti változókként leírtak szerint. Az értéket titkos kódként is tárolhatja az Azure Key Vaultban.
DEBUG Hozzon létre egy DEBUG beállítást az App Service-ben a (0 ) értékkel false , majd töltse be az értéket környezeti változóként. A fejlesztési környezetben hozzon létre egy környezeti változót DEBUG a (1) értékkel true .
ALLOWED_HOSTS Éles környezetben a Django megköveteli alkalmazás URL-címének szerepeltetését a ALLOWED_HOSTS settings.py tömbjében. Ezt az URL-címet futásidőben, a kód os.environ['WEBSITE_HOSTNAME']használatával lehet lekérni. Az App Service automatikusan beállítja a WEBSITE_HOSTNAME környezeti változót az alkalmazás URL-címére.
DATABASES Adja meg az App Service-ben az adatbázis-kapcsolat beállításait, és töltse be őket környezeti változóként a DATABASES szótár feltöltéséhez. Az értékeket (különösen a felhasználónevet és a jelszót) Key Vault-titkos kulcsként is tárolhatja.

Statikus fájlok kiszolgálása Django-alkalmazásokhoz

Ha a Django-webalkalmazás statikus előtérfájlokat tartalmaz, először kövesse a statikus fájlok django-dokumentációban való kezelésére vonatkozó utasításokat.

Az App Service esetében a következő módosításokat kell végeznie:

  1. A Django STATIC_URL és STATIC_ROOT a változók dinamikus beállításához fontolja meg a környezeti változók (helyi fejlesztéshez) és alkalmazásbeállítások használatát (a felhőben való üzembe helyezéskor). Példa:

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

    DJANGO_STATIC_URL és DJANGO_STATIC_ROOT szükség szerint módosítható a helyi és a felhőbeli környezetekhez. Ha például a statikus fájlok buildelési folyamata egy névvel ellátott django-staticmappába helyezi őket, beállíthatja DJANGO_STATIC_URL/django-static/ , hogy ne használja az alapértelmezettet.

  2. Ha egy olyan előre összeállított szkripttel rendelkezik, amely statikus fájlokat hoz létre egy másik mappában, vegye fel a mappát a Django STATICFILES_DIRS változóba, hogy a Django collectstatic folyamata megtalálja őket. Ha például az előtérbeli mappában fut yarn build , és a Yarn létrehoz egy build/static statikus fájlokat tartalmazó mappát, az alábbi módon foglalja bele a mappát:

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

    Ebben a kódban egy olyan elérési utat hozunk létre, ahol egy olyan buildelési eszköz fut, FRONTEND_DIR mint a Yarn. Ha szeretné, ismét használhat környezeti változót és alkalmazásbeállítást.

  3. Adja hozzá whitenoise a requirements.txt fájlhoz. WhiteNoise (whitenoise.evans.io) egy Python-csomag, amely egyszerűvé teszi egy éles Django-alkalmazás számára a saját statikus fájljainak kiszolgálását. A WhiteNoise a Django STATIC_ROOT változó által megadott mappában található fájlokat szolgálja ki.

  4. A settings.py fájlban adja hozzá a következő sort a WhiteNoise számára:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Módosítsa a listákat úgy MIDDLEWAREINSTALLED_APPS , hogy a WhiteNoise szerepeljen a listán:

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

Statikus fájlok kiszolgálása Flask-alkalmazásokhoz

Ha a Flask-webalkalmazás statikus előtérfájlokat tartalmaz, először kövesse a Flask dokumentációjában található statikus fájlok kezelésére vonatkozó utasításokat. A statikus fájlok Flask-alkalmazásban való kiszolgálására példaként tekintse meg a Flask-mintaalkalmazást a GitHubon.

Ha statikus fájlokat szeretne közvetlenül az alkalmazás egyik útvonaláról kiszolgálni, használja a send_from_directory következő módszert:

from flask import send_from_directory

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

A tároló jellemzői

Az App Service-ben való üzembe helyezéskor a Python-alkalmazások az App Service Python GitHub-adattárban meghatározott Linux Docker-tárolón belül futnak. A rendszerképkonfigurációkat a verzióspecifikus könyvtárakban találja.

Ez a tároló a következő jellemzőkkel rendelkezik:

  • Az alkalmazásokat a Gunicorn WSGI HTTP-kiszolgáló futtatja a további argumentumokkal --bind=0.0.0.0 --timeout 600.

    • A Gunicorn konfigurációs beállításait az indítási parancs testreszabásával adhatja meg.

    • A webalkalmazás véletlen vagy szándékos DDOS-támadásokkal szembeni védelme érdekében a Gunicorn egy Nginx fordított proxy mögött fut, a Gunicorn üzembe helyezésében leírtak szerint.

  • Alapértelmezés szerint az alaptároló lemezképe csak a Flask webes keretrendszert tartalmazza, de a tároló támogatja a WSGI-kompatibilis és a Python 3.6-os és újabb verzióival kompatibilis keretrendszereket, például a Django-t.

  • Más csomagok, például a Django telepítéséhez hozzon létre egy requirements.txt, pyproject.toml vagy setup.py fájlt a projekt gyökerében, amely meghatározza a közvetlen függőségeket. Az App Service ezután automatikusan telepíti ezeket a függőségeket a projekt üzembe helyezésekor.

    A függőségi fájlnak a projekt gyökérkönyvtárában kell lennie, különben a függőségek nem lesznek telepítve. Ha ez a fájl nincs a gyökérkönyvtárban, a buildelési folyamat a következő hibaüzenetet jelenti: "Nem található setup.py vagy requirements.txt; Nem futtatja a pip telepítését." Ha ezt a hibát tapasztalja, ellenőrizze a követelmények fájljának helyét.

  • Az App Service automatikusan meghatároz egy környezeti változót, WEBSITE_HOSTNAME amely tartalmazza a webalkalmazás URL-címét, például msdocs-hello-world.azurewebsites.net. Emellett meghatározza WEBSITE_SITE_NAMEaz alkalmazás nevét, például msdocs-hello-world.

  • Az npm és a Node.js a tárolóban vannak telepítve, így csomópontalapú buildelési eszközöket futtathat, például a Yarnt.

A tároló elindítási folyamata

Rendszerindítás során a Linux-tárolóban lévő App Service a következő lépéseket futtatja:

  1. Ha van ilyen, használjon egyéni indítási parancsot.
  2. Ellenőrizze, hogy létezik-e Django-alkalmazás, és ha észleli, indítsa el a Gunicorn alkalmazást.
  3. Ellenőrizze, hogy létezik-e Flask-alkalmazás, és ha észleli, indítsa el a Gunicorn alkalmazást.
  4. Ha más alkalmazás nem található, indítson el egy alapértelmezett alkalmazást, amely a tárolóba van beépítve.

Az alábbi szakaszok további részleteket nyújtanak az egyes lehetőségekről.

Django-alkalmazás

Django-alkalmazások esetén az App Service egy wsgi.py nevű fájlt keres az alkalmazáskódban, majd az alábbi paranccsal futtatja a Gunicorn parancsot:

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

Ha pontosabban szeretné szabályozni az indítási parancsot, használjon egyéni indítási parancsot, cserélje le <module> a wsgi.py tartalmazó mappa nevére, és adjon hozzá egy --chdir argumentumot, ha ez a modul nem szerepel a projekt gyökérkönyvtárában. Például, ha a wsgi.py a knboard/backend/config mappában található a projekt gyökerétől, használja az --chdir knboard/backend config.wsgi argumentumokat.

Az éles naplózás engedélyezéséhez adja hozzá a paramétereket és --access-logfile a --error-logfile paramétereket, ahogyan az egyéni indítási parancsokra vonatkozó példákban is látható.

Flask-alkalmazás

A Flask esetében az App Service egy application.py vagy app.py nevű fájlt keres, és az alábbiak szerint indítja el a Gunicornt:

# 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

Ha a fő alkalmazásmodul egy másik fájlban található, használjon másik nevet az alkalmazásobjektumnak. Ha más argumentumokat szeretne megadni a Gunicorn számára, használjon egyéni indítási parancsot.

Alapértelmezett viselkedés

Ha az App Service nem talál egyéni parancsot, Django-alkalmazást vagy Flask-alkalmazást, az alapértelmezett írásvédett alkalmazást futtatja az opt/defaultsite mappában, és az alábbi képen látható.

Ha telepítette a kódot, és továbbra is az alapértelmezett alkalmazást látja, olvassa el a Hibaelhárítás – Az alkalmazás nem jelenik meg című témakört.

Képernyőkép a Linuxon futó alapértelmezett App Service-weblapról.

Indítási parancs testreszabása

A tároló indítási viselkedését úgy szabályozhatja, hogy egyéni indítási parancsot vagy több parancsot ad meg egy indítási parancsfájlban. Az indítási parancsfájlok tetszőleges nevet használhatnak, például startup.sh, startup.cmd vagy startup.txt.

Minden parancsnak a projekt gyökérmappához viszonyított elérési utakat kell használnia.

Indítási parancs vagy parancsfájl megadása:

  • Azure Portal. Az alkalmazás lapjának bal oldali paneljének Beállítások területén válassza a Konfiguráció, majd az Általános beállítások lehetőséget. Az Indítási parancs mezőbe írja be az indítási parancs teljes szövegét vagy az indítási parancsfájl nevét. Ezután válassza a Mentés lehetőséget a módosítások alkalmazásához. Lásd: A Linux-tárolók általános beállításainak konfigurálása.

  • Azure parancssori felület (CLI). Az indítási parancs vagy fájl beállításához használja az az webapp config set parancsot a --startup-file paraméterrel:

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

    Cserélje le <custom-command> az indítási parancs teljes szövegére vagy az indítási parancsfájl nevére.

Az App Service figyelmen kívül hagyja az egyéni indítási parancsok vagy fájlok feldolgozásakor előforduló hibákat, majd django- és Flask-alkalmazásokat keresve folytatja az indítási folyamatot. Ha nem látja a várt viselkedést, ellenőrizze, hogy az indítási parancs vagy a fájl hibamentes-e, és hogy egy indítási parancsfájl van-e üzembe helyezve az App Service-ben az alkalmazáskóddal együtt. További információt a diagnosztikai naplókban is találhat. Az azure portalon pedig megtekintheti az alkalmazás Diagnosztizálás és problémamegoldás lapját.

Példa indítási parancsok

  • Gunicorn-argumentumok hozzáadva: Az alábbi példa hozzáadja az --workers=4 argumentumot egy Gunicorn parancssorhoz django-alkalmazás indításához:

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

    További információért lásd a Gunicorn futtatása című részt. Ha automatikus skálázási szabályokat használ a webalkalmazás vertikális fel- és leskálázásához, az indítási parancs környezeti változójának használatával NUM_CORES dinamikusan kell beállítania a Gunicorn-feldolgozók számát is. Például: --workers $((($NUM_CORES*2)+1)). A Gunicorn-feldolgozók javasolt számának beállításával kapcsolatos további információkért lásd a Gunicorn gyakori kérdéseit.

  • A Django számára az éles naplózás engedélyezése: Adja hozzá a és --access-logfile '-' argumentumokat a parancssorhoz.

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

    Ezek a naplók megjelennek az App Service-naplóstreamben.

    További információ: Gunicorn-naplózás.

  • Egyéni Flask főmodul: Az App Service alapértelmezés szerint feltételezi, hogy a Flask-alkalmazás fő modulja application.py vagy app.py. Ha a fő modul más nevet használ, testre kell szabnia az indítási parancsot. Ha például rendelkezik egy Flask-alkalmazással, amelynek fő modulja hello.py , és a Flask-alkalmazás objektuma a fájlban myapp néven van elnevezve, ez a parancs:

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

    Ha a fő modul egy almappában( például a webhelyen) található, adja meg azt a mappát az --chdir argumentummal:

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

  • Nem Gunicorn-kiszolgáló használata: Másik webkiszolgáló( például aiohttp) használatához használja a megfelelő parancsot indítási parancsként vagy az indítási parancsfájlban:

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

Alkalmazásbeállítások elérése környezeti változókként

Az alkalmazásbeállítások olyan értékek, amelyek a felhőben, kifejezetten az alkalmazáshoz vannak tárolva, az alkalmazásbeállítások konfigurálása című szakaszban leírtak szerint. Ezek a beállítások környezeti változókként érhetők el az alkalmazás kódjához, és a standard os.environ-mintán keresztül érhetők el.

Ha például létrehoz egy alkalmazásbeállítást, DATABASE_SERVERaz alábbi kód lekéri a beállítás értékét:

db_server = os.environ['DATABASE_SERVER']

HTTPS munkamenet észlelése

Az App Service-ben a TLS/SSL-leállítás a hálózati terheléselosztóknál történik, így minden HTTPS-kérés titkosítatlan HTTP-kérésként éri el az alkalmazást. Ha az alkalmazáslogikának ellenőriznie kell, hogy a felhasználói kérések titkosítva vannak-e, vizsgálja meg a fejlécet X-Forwarded-Proto :

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

A népszerű webes keretrendszerek lehetővé teszik a szabványos alkalmazásminta információinak X-Forwarded-* elérését. A Django-ban például SECURE_PROXY_SSL_HEADER konfigurálhatja a Django-t a X-Forwarded-Proto fejléc használatára.

Diagnosztikai naplók elérése

A tárolón belülről létrehozott konzolnaplókhoz hozzáférhet.

A tárolónaplózás bekapcsolásához futtassa a következő parancsot:

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

Cserélje le a <app-name> és a <resource-group-name> értékeket a webalkalmazásnak megfelelő nevekre.

A tárolónaplózás bekapcsolása után futtassa a következő parancsot a naplóstream megtekintéséhez:

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

Ha a konzolnaplók nem jelennek meg azonnal, ellenőrizze újra 30 másodpercen belül.

Ha bármikor le szeretné állítani a naplóstreamelést, használja a Ctrl+C billentyűparancsot.

Ha az Azure Portalon szeretne naplókat elérni, válassza az alkalmazás bal oldali ablaktábláján a Naplóstream figyelése> lehetőséget.

Üzembehelyezési naplók elérése

A kód üzembe helyezésekor az App Service végrehajtja a korábban ismertetett buildelési folyamatot a Build automatizálásának testreszabása szakaszban. Mivel a build a saját tárolójában fut, a buildnaplókat a rendszer az alkalmazás diagnosztikai naplóitól elkülönítve tárolja.

Az üzembehelyezési naplók eléréséhez kövesse az alábbi lépéseket:

  1. A webalkalmazás Azure Portal lapján válassza az Üzembehelyezési>központ lehetőséget a bal oldali panelen.
  2. A Naplók lapon válassza ki a legutóbbi véglegesítés véglegesítési azonosítóját.
  3. A megjelenő Napló részletei lapon válassza az Oryx-build mellett megjelenő Naplók megjelenítése hivatkozást.

Ezekben a naplókban megjelennek a buildelési problémák, például a függőségfájl helytelen függőségei és az összeállítás előtti vagy a build utáni szkriptekben előforduló hibák. Hibák akkor is megjelennek, ha a függőségi fájl nem található a projekt gyökérmappájában.

SSH-munkamenet megnyitása böngészőben

Ha közvetlen SSH-munkamenetet szeretne megnyitni a tárolóval, az alkalmazásnak futnia kell.

Használja az az webapp ssh parancsot.

Ha nincs hitelesítve, a csatlakozáshoz hitelesítenie kell az Azure-előfizetésével. Hitelesítéskor megjelenik egy böngészőbeli rendszerhéj, ahol parancsokat futtathat a tárolóban.

SSH-kapcsolat

Feljegyzés

A címtáron kívül /home végzett módosítások magában a tárolóban vannak tárolva, és nem maradnak fenn az alkalmazás újraindítása után.

Ha távoli SSH-munkamenetet szeretne megnyitni a helyi gépről, tekintse meg az SSH-munkamenet távoli rendszerhéjból történő megnyitásával foglalkozó témakört.

Ha sikeresen csatlakozik az SSH-munkamenethez, az ablak alján az "SSH-KAPCSOLAT LÉTREJÖTT" üzenetnek kell megjelennie. Ha olyan hibaüzenetek jelennek meg, mint a "SSH_CONNECTION_CLOSED" vagy egy üzenet, amely szerint a tároló újraindul, előfordulhat, hogy egy hiba megakadályozza az alkalmazástároló elindítását. A lehetséges problémák kivizsgálásával kapcsolatos információkért tekintse meg a hibaelhárítást .

URL-átírások

Ha Python-alkalmazásokat helyez üzembe a Linuxhoz készült App Service-ben, előfordulhat, hogy az alkalmazáson belül kell kezelnie az URL-átírásokat. Ez a módszer különösen hasznos annak biztosítására, hogy bizonyos URL-minták a külső webkiszolgáló konfigurációinak használata nélkül a megfelelő végpontokra legyenek átirányítva. A Flask-alkalmazások esetében ehhez URL-processzorokat és egyéni köztes szoftvereket használhat. Django-alkalmazásokban az URL-diszpécser lehetővé teszi az URL-átírások hatékony kezelését.

Hibaelhárítás

A hibaelhárítás első lépése általában az App Service-diagnosztika használata:

  1. A webalkalmazás Azure Portal lapján válassza a Bal oldali panelen a Problémák diagnosztizálása és megoldása lehetőséget.
  2. Válassza a Rendelkezésre állás és a Teljesítmény lehetőséget.
  3. Vizsgálja meg az alkalmazásnaplók, a tárolóösszeomlás és a tárolóproblémák adatait, ahol a leggyakoribb problémák jelennek meg.

Ezután vizsgálja meg az üzembe helyezési naplókat és az alkalmazásnaplókat az esetleges hibaüzenetek esetében. Ezek a naplók gyakran azonosítják azokat a problémákat, amelyek megakadályozhatják az alkalmazások üzembe helyezését vagy az alkalmazások indítását. A buildelés például meghiúsulhat, ha a függőségi fájl nem található a projekt gyökérmappájában.

A következő szakaszok konkrét problémákhoz nyújtanak útmutatást.

Az alkalmazás nem jelenik meg

  • Saját alkalmazáskódjának telepítése után megjelenik az alapértelmezett alkalmazás. Az alapértelmezett alkalmazás azért jelenik meg, mert nem telepítette az alkalmazáskódot az App Service-ben, vagy mert az App Service nem találta meg az alkalmazáskódot, és ehelyett az alapértelmezett alkalmazást futtatta.

    • Indítsa újra az alkalmazást, várjon 20 másodpercet, majd ellenőrizze újra az alkalmazást.

    • Az SSH használatával közvetlenül az App Service-tárolóhoz csatlakozhat, és ellenőrizheti, hogy a fájlok a webhely/wwwroot területen találhatók-e. Ha a fájlok nem léteznek, hajtsa végre a következő lépéseket:

      1. Hozzon létre egy olyan alkalmazásbeállítást SCM_DO_BUILD_DURING_DEPLOYMENT , amelynek értéke 1a következő: újra üzembe helyezi a kódot, várjon néhány percet, majd próbálja meg újból elérni az alkalmazást. További információ az alkalmazásbeállítások létrehozásáról: App Service-alkalmazás konfigurálása az Azure Portalon.
      2. Tekintse át az üzembe helyezési folyamatot, ellenőrizze az üzembehelyezési naplókat, javítsa ki a hibákat, és telepítse újra az alkalmazást.

    • Ha a fájlok léteznek, az App Service nem tudta azonosítani az indítási fájlt. Győződjön meg arról, hogy az alkalmazás úgy van felépítve, ahogy az App Service elvárja a Django vagy a Flask esetében, vagy használjon egyéni indítási parancsot.

  • A böngészőben megjelenik a "Szolgáltatás nem érhető el" üzenet. A böngésző időtúllépéssel várta az App Service válaszát. Ez azt jelzi, hogy az App Service elindította a Gunicorn-kiszolgálót, de maga az alkalmazás nem indult el. Ez a feltétel azt jelezheti, hogy a Gunicorn argumentumok helytelenek, vagy hiba történt az alkalmazáskódban.

    • Frissítse a böngészőt, különösen akkor, ha az App Service-csomag legalacsonyabb tarifacsomagjait használja. Az alkalmazás indítása hosszabb időt vehet igénybe, ha például ingyenes szinteket használ, és a böngésző frissítése után válaszkész lesz.

    • Ellenőrizze, hogy az alkalmazás úgy van-e strukturálva, ahogyan az App Service elvárja a Django vagy a Flask esetében, vagy használjon egyéni indítási parancsot.

    • Vizsgálja meg az alkalmazásnapló-adatfolyamot hibaüzenetek esetén. A naplók megjelenítik az alkalmazáskód hibáit.

Nem található setup.py vagy requirements.txt

  • A naplóstream a következőt jeleníti meg: "Nem található setup.py vagy requirements.txt; Nem futtatja a pip telepítést." Az Oryx buildfolyamata nem találta a requirements.txt, pyproject.toml vagy setup.py fájlt.

    • Csatlakozzon a webalkalmazás tárolójához SSH-n keresztül, és győződjön meg arról, hogy a függőségi fájl neve helyes, és közvetlenül a webhely/wwwroot alatt található. Ha nem létezik, győződjön meg arról, hogy a fájl létezik az adattárban, és szerepel az üzembe helyezésben. Ha egy külön mappában található, helyezze át a gyökérmappába.

ModuleNotFoundError az alkalmazás indításakor

Ha hasonló ModuleNotFoundError: No module named 'example'hibaüzenetet lát, a Python nem talált egy vagy több modult az alkalmazás indításakor. Ez a hiba leggyakrabban akkor fordul elő, ha a virtuális környezetet a kóddal együtt telepíti. A virtuális környezetek nem hordozhatóak, ezért a virtuális környezetet nem szabad üzembe helyezni az alkalmazáskóddal. Ehelyett hagyja, hogy az Oryx hozzon létre egy virtuális környezetet, és az alkalmazásbeállítás SCM_DO_BUILD_DURING_DEPLOYMENT létrehozásával és annak 1 értékre állításával telepítse a csomagokat a webalkalmazásba. Ez a beállítás arra kényszeríti az Oryxot, hogy az App Service-ben való üzembe helyezéskor telepítse a csomagokat. További információ: ez a cikk a virtuális környezet hordozhatóságáról.

Az adatbázis zárolva van

Amikor egy Django-alkalmazással próbál adatbázis-migrálásokat futtatni, az "sqlite3" jelenhet meg. OperationalError: az adatbázis zárolva van." A hiba azt jelzi, hogy az alkalmazás egy SQLite-adatbázist használ, amelyhez a Django alapértelmezés szerint konfigurálva van, nem pedig egy felhőalapú adatbázist, például az Azure Database for PostgreSQL-t.

Ellenőrizze az DATABASES alkalmazás settings.py fájljában lévő változót, hogy az alkalmazás SQLite helyett felhőalapú adatbázist használ-e.

Ha ezt a hibát a következő oktatóanyagban szereplő példában tapasztalja: Django-webalkalmazás üzembe helyezése a PostgreSQL-lel, ellenőrizze, hogy elvégezte-e a kapcsolatbeállítások ellenőrzése című szakasz lépéseit.

Egyéb problémák

  • Beíráskor a jelszavak nem jelennek meg az SSH-munkamenetben: Biztonsági okokból az SSH-munkamenet elrejti a jelszót a beíráskor. A karakterek rögzítése azonban folyamatban van, ezért írja be a jelszót a szokásos módon, és amikor elkészült, válassza az Enter billentyűt .

  • Úgy tűnik, hogy az SSH-munkamenet parancsai le vannak vágva: Lehet, hogy a szerkesztő nem tördel szavakat, de ennek ellenére is helyesen kell futniuk.

  • A statikus objektumok nem jelennek meg a Django-alkalmazásokban: Győződjön meg arról, hogy engedélyezte a WhiteNoise modult.

  • A következő üzenet jelenik meg: "Végzetes SSL-kapcsolat szükséges": Ellenőrizze az erőforrások (például adatbázisok) alkalmazáson belüli eléréséhez használt felhasználóneveket és jelszavakat.

Kapcsolódó tartalom

  • Last updated on