Teljes körű üzembe helyezés az Azure Developer CLI-vel

A modern webfejlesztés gyakori mintája az előtérbeli és a háttérszolgáltatásokat kombináló teljes veremű alkalmazások. Az Azure Developer CLI (azd) támogatja a teljes körű alkalmazások üzembe helyezését, ahol az előtér és a háttér különálló szolgáltatásként van üzemeltetve. Ez a cikk bemutatja, hogyan helyezhet üzembe full-stack alkalmazásokat azd segítségével, és kiemeli a hatékony üzembe helyezés stratégiáit és előnyeit.

Mi az a teljes veremű üzembe helyezés?

A teljes körű üzembe helyezés azd általában a következőkből áll:

  • Előtérbeli szolgáltatás: Felhasználói webalkalmazás, amely gyakran olyan keretrendszerekkel készült, mint a React, az Angular, a Vue vagy a Blazor. Az előtér statikus helyként vagy tárolóalapú alkalmazásként is üzemeltethető.
  • Háttérszolgáltatás: Üzleti logikát, adathozzáférést és integrációt kezelő API vagy szolgáltatásréteg. A háttérrendszert általában tárolókban vagy kiszolgáló nélküli függvényekként üzemeltetik.
  • Megosztott erőforrások: Adatbázisok, tárfiókok, kulcstartók és más Azure-erőforrások, amelyeket mindkét szolgáltatás használhat.

azd használatával mindkét szolgáltatást definiálhatja egyetlen azure.yaml fájlban, és együtt telepítheti őket infrastruktúra mint kód (Bicep vagy Terraform) alkalmazásával.

Az Azure Developer CLI életciklusa

Az Azure Developer CLI egy strukturált munkafolyamatot követ, amely különböző életciklus-eseményekkel rendelkezik:

Az Azure Developer CLI életciklusát bemutató ábra csomag-, kiépítési és üzembe helyezési fázisokkal.

  1. Csomag: Hozza létre az alkalmazás forráskódját, és készítse elő az összetevőket az üzembe helyezéshez.
  2. Kiépítés: Azure-infrastruktúra-erőforrások létrehozása vagy frissítése a Bicep vagy a Terraform használatával.
  3. Üzembe helyezés: A csomagolt alkalmazáskód üzembe helyezése a kiépített infrastruktúrában.

A azd up parancs mindhárom fázist egymás után futtatja. Az egyes fázisokat egymástól függetlenül futtathatja azd package, azd provision, és azd deploy használatával a részletesebb vezérlés érdekében. Ennek az életciklusnak a megértése elengedhetetlen a szolgáltatások közötti függőségek kezeléséhez, különösen olyan teljes körű üzemelő példányokban, ahol az időzítés és a sorrend számít.

Az életciklusról és a azd munkafolyamat testreszabásáról további információt az azd up munkafolyamat megismerése című témakörben talál.

Infrastruktúra-kialakítási szempontok

Teljes körű alkalmazás azdtervezésekor válassza ki a megfelelő Azure-üzemeltetési szolgáltatásokat az előtérben és a háttérrendszerben:

Szolgáltatás típusa Tárhely lehetőségek Felhasználási eset
felhasználói felület Azure Static Web Apps, Azure App Service, Azure Container Apps Statikus webhelyek, SLA-k, kiszolgáló által renderelt alkalmazások
Háttérrendszer Azure Container Apps, Azure App Service, Azure Functions, Azure Kubernetes Service API-k, mikroszolgáltatások, kiszolgáló nélküli függvények

További információ az alkalmazások Azure-ban való üzemeltetéséről.

Értsd meg az előtérbeli és a háttéralkalmazások közötti kölcsönös függőséget

A teljeskörű telepítések gyakran szembesülnek ciklikus függőségi problémákkal, amikor minden szolgáltatásnak információra van szüksége a másikról, mielőtt teljesen konfigurálható lenne. Ezeknek a kölcsönös függőségeknek a megértése segít a hatékony üzembehelyezési munkafolyamatok tervezésében.

Diagram, amely a felhasználói felület és a háttérszolgáltatások közötti körkörös hivatkozást ábrázolja a teljes stack üzembe helyezések során.

Az előtérnek háttér URL-címre van szüksége: Az előtérbeli alkalmazásnak általában ismernie kell a háttér API-végpont URL-címét a buildeléskor vagy a futtatókörnyezetben. A háttérszolgáltatás azonban csak akkor rendelkezik URL-címvel, ha azt üzembe helyezik az Azure-ban.

A háttérrendszernek előtér-URL-címre van szüksége: A háttérszolgáltatásnak szüksége lehet az előtér-URL-címre a CORS-szabályzatok konfigurálásához, de az előtérnek nincs URL-címe, amíg üzembe nem helyezi.

