Lageretablering

Azure Developer CLI (azd) har stöd för lageretablering, som du kan använda för att definiera flera etableringslager i azure.yaml filen. Varje lager pekar på en egen uppsättning IaC-mallar (Infrastruktur som kod). CLI:t provisionerar lager ett i taget i den ordning som beroendena mellan dem anger. Du kan också etablera eller ta bort enskilda lager oberoende.

Den här funktionen löser komplexa beroendescenarier där resurser i ett lager är beroende av resurser från ett annat lager. I stället för att blanda IaC med imperativa hook-skript håller lagerbaserad etablering allt deklarativt.

Anmärkning

Layered-etablering är för närvarande en betafunktion. Läs mer om versionsstrategin.

När du ska använda skiktad provisioning

Använd lagerbaserad provisionering när en enskild azd provision distribution inte kan hantera alla era infrastrukturbehov i ett steg. Överväg att använda skiktad resurstilldelning när:

Cirkulära beroenden: Vissa resurser måste referera till andra resurser som måste skapas först, till exempel ett virtuellt nätverk som måste finnas innan en privat slutpunkt kan konfigureras.
Grundläggande infrastruktur skiljer sig från programinfrastruktur: Du hanterar delade nätverks-, säkerhets- eller identitetsresurser separat från resurser per program.
Oberoende livscykelhantering krävs: Du uppdaterar och river olika infrastrukturkomponenter vid olika tidpunkter. Ett nätverkslager kan till exempel vara långvarigt, medan ett programlager distribueras om ofta.
Monorepoprojekt med distinkta infrastrukturgrupper: En enskild lagringsplats innehåller flera oberoende tjänster (till exempel en händelsehubb, en containerapp och en funktionsapp), var och en med sina egna infrastrukturmallar.

Konfigurera lager i azure.yaml

Definiera lager under avsnittet infra i azure.yaml filen. Varje lager kräver en name och en path som pekar på katalogen som innehåller IaC-mallarna för det lagret.

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

Viktigt!

Lagerbearbetningsordning:azd provision bearbetar lager baserat på deras beroenden. För Bicep-lager och anpassade leverantörer eller tilläggsprovidrar identifierar azd beroenden genom att skanna parameterfiler (*.bicepparam och *.parameters.json) efter referenser till miljövariabler och lagerutdata, och ordnar lagren därefter i stället för att strikt följa ordningen som anges i azure.yaml. Lager som inte har några härledda eller deklarerade beroenden körs i den ordning de visas. azd down följer motsvarande omvända ordning, så beroende lager tas bort innan de lager de är beroende av. Använd egenskapen dependsOn för att deklarera ordning som azd inte kan härledas.

Lageregenskaper

Varje lager har stöd för följande egenskaper:

Fastighet	Krävs	Description
`name`	Ja	Ett unikt namn för lagret. Använd det här namnet när du riktar in dig på ett visst lager med kommandon.
`path`	Ja	Den relativa sökvägen till katalogen som innehåller IaC-mallarna för det här lagret.
`module`	Nej.	Namnet på modulen i lagrets katalog. Standardinställningen är `main`.
`provider`	Nej.	IaC-providern för det här lagret (`bicep` eller `terraform`). Ärver från roten `infra.provider` om du inte anger den.
`dependsOn`	Nej.	Namnen på andra lager som det här lagret är beroende av. Använd den här egenskapen när ordningen är viktig men `azd` inte kan härleda beroendet från parameterreferenser.

Viktigt!

När du definierar infra.layerskan du inte deklarera andra egenskaper i infra avsnittet (path, module, deploymentStacks) på rotnivå. Du måste ange all infrastrukturkonfiguration inom varje lager.

Katalogstruktur

Ett typiskt projekt med lageretablering kan ha följande katalogstruktur:

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

Varje lagerkatalog innehåller en egen komplett uppsättning IaC-mallar, precis som en standardprojektkatalog azdinfra skulle göra.

Etablera och hantera lager

Du kan etablera alla lager samtidigt eller rikta in dig på ett visst lager efter namn. I följande avsnitt beskrivs vanliga kommandon för provisionering, borttagning och uppdatering av lagertillstånd.

Provisionera alla lager

Kör azd provision utan argument för att etablera alla lager:

azd provision

azd bearbetar varje lager ett i taget, vilket säkerställer att ett lager slutförs innan ett lager som är beroende av det börjar. För Bicep-lager och anpassade provider eller tilläggsprovider härleder azd beroenden från miljövariabler och referenser till lagerutdata i filerna *.bicepparam och *.parameters.json, så körningsordningen kan skilja sig från den ordning som anges i azure.yaml. Lager utan härledda eller deklarerade beroenden körs i den angivna ordningen. Den här processen garanterar att beroende resurser finns innan lager som refererar till dem distribueras.

Etablera ett specifikt lager

Om du bara vill etablera ett visst lager skickar du lagernamnet som ett argument:

azd provision networking

