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). Interfejs wiersza polecenia konfiguruje warstwy sekwencyjnie w kolejności ich definiowania. 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.

Uwaga / Notatka

Aprowizacja warstwowa jest obecnie funkcją beta. Dowiedz się więcej o strategii przechowywania wersji.

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

Ważne

Kolejność przetwarzania warstw:azd provision przetwarza warstwy od góry do dołu w kolejności, w której znajdują się na liście.azure.yaml azd down przetwarza warstwy w odwrotnej kolejności (od dołu do góry). Zdefiniuj warstwy, aby najpierw pojawiły się podstawowe zasoby, a następnie warstwy, które od nich zależą. Ta kolejność gwarantuje utworzenie zależności przed zasobami, które ich potrzebują, i usunięcie zależności po tych zasobach.

Właściwości warstwy

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

Majątek Wymagane Opis
name Tak Unikatowa nazwa warstwy. Użyj tej nazwy podczas wskazywania na konkretną warstwę za pomocą poleceń.
path Tak Ścieżka względna do katalogu zawierającego szablony IaC dla tej warstwy.
module Nie. Nazwa modułu w katalogu warstwy. Wartość domyślna to main.
provider Nie. Dostawca IaC dla tej warstwy (bicep lub terraform). Dziedziczy z root infra.provider, jeśli go nie określisz.

Ważne

Podczas definiowania infra.layers, nie można zadeklarować innych właściwości w sekcji infra (path, module, deploymentStacks) na poziomie głównym. Należy określić całą konfigurację infrastruktury w każdej warstwie.

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 sekwencyjnie w kolejności, w której są zdefiniowane w pliku azure.yaml.

azd provision

azd przetwarza każdą warstwę pojedynczo, zapewniając ukończenie pierwszej warstwy przed rozpoczęciem drugiej warstwy. 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, 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

Uwagi i ograniczenia

  • Podczas aprowizowania wszystkich warstw azd przetwarza je sekwencyjnie w zdefiniowanej kolejności. Zaplanuj kolejność warstw, aby najpierw aprowizować podstawowe zasoby.
  • Podczas usuwania wszystkich warstw azd przetwarza je w odwrotnej kolejności.
    • 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.
    • pl-PL: Aby zezwolić na niezależne śledzenie i usuwanie infrastruktury warstwowej, włącz stosy wdrażania przy użyciu polecenia azd config set alpha.deployment.stacks on. Stosy wdrażania pozwalają azd śledzić zasoby w poszczególnych warstwach zamiast polegać wyłącznie na usunięciu całej grupy zasobów.
  • 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.
  • 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