Oktatóanyag: Magas rendelkezésre állású többrégiós alkalmazás létrehozása Azure-alkalmazás Szolgáltatásban

A magas rendelkezésre állás és a hibatűrés a jól kivitelezett megoldások kulcsfontosságú összetevői. A legjobb, ha felkészül a váratlan eseményre egy vészhelyzeti tervvel, amely lerövidíti az állásidőt, és automatikusan üzemen tartja a rendszereket, ha valami meghibásodik.

Amikor üzembe helyezi az alkalmazást a felhőben, kiválaszt egy régiót abban a felhőben, ahol az alkalmazásinfrastruktúra alapul. Ha az alkalmazás egyetlen régióban van üzembe helyezve, és a régió elérhetetlenné válik, az alkalmazás is elérhetetlen lesz. A rendelkezésre állás hiánya az alkalmazás SLA-jának feltételei szerint elfogadhatatlan lehet. Ha igen, az alkalmazás és szolgáltatásai több régióban történő üzembe helyezése jó megoldás.

Ebben az oktatóanyagban megtudhatja, hogyan helyezhet üzembe magas rendelkezésre állású többrégiós webalkalmazást. Ezt a forgatókönyvet egyszerűnek tartja, ha az alkalmazás összetevőit csak egy webalkalmazásra és az Azure Front Doorra korlátozza, de a fogalmak bővíthetők és alkalmazhatók más infrastruktúra-mintákra. Ha például az alkalmazás egy Azure-adatbázis-ajánlathoz vagy tárfiókhoz csatlakozik, tekintse meg az SQL-adatbázisok aktív georeplikációját és a tárfiókok redundanciabeállításait. Részletesebb forgatókönyvre vonatkozó referenciaarchitektúra: Magas rendelkezésre állású többrégiós webalkalmazás.

Az alábbi architektúradiagram az oktatóanyagban létrehozott infrastruktúrát mutatja be. Két azonos App Services-szolgáltatásból áll külön régiókban, az egyik az aktív vagy az elsődleges régió, a másik pedig a készenléti vagy másodlagos régió. Az Azure Front Door a forgalmat az App Serviceshez irányítja, és a hozzáférési korlátozások úgy vannak konfigurálva, hogy az alkalmazásokhoz való közvetlen hozzáférés az internetről le legyen tiltva. A pontozott vonal azt jelzi, hogy a forgalom csak akkor lesz elküldve a készenléti régióba, ha az aktív régió leáll.

Az Azure különböző lehetőségeket kínál a terheléselosztáshoz és a forgalom útválasztásához. Az Azure Front Door azért lett kiválasztva ehhez a használati esethez, mert az Azure-alkalmazás szolgáltatásban több régióban üzembe helyezett, internetes webalkalmazásokat tartalmaz. Ha szeretné eldönteni, hogy mi használható a használati esethez, ha eltér az oktatóanyagtól, tekintse meg az Azure-ban a terheléselosztás döntési fáját.

Ezzel az architektúrával:

• Az azonos App Service-alkalmazások két külön régióban vannak üzembe helyezve.
• A nyilvános forgalom közvetlenül az App Service-alkalmazásokba le van tiltva.
• Az Azure Front Door az elsődleges/aktív régió felé irányítja a forgalmat. A másodlagos régióban van egy App Service, amely működik, és szükség esetén készen áll a forgalom kiszolgálására.

Ismertetett témák:

Előfeltételek

Ha nem rendelkezik Azure-előfizetéssel, első lépésként hozzon létre egy ingyenes Azure-fiókot.

Az oktatóanyag elvégzéséhez:

• Használja a Bash-környezetet az Azure Cloud Shellben. További információ: A Bash rövid útmutatója az Azure Cloud Shellben.

  

• Ha inkább helyi cli-referenciaparancsokat szeretne futtatni, telepítse az Azure CLI-t. Ha Windows vagy macOS rendszert használ, fontolja meg az Azure CLI Docker-tárolóban való futtatását. További információ: Az Azure CLI futtatása Docker-tárolóban.

  • Ha helyi telepítést használ, jelentkezzen be az Azure CLI-be az az login parancs futtatásával. A hitelesítési folyamat befejezéséhez kövesse a terminálon megjelenő lépéseket. További bejelentkezési lehetőségekért lásd : Bejelentkezés az Azure CLI-vel.

  • Amikor a rendszer kéri, először telepítse az Azure CLI-bővítményt. További információ a bővítményekről: Bővítmények használata az Azure CLI-vel.

  • Futtassa az az version parancsot a telepített verzió és a függő kódtárak megkereséséhez. A legújabb verzióra az az upgrade paranccsal frissíthet.

