階層型プロビジョニング

Azure Developer CLI (azd) では、階層型プロビジョニングがサポートされています。これを使用して、 azure.yaml ファイルで複数のプロビジョニング レイヤーを定義できます。 各レイヤーは、独自のコードとしてのインフラストラクチャ (IaC) テンプレートのセットを指します。 CLI は、レイヤー間の依存関係に従って、一度に 1 つずつレイヤーをプロビジョニングします。 個々のレイヤーを個別にプロビジョニングまたは破棄することもできます。

この機能は、あるレイヤー内のリソースが別のレイヤーのリソースに依存する複雑な依存関係シナリオを解決します。 IaC と命令型フック スクリプトを混在させる代わりに、階層型プロビジョニングでは、すべてを宣言型に保ちます。

階層型プロビジョニングを使用する場合

単一の azd provision デプロイでインフラストラクチャのニーズをすべて 1 つの手順で処理できない場合は、階層型プロビジョニングを使用します。 次の場合は、階層型プロビジョニングの使用を検討してください。

• 循環依存関係: 一部のリソースは、プライベート エンドポイントを構成する前に存在する必要がある仮想ネットワークなど、最初に作成する必要がある他のリソースを参照する必要があります。
• 基本インフラストラクチャはアプリケーション インフラストラクチャとは異なります。共有ネットワーク、セキュリティ、または ID リソースは、アプリケーションごとのリソースとは別に管理します。
• 独立したライフサイクル管理が必要です。さまざまなインフラストラクチャ コンポーネントを異なる時間に更新して破棄します。 たとえば、ネットワーク レイヤーは有効期間が長く、アプリケーション レイヤーは頻繁に再デプロイされます。
• 個別のインフラストラクチャ グループを持つ Monorepo プロジェクト: 1 つのリポジトリには、それぞれが独自のインフラストラクチャ テンプレートを持つ複数の独立したサービス (イベント ハブ、コンテナー アプリ、関数アプリなど) が含まれています。

azure.yaml でレイヤーを構成する

infra ファイルの [azure.yaml] セクションの下にレイヤーを定義します。 各レイヤーには、 name と、そのレイヤーの IaC テンプレートを含むディレクトリを指す path が必要です。

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

レイヤーのプロパティ

各レイヤーでは、次のプロパティがサポートされています。

ディレクトリの構造

階層型プロビジョニングを使用する一般的なプロジェクトには、次のディレクトリ構造が含まれる場合があります。

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

各レイヤー ディレクトリには、プロジェクトの標準 azdinfra ディレクトリと同様に、独自の IaC テンプレートの完全なセットが含まれています。

レイヤーのプロビジョニングと管理

すべてのレイヤーを一度にプロビジョニングすることも、特定のレイヤーを名前でターゲットにすることもできます。 次のセクションでは、レイヤーの状態をプロビジョニング、破棄、更新するための一般的なコマンドについて説明します。

すべてのレイヤーをプロビジョニングする

引数を指定せずに azd provision を実行して、すべてのレイヤーをプロビジョニングします。

azd provision

azd は各レイヤーを一度に 1 つずつ処理し、それに依存するレイヤーが開始される前にレイヤーが完了することを確認します。 Bicep レイヤーとカスタム プロバイダーまたは拡張プロバイダーの場合、azdは、*.bicepparam ファイルと*.parameters.json ファイル内の環境変数およびレイヤー出力参照からの依存関係を推測するため、実行順序はazure.yamlに記載されている順序とは異なる場合があります。 推定または宣言された依存関係がないレイヤーは、一覧に示されている順序で実行されます。 このプロセスでは、依存リソースを参照するレイヤーがデプロイされる前に、依存リソースが存在することが保証されます。

特定のレイヤーをプロビジョニングする

特定のレイヤーのみをプロビジョニングするには、レイヤー名を引数として渡します。

azd provision networking

このコマンドは、 networking レイヤーで定義されているリソースのみをデプロイします。 特定のレイヤーのプロビジョニングは、次の場合に役立ちます。

• 開発中は、1 つのレイヤーを反復処理しています。
• 他のレイヤーを再デプロイせずに、1 つのレイヤーを更新する必要があります。
• 既存のインフラストラクチャの上に新しいレイヤーを設定します。

すべてのレイヤーを破棄する

引数を指定せずに azd down を実行して、すべてのレイヤーからリソースを破棄します。 複数のレイヤーが存在する場合、 azd はプロビジョニング順序とは 逆 の順序で処理されるため、依存している基本リソースの前に依存リソースが削除されます。

azd down

特定のレイヤーを破棄する

特定のレイヤーのみを破棄するには、レイヤー名を引数として渡します。

azd down application

このコマンドを実行すると、 application レイヤーによってデプロイされたリソースのみが削除され、他のレイヤーはそのまま残ります。

環境の状態を更新する

--layerで azd env refresh フラグを使用して、特定のレイヤーから環境の状態を更新できます。

azd env refresh --layer networking

このコマンドは、指定されたレイヤーの最新のデプロイに基づいて環境変数と出力を更新します。

例: 複数のサービスを含む Monorepo

次の例は、イベント ハブ、複数のコンテナーを実行するコンテナー アプリ、および Azure Function App を含む monorepo の階層型プロビジョニングを示しています。

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}

対応するディレクトリ構造:

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

この構成では、次のことができます。

1. Event Hub インフラストラクチャのみをプロビジョニングします。 azd provision eventhub
2. Container App インフラストラクチャのみをプロビジョニングします。 azd provision aca
3. すべてを順番にプロビジョニングします。 azd provision
4. Function App レイヤーのみを破棄します。 azd down functionapp

例: 基本レイヤーとアプリケーション レイヤー

一般的なパターンでは、共有インフラストラクチャまたは基本インフラストラクチャがアプリケーションごとのインフラストラクチャから分離されます。

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

base レイヤーは、ネットワーク、ID、監視などの共有リソースを作成します。 app レイヤーは、基本リソースを参照するアプリケーション固有のリソース (Container App 環境やコンテナー アプリなど) を作成します。

開発中は、基本レイヤーを 1 回プロビジョニングし、アプリケーション レイヤーを反復処理できます。

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

例: 混合 IaC プロバイダー

各レイヤーは、異なる IaC プロバイダーを使用できます。 たとえば、Bicep をネットワークに使用し、アプリケーション レイヤーに Terraform を使用できます。

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

組み込みの非Bicep プロバイダー (Terraform、Pulumi、ARM、およびテスト プロバイダー) は、依存関係の推論に対して不透明です。これは、azdが他のレイヤーへの参照の入力を分析できないためです。 これらのレイヤー間、またはそれらのレイヤーと他のレイヤーの間で並べ替える場合は常に、明示的な dependsOn プロパティを使用します。

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

考慮事項と制限事項

• すべてのレイヤーをプロビジョニングすると、azd は依存関係に基づいてそれらを 1 つずつ処理します。 Bicep レイヤーとカスタム プロバイダーまたは拡張プロバイダーの場合、azdは、*.bicepparamファイルと*.parameters.json ファイル内の環境変数およびレイヤー出力参照からの依存関係を推論します。 推定または宣言された依存関係のないレイヤーは、定義した順序で実行されます。
• 組み込みの非Bicep プロバイダー (Terraform、Pulumi、ARM、およびテスト プロバイダー) は、依存関係の推論では不透明です。 これらのレイヤーを含む順序が重要な場合は、明示的な dependsOn プロパティを使用します。
• 順序が重要であり、かつdependsOnがパラメーター参照から依存関係を推論できない場合は、明示的なazdも必要です。 たとえば、1 つのレイヤーのpostprovision フックが別のレイヤーで使用する値を生成する場合は、dependsOnを使用します。これは、フックによって生成された値が*.bicepparamまたは*.parameters.json ファイルの出力参照として表示されないためです。
• すべてのレイヤーを破棄すると、 azd はプロビジョニング順序とは逆に処理されます。
  • 複数のレイヤーが同じ Azure リソース グループにリソースをデプロイし、既定のリソース グループベースの削除動作を使用している場合、azd down を実行すると共有リソースが削除される可能性があります。
  • 階層化インフラストラクチャの独立した追跡と削除を許可するには、コマンド azd config set alpha.deployment.stacks onを実行してデプロイ スタックを有効にします。
• 複数のレイヤーを一度にプロビジョニングするときに、 --preview フラグを使用することはできません。 プレビュー モードを使用する <layer> 名を指定します。
• レイヤーは、IaC の観点から独立して動作します。 別のレイヤーの 1 つのレイヤーからの出力を参照するには、各レイヤーのデプロイ後に設定 azd 環境変数を使用します。 *.bicepparamまたは*.parameters.json ファイルからこれらの環境変数を参照すると、レイヤー間の順序をazd推論することもできます。
• すべての標準 azd プロビジョニング機能 (デプロイ状態のキャッシュ、フック、パラメーター、Bicep、または Terraform) は、個々のレイヤー内で動作します。
  • コマンド レベルのフック ( preprovision、 postprovisionなど) は、レイヤーごとに 1 回呼び出されます。 複数のレイヤーが定義されている場合、フックは、レイヤーが処理される順序で各レイヤーに対して実行されます。

次のステップ

• 機能のバージョン管理とリリース戦略
• 環境変数の管理
• コマンド フックとイベント フックを使用してワークフローをカスタマイズする