Linux Python-alkalmazás konfigurálása Azure App Service

  • Cikk

Ez a cikk bemutatja, hogyan futtat Azure App Service Python-alkalmazásokat, hogyan migrálhat meglévő alkalmazásokat az Azure-ba, és hogyan szabhatja testre a App Service viselkedését, ha szükséges. A Python-alkalmazásokat az összes szükséges pip-modullal együtt kell üzembe helyezni.

A App Service üzembehelyezési motor 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 azoknak a Python-fejlesztőknek, akik beépített Linux-tárolót használnak App Service. Ha még soha nem használta Azure App Service, először kövesse a Python rövid útmutatóját és a Python és a PostgreSQL használatával című oktatóanyagot.

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

Megjegyzés

A Python-alkalmazások App Service való futtatásához a Linux az egyetlen operációs rendszer. 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 App Service. 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ű témakörben leírtak szerint.

  • Azure CLI:

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

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

      Cserélje le <resource-group-name> a és <app-name> a elemet a webalkalmazásának megfelelő nevekre.

    • A Python-verzió beállítása az az webapp config set paranccsal

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

    • Az az webapp list-runtimes Azure App Service által támogatott Összes Python-verzió megjelenítése:

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

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

Buildautomatizálás testreszabása

App Service Oryx nevű buildrendszere a következő lépéseket hajtja végre az alkalmazás üzembe helyezésekor, ha az alkalmazásbeállítás SCM_DO_BUILD_DURING_DEPLOYMENT értéke1:

  1. Futtasson egy egyéni, build előtti szkriptet, ha a PRE_BUILD_COMMAND beállítás meg van adva. (A szkript maga 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 builda .)

  2. Futtatja a pip install -r requirements.txt parancsot. A requirements.txt fájlnak jelen kell lennie 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 fut a pip telepítése."

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

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

Alapértelmezés szerint a PRE_BUILD_COMMAND, POST_BUILD_COMMANDés DISABLE_COLLECTSTATIC a beá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 értékre DISABLE_COLLECTSTATICtrue.

  • A build előtti parancsok futtatásához állítsa be úgy a PRE_BUILD_COMMAND beállítást, hogy az tartalmazzon egy parancsot, például echo Pre-build commanda parancsot, vagy egy szkriptfájl elérési útját a projekt gyökeréhez viszonyítva, 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 úgy a POST_BUILD_COMMAND beállítást, hogy az tartalmazzon egy parancsot, például echo Post-build commanda parancsot, vagy egy szkriptfájl elérési útját a projekt gyökeréhez 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 lásd: Oryx-konfiguráció.

A buildelési és üzembehelyezési naplók eléréséhez lásd: Üzembehelyezési naplók elérése.

A App Service Python-alkalmazások Linuxon való futtatásáról és buildeléséről az Oryx hogyan észleli és buildeli a Python-alkalmazásokat című témakörben talál.

Megjegyzés

A PRE_BUILD_SCRIPT_PATH és POST_BUILD_SCRIPT_PATH a beállítások megegyeznek a és POST_BUILD_COMMAND a beállításokkalPRE_BUILD_COMMAND, és örökölt célokra támogatottak.

A nevű SCM_DO_BUILD_DURING_DEPLOYMENTbeállítás, ha tartalmazza true vagy 1, aktivál egy Oryx-buildet az üzembe helyezés során. 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.

Megjegyzés

Mindig használjon relatív elérési utakat az összes 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 site/wwwroot mappába).

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: 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 részében.

    • Az requirements.txt fájlnak az adattár gyökerében kell lennie ahhoz, hogy 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. 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óanyag: Python- (Django- vagy Flask-) webalkalmazás üzembe helyezése a PostgreSQL-lel című oktatóanyagban leírtak szerint. Cserélje le az erőforráscsoport, a csomag App Service és a webalkalmazás nevét, hogy az jobban illeszkedjen az alkalmazáshoz.

  4. Környezeti változók: Ha az alkalmazásnak környezeti változókra van szüksége, hozzon létre egyenértékű App Service alkalmazásbeállításokat. Ezek a App Service beállítások környezeti változókként jelennek meg a kódban, az Access környezeti változóiról szóló cikkben 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 App Service futtatni az alkalmazást. 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 GitHub Actions, Bitbucket vagy Azure-adattárakból a Folyamatos üzembe helyezés Azure App Service című cikkben leírtak szerint. Vagy állítsa be a folyamatos üzembe helyezést a Helyi Gitből a Helyi Git üzembe helyezésről Azure App Service című cikkben leírtak szerint.

  7. Egyéni műveletek: Az alkalmazást üzemeltető App Service tárolón belüli műveletek végrehajtásához, például a Django-adatbázis migrálásához 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 PostgreSQL-lel – 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 buildautomatizálás testreszabása című szakaszban leírtak szerint.