Webalkalmazás két példányának létrehozása

Ehhez az oktatóanyaghoz szüksége lesz egy webalkalmazás két példányára, amelyek különböző Azure-régiókban futnak. A régiópárt az USA keleti régiója és az USA nyugati régiója használja, és két üres webalkalmazást hoz létre. Igény esetén nyugodtan választhatja ki saját régióját.

A felügyelet és a tisztítás egyszerűbbé tétele érdekében egyetlen erőforráscsoportot használ az oktatóanyag összes erőforrásához. Érdemes lehet külön erőforráscsoportokat használni az egyes régiókhoz/erőforrásokhoz az erőforrások vészhelyreállítási helyzetben történő további elkülönítéséhez.

Futtassa az alábbi parancsot az erőforráscsoport létrehozásához.

az group create --name myresourcegroup --location eastus

App Service-csomagok létrehozása

Futtassa az alábbi parancsokat az App Service-csomagok létrehozásához. Cserélje le a helyőrzőket két egyedi névre <app-service-plan-east-us><app-service-plan-west-us> , ahol könnyen azonosíthatja a régiót, amelyben vannak.

az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus

az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus

Webalkalmazások létrehozása

Az App Service-csomagok létrehozása után futtassa az alábbi parancsokat a webalkalmazások létrehozásához. Cserélje le a helyőrzőket két globálisan egyedi névre <web-app-east-us><web-app-west-us> (érvényes karakterek: a-zés 0-9) és ügyeljen arra, -hogy figyeljen a --plan paraméterre, hogy minden csomagban (és így minden régióban) egy alkalmazást helyezzen el. Cserélje le a paramétert <runtime> az alkalmazás nyelvi verziójára. Futtassa az webapp list-runtimes az elérhető futtatókörnyezetek listáját. Ha a következő szakaszokban az oktatóanyagban megadott minta Node.js alkalmazást tervezi használni, használja NODE:18-lts futtatókörnyezetként.

az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>

az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>

Jegyezze fel az egyes webalkalmazások alapértelmezett állomásnevét, hogy a következő lépésben definiálhassa a háttércímeket a Front Door üzembe helyezésekor. A következő formátumban kell lennie: <web-app-name>.azurewebsites.net. Ezek a gazdagépnevek az alábbi parancs futtatásával vagy az alkalmazás Áttekintés lapjára lépve találhatók az Azure Portalon.

az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"

Azure Front Door létrehozása

A többrégiós üzemelő példányok aktív-aktív vagy aktív-passzív konfigurációt használhatnak. Az aktív-aktív konfigurációk több aktív régióban osztják el a kéréseket. Az aktív-passzív konfiguráció továbbra is futtat példányokat a másodlagos régióban, de csak akkor küld forgalmat, ha az elsődleges régió meghibásodik. Az Azure Front Door beépített funkciójával engedélyezheti ezeket a konfigurációkat. A magas rendelkezésre állású és hibatűrésű alkalmazások tervezésével kapcsolatos további információkért lásd : Azure-alkalmazások tervezése a rugalmasság és a rendelkezésre állás érdekében.

Azure Front Door-profil létrehozása

Most létrehoz egy Azure Front Door Premiumot , amely átirányítja a forgalmat az alkalmazásokhoz.

Futtassa az afd profile create az Azure Front Door-profil létrehozásához.

az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor

Végpont hozzáadása

Futtassa az afd endpoint create egy végpont létrehozásához a profiljában. A létrehozási folyamat befejezése után több végpontot is létrehozhat a profiljában.

az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled

Forráscsoport létrehozása

Futtassa az afd origin-group create a két webalkalmazást tartalmazó forráscsoport létrehozását.

az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50

Forrás hozzáadása a csoporthoz

Futtassa az afd origin create , ha forrást szeretne hozzáadni a forráscsoporthoz. --host-name A paraméter esetében cserélje le a helyőrzőt <web-app-east-us> az alkalmazás nevére az adott régióban. Figyelje meg, hogy a --priority paraméter a következőre 1van állítva, ami azt jelzi, hogy a rendszer minden forgalmat elküld az elsődleges alkalmazásnak.

az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

Ismételje meg ezt a lépést a második forrás hozzáadásához. Ügyeljen a paraméterre --priority . Ehhez a forráshoz a következőre 2van állítva: . Ez a prioritási beállítás arra utasítja az Azure Front Doort, hogy az elsődleges forrás felé irányítsa az összes forgalmat, kivéve, ha az elsődleges lemegy. Ha ennek a forrásnak 1a prioritását állítja be, az Azure Front Door mindkét forrást aktív és mindkét régióba irányuló közvetlen forgalomként kezeli. Mindenképpen cserélje le a helyőrző mindkét példányát <web-app-west-us> a webalkalmazás nevére.

az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

Útvonal hozzáadása

Futtassa az afd route create a végpont forráscsoporthoz való leképezéséhez. Ez az útvonal továbbítja a végponttól érkező kéréseket a forráscsoportnak.

az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled 

Ez a lépés körülbelül 15 percet vesz igénybe, mivel a módosítás globális propagálása egy ideig tart. Ezen időszak után az Azure Front Door teljesen működőképes.

Webalkalmazások hozzáférésének korlátozása az Azure Front Door-példányhoz

Ezen a ponton továbbra is közvetlenül érheti el az alkalmazásokat az URL-címükkel. Annak érdekében, hogy a forgalom csak az Azure Front Dooron keresztül jusson el az alkalmazásokhoz, minden egyes alkalmazásra hozzáférési korlátozásokat kell beállítania. A Front Door funkciói akkor működnek a legjobban, ha a forgalom csak a Front Dooron halad át. A forrásokat úgy kell konfigurálnia, hogy blokkolják a Front Dooron keresztül még nem küldött forgalmat. Ellenkező esetben a forgalom megkerülheti a Front Door webalkalmazási tűzfalát, a DDoS-védelmet és más biztonsági funkciókat. Az Azure Front Door és az alkalmazások közötti forgalom a szolgáltatáscímkében AzureFrontDoor.Backend meghatározott, jól ismert IP-tartományokból származik. Szolgáltatáscímke-korlátozási szabály használatával korlátozhatja a forgalmat, hogy csak az Azure Front Doorból származjon.

Az App Service hozzáférési korlátozásainak beállítása előtt jegyezze fel a Front Door azonosítóját az alábbi parancs futtatásával. Erre az azonosítóra azért van szükség, hogy a forgalom csak az adott Front Door-példányból származhasson. A hozzáférési korlátozás tovább szűri a bejövő kéréseket az Azure Front Door által küldött egyedi HTTP-fejléc alapján.

az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"

Futtassa az alábbi parancsokat a webalkalmazások hozzáférési korlátozásainak beállításához. Cserélje le a helyőrzőt <front-door-id> az előző parancs eredményére. Cserélje le az alkalmazásnevek helyőrzőit.

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

A Front Door tesztelése

Az Azure Front Door Standard/Premium profil létrehozása néhány percet vesz igénybe, amíg a konfiguráció globálisan üzembe lesz helyezve. Miután elkészült, hozzáférhet a létrehozott előtér-gazdagéphez.

Futtassa az afd endpoint show a Front Door-végpont gazdagépnevének lekéréséhez.

az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"

Nyissa meg a böngészőben az előző parancs által visszaadott végpont állomásnevét: <myendpoint>-<hash>.z01.azurefd.net. A kérésnek automatikusan az USA keleti régiójában található elsődleges alkalmazáshoz kell irányítania.

Azonnali globális feladatátvétel tesztelése:

1. Nyisson meg egy böngészőt, és nyissa meg a végpont állomásnevét: <myendpoint>-<hash>.z01.azurefd.net.

2. Állítsa le az elsődleges alkalmazást az az webapp stop futtatásával.

   az webapp stop --name <web-app-east-us> --resource-group myresourcegroup
   

3. Frissítse a böngészőjét. Ugyanannak az információs oldalnak kell megjelennie, mert a forgalom most már az USA nyugati régiójában futó alkalmazáshoz lesz irányítva.

   Tipp.

   Előfordulhat, hogy a feladatátvétel befejezéséhez néhány alkalommal frissítenie kell a lapot.

4. Most állítsa le a másodlagos alkalmazást.

   az webapp stop --name <web-app-west-us> --resource-group myresourcegroup
   

