Rétegzett ellátás

Az Azure Developer CLI (azd) támogatja a rétegzett kiépítést, amellyel több kiépítési réteget definiálhat a azure.yaml fájlban. Minden egyes réteg a saját Infrastruktúra mint Kód (IaC) sablonkészletére mutat. A parancssori felület egyesével helyezi el a rétegeket, a közöttük lévő függőségek szerint rendezve. Önállóan is kiépítheti vagy lebonthatja az egyes rétegeket.

Ez a funkció olyan összetett függőségi forgatókönyveket old meg, amelyekben az egyik réteg erőforrásai egy másik réteg erőforrásaitól függenek. Ahelyett, hogy az IaC-t imperatív horogszkriptekkel kevernék, a rétegzett kiépítés mindent deklaratívvá teszi.

Megjegyzés:

A rétegzett kiépítés jelenleg bétaverziós funkció. További információ a verziószámozási stratégiáról.

Mikor érdemes rétegzett kiépítést használni?

Rétegzett kiépítést akkor használjon, ha egyetlen azd provision üzembe helyezés egyetlen lépésben nem tudja kezelni az összes infrastruktúraigényt. Fontolja meg a rétegzett kiépítés használatát a következő esetekben:

• Körkörös függőségek: Egyes erőforrásoknak más olyan erőforrásokra kell hivatkoznia, amelyeket először létre kell hozni, például egy virtuális hálózatot, amelynek léteznie kell egy privát végpont konfigurálása előtt.
• Az alapszintű infrastruktúra eltér az alkalmazásinfrastruktúrától: a megosztott hálózati, biztonsági vagy identitás-erőforrásokat az alkalmazásonkénti erőforrásoktól elkülönítve kezeli.
• Független életciklus-kezelésre van szükség: Különböző infrastruktúra-összetevőket frissíthet és bonthat le különböző időpontokban. Előfordulhat például, hogy egy hálózati réteg hosszú élettartamú, míg az alkalmazásréteget gyakran újra üzembe helyezik.
• Különálló infrastruktúracsoportokkal rendelkező monorepo-projektek: Egyetlen adattár több független szolgáltatást (például eseményközpontot, tárolóalkalmazást és függvényalkalmazást) tartalmaz, amelyek mindegyike saját infrastruktúrasablonokkal rendelkezik.

Rétegek konfigurálása az azure.yaml-ben

Definiálja a infra szakaszban lévő azure.yaml fájl rétegeket. Minden réteghez szükség van egy name és egy path olyan könyvtárra, amely az adott réteg IaC-sablonjait tartalmazza.

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
    - name: application
      path: ./infra/application
services:
  api:
    project: ./src/api
    language: js
    host: containerapp

Fontos

Rétegfeldolgozási sorrend:azd provision függőségeik alapján dolgozza fel a rétegeket. A Bicep rétegek és egyéni vagy bővítményszolgáltatók azd esetében függőségeket következtethet a környezeti változók és a rétegkimeneti hivatkozások paraméterfájljainak (*.bicepparam és *.parameters.json) vizsgálatával, és ennek megfelelően rendeli meg a rétegeket ahelyett, hogy szigorúan követi a listában felsorolt sorrendetazure.yaml. Azok a rétegek, amelyek nem rendelkeznek kikövetkezett vagy deklarált függőségekkel, a felsorolt sorrendben futnak. azd down a megfelelő fordított sorrendet követi, így a függő rétegek el lesznek távolítva a függő rétegek előtt, amelyektől függenek. Az dependsOn tulajdonság használatával megadhatja azt a sorrendet, amelyre a azd nem tud következtetni.

Rétegtulajdonságok

Minden réteg a következő tulajdonságokat támogatja:

Ingatlan	Kötelező	Description
name	Igen	A réteg egyedi neve. Ezt a nevet akkor használja, ha egy adott réteget céloz meg parancsokkal.
path	Igen	A réteg IaC-sablonjait tartalmazó könyvtár relatív elérési útja.
module	Nem	A modul neve a réteg könyvtárában. Alapértelmezett érték: main.
provider	Nem	A réteg IaC-szolgáltatója (bicep vagy terraform). A gyökértől infra.provider örökli, ha nem adja meg.
dependsOn	Nem	Azoknak a rétegeknek a neve, amelyektől ez a réteg függ. Ezt a tulajdonságot akkor használja, ha fontos a sorrend, de azd nem tudja a paraméterhivatkozásokból származó függőséget következtetni.

Fontos

Amikor definiálja a infra.layers, nem deklarálhat más tulajdonságokat a infra szakasz (path, module, deploymentStacks) gyökérszintjén. Minden rétegen belül meg kell adnia az összes infrastruktúra-konfigurációt.

Címtárstruktúra

Egy rétegzett kiépítést használó tipikus projekt a következő könyvtárstruktúrával rendelkezhet:

my-app/
├── azure.yaml
├── infra/
│   ├── networking/
│   │   └── main.bicep
│   └── application/
│       └── main.bicep
└── src/
    └── api/
        └── ...

Minden rétegkönyvtár saját teljes IaC-sablonkészletet tartalmaz, ahogyan egy standard azd projekt könyvtára infra tenné.

Rétegek kiépítése és kezelése

Az összes réteget kiépítheti egyszerre, vagy név szerint megcélzhat egy adott réteget. Az alábbi szakaszok a rétegállapot kiépítésére, lebontására és frissítésére vonatkozó gyakori parancsokat ismertetik.

Az összes réteg kiépítése

Az összes réteg kiépítésére futtassa a azd provision parancsot argumentumok nélkül:

azd provision

azd egyenként dolgozza fel az egyes rétegeket, biztosítva, hogy egy réteg befejeződjön, mielőtt az attól függő rétegek elkezdődnek. A Bicep-rétegek, valamint az egyéni vagy bővítményszolgáltatók esetében a azd a *.bicepparam és *.parameters.json fájlokban található, a környezeti változókra és a rétegek kimeneteire mutató hivatkozások alapján következteti ki a függőségeket, ezért a végrehajtási sorrend eltérhet a azure.yaml fájlban felsorolt sorrendtől. A kikövetkezett vagy deklarált függőségeket nem tartalmazó rétegek a felsorolt sorrendben futnak. Ez a folyamat garantálja, hogy a függő erőforrások még az rájuk hivatkozó rétegek üzembe helyezése előtt léteznek.

Adott réteg kiépítése

Ha csak egy adott réteget szeretne kiépíteni, adja meg a réteg nevét argumentumként:

azd provision networking

Ez a parancs csak a rétegben networking definiált erőforrásokat helyezi üzembe. Egy adott réteg kiépítése akkor hasznos, ha:

• A fejlesztés során egyetlen rétegen kell iterálnia.
• Frissítenie kell egy réteget anélkül, hogy újra üzembe kellene helyeznie másokat.
• Új réteget állít be a meglévő infrastruktúra fölé.

Az összes réteg bontása

Futtassa azd down argumentumok nélkül az összes rétegben lévő erőforrások lebontásához. Ha több réteg létezik, azd azokat a kiépítési sorrend fordítottja szerint dolgozza fel, így a függő erőforrások el lesznek távolítva az alaperőforrások előtt, amelyektől függenek:

azd down

Adott réteg lebontása

Ha csak egy adott réteget szeretne lebontani, adja át a réteg nevét argumentumként:

azd down application

Ez a parancs csak a réteg által application telepített erőforrásokat távolítja el, a többi réteget érintetlenül hagyva.

Környezeti állapot frissítése

A környezeti állapotot egy adott rétegből frissítheti a --layer következő jelölővel azd env refresh:

azd env refresh --layer networking

Ez a parancs frissíti a környezeti változókat és kimeneteket a megadott réteg legutóbbi üzembe helyezése alapján.

Példa: Monorepo több szolgáltatással

Az alábbi példa egy eseményközpontot, egy több tárolót futtató tárolóalkalmazást és egy Azure-függvényalkalmazást tartalmazó monorepó rétegzett kiépítését mutatja be:

name: logging-app
infra:
  layers:
    - name: eventhub
      path: ./infra/eventhub
    - name: aca
      path: ./infra/aca
    - name: functionapp
      path: ./infra/functionapp
services:
  functionapp:
    resourceName: ${site_name}
    language: dotnet
    project: ./src/function/functionapp.csproj
    host: appservice
    resourceGroup: ${rg_name}

A megfelelő könyvtárstruktúra:

logging-app/
├── azure.yaml
├── infra/
│   ├── eventhub/
│   │   └── main.bicep
│   ├── aca/
│   │   └── main.bicep
│   └── functionapp/
│       └── main.bicep
└── src/
    └── function/
        └── functionapp.csproj

Ezzel a konfigurációval a következő beállításokat végezheti el:

1. Csak az Event Hub-infrastruktúra kiépítése: azd provision eventhub
2. Csak a Container App-infrastruktúra kiépítése: azd provision aca
3. Mindent sorrendben üzembe helyezni: azd provision
4. Csak a függvényalkalmazás rétegének lebontása: azd down functionapp

Példa: Alap- és alkalmazásrétegek

A közös minta elválasztja a megosztott vagy az alapszintű infrastruktúrát az alkalmazásonkénti infrastruktúrától:

name: my-app
infra:
  layers:
    - name: base
      path: ./infra/base
    - name: app
      path: ./infra/app
services:
  web:
    project: ./src/web
    language: js
    host: containerapp

A base réteg megosztott erőforrásokat hoz létre, például hálózatkezelést, identitást és monitorozást. A app réteg létrehozza az alkalmazásspecifikus erőforrásokat (például tárolóalkalmazás-környezetet és tárolóalkalmazásokat), amelyek hivatkoznak az alaperőforrásokra.

A fejlesztés során kiépítheti egyszer az alapréteget, és iterálhat az alkalmazásrétegen:

azd provision base
azd provision app
azd provision app  # re-provision only the app layer after changes

Példa: Vegyes IaC-szolgáltatók

Minden réteg használhat egy másik IaC-szolgáltatót. Használhatja például a Bicep-et a hálózatkezeléshez és a Terraformot az alkalmazásréteghez:

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
      provider: bicep
    - name: application
      path: ./infra/application
      provider: terraform

A beépített, nem Bicep-szolgáltatók (Terraform, Pulumi, ARM és a tesztszolgáltató) nem átláthatók a függőségkövetkeztetés számára, mert azd nem tudja elemezni a bemeneteiket, hogy talál-e bennük más rétegekre mutató hivatkozásokat. Használjon explicit dependsOn tulajdonságot, amikor e rétegek közötti, illetve e rétegek és más rétegek közötti sorrend számít:

name: my-app
infra:
  layers:
    - name: networking
      path: ./infra/networking
      provider: bicep
    - name: application
      path: ./infra/application
      provider: terraform
      dependsOn:
        - networking

Megfontolások és korlátok

• Az összes réteg azd kiépítésekor a függőségeik alapján egyenként dolgozza fel őket. A Bicep-rétegek és az egyéni vagy bővítményszolgáltatók esetében a azd a környezeti változókra és a rétegkimenetekre mutató hivatkozásokból következteti ki a függőségeket a *.parameters.json és *.bicepparam fájlokban. A kikövetkezett vagy deklarált függőségek nélküli rétegek a megadott sorrendben futnak.
• A beépített, nem Bicep-alapú szolgáltatók (Terraform, Pulumi, ARM és a tesztszolgáltató) nem átláthatók a függőségek kikövetkeztetése szempontjából. Használjon explicit dependsOn tulajdonságot, ha fontos az ezen rétegeket érintő sorrend.
• Az explicit dependsOn használata akkor is szükséges, amikor a sorrend számít, de a azd nem tudja kikövetkeztetni a függőséget a paraméterhivatkozásokból. Használja például a dependsOn elemet, amikor az egyik réteg postprovision hookja olyan értéket állít elő, amelyet egy másik réteg használ, mert a hook által előállított értékek nem jelennek meg kimeneti hivatkozásként a *.parameters.json vagy *.bicepparam fájlokban.
• Ha az összes réteget lebontja, azd azokat a kiépítési sorrend fordítottja szerint dolgozza fel.
  • Ha több réteg helyez üzembe erőforrásokat ugyanabban az Azure-erőforráscsoportban, és az alapértelmezett erőforráscsoport-alapú törlési viselkedést használja, előfordulhat, hogy a megosztott erőforrások törlődnek az azd lefutásakor.
  • A rétegzett infrastruktúra önálló nyomon követésének és törlésének lehetővé tételéhez engedélyezze a telepítési vermeket a(z) azd config set alpha.deployment.stacks on parancs futtatásával.
• Több réteg egyszerre történő kiépítésekor nem használhatja a --preview jelölőt. Adjon meg egy <layer> nevet az előnézeti mód használatához.
• A rétegek az IaC szempontjából egymástól függetlenül működnek. Ha egy másik réteg egyik rétegének kimenetére szeretne hivatkozni, használjon környezeti változókat, amelyek azd az egyes rétegek üzembe helyezése után állíthatók be. Ha ezekre a környezeti változókra egy *.bicepparam vagy azd fájlból hivatkozik, az lehetővé teszi, hogy a *.parameters.json következtessen a rétegek közötti sorrendre.
• Minden standard azd kiépítési funkció (üzembehelyezési állapot gyorsítótárazása, horgok, paraméterek, Bicep vagy Terraform) az egyes rétegeken belül működik.
  • A parancsszintű horgokat (például preprovision, postprovision) rétegenként egyszer hívjuk meg. Ha több réteg van definiálva, a horgok minden rétegnél a rétegek feldolgozási sorrendjében futnak.

Következő lépések

azure.yaml sémahivatkozás

• Funkciók verziószámozási és kiadási stratégiája
• Környezeti változók kezelése
• Munkafolyamatok testreszabása parancs- és eseményhookok használatával