Megosztott erőforrás-függőségek: Mindkét szolgáltatás olyan megosztott erőforrásoktól függhet, mint az adatbázisok, a kulcstartók vagy a tárfiókok. Ezeket az erőforrásokat ki kell kiépíteni, mielőtt bármelyik szolgáltatás konfigurálható lenne a használatukra.

Környezetspecifikus konfiguráció: A különböző környezetek (fejlesztés, előkészítés, éles környezet) eltérő végponti URL-címeket és konfigurációkat igényelnek, de ezek az értékek a kiépítés befejezéséig nem ismertek.

A konfigurációs stratégiák ismertetése

Az Azure Developer CLI két megközelítéssel kezeli ezeket az interdependenciákat:

  • Üzembe helyezési idő konfigurálása: Függőségek feloldása a kiépítés és az üzembe helyezés során
  • Futtatókörnyezet konfigurálása: Halasztja a függőségi konfigurációt az alkalmazás futtatásakor

Ezek a megközelítések az alkalmazás létrehozásakor hozott tervezési döntéseket jelölik. Egyetlen stratégiát használhat kizárólag, vagy kombinálhatja mindkettőt az architektúrától és a követelményektől függően.

Diagram az üzembe helyezési idő és a futásidejű konfigurációs stratégiák összehasonlítására a teljes veremű telepítésekhez.

Üzembe helyezési idő konfigurálása

Az telepítés ideje alatti konfiguráció azt jelenti, hogy a szolgáltatáskapcsolatok és -konfigurációk meghatározása és zárolása a azd provision és azd deploy fázisok során történik. Ezzel a módszerrel konfigurálhatja a szolgáltatásokat adott végponti URL-címekkel, kapcsolati sztringekkel és egyéb függőségi adatokkal, mielőtt azok elindulnának. Ez a konfiguráció az üzembe helyezett szolgáltatás környezetének részévé válik, környezeti változókként vagy az üzembe helyezéssel csomagolt konfigurációs fájlokban.

Infrastruktúra-első kiépítés: Amikor elindítja a azd up vagy azd provision, az infrastruktúra először létrejön. Ez a lépés az üzembe helyezés megkezdése előtt létrehozza a szükséges URL-címeket és kapcsolati sztringeket, biztosítva, hogy a függő szolgáltatások rendelkezzenek a szükséges információkkal.

Kimeneti változók: A Bicep és a Terraform a kiépítés után képes kimeneti értékeket, például URL-címeket és kapcsolati sztringeket megjeleníteni. Ezek a kimenetek környezeti változókként válnak elérhetővé az üzembe helyezési fázis során, így a megfelelő végpontokkal konfigurálhatja a szolgáltatásokat a kezdés előtt.

Szekvenciális üzembe helyezés: Összetett forgatókönyvek esetén előfordulhat, hogy egy adott sorrendben kell üzembe helyeznie a szolgáltatásokat. A azdhorogokkal vezérelheti az üzembe helyezési sorrendet, biztosítva, hogy az előfeltétel-szolgáltatások a függő szolgáltatások üzembe helyezése előtt fussanak.

Konténer upsert minta: Az Azure Verified Modules (AVM) olyan konténeralkalmazás-mintákat biztosít, amelyek zökkenőmentesen működnek a container-app-upsert kétfázisú munkafolyamatával azd. A kiépítés során létrejön az infrastruktúra és a kezdeti tároló. Az üzembe helyezés során azd frissíti a konténerképet azokkal a környezeti változókkal, amelyek a kiépítés során létrehozott, például adatbázis-kapcsolati karakterláncokat vagy szolgáltatás URL-címeket tartalmazó értékeket tartalmaznak. Ez a minta azzal oldja meg a csirke-tojás problémát, hogy először engedélyezi az infrastruktúra meglétét, majd frissíti a tároló konfigurációját az összes szükséges függőségi információval.

Példa folyamat egy React front-endhez konténer API háttérrendszerrel:

  1. Futtatás azd up, amely egymás után hajtja végre a csomag-, kiépítési és üzembe helyezési fázisokat.
  2. A kiépítés során a Bicep AVM-modulokkal container-app-upsert hozza létre az Azure Container Apps-infrastruktúrát, és a háttér API URL-címét adja ki.
  3. Az üzembe helyezés azd során mindkét tároló automatikusan a megfelelő környezeti változókkal bővül, beleértve az előtérbeli API URL-címét is.
  4. Mindkét szolgáltatás a megfelelő konfigurációval kezdődik. A jövőbeli futtatások során a azd up vagy azd deploy frissítik a tárolókat az új konfigurációs értékekkel.