5. Frissítse a böngészőjét. Ezúttal egy hibaüzenetnek kell megjelennie.

   

6. Indítsa újra az egyik Web Apps alkalmazást az az webapp start futtatásával. Frissítse a böngészőt, és újra meg kell jelennie az alkalmazásnak.

   az webapp start --name <web-app-east-us> --resource-group myresourcegroup
   

Most már ellenőrizte, hogy az Azure Front Dooron keresztül érheti-e el az alkalmazásokat, és hogy a feladatátvétel a kívánt módon működjön. Ha végzett a feladatátvételi teszteléssel, indítsa újra a másik alkalmazást.

A hozzáférési korlátozások teszteléséhez és annak biztosításához, hogy az alkalmazások csak az Azure Front Dooron keresztül érhetők el, nyisson meg egy böngészőt, és navigáljon az egyes alkalmazások URL-címére. Az URL-címek megkereséséhez futtassa a következő parancsokat:

az webapp show --name <web-app-east-us> --resource-group myresourcegroup --query "hostNames"

az webapp show --name <web-app-west-us> --resource-group myresourcegroup --query "hostNames"

Egy hibaoldalnak kell megjelennie, amely azt jelzi, hogy az alkalmazások nem érhetők el.

Az erőforrások eltávolítása

Az előző lépésekben Azure-erőforrásokat hozott létre egy erőforráscsoportban. Ha várhatóan nem lesz szüksége ezekre az erőforrásokra a jövőben, törölje az erőforráscsoportot a következő parancs Cloud Shellben történő futtatásával.

az group delete --name myresourcegroup

A parancs futtatása eltarthat néhány percig.

Üzembe helyezés AZ ARM/Bicep-ből

Az oktatóanyagban létrehozott erőforrások ARM/Bicep-sablonnal telepíthetők. A Bicep-sablon magas rendelkezésre állású többrégiós webalkalmazással biztonságos, magas rendelkezésre állású, többrégiós végpontok közötti megoldást hozhat létre két webalkalmazással az Azure Front Door mögött különböző régiókban.

Az ARM/Bicep-sablonok üzembe helyezéséről az Erőforrások üzembe helyezése a Bicep és az Azure CLI használatával című témakörben olvashat.

Gyakori kérdések

Ebben az oktatóanyagban eddig üzembe helyezte az alapinfrastruktúrát egy többrégiós webalkalmazás engedélyezéséhez. Az App Service olyan funkciókat biztosít, amelyekkel biztosítható, hogy a biztonsági ajánlott eljárásokat és javaslatokat követve futtassa az alkalmazásokat.

Ez a szakasz gyakori kérdéseket tartalmaz, amelyek segíthetnek az alkalmazások további védelmében, valamint az erőforrások üzembe helyezésében és kezelésében az ajánlott eljárások használatával.

Mi az alkalmazásinfrastruktúra és az Azure-erőforrások kezeléséhez és üzembe helyezéséhez ajánlott módszer?

Ebben az oktatóanyagban az Azure CLI használatával telepítette az infrastruktúra-erőforrásokat. Fontolja meg egy folyamatos üzembehelyezési mechanizmus konfigurálását az alkalmazásinfrastruktúra kezeléséhez. Mivel különböző régiókban helyezi üzembe az erőforrásokat, ezeket az erőforrásokat egymástól függetlenül kell kezelnie a régiók között. Annak érdekében, hogy az erőforrások minden régióban azonosak legyenek, az olyan üzembehelyezési folyamatokkal, mint az Azure Pipelines vagy a GitHub Actions, kódként (IaC) kell használni az infrastruktúrát, például az Azure Resource Manager-sablonokat vagy a Terraformot. Így, ha megfelelően van konfigurálva, az erőforrások bármilyen módosítása frissítéseket váltana ki az összes olyan régióban, ahol üzembe van helyezve. További információ: Folyamatos üzembe helyezés Azure-alkalmazás szolgáltatásban.

Hogyan használhatok átmeneti tárolóhelyeket az éles környezetben való biztonságos üzembe helyezés gyakorlásához?

Az alkalmazáskód éles alkalmazásokban/tárolóhelyeken való közvetlen üzembe helyezése nem ajánlott. Ennek az az oka, hogy biztonságos helyen szeretné tesztelni az alkalmazásokat, és ellenőrizni szeretné a módosításokat, mielőtt éles környezetbe küldené. Az előkészítési pontok és a pontcserék kombinációjával kódot helyezhet át a tesztelési környezetből az éles környezetbe.