A lépések elvégzése után képesnek kell lennie módosítások véglegesítésére a forrásadattárban, és ezeket a frissítéseket automatikusan üzembe kell helyeznie App Service.

A Django-alkalmazások éles beállításai

A Azure App Service-hez hasonló éles környezetben a Django-alkalmazásoknak követnie kell a Django üzembehelyezé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 meghatározva.

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 leírtak szerint környezeti változókként. Az értéket "titkos kódként" is tárolhatja az Azure Key Vault.
DEBUG Hozzon létre egy DEBUG beállítást App Service 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 1 (igaz) értékkel.
ALLOWED_HOSTS Éles környezetben a Django megköveteli, hogy az alkalmazás URL-címét szerepeltesse a ALLOWED_HOSTSsettings.py tömbjében. Ezt az URL-címet futásidőben a következő kóddal kérdezheti le: os.environ['WEBSITE_HOSTNAME']. App Service automatikusan beállítja a WEBSITE_HOSTNAME környezeti változót az alkalmazás URL-címére.
DATABASES Adja meg App Service beállításait az adatbázis-kapcsolathoz, és töltse be őket környezeti változókké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 kódké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ése című útmutatót a Django dokumentációjában.

A 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 az alkalmazásbeállítások (a felhőben való üzembe helyezéskor) használatát. Például:

    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őkörnyezetekben. Ha például a statikus fájlok buildelési folyamata egy nevű django-staticmappába helyezi őket, akkor beállíthatja DJANGO_STATIC_URL úgy, hogy /django-static/ ne használja az alapértelmezettet.

  2. Ha egy olyan build előtti 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, ahol egy olyan buildelési eszköz fut, FRONTEND_DIRmint 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 és INSTALLED_APPS a MIDDLEWARE listákat úgy is, hogy tartalmazzák a 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 Statikus fájlok kezelésével kapcsolatos utasításokat a Flask dokumentációjában. A statikus fájlok Flask-alkalmazásban való kiszolgálására vonatkozó példát a GitHubon található Flask-mintaalkalmazás rövid útmutatójában találja.

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

A App Service üzembe helyezésekor a Python-alkalmazások egy Linux Docker-tárolóban futnak, amely a App Service Python GitHub-adattárban van definiálva. 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. App Service ezután automatikusan telepíti ezeket a függőségeket a projekt üzembe helyezésekor.

    A függőségek telepítéséhez arequirements.txtfájlnak a projekt gyökerében kell lennie. 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.

  • App Service automatikusan definiál egy nevű környezeti változót WEBSITE_HOSTNAME a webalkalmazás URL-címével, például msdocs-hello-world.azurewebsites.net: . Az alkalmazás nevével is definiálható WEBSITE_SITE_NAME , például msdocs-hello-world: .

  • Az npm és a Node.js a tárolóba vannak telepítve, így node-alapú 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 meg van adva, 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 a elemet <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 projektgyökér knboard/backend/config területén található, használja az argumentumokat --chdir knboard/backend config.wsgi.

Az éles naplózás engedélyezéséhez adja hozzá a és --error-logfile a --access-logfile paramétereket az egyéni indítási parancsok példáiban látható módon.

Flask-alkalmazás

A Flask esetében 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 ha más argumentumokat szeretne megadni a Gunicorn számára, használjon egy egyéni indítási parancsot.

Alapértelmezett viselkedés

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

Ha kódot helyezett üzembe, é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 az alapértelmezett App Service on Linux 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.txtstb.

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ó lapjá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 paraméterrel az --startup-file 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 a elemet <custom-command> az indítási parancs teljes szövegére vagy az indítási parancsfájl nevére.

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 fájl hibamentes-e, és hogy egy indítási parancsfájl van-e üzembe helyezve App Service az alkalmazás kódjával együtt. További információt a diagnosztikai naplókban is találhat. Ellenőrizze az alkalmazás Problémák diagnosztizálása és megoldása lapját is a Azure Portal.