Futtatókörnyezet konfigurálása

A futtatókörnyezet-konfiguráció lehetővé teszi az alkalmazások számára a konfiguráció betöltését, amikor az alkalmazás az üzembe helyezés helyett fut. Ez a megközelítés rugalmasságot biztosít a szolgáltatásvégpontok, kapcsolati sztringek és szabályzatok frissítéséhez az alkalmazás ismételt üzembe helyezése nélkül.

Konfigurációs források: Az alkalmazások két elsődleges forrásból tölthetik be a futtatókörnyezet konfigurációját:

  • Helyi konfigurációs fájlok: Helyezzen üzembe egy konfigurációs fájlt, például config.jsonaz alkalmazás mellett. Az alkalmazás indításkor betölti ezt a fájlt az aktuális végpont URL-címeinek, hitelesítési beállításainak és egyéb konfigurációs értékeinek lekéréséhez. Ez a megközelítés jól működik az olyan ügyféloldali keretrendszerek esetében, mint a React, az Angular, a Vue és a Blazor WebAssembly, amelyek be tudják kérni a konfigurációt, amikor az alkalmazás elindul a böngészőben.

  • Felhőkonfigurációs szolgáltatások: Az Azure App Configuration vagy hasonló szolgáltatások használatával központilag kezelheti a konfigurációt minden környezetben. Az alkalmazások indításkor vagy igény szerint lekérdezik a konfigurációs szolgáltatást az aktuális értékek lekéréséhez. Ez a megközelítés olyan mikroszolgáltatás-architektúrák esetében hasznos, amelyekben több szolgáltatásnak összehangolt konfigurációfrissítésre van szüksége.

Előnyök: Mindkét megközelítéssel a konfigurációs módosítások azonnal elérhetővé válnak újratelepítés nélkül. Frissítse a konfigurációs fájlt az üzembe helyezési folyamaton keresztül, vagy módosítsa az Azure App Configuration értékeit az Azure Portalon keresztül. Amikor az alkalmazás újraindítja vagy frissíti a konfigurációját, felveszi az új értékeket. Ez a minta különösen hasznos a következő esetekben:

  • Előtérbeli alkalmazások, amelyeknek háttér API-URL-címeket, hitelesítési végpontokat és mikroszolgáltatási helyeket kell felderítenie
  • Háttérszolgáltatások, amelyeknek frissíteni kell a CORS-szabályzatokat az előtérbeli URL-címek változásakor
  • Különböző konfigurációt igénylő szolgáltatások a fejlesztési, tesztelési és éles környezetekben.

Példa munkafolyamat egy háttér API-t felfedező React front-endhez:

  1. Indítsa el azd up az infrastruktúra kiépítéséhez és mindkét szolgáltatás telepítéséhez.
  2. Az üzembe helyezés utáni hívás létrehoz egy config.json fájlt, amely tartalmazza a háttérrendszer URL-címét, és feltölti azt az előtér tárolási helyére.
  3. A React alkalmazás indításkor lekéri config.json az API-végpontot.
  4. A végpont későbbi frissítéséhez módosítsa config.json a felület újbóli üzembe helyezése nélkül.

Ez a módszer nem működik a statikusan létrehozott webhelyeken, ahol az összes tartalom előre renderelve van a buildeléskor.

Az üzembehelyezési munkafolyamat megtervezése

Vegye figyelembe ezeket a tényezőket a teljes stackes üzembe helyezés tervezésekor:

  1. Függőségek azonosítása: Annak leképezése, hogy mely szolgáltatásoknak van szükségük más szolgáltatásoktól származó információkra. Egyirányú függőségek esetén (mint például egy adatbázistól függő API), az előállítási platform (Bicep vagy Terraform) automatikusan kezeli a sorrendet. A körkörös függőségek (például az előtérbeli és a háttérszolgáltatások esetében, amelyekhez mindkettőnek szüksége van egymás URL-címére az indításkor) a koordinációt üzembe helyezési vagy futásidejű konfigurációs stratégiák használatával kell megterveznie.
  2. Üzembe helyezés előtti üzembe helyezés: Győződjön meg arról, hogy az összes infrastruktúra létezik az alkalmazáskód üzembe helyezése előtt.
  3. Környezeti változók használata: Konfiguráció átadása az infrastruktúra és az alkalmazásrétegek között az azd környezeti változók használatával.
  4. Több környezet tervezése: Tervezze meg, hogy a konfiguráció hogyan különbözik a fejlesztési, előkészítési és éles környezetekben.
  5. Fontolja meg az üzembe helyezés sorrendjét: Egyes forgatókönyvek esetében szükség lehet a szolgáltatások adott sorrendben történő üzembe helyezésére.