Ehhez a forgatókönyvhöz már létrehozta az alapinfrastruktúrát. Most üzembehelyezési pontokat hozhat létre az alkalmazás minden példányához, és konfigurálhatja a folyamatos üzembe helyezést ezekre az átmeneti pontokra a GitHub Actions használatával. Az infrastruktúra-kezeléshez hasonlóan a folyamatos üzembe helyezés konfigurálása az alkalmazás forráskódjához is ajánlott annak biztosítása érdekében, hogy a régiók közötti változások szinkronban legyenek. Ha nem konfigurálja a folyamatos üzembe helyezést, minden egyes régióban manuálisan kell frissítenie az egyes alkalmazásokat, amikor kódmódosítás történik.

Az oktatóanyag hátralévő lépéseihez rendelkeznie kell egy alkalmazással, amely üzembe helyezhető az App Servicesben. Ha mintaalkalmazásra van szüksége, használhatja a Node.js „Helló világ!” alkalmazás mintaalkalmazást. Az adattár elágazása, hogy saját másolata legyen.

Mindenképpen állítsa be az App Service verembeállításait az alkalmazásokhoz. A verembeállítások az alkalmazáshoz használt nyelvre vagy futtatókörnyezetre vonatkoznak. Ez a beállítás az Azure CLI-vel konfigurálható a az webapp config set paranccsal vagy a portálon az alábbi lépésekkel. Ha a Node.js mintát használja, állítsa a verem beállításait a Node 18 LTS értékre.

1. Lépjen az alkalmazásra, és válassza a Konfiguráció lehetőséget a bal oldali tartalomjegyzékben.
2. Válassza az Általános beállítások lapot.
3. A Stack settings (Verem beállításai) területen válassza ki az alkalmazás megfelelő értékét.
4. Válassza a Mentés , majd a Folytatás lehetőséget a frissítés megerősítéséhez.
5. Ismételje meg ezeket a lépéseket a többi alkalmazás esetében.

Futtassa az alábbi parancsokat az egyes alkalmazásokhoz tartozó "stage" nevű átmeneti pontok létrehozásához. Cserélje le a helyőrzőket az alkalmazásnevekre <web-app-east-us> és <web-app-west-us> az alkalmazásnevekre.

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-east-us> --slot stage --configuration-source <web-app-east-us>

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-west-us> --slot stage --configuration-source <web-app-west-us>

A folyamatos üzembe helyezés beállításához az Azure Portalt kell használnia. A folyamatos üzembe helyezés olyan szolgáltatókkal való konfigurálásához, mint a GitHub Actions, részletes útmutatásért lásd: Folyamatos üzembe helyezés Azure-alkalmazás szolgáltatásban.

Ha a GitHub Actions használatával szeretné konfigurálni a folyamatos üzembe helyezést, végezze el a következő lépéseket az egyes átmeneti pontokhoz.

1. Az Azure Portalon nyissa meg az Egyik App Service-alkalmazáshely felügyeleti lapját.

2. A bal oldali panelen válassza az Üzembe helyezési központ lehetőséget. Ezután válassza a Beállítások lehetőséget.

3. A Forrás mezőben válassza a "GitHub" lehetőséget a CI/CD beállításai közül:

   

4. Ha első alkalommal telepíti a GitHubot, válassza az Engedélyezés lehetőséget, és kövesse az engedélyezési utasításokat. Ha egy másik felhasználó adattárából szeretné üzembe helyezni az üzembe helyezést, válassza a Fiók módosítása lehetőséget.

5. Miután engedélyezte Azure-fiókját a GitHubon, válassza ki a Szervezet, az Adattár és a Branch lehetőséget a CI/CD konfigurálásához. Ha nem talál szervezetet vagy adattárat, előfordulhat, hogy további engedélyeket kell engedélyeznie a GitHubon. További információ: A szervezet adattáraihoz való hozzáférés kezelése.

   1. Ha a Node.js mintaalkalmazást használja, használja az alábbi beállításokat.

      Beállítás	Érték
      Organization	<your-GitHub-organization>
      Adattár	nodejs-docs-hello-world
      Branch	main

6. Válassza a Mentés lehetőséget.

   A kijelölt adattárban és ágban lévő új véglegesítések mostantól folyamatosan üzembe helyezhetők az App Service-alkalmazáshelyen. A véglegesítéseket és az üzembe helyezéseket a Naplók lapon követheti nyomon.

