Egyéni tároló konfigurálása az Azure App Service-hez

  • Cikk

Ez a cikk bemutatja, hogyan konfigurálhat egyéni tárolót Azure-alkalmazás szolgáltatáson való futtatáshoz.

Ez az útmutató a Windows-alkalmazások App Service-ben történő tárolóba helyezésének alapvető fogalmait és utasításait ismerteti. Az új Azure-alkalmazás szolgáltatásfelhasználóknak először az egyéni tároló rövid útmutatót és oktatóanyagot kell követnie.

Ez az útmutató alapvető fogalmakat és utasításokat tartalmaz a Linux-alkalmazások App Service-ben való tárolóba helyezéséhez. Ha még nem ismerkedik a Azure-alkalmazás szolgáltatással, először kövesse az egyéni tároló rövid útmutatót és oktatóanyagot. Emellett egy többtárolós alkalmazás rövid útmutatója és oktatóanyaga is elérhető. A sidecar-tárolók (előzetes verzió) esetében lásd: Oktatóanyag: Oldalkocsi-tároló konfigurálása egyéni tárolóhoz Azure-alkalmazás szolgáltatásban (előzetes verzió).

Feljegyzés

A Szolgáltatásnév már nem támogatott a Windows tárolólemezképek lekéréses hitelesítéséhez. Az ajánlott módszer a Felügyelt identitás használata Windows és Linux rendszerű tárolókhoz

Támogatott szülőképek

Az egyéni Windows-rendszerképhez a megfelelő szülőrendszerképet (alaprendszerképet) kell választania a kívánt keretrendszerhez:

Az alkalmazás indításakor a szülőrendszerkép letöltése hosszabb időbe telhet. Az indítási időt azonban lecsökkentheti az alábbi, az Azure App Service-ben már gyorsítótárazott szülőrendszerképek egyikének használatával:

  • mcr.microsoft.com/windows/servercore:ltsc2022
  • mcr.microsoft.com/windows/servercore:ltsc2019
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-1809
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809

Egyéni tároló Docker-lemezképének módosítása

Ha egy meglévő egyéni tárolót az aktuális Docker-lemezképről új lemezképre szeretne módosítani, használja a következő parancsot:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

Rendszerkép használata privát beállításjegyzékből

Ha egy privát beállításjegyzékből (például az Azure Container Registryből) származó lemezképet szeretne használni, futtassa a következő parancsot:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

A felhasználónév> és <a jelszó> megadásához <adja meg a bejelentkezési hitelesítő adatokat a privát beállításjegyzék-fiókhoz.

Felügyelt identitás használata lemezkép lekéréséhez az Azure Container Registryből

Az alábbi lépésekkel konfigurálhatja a webalkalmazást úgy, hogy lekérje az Azure Container Registryből (ACR) felügyelt identitás használatával. A lépések a rendszer által hozzárendelt felügyelt identitást használják, de használhat felhasználó által hozzárendelt felügyelt identitást is.

  1. Engedélyezze a webalkalmazás rendszer által hozzárendelt felügyelt identitását a az webapp identity assign következő paranccsal:

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    Cserélje le <app-name> az előző lépésben használt névre. A parancs kimenete (amelyet az és --output az --query argumentumok szűrnek) a hozzárendelt identitás egyszerű szolgáltatásazonosítója.

  2. Kérje le az Azure Container Registry erőforrás-azonosítóját:

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    Cserélje le a <registry-name> elemet a tárolójegyzék nevére. A parancs kimenete (az és --output argumentumok --query alapján szűrve) az Azure Container Registry erőforrás-azonosítója.

  3. Adjon engedélyt a felügyelt identitásnak a tárolóregisztrációs adatbázis eléréséhez:

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    Cserélje le a következő értékeket:

    • <principal-id>a parancs szolgáltatásnév-azonosítójával az webapp identity assign
    • <registry-resource-id> a tárolóregisztrációs adatbázis azonosítójával a az acr show parancsból

    További információ ezekről az engedélyekről: Mi az Azure szerepköralapú hozzáférés-vezérlése?

  4. Konfigurálja az alkalmazást úgy, hogy a felügyelt identitás használatával lekérje az Azure Container Registryből.

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'

    Cserélje le a következő értékeket:

    • <app-name> a webalkalmazás nevével.

    Tipp.

    Ha PowerShell-konzolt használ a parancsok futtatásához, az ebben és a következő lépésben --generic-configurations szereplő argumentum sztringjei elől kell menekülnie. Például: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Nem kötelező) Ha az alkalmazás felhasználó által hozzárendelt felügyelt identitást használ, győződjön meg arról, hogy az identitás konfigurálva van a webalkalmazásban, majd állítsa be a tulajdonságot az acrUserManagedIdentityID ügyfélazonosító megadásához:

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv

    Cserélje le a <identity-name> felhasználó által hozzárendelt felügyelt identitást, és a kimenettel <client-id> konfigurálja a felhasználó által hozzárendelt felügyelt identitásazonosítót.

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'

