Azure Developer CLI (azd) テンプレートは、azdがプロジェクトをプロビジョニングしてデプロイできるようにする構成資産とインフラストラクチャ資産を含む標準リポジトリです。 新しいテンプレートを作成する場合も、既存のテンプレートから開始する場合でも、プロジェクトの進化に合ったファイルの確認と保守は引き続き行います。
この記事では、プライマリ テンプレート ファイルを検査および編集する方法について説明します。 完全な構造の概念の説明については、開発者 CLI テンプレートAzure参照してください。
この記事では、 hello-azd テンプレートを標準化された例として使用して、各ファイルが実際のプロジェクトで何を行うかを確認できます。 独自のアプリ用に生成するテンプレートにも同じ概念が適用されます。 続くには、空のディレクトリでテンプレートを初期化します。
azd init --template hello-azd
hello-azd テンプレートは、コンテナー化された C# アプリをAzure Container Appsにデプロイし、Bicepを介してサポートAzure リソースをプロビジョニングします。 ここでは、次のようなフォルダー構造を使用します。各プライマリ アセットは、この記事のセクションにマップされます。
.
├── azure.yaml # Project configuration (Explore azure.yaml)
├── infra/ # Infrastructure as code (Infrastructure files)
│ ├── main.bicep # Deployment entry point
│ ├── main.parameters.json # Parameter values that azd supplies
│ ├── abbreviations.json # Resource name abbreviations
│ ├── app/ # Application-specific modules
│ └── core/ # Reusable resource modules
├── src/ # Application source code (Source code)
│ └── Dockerfile # Container image build for the app
├── .azure/ # Environment configuration
└── README.md
正確な構造はプロジェクトによって異なり、 azure.yaml は azd が使用するパスを識別します。 次のセクションでは、各資産を編集する方法について説明します。
大幅な変更を行う前に、既知の適切なバージョンのテンプレートをコミットするか保存します。 埋め込み資格情報、不要なリソース、過剰なアクセス許可、ネットワーク公開、サービス レベル、環境固有の値に関するすべての変更を確認します。
azure.yaml について確認する
azure.yaml ファイルはプロジェクトを定義し、インフラストラクチャのプロビジョニング、アプリケーション コードのパッケージ化、各サービスのデプロイ方法をazdに指示します。 サービス、インフラストラクチャ設定、フック、ワークフロー、その他のプロジェクト動作を定義できます。
hello-azd テンプレートは、acaという名前の 1 つのサービスを定義します。
name: azd-starter
metadata:
template: hello-azd-dotnet
services:
aca:
project: ./src
language: csharp
host: containerapp
docker:
path: ./Dockerfile
remoteBuild: true
各プロパティは、 azd サービスの処理方法を示します。
-
acaはサービス名です。azdは、サービスをホストするAzure リソースとサービスを照合するために使用します。 詳細については、「 サービス検出の構成」を参照してください。 -
project: ./srcは、パッケージとデプロイをazdするアプリケーション ソース コードを指します。 -
language: csharpはアプリケーション言語を識別します。 -
host: containerappは、Azure Container Appsにサービスをデプロイするようにazdに指示します。 -
dockerは、srcディレクトリ内のDockerfileからコンテナー イメージをビルドします。 -
remoteBuildは、Azure Container Registry (ACR) を使用してコンテナー イメージをビルドするようにazdに指示します。
サービス定義を追加する
azd展開する必要がある追加のアプリケーションごとに、servicesの下にエントリを追加します。 サービス定義は、そのソース ディレクトリ、言語、およびホスティング ターゲットAzure指定します。 たとえば、新しい API プロジェクトを記述するには、次のようにします。
services:
api:
project: ./src/api
language: csharp
host: appservice
アプリケーション コードを移動するときは、対応する project パスを更新します。 ホスティング アーキテクチャを変更する場合は、サービス定義とホストをプロビジョニングするインフラストラクチャの両方を更新します。
使用可能なすべてのプロパティとサポートされている値については、 azure.yaml スキーマを参照してください。
ソース コード
アプリケーション ソースは省略可能です。 デプロイ可能なアプリケーションを含むテンプレートは、多くの場合、ソース コードを src ディレクトリの下に整理しますが、特定のフォルダー名やレイアウトを使用する必要はありません。
project 内の各サービスの azure.yaml プロパティは、ソース コードがどこに保存されているかを azd に伝えます。
hello-azdでは、aca サービスによってproject: ./srcが設定されるため、azdは C# アプリを src ディレクトリにパッケージし、Azure Container Appsにデプロイします。 サービスはdocker構成も設定するため、azdデプロイの前に、src ディレクトリ内のDockerfileからコンテナー イメージをビルドします。
azdでは、サポートされているAzure ホストの Node.js、Python、.NET、Java、および Go がサポートされます。 テンプレートでは、コンテナーをデプロイすることもできます。 現在の言語、フレームワーク、ホストの組み合わせについては、「 サポートされている言語と環境」を参照してください。
任意のアプリケーション リポジトリの場合と同様に、ソース コードを編集します。 サービスを追加するか、そのソース ディレクトリを移動する場合は、サービス定義 azure.yaml 更新します。 アプリケーションに新しいAzure リソースが必要な場合は、インフラストラクチャを更新し、構成を使用して必要なエンドポイントまたはリソース名をアプリケーションに渡します。
サービス ソース ディレクトリを変更する
たとえば、hello-azd アプリを src から src/app に移動する場合は、aca サービスのproject値を更新します。
services:
aca:
project: ./src/app
language: csharp
host: containerapp
docker:
path: ./Dockerfile
remoteBuild: true
インフラストラクチャ ファイル
infra ディレクトリには、テンプレートのAzure リソースを定義するBicepまたは Terraform ファイルが含まれています。
hello-azdでは、infra ディレクトリはBicepを使用し、次の主要な資産を含みます。
-
main.bicepは、リソースをプロビジョニングするために実行azd標準のデプロイ エントリ ポイントです。 -
main.parameters.jsonは、main.bicepのパラメーター値を提供します。 -
appには、アプリケーションに固有のモジュールが含まれています。 -
coreには、ストレージやホスティングなどの一般的なリソース用の再利用可能なモジュールが含まれています。
azd up中のmain.bicepの実行方法
azd upを実行すると、プロビジョニング フェーズでinfra/main.bicepがデプロイされます。
hello-azdでは、main.bicepはサブスクリプション スコープを対象とし、リソース グループを作成してから、モジュールを呼び出してアプリに必要なリソースをプロビジョニングします。
targetScope = 'subscription'
// Create a storage account
module storage './core/storage/storage-account.bicep' = {
name: 'storage'
scope: rg
params: {
name: !empty(storageAccountName) ? storageAccountName : '${abbrs.storageStorageAccounts}${resourceToken}'
location: location
tags: tags
allowSharedKeyAccess: false
containers: [ { name: 'attachments' } ]
tables: [ { name: 'tickets' } ]
}
}
// Container app for the 'aca' service
module web 'app/app.bicep' = {
name: serviceName
scope: rg
params: {
// ...
serviceName: serviceName
}
}
main.bicep ファイルは、ユーザー割り当てマネージド ID、Azure Storage アカウント、Azure Container Apps環境とレジストリ、およびaca サービスをホストするコンテナー アプリをプロビジョニングします。 また、マネージド ID がストレージにアクセスできるようにするロールも割り当てられます。 モジュールは、各リソースを独自のファイルに保持するため、 main.bicep 読み取り可能な状態を維持します。
main.bicep にリソースを追加する
単純なリソースまたは 1 回限りのリソースの infra/main.bicep にリソース宣言を直接追加します。 リソースを再利用する場合、リソースに複数の関連リソースが必要な場合、または読み取り可能な状態を維持する場合main.bicep、リソースを個別のBicep モジュールに組み込みます。
hello-azdと同様に、多くのテンプレートは再利用可能なモジュールをinfra/coreの下にグループ化します。
一般的なAzure リソースの場合は、モジュールをゼロから作成するよりも、Azure検証済みモジュールを優先します。 検証済みモジュールはMicrosoft維持され、セキュリティと信頼性のベスト プラクティスに従い、テンプレートで保持するインフラストラクチャ コードの量を減らします。
hello-azdに新しいリソースを追加する完全なチュートリアルについては、「テンプレートの拡張」を参照してください。
main.parameters.json ファイルは、azdが保持する値を Bicep パラメーターにマップします。
hello-azd テンプレートでは、次のパラメーターを使用します。
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"environmentName": { "value": "${AZURE_ENV_NAME}" },
"location": { "value": "${AZURE_LOCATION}" },
"principalId": { "value": "${AZURE_PRINCIPAL_ID}" },
"principalType": { "value": "${AZURE_PRINCIPAL_TYPE=User}" }
}
}
各エントリは、Bicep パラメーターを、環境の名前、場所、デプロイを実行するプリンシパルなど、環境内で保持azd値にバインドします。 環境名、場所、または azd が生成するリソース名など、環境またはデプロイによって異なる値には main.parameters.json を使用します。
main.bicepでは、環境間で変更されない安定した値をパラメーターの既定値またはリテラルとして保持します。 この方法では、デプロイごとに編集することなく、環境全体で同じBicepを再利用できます。
インフラストラクチャを追加または編集する場合:
- リソース構成環境を独立させます。 サブスクリプション ID、リソース名、場所、または資格情報を埋め込む代わりに、パラメーターと
azd環境の値を使用します。 - 機密性の高い値にはセキュリティで保護された出力を使用し、プレーンテキストのデプロイ出力としてシークレットを公開しないでください。
- マネージド ID に最小特権ロールの割り当てを適用します。
- サービス定義は
azure.yaml対象のリソースに合わせて維持します。 - サービス レベル、スケーリング制限、冗長性、リテンション期間の設定がコストに及ぼす影響を確認します。
Bicep言語とモジュールのガイダンスについては、Bicepのドキュメントを参照してください。 Terraform ベースのテンプレートについては、「Azure Developer CLI で Terraform を使用する」を参照してください。
サービス検出を構成する
既定では、azdは、azd-service-name タグが azure.yaml のサービス名と一致するリソースを見つけることで、サービスのAzure リソースを検出します。 サービスの名前を変更する場合は、対応するリソース タグを更新するか、 azure.yamlでリソース名を明示的に構成します。
たとえば、 hello-azd では、 aca サービス名がコンテナー アプリ リソースの azd-service-name タグと一致します。
azure.yaml サービス定義は、次の名前を設定します。
services:
aca:
project: ./src
language: csharp
host: containerapp
infra/app/app.bicepのコンテナー アプリ モジュールは、一致するタグを適用します。
tags: union(tags, { 'azd-service-name': serviceName })
非標準インフラストラクチャ パスを構成する
azure.yamlの infra セクションでは、インフラストラクチャ プロバイダーとエントリ ポイントを識別します。 既定のBicep レイアウトを使用する場合、これらの値は省略可能ですが、宣言すると、非標準のレイアウトを理解しやすくなります。
infra:
provider: bicep
path: infra
module: main
環境構成
.azure ディレクトリには、ローカル環境の状態と、選択したサブスクリプション、場所、リソース名、デプロイ出力など、azd作成される値が含まれます。 このディレクトリは、再利用可能なテンプレート資産ではなくローカル状態として扱います。 シークレットまたは環境固有の値を含む環境ファイルはコミットしないでください。
インフラストラクチャの出力を追加する
azd provision を実行して Bicep をデプロイすると、インフラストラクチャのエントリ ポイントからの出力が azd 環境値として取得されます。 アプリケーション サービスまたはフックで必要なリソース エンドポイント、リソース名、およびマネージド ID クライアント ID の出力を追加します。 たとえば、 hello-azd は、 main.bicepからコンテナー レジストリとマネージド ID の詳細を出力します。
output AZURE_CONTAINER_REGISTRY_ENDPOINT string = containerAppsEnv.outputs.registryLoginServer
output AZURE_CONTAINER_REGISTRY_NAME string = containerAppsEnv.outputs.registryName
output AZURE_USER_ASSIGNED_IDENTITY_NAME string = identity.outputs.name
マネージド ID またはKey Vault参照が代わりにアクセスを提供できる場合は、シークレットを出力しないでください。 プロビジョニング後、 azd env get-valuesを実行してキャプチャされた値を検査します。
詳細については、「環境変数の 管理」を参照してください。
変更内容をテストする
azd upを実行してインフラストラクチャをプロビジョニングし、任意のアプリケーション サービスをデプロイします。
azd up
テンプレートを共有する場合は、クリーン ディレクトリで初期化し、新しい環境でデプロイします。 このテストは、テンプレートに含まれていないローカル ファイル、キャッシュされた値、または環境固有の前提条件を識別するのに役立ちます。
関連するコンテンツ
ヘルプを要求する
Azure Developer CLI のバグの報告、ヘルプの要求、または新機能の提案の方法については、トラブルシューティングとサポートページを参照してください。