Egy alapértelmezett munkafolyamat-fájl, amely közzétételi profilt használ az App Service-hitelesítéshez, hozzáadódik a GitHub-adattárhoz. Ezt a fájlt a <repo-name>/.github/workflows/ könyvtárban tekintheti meg.

Hogyan tiltsa le az alapszintű hitelesítést az App Service-ben?

Fontolja meg az alapszintű hitelesítés letiltását, amely korlátozza az FTP- és SCM-végpontok elérését a Microsoft Entra ID által támogatott felhasználók számára. Ha egy folyamatos üzembehelyezési eszközt használ az alkalmazás forráskódja üzembe helyezéséhez, az alapszintű hitelesítés letiltásához további lépésekre van szükség a folyamatos üzembe helyezés konfigurálásához. Például nem használhat közzétételi profilt, mivel nem használja a Microsoft Entra hitelesítő adatait. Ehelyett szolgáltatásnevet vagy OpenID Connectet kell használnia.

Az App Service alapszintű hitelesítésének letiltásához futtassa az alábbi parancsokat az egyes alkalmazásokhoz és pontokhoz az alkalmazásnevek helyőrzőinek <web-app-east-us> lecserélésével.<web-app-west-us> Az első parancskészlet letiltja az FTP-hozzáférést az éles helyekhez és az előkészítési pontokhoz, a második parancskészlet pedig letiltja a WebDeploy-porthoz és az SCM-helyhez való alapvető hozzáférést az éles helyekhez és az előkészítési pontokhoz.

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

További információ az alapszintű hitelesítés letiltásáról, beleértve a bejelentkezések tesztelését és monitorozását, olvassa el az Alapszintű hitelesítés letiltása az App Service-környezetekben című témakört.

Hogyan a kód folyamatos üzembe helyezéssel történő üzembe helyezését, ha letiltottam az alapszintű hitelesítést?

Ha úgy dönt, hogy engedélyezi az alapszintű hitelesítést az App Service-alkalmazásokban, az App Service-ben elérhető üzembe helyezési módszerek bármelyikét használhatja, beleértve az előkészítési pontok szakaszban konfigurált közzétételi profilt is.

Ha letiltja az App Services alapszintű hitelesítését, a folyamatos üzembe helyezéshez szolgáltatásnévre vagy OpenID Connectre van szükség a hitelesítéshez. Ha a GitHub Actionst használja kódtárként, tekintse meg a szolgáltatásnév vagy az OpenID Connect használatával az App Service-ben a GitHub Actions használatával történő üzembe helyezésére vonatkozó részletes oktatóanyagot, vagy hajtsa végre a következő szakaszban leírt lépéseket.

A szolgáltatásnév létrehozása és hitelesítő adatok konfigurálása a GitHub Actions használatával

A folyamatos üzembe helyezés GitHub Actions és szolgáltatásnév használatával történő konfigurálásához kövesse az alábbi lépéseket.

1. Futtassa a következő parancsot a szolgáltatásnév létrehozásához. Cserélje le a helyőrzőket az Ön és az <subscription-id> alkalmazás nevére. A kimenet egy JSON-objektum, amelynek szerepkör-hozzárendelési hitelesítő adatai hozzáférést biztosítanak az App Service-alkalmazásokhoz. Másolja ezt a JSON-objektumot a következő lépéshez. Tartalmazza az ügyfél titkos kódját, amely jelenleg csak látható. Mindig ajánlott minimális hozzáférést biztosítani. A jelen példában szereplő hatókör csak az alkalmazásokra korlátozódik, nem pedig a teljes erőforráscsoportra.

   az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-auth
   

2. A használt GitHub Action-munkafolyamat részeként meg kell adnia a szolgáltatásnév hitelesítő adatait az Azure/login művelethez. Ezek az értékek közvetlenül a munkafolyamatban is megadhatóak, vagy a GitHub titkos kulcsaiban tárolhatók, és a munkafolyamatban hivatkozhatnak gombra. Az értékek GitHub-titkos kulcsként való mentése a biztonságosabb megoldás.

   1. Nyissa meg a GitHub-adattárat, és lépjen a Beállítások>biztonsági>titkos kulcsok és változók>műveletek lapra

   2. Válassza az Új tárház titkos kód lehetőséget, és hozzon létre egy titkos kulcsot az alábbi értékek mindegyikéhez. Az értékek a korábban másolt json-kimenetben találhatók.

      Név szerint	Érték
      AZURE_APP_ID	<application/client-id>
      AZURE_PASSWORD	<client-secret>
      AZURE_TENANT_ID	<tenant-id>
      AZURE_SUBSCRIPTION_ID	<subscription-id>

A GitHub Actions munkafolyamatának létrehozása

Most, hogy már rendelkezik egy szolgáltatásnévvel, amely hozzáfér az App Service-alkalmazásokhoz, szerkessze az alkalmazásokhoz a folyamatos üzembe helyezés konfigurálásakor létrehozott alapértelmezett munkafolyamatokat. A hitelesítést a szolgáltatásnévvel kell elvégezni a közzétételi profil helyett. A minta-munkafolyamatokért tekintse meg a "Szolgáltatásnév" lapot a Munkafolyamat-fájl hozzáadása a GitHub-adattárhoz című témakörben. A következő minta-munkafolyamat használható a megadott Node.js mintaalkalmazáshoz.

1. Nyissa meg az alkalmazás GitHub-adattárát, és nyissa meg a <repo-name>/.github/workflows/ könyvtárat. Látnia kell az automatikusan létrehozott munkafolyamatokat.

2. Minden munkafolyamat-fájlhoz kattintson a jobb felső sarokban található "ceruza" gombra a fájl szerkesztéséhez. Cserélje le a tartalmat a következő szövegre, amely feltételezi, hogy korábban létrehozta a GitHub titkos kulcsait a hitelesítő adatokhoz. Frissítse a helyőrzőt <web-app-name> az "env" szakaszban, majd véglegesítse közvetlenül a fő ágra. Ez a véglegesítés aktiválja a GitHub-műveletet, hogy újra fusson, és telepítse a kódot, ezúttal a szolgáltatásnév használatával a hitelesítéshez.

   
   name: Build and deploy Node.js app to Azure Web App
   
   on:
     push:
       branches:
         - main
     workflow_dispatch:
   
   env:
     AZURE_WEBAPP_NAME: <web-app-name>   # set this to your application's name
     NODE_VERSION: '18.x'                # set this to the node version to use
     AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
     AZURE_WEBAPP_SLOT_NAME: stage       # set this to your application's slot name
   
   jobs:
     build:
       runs-on: ubuntu-latest
   
       steps:
         - uses: actions/checkout@v2
   
         - name: Set up Node.js version
           uses: actions/setup-node@v1
           with:
             node-version: ${{ env.NODE_VERSION }}
   
         - name: npm install, build
           run: |
             npm install
             npm run build --if-present
   
         - name: Upload artifact for deployment job
           uses: actions/upload-artifact@v2
           with:
             name: node-app
             path: .
   
     deploy:
       runs-on: ubuntu-latest
       needs: build
       environment:
         name: 'stage'
         url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
   
       steps:
         - name: Download artifact from build job
           uses: actions/download-artifact@v2
           with:
             name: node-app
   
         - uses: azure/login@v1
           with:
             creds: |
               {
                 "clientId": "${{ secrets.AZURE_APP_ID }}",
                 "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
                 "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
                 "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
               }
   
         - name: 'Deploy to Azure Web App'
           id: deploy-to-webapp
           uses: azure/webapps-deploy@v2
           with:
             app-name: ${{ env.AZURE_WEBAPP_NAME }}
             slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
             package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
   
         - name: logout
           run: |
             az logout
   

Hogyan teszi lehetővé a pontforgalom-útválasztás az alkalmazásaimon végzett frissítések tesztelését?

A tárolóhelyekkel rendelkező forgalomirányítás lehetővé teszi, hogy a felhasználói forgalom egy előre meghatározott részét irányítsa az egyes pontokra. Kezdetben a forgalom 100%-a az éles helyre lesz irányítva. Lehetősége van azonban például arra, hogy a forgalom 10%-át az előkészítési pontra küldje. Ha így konfigurálja a pontforgalom útválasztását, amikor a felhasználók megpróbálják elérni az alkalmazást, a rendszer automatikusan átirányítja 10%-át az előkészítési pontra, és nem módosítja a Front Door-példányt. A pontcserékről és az előkészítési környezetekről az App Service-ben további információt a Azure-alkalmazás Service átmeneti környezeteinek beállítása című témakörben talál.

Hogyan áthelyezni a kódot az előkészítési pontról az éles pontomra?

Miután végzett az előkészítési pontok tesztelésével és ellenőrzésével, elvégezhet egy pontcserét az előkészítési pontról az éles helyre. Ezt a felcserélést minden régióban az alkalmazás összes példánya esetében el kell végeznie. A pontcserék során az App Service platform biztosítja, hogy a célhely ne tapasztaljon állásidőt.

A felcserélés végrehajtásához futtassa az alábbi parancsot minden alkalmazáshoz. Cserélje le a helyőrzőt a következőre <web-app-name>: .

az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production

Néhány perc elteltével navigálhat a Front Door végpontjára, hogy ellenőrizze a pontcserét.

Ezen a ponton az alkalmazások futnak és futnak, és az alkalmazás forráskódján végrehajtott módosítások automatikusan aktiválják a frissítést mindkét átmeneti tárolóhelyre. Ezután megismételheti a pontcserélési folyamatot, amikor készen áll a kód éles környezetbe való áthelyezésére.

Hogyan használhatom még az Azure Front Doort a többrégiós üzemelő példányaimban?

Ha aggódik a régiók közötti lehetséges fennakadások vagy a folytonossággal kapcsolatos problémák miatt, mivel egyes ügyfelek az alkalmazás egyik verzióját látják, míg mások egy másik verziót látnak, vagy ha jelentős módosításokat végez az alkalmazásokon, ideiglenesen eltávolíthatja a pontcserén átesett webhelyet a Front Door forráscsoportjából. Ezután az összes forgalom a másik forráshoz lesz irányítva. Lépjen a Forráscsoport frissítése panelre, és törölje a módosítás alatt álló forrást. Miután végrehajtotta az összes módosítást, és készen áll arra, hogy újra kiszolgálja a forgalmat, visszatérhet ugyanahhoz a panelhez, és a + Forrás hozzáadása lehetőséget választva felolvashatja a forrást.

Ha nem szeretné törölni, majd beolvasni a forrásokat, létrehozhat további forráscsoportokat a Front Door-példányhoz. Ezután társíthatja az útvonalat a forráscsoporthoz, amely a kívánt forrásra mutat. Létrehozhat például két új forráscsoportot, egyet az elsődleges régióhoz, egyet pedig a másodlagos régióhoz. Amikor az elsődleges régió módosul, társítsa az útvonalat a másodlagos régióhoz, és fordítva, amikor a másodlagos régió változáson megy keresztül. Ha minden módosítás befejeződött, társíthatja az útvonalat az eredeti forráscsoporthoz, amely mindkét régiót tartalmazza. Ez a módszer azért működik, mert egy útvonal egyszerre csak egy forráscsoporthoz társítható.

A több forrással végzett munka bemutatásához az alábbi képernyőképen három forráscsoport található. A "MyOriginGroup" mindkét webalkalmazásból áll, a másik két forráscsoport pedig a saját régiójában lévő webalkalmazásból áll. A példában az elsődleges régióban lévő alkalmazás módosul. A módosítás megkezdése előtt az útvonal a "MySecondaryRegion"-hoz lett társítva, így a rendszer a módosítási időszak alatt az összes forgalmat a másodlagos régióban lévő alkalmazásba küldi. Az útvonal frissítéséhez válassza a Társítás nélküli lehetőséget, amely megjeleníti az Útvonalak társítása panelt.

Hogyan korlátozza a speciális eszközök webhelyhez való hozzáférést?

A Azure-alkalmazás szolgáltatással az SCM/speciális eszközök webhelye az alkalmazások kezelésére és az alkalmazás forráskódjának üzembe helyezésére szolgál. Fontolja meg az SCM/advanced tools webhely zárolását, mivel ezt a webhelyet valószínűleg nem kell elérni a Front Dooron keresztül. Beállíthat például olyan hozzáférési korlátozásokat, amelyek csak a tesztelés elvégzését teszik lehetővé, és lehetővé teszik a folyamatos üzembe helyezést a választott eszközről. Ha üzembehelyezési pontokat használ, kifejezetten éles tárolóhelyekhez, szinte minden hozzáférést megtagadhat az SCM-webhelyhez, mivel a tesztelés és az ellenőrzés az előkészítési pontokon történik.

Következő lépések