Warstwowe dostarczanie

Interfejs wiersza polecenia dla deweloperów platformy Azure (azd) obsługuje aprowizację warstwową, której można użyć do definiowania wielu warstw aprowizacji w azure.yaml pliku. Każda warstwa wskazuje własny zestaw szablonów infrastruktury jako kodu (IaC). CLI tworzy warstwy po jednej, w kolejności wynikającej z zależności między nimi. Można również niezależnie wdrażać lub usuwać poszczególne warstwy.

Ta funkcja rozwiązuje złożone scenariusze zależności, w których zasoby w jednej warstwie zależą od zasobów z innej warstwy. Zamiast mieszać IaC ze skryptami imperatywnych haków, warstwowa aprowizacja utrzymuje wszystko w sposób deklaratywny.

Kiedy należy używać prowizjonowania warstwowego

Użyj aprowizacji warstwowej, kiedy jedno azd provision wdrożenie nie jest w stanie obsłużyć wszystkich potrzeb infrastruktury za jednym razem. Rozważ użycie aprowizacji warstwowej w przypadku:

• Zależności cykliczne: niektóre zasoby muszą odwoływać się do innych zasobów, które muszą zostać utworzone jako pierwsze, takie jak sieć wirtualna, która musi istnieć przed skonfigurowaniem prywatnego punktu końcowego.
• Podstawowa infrastruktura różni się od infrastruktury aplikacji: zarządzasz udostępnionymi zasobami sieci, zabezpieczeń lub tożsamości niezależnie od zasobów poszczególnych aplikacji.
• Wymagane jest niezależne zarządzanie cyklem życia: aktualizujesz i wyłączasz różne składniki infrastruktury w różnym czasie. Na przykład warstwa sieciowa może być długotrwała, podczas gdy warstwa aplikacji jest często wdrażana ponownie.
• Projekty Monorepo z różnymi grupami infrastruktury: pojedyncze repozytorium zawiera wiele niezależnych usług (takich jak centrum zdarzeń, aplikacja kontenera i aplikacja funkcji), z których każdy ma własne szablony infrastruktury.

Konfigurowanie warstw w pliku azure.yaml

Zdefiniuj warstwy w sekcji infra pliku azure.yaml. Każda warstwa wymaga zarówno name, jak i path, które wskazują na katalog zawierający szablony IaC dla tej warstwy.

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

Właściwości warstwy

Każda warstwa obsługuje następujące właściwości:

Struktura katalogu

Typowy projekt korzystający z aprowizacji warstwowej może mieć następującą strukturę katalogów:

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

Każdy katalog warstwy zawiera własny kompletny zestaw szablonów IaC, podobnie jak katalog projektu standardowego azdinfra .

Aprowizuj warstwy i zarządzaj nimi

Możesz aprowizować wszystkie warstwy jednocześnie lub określić określoną warstwę według nazwy. W poniższych sekcjach opisano typowe polecenia wdrażania, likwidacji i odświeżania stanu warstwy.

Skonfiguruj wszystkie warstwy

Uruchom polecenie azd provision bez argumentów, aby aprowizować wszystkie warstwy:

azd provision

azd przetwarza każdą warstwę pojedynczo, upewniając się, że warstwa zostanie ukończona przed rozpoczęciem dowolnej warstwy, która jest od niej zależna. W przypadku warstw Bicep oraz niestandardowych dostawców lub dostawców rozszerzeń program azd określa zależności na podstawie zmiennych środowiskowych i odwołań do danych wyjściowych warstwy w plikach *.bicepparam i *.parameters.json, dlatego kolejność wykonywania może się różnić od kolejności podanej w pliku azure.yaml. Warstwy bez wywnioskowanych lub zadeklarowanych zależności są uruchamiane w podanej kolejności. Ten proces gwarantuje, że zasoby zależne istnieją przed wdrożeniem warstw odwołujących się do nich.

Aprowizuj określoną warstwę

Aby aprowizować tylko określoną warstwę, przekaż nazwę warstwy jako argument:

azd provision networking

To polecenie wdraża tylko zasoby zdefiniowane w warstwie networking . Aprowizowanie określonej warstwy jest przydatne w następujących przypadkach:

• Iterujesz pojedynczą warstwę podczas programowania.
• Należy zaktualizować jedną warstwę bez ponownego wdrażania innych.
• Konfigurujesz nową warstwę na podstawie istniejącej infrastruktury.

Rozerwanie wszystkich warstw

Uruchom polecenie azd down bez argumentów, aby usunąć zasoby ze wszystkich warstw. Gdy istnieje wiele warstw, azd przetwarza je w odwrotnej kolejności aprowizacji, więc zasoby zależne są usuwane przed podstawowymi zasobami, od których zależą:

azd down

Rozerwanie konkretnej warstwy

Aby usunąć tylko określoną warstwę, przekaż nazwę warstwy jako argument:

azd down application

To polecenie usuwa tylko zasoby wdrożone przez warstwę application , pozostawiając inne warstwy nienaruszone.

Odśwież stan środowiska

Stan środowiska można odświeżyć z określonej warstwy, używając flagi --layer z azd env refresh:

azd env refresh --layer networking

To polecenie aktualizuje zmienne środowiskowe i dane wyjściowe w oparciu o najnowsze wdrożenie określonej warstwy.

Przykład: Monorepo z wieloma usługami

W poniższym przykładzie przedstawiono aprowizowanie warstwowe dla monorepo zawierającego Event Hub, aplikację kontenerową obsługującą wiele kontenerów i Azure Function App.

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}

Odpowiednia struktura katalogu:

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

Za pomocą tej konfiguracji można wykonywać następujące czynności:

1. Udostępnij tylko infrastrukturę Event Hub: azd provision eventhub
2. Dostarcz tylko infrastrukturę aplikacji kontenerowej: azd provision aca
3. Skonfiguruj wszystkie elementy w ustalonej kolejności: azd provision
4. Usuń tylko warstwę aplikacji funkcji: azd down functionapp

Przykład: warstwy podstawowe i warstwy aplikacji

Wspólny wzorzec oddziela współdzieloną lub podstawową infrastrukturę od infrastruktury dla aplikacji:

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

Warstwa base tworzy udostępnione zasoby, takie jak sieć, tożsamość i monitorowanie. Warstwa app tworzy zasoby specyficzne dla aplikacji (takie jak środowisko aplikacji kontenera i aplikacje kontenera), które odwołują się do podstawowych zasobów.

Podczas programowania można aprowizować warstwę podstawową raz i iterować ją w warstwie aplikacji:

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

Przykład: mieszani dostawcy IaC

Każda warstwa może używać innego dostawcy IaC. Na przykład możesz użyć Bicep do obsługi sieci i narzędzia Terraform dla warstwy aplikacji:

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

Wbudowani dostawcy inni niż Bicep (Terraform, Pulumi, ARM i dostawca testowy) są nieprzejrzyste dla mechanizmu wnioskowania o zależnościach, ponieważ azd nie może analizować ich danych wejściowych pod kątem odwołań do innych warstw. Użyj jawnej dependsOn właściwości za każdym razem, gdy kolejność między tymi warstwami lub między tymi warstwami i innymi warstwami ma znaczenie:

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

Uwagi i ograniczenia

• Podczas aprowizowania wszystkich warstw azd przetwarza je pojedynczo na podstawie ich zależności. W przypadku warstw Bicep oraz dostawców niestandardowych lub dostawców rozszerzeń narzędzie azd wywnioskuje zależności na podstawie zmiennych środowiskowych i odwołań do danych wyjściowych warstwy w plikach *.bicepparam i *.parameters.json. Warstwy bez wywnioskowanych lub zadeklarowanych zależności są uruchamiane w zdefiniowanej kolejności.
• Wbudowani dostawcy inni niż Bicep (Terraform, Pulumi, ARM i dostawca testowy) są niejawni z perspektywy wnioskowania o zależnościach. Użyj właściwości dependsOn, gdy ważna jest kolejność tych warstw.
• Jawne dependsOn jest również wymagane, gdy kolejność ma znaczenie, ale azd nie może wywnioskować zależności z odwołań do parametrów. Na przykład użyj dependsOn, gdy hook postprovision jednej warstwy generuje wartość, którą wykorzystuje inna warstwa, ponieważ wartości generowane przez hooki nie pojawiają się jako odwołania wyjściowe w plikach *.parameters.json lub *.bicepparam.
• Po usunięciu wszystkich warstw azd przetwarza je w odwrotnej kolejności aprowizacji.
  • Jeśli wiele warstw wdraża zasoby do tej samej grupy zasobów platformy Azure i używasz domyślnego zachowania usuwania bazującego na grupie zasobów, zasoby udostępnione mogą zostać usunięte podczas uruchamiania azd down.
  • Aby umożliwić niezależne śledzenie i usuwanie infrastruktury warstwowej, włącz stosy wdrażania, uruchamiając polecenie azd config set alpha.deployment.stacks on.
• Nie można użyć flagi --preview podczas aprowizacji wielu warstw jednocześnie. Aby użyć trybu podglądu, określ nazwę <layer>.
• Warstwy działają niezależnie pod względem IaC. Aby odwołać się do danych wyjściowych z jednej warstwy w innej warstwie, użyj zmiennych środowiskowych ustawianych azd po wdrożeniu każdej warstwy. Odwoływanie się do tych zmiennych środowiskowych z pliku *.bicepparam lub *.parameters.json umożliwia azd również wnioskowanie kolejności między warstwami.
• Wszystkie standardowe azd funkcje aprowizacji (buforowanie stanu wdrożenia, hooki, parametry, Bicep lub Terraform) działają w każdej warstwie.
  • Haki na poziomie polecenia (na przykład preprovision, postprovision) są wywoływane raz na warstwę. Gdy zdefiniowane są wiele warstw, haki uruchamiane są dla każdej z nich w kolejności, w jakiej są przetwarzane.

Dalsze kroki

• Versionowanie funkcji i strategia wydawania
• Zarządzanie zmiennymi środowiskowymi
• Dostosuj przepływy pracy przy użyciu komend i hooków zdarzeń