Gelaagde voorziening

Azure Developer CLI (azd) ondersteunt gelaagde inrichting, die u kunt gebruiken om meerdere inrichtingslagen in uw azure.yaml bestand te definiëren. Elke laag verwijst naar een eigen set IaC-sjablonen (Infrastructure as Code). De CLI richt lagen één voor één in, gerangschikt op de afhankelijkheden ertussen. U kunt afzonderlijke lagen ook afzonderlijk inrichten of afbreken.

Deze functie lost complexe afhankelijkheidsscenario's op waarbij resources in de ene laag afhankelijk zijn van resources uit een andere laag. In plaats van IaC te combineren met imperatieve hookscripts, houdt gelaagde provisioning alles declaratief.

Opmerking

Gelaagde provisioning is momenteel een functie in bèta. Meer informatie over de versiebeheerstrategie.

Wanneer u gelaagde voorziening moet gebruiken

Gebruik gelaagde inrichting wanneer één azd provision implementatie niet in één stap kan omgaan met al uw infrastructuurbehoeften. Overweeg het gebruik van lagen-provisioning wanneer:

  • Kringafhankelijkheden: Sommige resources moeten verwijzen naar andere resources die eerst moeten worden gemaakt, zoals een virtueel netwerk dat moet bestaan voordat een privé-eindpunt kan worden geconfigureerd.
  • De basisinfrastructuur verschilt van de toepassingsinfrastructuur: u beheert gedeelde netwerken, beveiliging of identiteitsresources afzonderlijk van resources per toepassing.
  • Onafhankelijk levenscyclusbeheer is nodig: u kunt verschillende infrastructuuronderdelen op verschillende momenten bijwerken en afbreken. Een netwerklaag kan bijvoorbeeld lang duren, terwijl een toepassingslaag vaak opnieuw wordt geïmplementeerd.
  • Monorepo-projecten met afzonderlijke infrastructuurgroepen: één opslagplaats bevat meerdere onafhankelijke services (zoals een Event Hub, een container-app en een functie-app), elk met eigen infrastructuursjablonen.

Lagen configureren in azure.yaml

Definieer lagen onder de infra sectie van het azure.yaml bestand. Elke laag vereist een name en een path verwijzing naar de map die de IaC-sjablonen voor die laag bevat.

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

Belangrijk

Volgorde van laagverwerking:azd provision verwerkt lagen op basis van hun afhankelijkheden. Voor Bicep-lagen en aangepaste of extensieproviders leidt azd afhankelijkheden af door parameterbestanden (*.bicepparam en *.parameters.json) te scannen op verwijzingen naar omgevingsvariabelen en laaguitvoer, en ordent het de lagen dienovereenkomstig in plaats van strikt de volgorde in azure.yaml te volgen. Lagen zonder afgeleide of gedeclareerde afhankelijkheden worden verwerkt in de volgorde waarin ze zijn vermeld. azd down volgt de overeenkomstige omgekeerde volgorde, zodat afhankelijke lagen worden verwijderd voordat de lagen ervan afhankelijk zijn. Gebruik de eigenschap dependsOn om de volgorde op te geven die azd niet kan afleiden.

Laageigenschappen

Elke laag ondersteunt de volgende eigenschappen:

Vastgoed Verplicht Description
name Ja Een unieke naam voor de laag. Gebruik deze naam om een specifieke laag aan te wijzen bij het uitvoeren van opdrachten.
path Ja Het relatieve pad naar de map met de IaC-sjablonen voor deze laag.
module Nee. De naam van de module in de map van de laag. Standaardwaarde is main.
provider Nee. De IaC-provider voor deze laag (bicep of terraform). Neemt over van de root infra.provider indien u deze niet opgeeft.
dependsOn Nee. De namen van andere lagen waarvan deze laag afhankelijk is. Gebruik deze eigenschap bij het ordenen van zaken, maar azd kan de afhankelijkheid van parameterverwijzingen niet afleiden.

