Bicep ファイル内で、文字列補間関数と Bicep 関数を使用して、一意で、決定論的で意味があり、デプロイする環境ごとに異なるリソース名を作成します。
コンテキストと問題
Azure では、リソースに付ける名前が重要です。 名前は、自分とチームがリソースを識別するのに役立ちます。 多くのサービスでは、リソース名は、リソースへのアクセスに使用する DNS 名の一部を形成しています。 リソースの作成後に名前を簡単に変更することはできません。
リソースの名前を計画する場合は、次の条件を確認する必要があります。
- 一意: Azure リソース名は一意である必要がありますが、一意性の範囲はリソースによって異なります。
- 決定論的: 既存のリソースを再作成せずに、Bicep ファイルを繰り返しデプロイできることが重要です。 同じパラメーターで Bicep ファイルを再デプロイする場合、リソースは同じ名前を維持する必要があります。
- 意味がある: 名前は、リソースの目的に関する重要な情報をユーザーとチームに伝えます。 可能であれば、リソースの目的を示す名前を使います。
- 環境ごとに異なる: ロールアウト プロセスの一環として、テスト環境、ステージング環境、運用環境などの複数の環境にデプロイすることはよくあることです。
- 特定のリソースに対して有効:各 Azure リソースには、有効なリソース名を作成するときに従う必要がある一連のガイドラインがあります。これには、最大長、使用できる文字、リソース名が文字で始まる必要があるかどうか、が含まれます。
注
組織には、従う必要がある独自の名前付け規則がある場合があります。 組織の名前付け戦略を作成する方法について、Azure Cloud Adoption Framework ではガイダンスを提供しています。 従うべき厳密な名前付け規則があり、生成される名前が識別的で一意である場合は、このパターンに従う必要がない場合もあります。
解決策
Bicep の文字列補間を使用して、リソース名を変数として生成します。 リソースでグローバルに一意の名前が必要な場合は、uniqueString() 関数を使用してリソース名の一部を生成します。 リソースを簡単に識別するために、意味のある情報を先頭か末尾に追加します。
注
Azure RBAC ロールの定義やロールの割り当てなど、一部の Azure リソースには、グローバルに一意な識別子 (GUID) を名前として指定する必要があります。 guid() 関数を使用して、これらのリソースの名前を生成します。
再利用可能な Bicep コードを作成する場合は、パラメーターとして名前を定義することを検討する必要があります。 既定のパラメーター値を使用して、オーバーライドできる既定の名前を定義します。 既定値は、Bicep ファイルの再利用性を高めるのに役立ち、別の名前付け規則に従う必要がある場合に、ファイルのユーザーが独自の名前を定義できるようにします。
例 1: 組織の名前付け規則
次の例では、App Service アプリとプランの名前を生成します。 これは、リソースの種類コード (app か plan)、アプリケーションかワークロード名 (contoso)、環境名 (パラメーターで指定)、リソース グループの ID のシード値を持つ uniqueString() 関数を使用して一意性を確保する文字列などの、組織の規則に従います。
App Service プランではグローバルに一意の名前は必要ありませんが、組織のポリシーに確実に準拠するために、プラン名は同じ形式で構成されます。
param location string = resourceGroup().location
param environmentName string
param appServiceAppName string = 'app-contoso-${environmentName}-${uniqueString(resourceGroup().id)}'
param appServicePlanName string = 'plan-contoso-${environmentName}-${uniqueString(resourceGroup().id)}'
resource appServiceApp 'Microsoft.Web/sites@2022-09-01' = {
name: appServiceAppName
// ...
}
resource appServicePlan 'Microsoft.Web/serverfarms@2022-09-01' = {
name: appServicePlanName
// ...
}
例 2
次の例では、名前付け規則を使用せずに、異なる組織の 2 つのストレージ アカウントの名前を生成します。 この例では、リソース グループの ID で uniqueString() 関数を再び使用します。 2 つのストレージ アカウントのそれぞれに個別の名前が付くように、生成された名前の前に短い文字列が付加されます。 これは、ストレージ アカウントの要件である文字で始まる名前を確保するのにも役立ちます。
param primaryStorageAccountName string = 'contosopri${uniqueString(resourceGroup().id)}'
param secondaryStorageAccountName string = 'contososec${uniqueString(resourceGroup().id)}'
resource primaryStorageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
name: primaryStorageAccountName
// ...
}
resource secondaryStorageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
name: secondaryStorageAccountName
// ...
}
考慮事項
- 必ずリソース名の一意性の範囲を確認します。
uniqueString() 関数に適切なシード値を使用して、Azure リソース グループとサブスクリプション全体で Bicep ファイルを再利用できることを確実にします。
ヒント
ほとんどの場合、完全修飾リソース グループ ID は、
uniqueString関数のシード値に対して適したオプションです。var uniqueNameComponent = uniqueString(resourceGroup().id)リソース グループ (
resourceGroup().name) の名前は、サブスクリプション全体でファイルを再利用するためには十分に一意ではない場合があります。 - リソースのデプロイ後に、
uniqueString()関数のシード値を変更しないようにします。 シード値を変更すると、新しい名前になり、運用リソースに影響する可能性があります。