A azd up parancs a legtöbb üzembe helyezési forgatókönyvet úgy kezeli, hogy automatikusan futtatja a kiépítést, majd az üzembe helyezést egyetlen munkafolyamatban. A standard önálló alkalmazások esetében ez a megközelítés jól működik, és minimális konfigurációt igényel.

Bonyolultabb üzembe helyezések, például körkörös függőségekkel rendelkező teljes verem esetén:

  • Szolgáltatásrendelés konfigurálása: A azure.yaml fájlban adja meg a szolgáltatásokat abban a sorrendben, amelyben üzembe szeretné helyezni őket. Bár azd alapértelmezés szerint párhuzamosan helyezi üzembe a szolgáltatásokat, szükség esetén a horogokkal kényszerítheti a szekvenciális üzembe helyezést.

  • Munkafolyamat-lépések testreszabása: Az alapértelmezett azd up munkafolyamat felülbírálása egy egyéni workflows tulajdonság definiálásával a azure.yaml fájlban. Az alkalmazás forráskódjának létrehozása előtt például módosíthatja az alapértelmezett viselkedést a kiépítés futtatására:

    name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
workflows:
  up: 
    steps:
      - azd: provision
      - azd: package
      - azd: deploy

    Ez a minta akkor hasznos, ha a buildelési folyamatnak olyan konfigurációs értékekre van szüksége, amelyek csak a kiépítés befejezése után érhetők el.

  • Külön előkészítés és üzembe helyezés: Ahelyett, hogy a azd up-t használná, futtassa a azd provision és a azd deploy parancsokat külön. Ez az elkülönítés akkor hasznos, ha ellenőriznie kell az infrastruktúra konfigurációját az alkalmazáskód üzembe helyezése előtt, vagy az üzembehelyezési problémák elhárítása során. Az infrastruktúrát egyszer kiépítheti, majd újraépítés nélkül többször üzembe helyezheti és újra üzembe helyezheti az alkalmazáskódot.

  • Testreszabás horgokkal: A kiépítési és üzembe helyezési fázisok közötti egyéni logika végrehajtásához adjon hozzá elő- és posthorgokat a azure.yaml fájlban. A horogokkal feltöltheti a konfigurációs fájlokat, ellenőrizheti a környezet állapotát, vagy koordinálhatja az összetett üzembehelyezési folyamatokat.

Ajánlott eljárások

Ha teljes körű alkalmazásokat azdkészít, kövesse az alábbi ajánlott eljárásokat:

  1. Függőségek korai leképezése: Annak meghatározása, hogy mely szolgáltatásoknak van szükségük más szolgáltatásoktól származó információkra a tervezési fázis során. Különbséget kell tenni az egyirányú függőségek között, amelyeket a Bicep vagy a Terraform automatikusan kezel, valamint azokat a körkörös függőségeket, amelyek üzembe helyezési idejű vagy futtatókörnyezeti konfigurációs stratégiákat igényelnek.
  2. Válassza ki a megfelelő konfigurációs stratégiát: Üzembe helyezési idejű konfiguráció használata, ha a szolgáltatásoknak az üzembe helyezéskor zárolt konfigurációra van szükségük. Használja a futtatókörnyezet konfigurációját, ha rugalmasságra van szüksége a konfiguráció ismételt üzembe helyezés nélküli frissítéséhez. Szükség esetén kombinálja mindkét stratégiát.
  3. Azure Verified Modules (AVM) használata: Használja az Azure Verified Modules Bicep-modulokat, például container-app-upsert a tárolóalkalmazásokhoz. Ezek a minták zökkenőmentesen működnek a kétfázisú munkafolyamattal azda körkörös függőségek megoldása érdekében.
  4. Szükség esetén testre szabhatja a munkafolyamatokat: Egyszerű üzembe helyezéshez használja azd up az alapértelmezett beállításokat. Körkörös függőségekkel rendelkező összetett forgatókönyvek esetén testre szabhatja a workflows fájl tulajdonságát azure.yaml a csomag, a kiépítés és az üzembe helyezés lépéseinek sorrendjének szabályozásához.
  5. A futtatókörnyezet konfigurációjának kihasználása: A környezetek közötti maximális rugalmasság érdekében használja az Azure App Configuration-t vagy a helyi konfigurációs fájlokat a szolgáltatásvégpontok és a beállítások kezeléséhez, amelyeket újra üzembe helyezés nélkül frissíthet.
  6. Tesztelés különböző környezetekben: Győződjön meg arról, hogy a konfigurációs stratégia megfelelően működik a fejlesztési, előkészítési és éles környezetekben, ahol a szolgáltatás URL-címei és konfigurációi eltérnek.

Következő lépések

  • Utolsó frissítés időpontja: