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

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

  • Cikk

Ez a cikk bemutatja, hogyan futtatja a Azure-alkalmazás Service 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, ha szükséges. 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 egy Git-adattár vagy egy olyan zip-csomag üzembe helyezésekor futpip install -r requirements.txt, amelyen engedélyezve van a buildautomatizálás.

Ez az útmutató 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 a Azure-alkalmazás szolgáltatást, először kövesse a Python rövid útmutatóját és a Pythont 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.

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ű szakaszban leírtak szerint.

  • Azure CLI:

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

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

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

    • A Python-verzió beállítása az webapp konfigurációs készlettel 

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

    • Az Azure-alkalmazás Szolgáltatásban 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.

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

Az App Service Oryx nevű buildrendszere a következő 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 van állítva 1:

  1. Ha a PRE_BUILD_COMMAND beállítás meg van adva, futtasson egy egyéni előre elkészített 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. Futtassa az pip install -r requirements.txt parancsot. A requirements.txt fájlnak szerepelnie kell a projekt gyökérmappájában. Ellenkező esetben a buildelési folyamat a következő hibát 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 (django-alkalmazásra utal), futtassa manage.py collectstatic parancsot. Ha azonban a DISABLE_COLLECTSTATIC beállítás az true, a rendszer kihagyja ezt a lépést.

  4. Ha a beállítás megadja, futtassa az egyéni build utáni szkriptet POST_BUILD_COMMAND . (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 , POST_BUILD_COMMANDés DISABLE_COLLECTSTATIC a PRE_BUILD_COMMANDbeállítások üresek.

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

  • Az előre összeállított parancsok futtatásához állítsa be a PRE_BUILD_COMMAND beállítást úgy, hogy az tartalmazzon egy parancsot, például echo Pre-build commandegy szkriptfájl elérési útját a projektgyökérhez képest, például scripts/prebuild.sh. Minden parancsnak a projekt gyökérmappájának relatív elérési útját kell használnia.

  • A buildelés utáni parancsok futtatásához állítsa be a POST_BUILD_COMMAND beállítást úgy, hogy az tartalmazzon egy parancsot, például echo Post-build commandegy szkriptfájl elérési útját a projekt gyökérkönyvtárához képest, például scripts/postbuild.sh. Minden parancsnak a projekt gyökérmappájának relatív elérési útját kell használnia.

A buildautomatizálást testre szabó egyéb beállításokért tekintse meg az Oryx-konfigurációt.

A buildelési és üzembehelyezési naplók eléréséhez tekintse meg az Access üzembehelyezési naplóit.

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 beállítások és POST_BUILD_SCRIPT_PATH a beállítások megegyeznek az PRE_BUILD_COMMAND örökölt célokkal, és POST_BUILD_COMMAND támogatottak.

Az Oryx-buildeket az üzembe helyezés során aktiválja, ha az tartalmazza true vagy 1 nevű SCM_DO_BUILD_DURING_DEPLOYMENTbeállítást. A beállítás igaz a Git, az Azure CLI parancs az webapp upés a Visual Studio Code használatával történő üzembe helyezéskor.

Feljegyzés

Mindig használjon relatív elérési utakat minden build 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ások az alábbiak szerint helyezhetők újra üzembe az Azure-ban:

  1. Forrásadattár: A forráskód karbantartása 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 szükséges csomagok automatikus telepítéséhez a requirements.txt fájlnak az App Service adattárának gyökerénél kell lennie.

  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. Ezt egyszerűen megteheti az Azure CLI parancs futtatásával az webapp up. Vagy létrehozhat és üzembe helyezhet erőforrásokat az oktatóanyagban látható módon: Python (Django vagy Flask) webalkalmazás üzembe helyezése a PostgreSQL-lel. Cserélje le az erőforráscsoport, az App Service-csomag és a webalkalmazás nevét, hogy az jobban megfeleljön az alkalmazásnak.

  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 jelen 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, amelynek 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: Folyamatos üzembe helyezés beállítása a GitHub Actionsből, a Bitbucketből vagy az Azure-adattárakból a folyamatos üzembe helyezésről Azure-alkalmazás szolgáltatásba 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 Azure-alkalmazás szolgáltatásba című cikkben leírtak szerint.

  7. Egyéni műveletek: Ha az alkalmazást üzemeltető App Service-tárolón belül szeretne műveleteket végrehajtani, például Django-adatbázisok áttelepítését, SSH-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 használatával – adatbázisséma létrehozása.

    • A folyamatos üzembe helyezés használatakor ezeket a műveleteket a build utáni parancsokkal hajthatja végre, a build automatizálásának testreszabása című 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 éles beállításai

A Azure-alkalmazás Service-hez hasonló éles környezetben a Django-alkalmazásoknak követnie kell a Django üzembe helyezési ellenőrzőlistát (djangoproject.com).

Az alábbi táblázat az Azure-ra vonatkozó éles 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ásaiban ismertetett módon környezeti változókként. 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 (hamis) értékkel, 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 az 1 (igaz) értékkel.
ALLOWED_HOSTS Éles környezetben a Django megköveteli, hogy az alkalmazás URL-címe szerepeljen a ALLOWED_HOSTS settings.py tömbjében. Ezt az URL-címet futásidőben lekérheti a kóddal. os.environ['WEBSITE_HOSTNAME'] 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) az Azure Key Vault titkos kulcsaké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 kezelésével kapcsolatos utasításokat a Django dokumentációjában.

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

  1. A Django STATIC_URL és a változók dinamikus beállításához fontolja meg a környezeti változók (helyi fejlesztéshez) és STATIC_ROOT az 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 nevesített django-staticmappába helyezi őket, beállíthatja DJANGO_STATIC_URL , hogy /django-static/ 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érmappában fut yarn build , és a Yarn létrehoz egy build/static statikus fájlokat tartalmazó mappát, akkor a következőképpen foglalja bele a mappát:

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

    Itt egy olyan útvonalat hozhat létre, FRONTEND_DIRamelyen egy olyan buildelési eszköz fut, mint a yarn. Igény szerint ismét használhat környezeti változót és alkalmazásbeállítást.

  3. Adja hozzá whitenoise a requirements.txt fájlhoz. A 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 kifejezetten azokat a fájlokat szolgálja ki, amelyek a Django STATIC_ROOT változó által megadott mappában találhatók.

  4. A settings.py fájlban adja hozzá a Whitenoise következő sorát:

    STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')

  5. Módosítsa a listákat úgy INSTALLED_APPS is, hogy tartalmazzák a MIDDLEWARE Whitenoise-t:

    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ásokban való kiszolgálására vonatkozó példát a GitHubon található Flask-mintaalkalmazásban tekintheti meg.

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ások a Gunicorn WSGI HTTP-kiszolgálóval futnak a további argumentumok --bind=0.0.0.0 --timeout 600használatával.

  • 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+-tal 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 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 requirements.txt fájlnak a projekt gyökerében kell lennie ahhoz, hogy a függőségek telepítve legyenek. Ellenkező esetben a buildelési folyamat a következő hibát 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, amely a webalkalmazás URL-címével van elnevezve WEBSITE_HOSTNAME , például msdocs-hello-world.azurewebsites.net. Emellett az alkalmazás nevével is definiál WEBSITE_SITE_NAME , 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.