Minden be van állítva, és a webalkalmazás mostantól felügyelt identitást használ az Azure Container Registryből való lekéréshez.

Rendszerkép használata hálózati védelem alatt álló beállításjegyzékből

A virtuális hálózaton vagy a helyszínen lévő beállításjegyzékből való csatlakozáshoz és lekéréshez az alkalmazásnak integrálnia kell egy virtuális hálózattal (VNET). A virtuális hálózatok integrációjára az Azure Container Registryhez is szükség van privát végponttal. Ha a hálózat és a DNS felbontása konfigurálva van, a helybeállítás konfigurálásával engedélyezheti a rendszerkép-lekérés útválasztását a vnetImagePullEnabled virtuális hálózaton:

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

Nem látom a frissített tárolót

Ha úgy módosítja a Docker-tároló beállításait, hogy egy új tárolóra mutasson, az eltarthat néhány percig, amíg az alkalmazás http-kéréseket küld az új tárolóból. Miközben az új tároló lekérése és elindítása folyamatban van, az App Service továbbra is kiszolgálja a régi tárolóból érkező kéréseket. Az App Service csak akkor indítja el a kéréseket, ha az új tároló elindult, és készen áll a kérelmek fogadására.

Tárolólemezképek tárolása

Amikor először futtat egyéni Docker-lemezképet az App Service-ben, az App Service elvégzi docker pull az összes képréteg lekérését és lekérését. Ezek a rétegek lemezen vannak tárolva, például a Docker helyszíni használata esetén. Minden alkalommal, amikor az alkalmazás újraindul, az App Service elvégzi a docker pullelemet, de csak a módosított rétegeket húzza le. Ha nincsenek módosítások, az App Service meglévő rétegeket használ a helyi lemezen.

Ha az alkalmazás bármilyen okból módosítja a számítási példányokat, például a tarifacsomagok fel- és leskálázását, az App Service-nek újra le kell húznia az összes réteget. Ugyanez igaz, ha vertikális felskálázást végez további példányok hozzáadásához. Vannak olyan ritka esetek is, amikor az alkalmazáspéldányok skálázási művelet nélkül változhatnak.

Portszám konfigurálása

Alapértelmezés szerint az App Service azt feltételezi, hogy az egyéni tároló a 80-as porton figyel. Ha a tároló egy másik portot figyel, állítsa be az WEBSITES_PORT alkalmazásbeállítást az App Service-alkalmazásban. Ezt a Cloud Shell használatával állíthatja be. A Bashben:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

A PowerShellben:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}

Az App Service jelenleg lehetővé teszi, hogy a tároló csak egy portot tegyen elérhetővé a HTTP-kérésekhez.

Környezeti változók konfigurálása

Előfordulhat, hogy az egyéni tároló környezeti változókat használ, amelyeket külsőleg kell megadni. Ezeket a Cloud Shellen keresztül is átadhatja. A Bashben:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

A PowerShellben:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

Az alkalmazás futtatásakor a rendszer automatikusan környezeti változókként injektálja az App Service alkalmazásbeállításait a folyamatba. A tárolókörnyezet változóit az URL-címmel https://<app-name>.scm.azurewebsites.net/Envellenőrizheti.

Ha az alkalmazás magánregisztrációs adatbázisból vagy a Docker Hubról származó lemezképeket használ, az adattár eléréséhez szükséges hitelesítő adatokat a rendszer környezeti változókba menti: DOCKER_REGISTRY_SERVER_URLés DOCKER_REGISTRY_SERVER_USERNAMEDOCKER_REGISTRY_SERVER_PASSWORD. A biztonsági kockázatok miatt ezek közül a fenntartott változónevek egyike sem érhető el az alkalmazás számára.

IIS- vagy .NET-keretrendszer -alapú (4.0-s vagy újabb) tárolók esetén az App Service automatikusan .NET-alkalmazásbeállításokként és kapcsolati sztring adja meg System.ConfigurationManager őket. Az összes többi nyelvhez vagy keretrendszerhez környezeti változóként vannak megadva a folyamathoz, az alábbi előtagok egyikével:

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

Ez a módszer egytárolós vagy többtárolós alkalmazások esetében is működik, ahol a környezeti változók a docker-compose.yml fájlban vannak megadva.

Állandó megosztott tárterület használata

A C:\home könyvtárat az egyéni tároló fájlrendszerében használhatja a fájlok újraindítások közötti megőrzéséhez és példányok közötti megosztásához. A C:\home címtár lehetővé teszi az egyéni tároló számára az állandó tároló elérését.

Ha az állandó tárterület le van tiltva, akkor a C:\home címtárba való írás nem marad meg az alkalmazás újraindítása vagy több példány között. Ha az állandó tárolás engedélyezve van, a C:\home címtárba írt összes írás megmarad, és egy kibővített alkalmazás összes példánya elérheti. Emellett a C:\home tároló könyvtárában lévő összes tartalmat felülírja a tároló indításakor az állandó tárban már meglévő fájlok.

Az egyetlen kivétel a C:\home\LogFiles tároló- és alkalmazásnaplók tárolására használt könyvtár. Ez a mappa mindig megmarad az alkalmazás újraindításakor, ha az alkalmazásnaplózás engedélyezve van a fájlrendszer beállítással, függetlenül attól, hogy az állandó tároló engedélyezve van vagy le van tiltva. Más szóval az állandó tárterület engedélyezése vagy letiltása nem befolyásolja az alkalmazás naplózási viselkedését.

Alapértelmezés szerint az állandó tárolás le van tiltva a Windows egyéni tárolóiban. Az engedélyezéshez állítsa be az WEBSITES_ENABLE_APP_SERVICE_STORAGE alkalmazásbeállítás értékét true a Cloud Shellen keresztül. A Bashben:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

A PowerShellben:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

A /home könyvtárat az egyéni tároló fájlrendszerében használhatja a fájlok újraindítások közötti megőrzéséhez és példányok közötti megosztásához. A /home címtár lehetővé teszi az egyéni tároló számára az állandó tároló elérését. Az adatok /home az App Service-csomagban foglalt tárhelykvótához járulnak hozzá.

Ha az állandó tárterület le van tiltva, akkor a /home címtárba való írás nem marad meg az alkalmazás újraindítása vagy több példány között. Ha az állandó tárolás engedélyezve van, a /home címtárba írt összes írás megmarad, és egy kibővített alkalmazás összes példánya elérheti. Emellett a /home tároló könyvtárában lévő összes tartalmat felülírja a tároló indításakor az állandó tárban már meglévő fájlok.

Az egyetlen kivétel a /home/LogFiles tároló- és alkalmazásnaplók tárolására használt könyvtár. Ez a mappa mindig megmarad az alkalmazás újraindításakor, ha az alkalmazásnaplózás engedélyezve van a fájlrendszer beállítással, függetlenül attól, hogy az állandó tároló engedélyezve van vagy le van tiltva. Más szóval az állandó tárterület engedélyezése vagy letiltása nem befolyásolja az alkalmazás naplózási viselkedését.

Javasoljuk, hogy adatokat /home írjon az Azure Storage-ba vagy egy csatlakoztatott Azure Storage-elérési útra. Az ezeken az útvonalakon kívül írt adatok nem állandók az újraindítások során, és a rendszer az App Service-csomagok fájltárolási kvótájától eltérő, platform által felügyelt gazdagép lemezterületére menti őket.

Alapértelmezés szerint az állandó tárolás engedélyezve van linuxos egyéni tárolókon. A letiltásához állítsa be az WEBSITES_ENABLE_APP_SERVICE_STORAGE alkalmazásbeállítás értékét false a Cloud Shellen keresztül. A Bashben:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

A PowerShellben:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

Feljegyzés

Saját állandó tárterületet is konfigurálhat.

HTTPS munkamenet észlelése

Az App Service az előtérnél leállítja a TLS/SSL protokollt. Ez azt jelenti, hogy a TLS-/SSL-kérések soha nem jutnak el az alkalmazáshoz. Nem kell, és nem kell implementálnia a TLS/SSL támogatását az alkalmazásba.

Az előtér az Azure-adatközpontokban található. Ha TLS/SSL-t használ az alkalmazással, az interneten keresztüli forgalom mindig biztonságosan titkosítva lesz.

ASP.NET gépkulcs-injektálás testreszabása

A tároló indítása során a rendszer automatikusan generált kulcsokat injektál a tárolóba ASP.NET titkosítási rutinok gépkulcsaként. Ezeket a kulcsokat a tárolóban a következő környezeti változók keresésével találja meg: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, , MACHINEKEY_ValidationMACHINEKEY_ValidationKey.

Az egyes újraindításokkor az új kulcsok alaphelyzetbe állíthatják ASP.NET űrlapok hitelesítését és megtekintési állapotát, ha az alkalmazás ezektől függ. A kulcsok automatikus újragenerálásának megakadályozásához állítsa őket manuálisan App Service-alkalmazásbeállításokként.

Csatlakozás a tárolóhoz

Az SSH-lehetőség kiválasztásával https://<app-name>.scm.azurewebsites.net/ közvetlenül csatlakozhat a Windows-tárolóhoz diagnosztikai feladatokhoz. Létrejön egy közvetlen SSH-munkamenet a tárolóval, amelyben parancsokat futtathat a tárolón belül.

  • A fenti grafikus böngészőtől külön működik, amely csak a megosztott tárban lévő fájlokat jeleníti meg.
  • A kibővített alkalmazásokban az SSH-munkamenet az egyik tárolópéldányhoz csatlakozik. A felső Kudu menü Példány legördülő menüjében másik példányt is választhat.
  • A tárolóban az SSH-munkameneten belül végrehajtott módosítások nem maradnak meg az alkalmazás újraindításakor (kivéve a megosztott tároló módosításait), mert az nem része a Docker-rendszerképnek. Ha meg szeretné őrizni a módosításokat, például a beállításjegyzék beállításait és a szoftvertelepítést, tegye őket a Dockerfile részévé.

Diagnosztikai naplók elérése

Az App Service naplózza a Docker-gazdagép műveleteit és a tárolón belüli tevékenységeket. A Docker-gazdagépről (platformnaplókból) származó naplók alapértelmezés szerint le vannak szállítva, de a tárolón belüli alkalmazásnaplókat vagy webkiszolgáló-naplókat manuálisan kell engedélyezni. További információ: Az alkalmazásnaplózás engedélyezése és a webkiszolgáló-naplózás engedélyezése.

A Docker-naplók többféleképpen is elérhetők:

Az Azure Portalon