Det här kommandot distribuerar endast de resurser som definierats i networking lagret. Det är användbart att etablera ett visst lager när:

Du itererar på ett enda lager under utvecklingen.
Du måste uppdatera ett lager utan att distribuera om andra.
Du konfigurerar ett nytt lager ovanpå befintlig infrastruktur.

Ta bort alla lager

Kör azd down utan argument för att ta bort resurser från alla lager. När det finns azd flera lager bearbetar azd dem i omvänd ordning, så att beroende resurser tas bort innan de grundläggande resurser som de är beroende av:

azd down

Ta ned ett visst lager

Om du bara vill ta bort ett visst lager skickar du lagernamnet som ett argument:

azd down application

Det här kommandot tar bara bort de resurser som distribueras av application lagret och lämnar de andra lagren intakta.

Uppdatera miljötillstånd

Du kan uppdatera miljöns tillstånd från en specifik nivå genom att använda --layer flaggan med azd env refresh:

azd env refresh --layer networking

Det här kommandot uppdaterar miljövariabler och utdata baserat på den senaste distributionen av det angivna lagret.

Exempel: Monorepo med flera tjänster

I följande exempel visas lageretablering för ett monorepo som innehåller en händelsehub, en containerapp som kör flera containrar, och en Azure-funktionsapp.

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}

Motsvarande katalogstruktur:

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

Med den här konfigurationen kan du:

Etablera endast Event Hub-infrastrukturen: azd provision eventhub
Etablera endast containerappens infrastruktur: azd provision aca
Konfigurera allt i ordning: azd provision
Ta bara ned funktionsapplagret: azd down functionapp

Exempel: Bas- och programlager

Ett vanligt mönster separerar delad eller grundläggande infrastruktur från infrastruktur per program:

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

Lagret base skapar delade resurser som nätverk, identitet och övervakning. Lagret app skapar de programspecifika resurserna (till exempel en Container App-miljö och containerappar) som refererar till basresurserna.

Under utvecklingen kan du etablera basskiktet en gång och iterera på programskiktet:

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

Exempel: Blandade IaC-leverantörer

Varje lager kan använda en annan IaC-provider. Du kan till exempel använda Bicep för nätverk och Terraform för programskiktet:

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

De inbyggda providererna som inte är Bicep-providerer (Terraform, Pulumi, ARM och testprovidern) är inte transparenta för beroendehärledning, eftersom azd inte kan analysera deras indata efter referenser till andra skikt. Använd en uttrycklig dependsOn-egenskap när ordningen mellan dessa lager, eller mellan dessa lager och andra lager, är viktig:

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

Överväganden och begränsningar

När du etablerar alla lager azd bearbetar du dem en i taget baserat på deras beroenden. För Bicep-lager och anpassade leverantörer eller tilläggsleverantörer, azd härleder beroenden från referenser till miljövariabler och lagerutdata i *.bicepparam- och *.parameters.json-filer. Lager utan härledda eller deklarerade beroenden körs i den ordning du definierar.
De inbyggda icke-Bicep providrar (Terraform, Pulumi, ARM och testprovidern) är ogenomskinliga för beroendeinferens. Använd egenskapen dependsOn uttryckligen när ordningen mellan dessa lager är viktig.
Explicit dependsOn krävs också när ordningen är viktig men azd inte kan härleda beroendet från parameterreferenser. Använd dependsOn till exempel när ett lagers postprovision krok genererar ett värde som ett annat lager förbrukar, eftersom hook-producerade värden inte visas som utdatareferenser i *.bicepparam eller *.parameters.json filer.
När du river alla lager bearbetar azd dem i omvänd etableringsordning.
- Om flera lager distribuerar resurser till samma Azure-resursgrupp och du använder standardbeteendet för resursgruppbaserad borttagning kan delade resurser tas bort när du kör azd down.
- För att möjliggöra oberoende spårning och borttagning av skiktad infrastruktur aktiverar du driftsättningsstackar genom att köra kommandot azd config set alpha.deployment.stacks on.
Du kan inte använda --preview flaggan när du etablerar flera lager samtidigt. Ange ett <layer> namn som ska användas i förhandsgranskningsläge.
Lager fungerar oberoende av varandra när det gäller IaC. Om du vill referera till utdata från ett lager i ett annat lager använder du miljövariabler som azd ställs in efter varje lagers distribution. Genom att referera till dessa miljövariabler från en *.bicepparam- eller *.parameters.json-fil kan azd också avgöra ordningen mellan lagren.
Alla standardetableringsfunktioner azd (cachelagring av distributionstillstånd, krokar, parametrar, Bicep eller Terraform) fungerar inom varje enskilt lager.
- Kommandonivåkrokar (till exempel preprovision, postprovision) anropas en gång per lager. När flera lager definieras, körs krokar för varje lager i den ordning som lagren bearbetas.

Nästa steg

schemareferens för azure.yaml

Feedback

Var den här sidan till hjälp?

Uppdaterades senast 2026-08-15