Tároló indí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 a(z) wsgi.py nevű fájlt keresi az alkalmazáskódban, majd a Gunicorn futtatásához a következő parancsot használja:

# <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. Ha például a wsgi.py a projekt gyökeréből származó knboard/backend/config területen található, használja az argumentumokat--chdir knboard/backend config.wsgi.

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

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, vagy adjon meg más argumentumokat a Gunicornnak, 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, akkor egy alapértelmezett írásvédett alkalmazást futtat, amely az opt/defaultsite mappában található, é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.

Ha az alapértelmezett alkalmazás helyett egy üzembe helyezett alkalmazást vár, olvassa el a Hibaelhárítás – Az alkalmazás nem jelenik meg című témakört.

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

Minden parancsnak a projekt gyökérmappájának relatív elérési útját kell használnia.

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

  • Azure Portal: válassza ki az alkalmazás konfigurációs oldalát, majd válassza az Általános beállítások lehetőséget. Az Indítási parancs mezőben helyezze el 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 CLI: használja az az webapp config set parancsot a --startup-file paraméterrel az indítási parancs vagy fájl beállításához:

    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. Tekintse meg az alkalmazás Problémák diagnosztizálása és megoldása lapját is az Azure Portalon.

Példa indítási parancsok

  • Gunicorn-argumentumok hozzáadva: Az alábbi példa hozzáadja a --workers=4 Gunicorn parancssort egy Django-alkalmazás elindí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 containing wsgi.py.
gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi

    További információkért lásd: A Gunicorn futtatása (docs.gunicorn.org). Ha automatikus skálázási szabályokat használ a webalkalmazás fel- és leskálázásához, dinamikusan kell beállítania a gunicorn-feldolgozók számát az indítási parancs környezeti változóját használva NUM_CORES , 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 éles naplózásának engedélyezése: Adja hozzá az és --error-logfile '-' az --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 (docs.gunicorn.org).

  • 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 egy olyan Flask-alkalmazással rendelkezik, amelynek a főmodulja a hello.py, és a fájlban a Flask-alkalmazásobjektum neve myapp, a parancs a következő lesz:

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

    Ha a főmodul egy almappában található (például website), a mappát a --chdir argumentummal határozhatja meg:

    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 a felhőben, kifejezetten az alkalmazáshoz tárolt értékek, 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ával érhetők el.

Ha például létrehozott egy alkalmazásbeállítást, DATABASE_SERVERaz alábbi kód beolvassa 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 (wikipedia.org) 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 az X-Forwarded-Proto fejlécet.

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 X-Forwarded-* szabványos alkalmazásminta információinak elérését. A Django-ban például a SECURE_PROXY_SSL_HEADER segítségével jelezheti Django-nak, hogy használja a fejlécet X-Forwarded-Proto .

Diagnosztikai naplók elérése

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

Először kapcsolja be a tárolónaplózást a következő parancs futtatásával:

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

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

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 nem jelennek meg azonnal a konzolnaplófájlok, ellenőrizze ismét 30 másodperc múlva.

Ha bármikor le szeretné állítani a naplóstreamelést, írja be a Ctrl C billentyűkombinációt.+

A naplófájlokat a böngészőben is megvizsgálhatja a következő helyen https://<app-name>.scm.azurewebsites.net/api/logs/docker: .

Ha az Azure Portalon keresztül szeretné elérni a naplókat, válassza az alkalmazás bal oldali menüjében a Figyelési>naplóstream lehetőséget.

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

A kód üzembe helyezésekor az App Service végrehajtja a buildelési automatizálás testreszabása című szakaszban korábban ismertetett buildelési folyamatot. 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 Portalján válassza az Üzembehelyezési>központ lehetőséget a bal oldali menüben.
  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 a Naplók megjelenítése... hivatkozást, amely az "Oryx-build futtatása..." mellett jelenik meg.

Ezekben a naplókban megjelennek a buildelési problémák, például a requirements.txt helytelen függőségei, valamint a build előtti vagy utáni szkriptek hibái. Hibák akkor is megjelennek, ha a követelményfájl neve nem pontosan requirements.txt , vagy nem jelenik meg a projekt gyökérmappájában.

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

Ahhoz, hogy közvetlen SSH-munkamenetet nyisson meg a tárolóval, az alkalmazásának futnia kell.

Illessze be a következő URL-címet a böngészőbe, és cserélje le az <app-name> kifejezést az alkalmazása nevére:

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

Ha még nem végezte el a hitelesítést, a csatlakozáshoz el kell végeznie a hitelesítést az Azure-előfizetésével. A hitelesítés után egy böngészőn belüli felület jelenik meg, ahol a tárolón belül futtathat parancsokat.

SSH-kapcsolat

Feljegyzés

A rendszer a /home könyvtáron kívül elvégzett módosításokat magában a tárolóban helyezi el, és ezek nem maradnak meg 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üzeneteket lát, mint a "SSH_CONNECTION_CLOSED" vagy egy üzenet, amely szerint a tároló újraindul, előfordulhat, hogy hiba miatt nem indul el az alkalmazástároló. A lehetséges problémák kivizsgálásának lépéseit a Hibaelhárítás című témakörben találja.

URL-átírások

Amikor Python-alkalmazásokat helyez üzembe a Linuxhoz készült Azure-alkalmazás Service-ben, előfordulhat, hogy url-átírásokat kell kezelnie az alkalmazásban. Ez különösen hasznos annak biztosításához, hogy bizonyos URL-minták a megfelelő végpontokra kerüljenek, külső webkiszolgáló-konfigurációk használata nélkül. A Flask-alkalmazások esetében az URL-processzorok és az egyéni köztes szoftver is használható ennek eléréséhez. A Django-alkalmazásokban a robusztus 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 Diagnostics használata:

  1. A webalkalmazásHoz készült Azure Portalon válassza a Bal oldali menüben 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 beállításaiban szereplő információkat, 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 requirements.txt fájl neve nem megfelelő, vagy nem található meg 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 vagy nem telepítette az alkalmazáskódot az App Service-ben, vagy az App Service nem találta meg az alkalmazáskódot, és ehelyett az alapértelmezett alkalmazást futtatta.

    • Indítsa újra az App Service-t, várjon 15-20 másodpercet, és 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, kövesse az alábbi lépéseket:

      1. Hozzon létre egy 1 értékű alkalmazásbeállítást SCM_DO_BUILD_DURING_DEPLOYMENT , telepítse újra 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 adott indítási fájlt. Ellenőrizze, hogy az alkalmazás struktúrája megfelel-e annak, amit az App Service a Django vagy a Flask számára elvár, 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ést jelzett az App Service válaszára várva, ami 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 tarifacsomagját használja. Az ingyenes szolgáltatásszintek használatakor például az alkalmazás lassabban indul, és csak a böngésző frissítése után fog ismét reagálni.

    • Ellenőrizze, hogy az alkalmazás struktúrája megfelel-e annak, amit az App Service a Django vagy a Flask számára elvár, vagy használjon egyéni indítási parancsot.

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

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

ModuleNotFoundError az alkalmazás indításakor

Ha hasonló ModuleNotFoundError: No module named 'example'hibaüzenetet lát, akkor 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 telepítse a csomagokat a webalkalmazásra egy alkalmazásbeállítás létrehozásával és SCM_DO_BUILD_DURING_DEPLOYMENTbeállításával 1. Ez a beállítás arra kényszeríti az Oryxot, hogy telepítse a csomagokat az App Service-ben való üzembe helyezéskor. További információt a virtuális környezet hordozhatóságáról szóló cikkben talá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 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 nyomja le az Enter billentyűt , amikor elkészült.

  • Úgy tűnik, hogy az SSH-munkamenet parancsai le vannak vágva: Lehet, hogy a szerkesztő nem szóburkoló parancsok, de továbbra is megfelelően kell futniuk.

  • A statikus objektumok nem jelennek meg a Django-alkalmazásokban: Győződjön meg arról, hogy engedélyezte a fehérítési 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.

További erőforrások