A Docker-naplók az alkalmazás Tároló Gépház lapján jelennek meg a portálon. A naplók csonkoltak, de a Letöltés lehetőséget választó összes naplót letöltheti.

Forrás: Kudu

Lépjen a https://<app-name>.scm.azurewebsites.net/DebugConsole LogFiles mappára, és válassza ki az egyes naplófájlokat . A teljes LogFiles-könyvtár letöltéséhez válassza a könyvtárnév bal oldalán található "Letöltés" ikont. Ezt a mappát FTP-ügyféllel is elérheti.

Az SSH-terminálban alapértelmezés szerint nem férhet hozzá a C:\home\LogFiles mappához, mert az állandó megosztott tárterület nincs engedélyezve. Ha engedélyezni szeretné ezt a viselkedést a konzolterminálon, engedélyezze az állandó megosztott tárterületet.

Ha ftp-ügyféllel próbálja letölteni a jelenleg használt Docker-naplót, a fájlzárolás miatt hibaüzenet jelenhet meg.

A Kudu API-val

Lépjen közvetlenül a https://<app-name>.scm.azurewebsites.net/api/logs/docker Docker-naplók metaadatainak megtekintéséhez. Előfordulhat, hogy több naplófájl is megjelenik a listában, és a href tulajdonság lehetővé teszi a naplófájl közvetlen letöltését.

Ha az összes naplót egy ZIP-fájlban szeretné letölteni, lépjen be a fájlba https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Tárolómemória testreszabása

Alapértelmezés szerint az Azure-alkalmazás szolgáltatásban üzembe helyezett összes Windows-tároló rendelkezik memóriakorláttal. Az alábbi táblázat az App Service-csomag termékváltozatának alapértelmezett beállításait sorolja fel.

App Service-csomag termékváltozata Alkalmazásonkénti alapértelmezett memóriakorlát MB-ban
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Ezt az értéket úgy módosíthatja, hogy megadja az WEBSITE_MEMORY_LIMIT_MB alkalmazásbeállítást a Cloud Shellen keresztül. A Bashben:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

A PowerShellben:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

Az érték MB-ban van definiálva, és a gazdagép teljes fizikai memóriájának kisebbnek és egyenlőnek kell lennie. Egy 8 GB RAM-mal rendelkező App Service-csomagban például az összes alkalmazás összesített összege WEBSITE_MEMORY_LIMIT_MB nem haladhatja meg a 8 GB-ot. Az egyes tarifacsomagok memóriahasználatával kapcsolatos információk az App Service díjszabásában, a Premium v3 szolgáltatáscsomag szakaszban találhatók.

A számítási magok számának testreszabása

Alapértelmezés szerint egy Windows-tároló a kiválasztott tarifacsomag összes elérhető magjával fut. Érdemes lehet például csökkenteni az előkészítési pont által használt magok számát. A tároló által használt magok számának csökkentéséhez állítsa be az WEBSITE_CPU_CORES_LIMIT alkalmazásbeállítást az előnyben részesített magok számára. Ezt a Cloud Shell használatával állíthatja be. A Bashben:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

A PowerShellben:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

Feljegyzés

Az alkalmazásbeállítás frissítése automatikus újraindítást vált ki, ami minimális állásidőt okoz. Éles alkalmazások esetében fontolja meg az előkészítési pontra való felcserélést, az előkészítési ponton az alkalmazás beállításának módosítását, majd az éles környezetbe való visszacserélését.

