Azure Developer CLI テンプレートの概要

Azure Developer CLI (azd) テンプレートは、azd規則に従うコード リポジトリです。 プロジェクト構成、コードとしてのインフラストラクチャ、およびオプションのアプリケーション ソースを組み合わせて、反復可能なAzure環境とデプロイを作成できます。

テンプレートでは、次のようなさまざまなプロジェクトの種類をサポートできます。

  • 1 つ以上のデプロイ可能なサービスを備えた完全なアプリケーション。
  • アプリケーション コードのないインフラストラクチャ専用ソリューション。
  • 別の開発者が初期化して拡張できる再利用可能な開始点。
  • azdを使用してプロビジョニングとデプロイを準備する既存のプロジェクト。

この記事では、テンプレートの構造と、 azd コマンドでファイルを使用する方法について説明します。

テンプレートを使用する理由

テンプレートは、Azureでプロジェクトを実行するために必要な決定をキャプチャします。 プロジェクトに応じて、以下を定義できます。

  • Azure リソースとその構成。
  • デプロイ可能なアプリケーション サービスとパッケージ化の手順。
  • アプリケーション サービスとAzure リソース間の接続。
  • 環境固有のパラメーターと出力。
  • ローカル開発、継続的インテグレーション、継続的デリバリーの構成。

構成はプロジェクトと共に保存されるため、チームはソース管理の変更を確認し、一貫した開発、テスト、運用環境を作成できます。

azdでテンプレートを使用する方法

テンプレート内のファイルは、 azd ワークフローのさまざまなステージをサポートします。

  • azd init はプロジェクトを初期化し、 azd 環境を作成します。 また、GitHub Copilotを使用して初期テンプレートを生成したり、既存のテンプレートをコピーしたりすることもできます。
  • azd provisionはインフラストラクチャ定義を評価し、リソースAzure作成または更新します。
  • azd package は、 azure.yamlに従ってデプロイ可能なアプリケーション サービスを準備します。
  • azd deployは、各サービスをAzure ホストに関連付け、アプリケーション パッケージをデプロイします。
  • azd up では、プロビジョニング、パッケージ化、デプロイの各ステージが組み合わされたワークフローとして実行されます。

テンプレート ファイルは、このプロセスを通じて通常のソース ファイルのままです。 プロジェクトの残りの部分で、それらを確認、編集、およびバージョン管理できます。

Azure Developer CLI テンプレートの構造を調べる

azd テンプレートは、追加の構成とインフラストラクチャ資産を備えた標準コード リポジトリです。 ほとんどのテンプレートでは、次の構造が使用されます。

  • azure.yaml ファイル - プロジェクトを定義し、配置可能なソース ディレクトリをAzureリソースにマップします。
  • infra フォルダー - Azure リソースを作成するBicepまたは Terraform のコードとしてのインフラストラクチャ ファイルが含まれています。
  • src フォルダー - 一般に、配置可能なアプリケーション ソース コードが含まれています。 インフラストラクチャのみのテンプレートではアプリケーション ソースを省略でき、アプリケーション テンプレートでは他のソース ディレクトリ名を使用できます。
  • .azure フォルダー - azdによって作成されたローカル環境と値が含まれます。 このフォルダーはローカル プロジェクトの状態であり、通常は再利用可能なテンプレートの一部として共有されません。

たとえば、共通のazdテンプレートは、次のフォルダー構造と一致する場合があります。

contoso-project/
├── azure.yaml                 # azd project and service configuration
├── infra/
│   ├── main.bicep            # Infrastructure entry point
│   └── main.parameters.json  # Maps azd values to Bicep parameters
├── src/                      # Optional application source
│   ├── api/
│   └── web/
├── .github/workflows/        # Optional GitHub Actions pipelines
└── .azure/                   # Local environment state; don't distribute

azd テンプレートには、オプションで次のフォルダーも 1 つ以上含まれます。

  • .github フォルダー - GitHub Actionsの CI/CD ワークフロー ファイルを保持します。
  • .azdo フォルダー - CI/CD に Azure Pipelines を使用する場合は、このフォルダー内にワークフロー構成ファイルを定義します。
  • .devcontainer フォルダー - プロジェクトの 開発環境 を定義します。

次の図は、プライマリ テンプレート資産がどのように連携するかを示しています。

flowchart LR
AZ[azure.yaml] -->|Defines services| SRC[Application source]
AZ -->|Selects provider and path| INFRA[Infrastructure as code]
INFRA -->|Provisions| RES[Azure resources]
INFRA -->|Exports values| ENV[azd environment]
ENV -->|Configures| SRC
AZ -->|Maps services to| RES

必須資産と省略可能な資産

正確な構造はプロジェクトによって異なりますが、ほとんどのテンプレートでは次のアセットが使用されます。

azure.yaml

azure.yaml ファイルは、プライマリ プロジェクト構成ファイルです。 プロジェクト名を定義し、配置可能なサービス、インフラストラクチャ プロバイダー、フック、ワークフロー、およびその他の azd 動作を定義できます。

アプリケーション サービスの場合、 azure.yaml 一般的に次の情報が識別されます。

  • アプリケーション ソースへのパス。
  • プログラミング言語またはパッケージ化戦略。
  • アプリケーションをホストするAzure サービス。
  • ビルド、デプロイ、コンテナー、または Kubernetes の設定。

インフラストラクチャのみのテンプレートでは、アプリケーション サービスを省略できます。 完全な構成モデルについては、 azure.yaml スキーマを参照してください。

次の例では、2 つのアプリケーション サービスを定義します。 サービス名、ソース パス、言語、ホスティング ターゲットは、azd に何をパッケージ化し、どこにデプロイするかを示します。

name: store
services:
  api:
    project: ./src/api
    language: js
    host: containerapp
  web:
    project: ./src/web
    language: js
    host: staticwebapp

コードとしてのインフラストラクチャ

ほとんどのテンプレートには、Bicepまたは Terraform ファイルを含むinfra ディレクトリが含まれています。 これらのファイルは、Azureリソース、ロールの割り当て、ネットワーク、アプリケーション設定、およびプロジェクトで必要な配置出力を定義します。

既定のBicep プロバイダーの場合、azdは通常、infra/main.bicepを展開エントリ ポイントとして使用し、infra/main.parameters.jsonazd環境の値をBicepパラメーターにマップします。 Terraform テンプレートでは、通常、 infra/main.tf および関連する Terraform ファイルが使用されます。

たとえば、Bicep パラメーター ファイルは、azdによって選択された値をインフラストラクチャのデプロイに渡すことができます。

{
  "parameters": {
    "environmentName": { "value": "${AZURE_ENV_NAME}" },
    "location": { "value": "${AZURE_LOCATION}" }
  }
}

Bicepプロビジョニングが完了すると、azdはエントリ ポイントからの出力を環境の値として格納します。 アプリケーション サービスとフックは、リソース エンドポイント、名前、およびその他のランタイム構成にこれらの値を使用できます。

output API_ENDPOINT string = api.outputs.uri

アプリケーション ソース

アプリケーション ソースは省略可能です。 テンプレートにデプロイ可能なサービスが含まれている場合、 azure.yaml 内の各サービス定義は、そのソース ディレクトリを指します。 テンプレートは、 srcでサービスを整理したり、リポジトリ内の別の場所でディレクトリを使用したり、リポジトリ ルートでサービスをポイントしたりできます。

フォルダー名自体は重要ではありません。 azure.yamlのproject値によって、azdが各サービスを検索する場所が決まります。

環境構成

.azure ディレクトリには、ローカル環境の状態と、azdによって作成された値が含まれています。 複数の環境のサブスクリプション、場所、リソース名、エンドポイント、デプロイの出力値を含めることができます。

このディレクトリは、再利用可能なテンプレート資産ではなくローカル状態として扱います。 シークレットまたは環境固有の値を含む環境ファイルはコミットしないでください。

補助アセット

テンプレートには、次を含めることもできます。

  • GitHub Actions または Azure Pipelines の定義。
  • Dockerfile とコンテナーの構成。
  • 開発コンテナーの構成。
  • コマンドフックとサービスフック。
  • テスト、スクリプト、およびプロジェクトのドキュメント。

これらの資産は省略可能であり、目的のテンプレート エクスペリエンスをサポートする場合にのみ含める必要があります。

サービスとリソースの関連付け

アプリケーション サービスをデプロイするには、azdazure.yaml内の定義をプロビジョニングされたAzure リソースに関連付ける必要があります。 既定では、 azd は、 azd-service-name タグがサービス名と一致するリソースを検索します。

たとえば、 api という名前のサービスは、 azd-service-name: apiでタグ付けされたリソースにマップされます。 代わりに、 resourceName サービス プロパティを使用して、デプロイ ターゲットを明示的に識別できます。

次のBicep式は、リソースの既存のタグに探索タグを追加します。

tags: union(tags, {
  'azd-service-name': 'api'
})

テンプレートを編集するときに、サービス名、リソース検出設定、インフラストラクチャ出力、アプリケーション環境変数を揃えておきます。

テンプレートをビルドまたは調整する

推奨される作成エクスペリエンスは、azd initを実行し、[Set up with GitHub Copilot (プレビュー)] を選択します。 専用のCopilot エージェント セッションでは、既存のファイルの分析、新しいプロジェクトの計画、テンプレート資産の生成、結果の検証を行うことができます。 このワークフローとその他の作成方法については、「 新しいテンプレートで開始する」を参照してください。

生成されたファイルはCopilotに関連付けられません。 テンプレート ファイルは、初期化後に直接調べて編集できます。 また、同じファイルを手動で作成することも、別の AI コーディング エージェントを使用して作成することもできます。

Microsoft、組織、または開発者コミュニティのテンプレートが既に便利なアーキテクチャを提供している場合は、既存のテンプレートから開始し、プロジェクトに合わせて調整します。 テンプレート ギャラリーで使用可能なテンプレートを参照します。

テンプレートの使用ガイドライン

各テンプレートは、テンプレートに付随する契約に基づき、所有者によってライセンスされます。 テンプレートを使用または配布する前に、適用されるライセンスを決定します。

Microsoft は、Microsoft 以外が提供するテンプレートについて責任を負いません。また、セキュリティ、プライバシー、互換性、またはパフォーマンスの問題について、これらのテンプレートを審査していません。 Microsoft提供のテンプレートを含むテンプレートは、Microsoftサポート プログラムまたはサービスではサポートされず、保証なしでそのまま提供されます。

プロビジョニングする前にすべてのテンプレート ファイルを確認します。 特に、ロールの割り当て、ネットワーク公開、認証方法、サービス レベル、リソースの場所、予想されるコストを評価します。

次のステップ

テンプレート開発の概要

  • 最終更新: