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

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 a Git-adattár üzembe helyezésekor, illetve egy 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, a Flaskot, a Django-t vagy a FastAPI-t a PostgreSQL-oktatóanyaggal.

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

• Az Azure Portalon használja az alkalmazás Beállítások>konfigurációs lapját az App Service-alkalmazás konfigurálása az Azure Portalon című cikkben leírtak szerint.

• Azure CLI: két lehetőség közül választhat.

  • Parancsok futtatása az Azure Cloud Shellben.
  • A parancsok helyi futtatásához telepítse az Azure CLI legújabb verzióját, majd jelentkezzen be az Azure-ba az login használatával.

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 telepíté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 beállítás határozza meg, futtassa az PRE_BUILD_COMMAND 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. Futtassa az egyéni összeállítás utáni szkriptet, ha ezt a lépést a POST_BUILD_COMMAND beállítás határozza meg. (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őzetes buildelési parancsok futtatásához állítsa be a PRE_BUILD_COMMAND beállítást úgy, hogy egy parancsot, például echo Pre-build commandegy szkriptfájl elérési útját tartalmazza a projekt gyökeréhez 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 egy parancsot( például echo Post-build commandegy szkriptfájl elérési útját) tartalmazzon 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 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.

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

   • Az adatbázis-kapcsolatokat például gyakran kezelik ilyen beállításokkal, ahogyan az oktatóanyagban is látható: Django-webalkalmazás üzembe helyezése a PostgreSQL-lel – kapcsolatbeállítások ellenőrzése.
   • A Django-alkalmazások éles beállításai között megtekintheti a tipikus Django-alkalmazások konkrét beállításait.

5. Alkalmazásindítás: 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

Az olyan éles környezetek esetében, mint a Azure-alkalmazás Szolgáltatás, a Django-alkalmazásoknak követnie kell a Django üzembe helyezési ellenőrzőlistát.

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.

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 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 hozunk létre, FRONTEND_DIR ahol egy buildelési eszköz, például a yarn fut. 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 és INSTALLED_APPS a MIDDLEWARE listákat is a WhiteNoise-ra:

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

  • 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ások elleni védelme érdekében a Gunicorn egy Nginx fordított proxy mögött fut, a Gunicorn üzembe helyezéséről szóló cikkben 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+-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. 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, 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.

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ósoldalá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 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 containing wsgi.py.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi
  

  További információ: Gunicorn futtatása. 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.

• 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 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 az "Oryx build futtatása..." mellett megjelenő Naplók megjelenítése hivatkozást.

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

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

Ha Python-alkalmazásokat helyez üzembe Azure-alkalmazás Linux-alapú szolgáltatásban, előfordulhat, hogy az url-átírásokat az alkalmazásban kell kezelnie. 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-diagnosztika 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 – az alapértelmezett alkalmazás jelenik meg
• Az alkalmazás nem jelenik meg – "a szolgáltatás nem érhető el" üzenet
• Nem található setup.py vagy requirements.txt
• ModuleNotFoundError indításkor
• Az adatbázis zárolva van
• Beíráskor a jelszavak nem jelennek meg az SSH-munkamenetben
• Úgy tűnik, hogy az SSH-munkamenet parancsai le lettek vágva
• A statikus objektumok nem jelennek meg Django-alkalmazásban
• Végzetes SSL-kapcsolat szükséges

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 tarifacsomagjait használja. Az alkalmazás indítása hosszabb időt is igénybe vehet, ha például ingyenes szinteket használ, és a böngésző frissítése után válaszképessé válik.

  • 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

• A naplóstream a következőt jeleníti meg: "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 ellenőrizze, hogy a requirements.txt helyesen van-e elnevezve, és közvetlenül a webhely/wwwroot alatt található-e. 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érkönyvtárba.

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ó: 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 válassza az Enter lehetőséget , amikor elkészült.

• Úgy tűnik, hogy az SSH-munkamenet parancsai ki 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 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

• Oktatóanyag: Flask-alkalmazás a PostgreSQL-lel
• Oktatóanyag: Django-alkalmazás a PostgreSQL-lel
• Oktatóanyag: FastAPI-alkalmazás a PostgreSQL-lel
• Oktatóanyag: Üzembe helyezés privát tárolóadattárból
• App Service Linuxon – gyakori kérdések
• Környezeti változók és alkalmazásbeállítások referenciája