Példa indítási parancsok

  • Gunicorn-argumentumok hozzáadva: Az alábbi példa hozzáadja a --workers=4 elemet egy Gunicorn parancssorhoz 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 méretezé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át használó NUM_CORES gunicorn-feldolgozók számát is dinamikusan kell beállítania, 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.

  • Éles naplózás engedélyezése a Django esetében: Adja hozzá az --access-logfile '-' és --error-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 a App Service naplóstreamben.

    További információ: Gunicorn-naplózás (docs.gunicorn.org).

  • Custom Flask főmodul: Alapértelmezés szerint App Service feltételezi, hogy egy 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 nevű DATABASE_SERVERalkalmazásbeállítást, a következő kód kéri le a beállítás értékét:

db_server = os.environ['DATABASE_SERVER']

HTTPS-munkamenet észlelése

A App Service TLS/SSL-leállítás (wikipedia.org) történik a hálózati terheléselosztóknál, í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 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 tudathatja 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 <app-name> a és <resource-group-name> a nevet 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 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 CtrlCbillentyűkombinációt+.

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

A naplók Azure Portal keresztüli eléréséhez válassza az alkalmazás bal oldali menüjének Figyelési>naplóstream elemét.

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

A kód üzembe helyezésekor App Service végrehajtja a buildelési folyamat korábban ismertetett folyamatát a Buildautomatizálás testreszabása című 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 válassza az Üzembe helyezé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 látható.

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 szkriptekben előforduló hibák. A 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

Megjegyzé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 csatlakozott 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ának lépéseit a Hibaelhárítás című témakörben találja.

Hibaelhárítás

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

  1. A webalkalmazás Azure Portal a bal oldali menüben válassza a Problémák diagnosztizálása és megoldása lehetőséget.
  2. Válassza a Rendelkezésre állás és 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 található 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 is, hogy vannak-e hibaüzenetek. 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.

Az alábbi szakaszok útmutatást nyújtanak a konkrét problémákhoz.

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 App Service, vagy 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 csatlakozhat a App Service tárolóhoz, és ellenőrizheti, hogy a fájlok léteznek-e a site/wwwroot területen. Ha a fájlok nem léteznek, kövesse az alábbi lépéseket:

      1. Hozzon létre egy 1 értékű nevű SCM_DO_BUILD_DURING_DEPLOYMENT alkalmazásbeállítást, telepítse újra a kódot, várjon néhány percet, majd próbálkozzon újra az alkalmazás elérésével. További információ az alkalmazásbeállítások létrehozásáról: App Service alkalmazás konfigurálása a Azure Portal.
      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és miatt nem várt választ App Service, ami azt jelzi, hogy 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 hogy hiba van az alkalmazás kódjában.

    • 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 , hogy vannak-e hibaüzenetek. A naplók megjelenítik az alkalmazás kódjában szereplő hibákat.

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

  • A naplóstreamben a következő látható: "Nem található setup.py vagy requirements.txt; Nem fut a pip telepítése.": Az Oryx buildelési folyamata nem találta meg a requirements.txt fájlt.

    • Csatlakozzon a webalkalmazás tárolóhoz SSH-n keresztül, és győződjön meg arról, hogy arequirements.txt neve helyes, és közvetlenül a site/wwwroot alatt található. Ha nem létezik, győződjön meg róla, 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érkönyvtárba.

ModuleNotFoundError az alkalmazás indításakor

Ha a következő hibaüzenet jelenik meg: ModuleNotFoundError: No module named 'example', 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 helyezi üzembe. 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, SCM_DO_BUILD_DURING_DEPLOYMENTmajd állítsa be a következőre 1: . Ez a beállítás arra kényszeríti az Oryxot, hogy telepítse a csomagokat, amikor a App Service üzembe helyezi. 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 adatbázis-migrálásokat próbál futtatni egy Django-alkalmazással, 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-hoz készült PostgreSQL-t.

Ellenőrizze az DATABASES alkalmazás settings.py fájljában található változót, és győződjön meg arról, hogy az alkalmazás SQLite helyett felhőalapú adatbázist használ.

Ha ezt a hibát az Oktatóanyag: Django-webalkalmazás üzembe helyezése a PostgreSQL-ben című témakörben szereplő példában találja, ellenőrizze, hogy elvégezte-e a kapcsolati beá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 rejtve tartja 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, majd 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ó parancs, de továbbra is helyesen kell futnia.

  • A statikus objektumok nem jelennek meg egy Django-alkalmazásban: 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 alkalmazáson belüli erőforrások (például adatbázisok) eléréséhez használt felhasználóneveket és jelszavakat.

További erőforrások