Belangrijk

Wanneer u definieert infra.layers, kunt u geen andere eigenschappen declareren voor de infra sectie (path, module, deploymentStacks) op het hoofdniveau. U moet alle infrastructuurconfiguraties binnen elke laag opgeven.

Mappenstructuur

Een typisch project met gelaagde provisioning kan de volgende mapstructuur hebben:

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

Elke laagmap bevat een eigen volledige set IaC-sjablonen, net zoals een standaardprojectmap azdinfra zou bevatten.

Lagen inrichten en beheren

U kunt alle lagen tegelijk inrichten of een specifieke laag op naam richten. In de volgende secties worden algemene opdrachten beschreven voor het inrichten, afbreken en vernieuwen van de laagstatus.

Alle lagen inrichten

Voer azd provision zonder argumenten uit om alle lagen in te richten:

azd provision

azd verwerkt elke laag één voor één, zodat een laag wordt voltooid voordat een laag die ervan afhankelijk is, begint. Voor Bicep-lagen en aangepaste of uitbreidingsproviders leidt azd afhankelijkheden af uit verwijzingen naar omgevingsvariabelen en laaguitvoer in de *.bicepparam- en *.parameters.json-bestanden, zodat de uitvoeringsvolgorde kan verschillen van de volgorde die in azure.yaml staat. Lagen zonder afgeleide of gedeclareerde afhankelijkheden worden in de vermelde volgorde verwerkt. Dit proces garandeert dat afhankelijke bronnen aanwezig zijn voordat verwijzende lagen worden geïmplementeerd.

Een specifieke laag inrichten

Als u alleen een specifieke laag wilt inrichten, geeft u de naam van de laag door als argument:

azd provision networking

Met deze opdracht worden alleen de resources geïmplementeerd die in de networking laag zijn gedefinieerd. Het inrichten van een specifieke laag is handig wanneer:

  • Tijdens de ontwikkeling gaat u herhalen op één laag.
  • U moet één laag bijwerken zonder dat u andere lagen opnieuw hoeft te implementeren.
  • U stelt een nieuwe laag in op de bestaande infrastructuur.

Alle lagen afbreken

Voer azd down zonder argumenten uit om resources uit alle lagen te verwijderen. Wanneer er meerdere lagen zijn, verwerkt azd deze in de omgekeerde volgorde van de provisioningvolgorde, zodat afhankelijke resources worden verwijderd voordat de basisresources waarvan ze afhankelijk zijn:

azd down

Een specifieke laag afbreken

Als u alleen een specifieke laag wilt afbreken, geeft u de naam van de laag door als argument:

azd down application

Met deze opdracht worden alleen de resources verwijderd die door de application laag zijn geïmplementeerd, waardoor de andere lagen intact blijven.

Omgevingsstatus vernieuwen

U kunt de omgevingsstatus van een specifieke laag vernieuwen met behulp van de --layer vlag met azd env refresh:

azd env refresh --layer networking

Met deze opdracht worden de omgevingsvariabelen en uitvoer bijgewerkt op basis van de meest recente implementatie van de opgegeven laag.

Voorbeeld: Monorepo met meerdere services

In het volgende voorbeeld ziet u gelaagde inrichting voor een monorepo die een Event Hub, een container-app met meerdere containers en een Azure Function-app bevat:

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}

De bijbehorende directorystructuur:

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

Met deze configuratie kunt u het volgende doen:

  1. Alleen de Event Hub-infrastructuur inrichten: azd provision eventhub
  2. Alleen de Container App-infrastructuur provisioneren: azd provision aca
  3. Alles in de volgorde inrichten: azd provision
  4. Alleen de Function App-laag afbreken: azd down functionapp

Voorbeeld: Basis- en toepassingslagen

Een algemeen patroon scheidt gedeelde of fundamentele infrastructuur van infrastructuur per toepassing:

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

De base laag maakt gedeelde resources, zoals netwerkvoorzieningen, identiteit en monitoring. De app laag maakt de toepassingsspecifieke resources (zoals een Container App-omgeving en container-apps) die verwijzen naar de basisbronnen.

Tijdens de ontwikkeling kunt u de basislaag één keer inrichten en herhalen op de toepassingslaag:

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

Voorbeeld: Gemengde IaC-providers

Elke laag kan een andere IaC-provider gebruiken. U kunt bijvoorbeeld Bicep gebruiken voor netwerken en Terraform voor de toepassingslaag:

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

De ingebouwde niet-Bicep-providers (Terraform, Pulumi, ARM en de testprovider) zijn ondoorzichtig voor afhankelijkheidsdeductie, omdat azd ze hun invoer niet kunnen analyseren voor verwijzingen naar andere lagen. Gebruik een expliciete dependsOn eigenschap wanneer u deze lagen rangschikt, of tussen die lagen en andere lagen, wat belangrijk is:

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

Overwegingen en beperkingen

  • Wanneer u alle lagen inricht, azd worden ze één voor één verwerkt op basis van hun afhankelijkheden. Voor Bicep-lagen en aangepaste of extensieproviders leidt azd afhankelijkheden af uit verwijzingen naar omgevingsvariabelen en laaguitvoer in *.bicepparam- en *.parameters.json-bestanden. Lagen zonder uitgestelde of gedeclareerde afhankelijkheden worden uitgevoerd in de volgorde die u definieert.
  • De ingebouwde niet-Bicep-providers (Terraform, Pulumi, ARM en de test-provider) zijn niet transparant voor het afleiden van afhankelijkheden. Gebruik een expliciete dependsOn eigenschap bij het ordenen van deze lagen.
  • Expliciet dependsOn is ook vereist wanneer ordenen van belang is, maar azd de afhankelijkheid van parameterverwijzingen niet kan afleiden. Gebruik bijvoorbeeld dependsOn wanneer de haak van postprovision de ene laag een waarde produceert die een andere laag verbruikt, omdat door hook geproduceerde waarden niet worden weergegeven als uitvoerverwijzingen in *.bicepparam of *.parameters.json bestanden.
  • Wanneer u alle lagen afbreekt, verwerkt azd deze in de omgekeerde volgorde waarin ze zijn ingericht.
    • Als meerdere lagen resources implementeren in dezelfde Azure-resourcegroep en u het standaardgedrag voor verwijdering op basis van resourcegroepen gebruikt, kunnen gedeelde resources worden verwijderd wanneer u azd down uitvoert.
    • Als u onafhankelijke tracering en verwijdering van gelaagde infrastructuur wilt toestaan, schakelt u implementatiestacks in door de opdracht azd config set alpha.deployment.stacks onuit te voeren.
  • U kunt de vlag niet gebruiken bij het --preview inrichten van meerdere lagen tegelijk. Geef een <layer> naam op voor het gebruik van de preview-modus.
  • Lagen werken onafhankelijk in termen van IaC. Als u wilt verwijzen naar uitvoer van de ene laag in een andere laag, gebruikt u omgevingsvariabelen die azd na de implementatie van elke laag worden ingesteld. Door in een *.bicepparam- of *.parameters.json-bestand naar deze omgevingsvariabelen te verwijzen, kan azd ook de volgorde van de lagen afleiden.
  • Alle standaardinrichtingsfuncties azd (caching van implementatiestatus, hooks, parameters, Bicep of Terraform) werken binnen elke afzonderlijke laag.
    • Haken op opdrachtniveau (bijvoorbeeld preprovision, postprovision) worden eenmaal per laag aangeroepen. Wanneer er meerdere lagen zijn gedefinieerd, worden hooks uitgevoerd voor elke laag in de volgorde waarin de lagen worden verwerkt.

Volgende stappen

azure.yaml-schemaverwijzing

  • Last updated on