Ellenőrizze a módosított számot egy SSH-munkamenet megnyitásával a portálon vagy a Kudu portálon (https://<app-name>.scm.azurewebsites.net/webssh/host) keresztül, és írja be a következő parancsokat a PowerShell használatával. Minden parancs egy számot ad ki.

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

A processzorok lehetnek többmagos vagy hipertreading processzorok. Az egyes tarifacsomagok magjairól az App Service díjszabásában, a Premium v3 szolgáltatáscsomag szakaszban tájékozódhat.

Állapot pingelési viselkedésének testreszabása

Az App Service úgy véli, hogy a tároló indításakor a tároló sikeresen elindult, és http-pingre válaszol. Az állapot pingelési kérése tartalmazza a fejlécet User-Agent= "App Service Hyper-V Container Availability Check". Ha a tároló elindul, de bizonyos idő elteltével nem válaszol a pingekre, az App Service naplóz egy eseményt a Docker naplójában, amely szerint a tároló nem indult el.

Ha az alkalmazás erőforrás-igényes, előfordulhat, hogy a tároló nem válaszol időben a HTTP-pingre. A HTTP-pingek sikertelen futtatásakor végrehajtandó műveletek szabályozásához állítsa be az alkalmazásbeállítást CONTAINER_AVAILABILITY_CHECK_MODE . Ezt a Cloud Shell használatával állíthatja be. A Bashben:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

A PowerShellben:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

Az alábbi táblázat a lehetséges értékeket mutatja be:

Érték Leírások
Javítás Három egymást követő rendelkezésre állási ellenőrzés után indítsa újra a tárolót
ReportOnly Az alapértelmezett érték. Ne indítsa újra a tárolót, hanem három egymást követő rendelkezésre állási ellenőrzés után jelentse be a tároló Docker-naplóiban.
Kikapcsolva Ne ellenőrizze a rendelkezésre állást.

Csoport által felügyelt szolgáltatásfiókok támogatása

A csoportosan felügyelt szolgáltatásfiókok (gMSA-k) jelenleg nem támogatottak az App Service Windows-tárolóiban.

SSH engedélyezése

A Secure Shellt (SSH) gyakran használják rendszergazdai parancsok parancssori terminálról távolról történő végrehajtására. Ahhoz, hogy az Azure Portal SSH-konzolfunkciója egyéni tárolókkal legyen engedélyezve, a következő lépések szükségesek:

  1. Hozzon létre egy standard sshd_config fájlt a következő példatartalommal, és helyezze el az alkalmazásprojekt gyökérkönyvtárában:

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Feljegyzés

    Ez a fájl konfigurálja az OpenSSH-t, és a következő elemeket kell tartalmaznia az Azure Portal SSH-funkciójának való megfeleléshez:

    • Port 2222-nek kell lennie.
    • A Ciphers beállításnak tartalmaznia kell legalább egy elemet a következő listából: aes128-cbc,3des-cbc,aes256-cbc.
    • A MACs beállításnak tartalmaznia kell legalább egy elemet a következő listából: hmac-sha1,hmac-sha1-96.

  2. Hozzon létre egy entrypoint-szkriptet a névvel entrypoint.sh (vagy módosítsa a meglévő belépésipont-fájlt), és adja hozzá a parancsot az SSH szolgáltatás elindításához az alkalmazás indítási parancsával együtt. Az alábbi példa egy Python-alkalmazás elindítását mutatja be. Cserélje le az utolsó parancsot a projekt nyelvének/veremének megfelelően:

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. Adja hozzá a Dockerfile-hoz az alábbi utasításokat az alaprendszerkép-eloszlásnak megfelelően. Ezek az utasítások átmásolják az új fájlokat, telepítik az OpenSSH-kiszolgálót, beállítják a megfelelő engedélyeket, konfigurálják az egyéni belépési pontot, és elérhetővé teszik az alkalmazás és az SSH-kiszolgáló által igényelt portokat:

    COPY entrypoint.sh ./

# Start and enable SSH
RUN apt-get update \
    && apt-get install -y --no-install-recommends dialog \
    && apt-get install -y --no-install-recommends openssh-server \
    && echo "root:Docker!" | chpasswd \
    && chmod u+x ./entrypoint.sh
COPY sshd_config /etc/ssh/

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]

    Feljegyzés

    A gyökérjelszónak pontosan Docker! úgy kell lennie, ahogyan azt az App Service használja, hogy hozzáférhessen az SSH-munkamenethez a tárolóval. Ez a konfiguráció nem teszi lehetővé a tároló külső kapcsolatait. A tároló 2222-s portja csak egy magánhálózat hídhálózatán belül érhető el, és nem érhető el a támadók számára az interneten.

  4. Újraépítheti és leküldheti a Docker-rendszerképet a beállításjegyzékbe, majd tesztelheti a Web App SSH-funkcióját az Azure Portalon.

További hibaelhárítási információk a Azure-alkalmazás szolgáltatás blogján érhetők el: Az SSH engedélyezése Linux Web App for Containers rendszeren

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

Többtárolós alkalmazások konfigurálása

Állandó tárterület használata a Docker Compose-ban

A többtárolós alkalmazásoknak, például a WordPressnek állandó tárterületre van szükségük a megfelelő működéshez. Ennek engedélyezéséhez a Docker Compose-konfigurációnak a tárolón kívüli tárolóra kell mutatnia. A tárolón belüli tárolási helyek nem őriznek meg módosításokat az alkalmazás újraindítása után.

Engedélyezze az állandó tárolást az WEBSITES_ENABLE_APP_SERVICE_STORAGE alkalmazásbeállítás beállításával, az az webapp config appsettings set paranccsal a Cloud Shellben.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

A docker-compose.yml fájlban adja meg a lehetőséget${WEBAPP_STORAGE_HOME}.volumes

A WEBAPP_STORAGE_HOME egy környezeti változó az App Service szolgáltatásban, amely az alkalmazás állandó tárolójára mutat. Példa:

wordpress:
  image: <image name:tag>
  volumes:
  - "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
  - "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
  - "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"

Előzetes verzióra vonatkozó korlátozások

A többtárolós tároló jelenleg előzetes verzióban érhető el. A következő App Service-platformfunkciók nem támogatottak:

  • Hitelesítés / engedélyezés
  • Felügyelt identitások
  • CORS
  • A Docker Compose-forgatókönyvek esetében a virtuális hálózati integráció nem támogatott
  • A Docker Compose jelenleg 4000 karakterből áll a Azure-alkalmazás-szolgáltatásokban.

A Docker Compose beállításai

Az alábbi listák a Docker Compose támogatott és nem támogatott konfigurációs beállításait jelenítik meg:

Támogatott beállítások

Nem támogatott beállítások

  • build (nem engedélyezett)
  • depends_on (figyelmen kívül hagyva)
  • networks (figyelmen kívül hagyva)
  • secrets (figyelmen kívül hagyva)
  • a 80 és 8080 porttól eltérő portok (figyelmen kívül hagyva)
  • alapértelmezett környezeti változók, például $variable and ${variable} a Dockerben

Szintaxiskorlátozások

  • Az x.x verziónak mindig az első YAML-utasításnak kell lennie a fájlban
  • a portszakasznak idézőszámokat kell használnia
  • a képkötet > szakaszát idézni kell, és nem rendelkezhet engedélydefiníciókkal
  • a kötetek szakaszának nem lehet üres kapcsos zárójele a kötet neve után

Feljegyzés

A nyilvános előzetes verzió figyelmen kívül hagyja a nem explicit módon kikiáltott egyéb beállításokat.

robots933456 a naplókban

A következő üzenet jelenhet meg a tárolónaplókban:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Az üzenet biztonságosan figyelmen kívül hagyható. /robots933456.txt egy olyan próba URL-cím, amelyet az App Service annak a vizsgálatára használ, hogy a tároló képes-e a kérések kiszolgálására. A 404-es válasz egyszerűen azt jelenti, hogy a cím nem létezik, azonban jelzi az App Service számára, hogy a tároló kifogástalan állapotú, és készen áll a kérések megválaszolására.

Következő lépések

Oktatóanyag: Egyéni szoftverek migrálása Azure-alkalmazás szolgáltatásba egyéni tároló használatával

Oktatóanyag: Többtárolós WordPress-alkalmazás

Vagy tekintse meg a további erőforrásokat: