子リソースの定義

5 分

一部のリソースについては、その親のコンテキスト内でのみデプロイするのが理にかなっています。これらのリソースは "子リソース" と呼ばれます。 Azure には、多くの種類の子リソースがあります。次に例をいくつか示します。

名前	リソースの種類
仮想ネットワークサブネット	`Microsoft.Network/virtualNetworks/subnets`
App Service 構成	`Microsoft.Web/sites/config`
SQL データベース	`Microsoft.Sql/servers/databases`
仮想マシン拡張機能	`Microsoft.Compute/virtualMachines/extensions`
ストレージ BLOB コンテナー	`Microsoft.Storage/storageAccounts/blobServices/containers`
Azure Cosmos DB コンテナー	`Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers`

例として、ストレージ BLOB コンテナーについて考えてみましょう。 BLOB コンテナーは、ストレージアカウントにデプロイする必要があり、ストレージアカウントの外部にコンテナーが存在することには意味がありません。

子リソースの種類は、名前は長く、複数の部分があります。ストレージ BLOB コンテナーには、Microsoft.Storage/storageAccounts/blobServices/containers という完全修飾型名があります。 BLOB コンテナーのリソース ID には、コンテナーを含むストレージアカウントの名前と、コンテナーの名前が含まれます。

Note

子リソースの中には、親が異なる他の子リソースの種類と同じ名前を持つものもあります。たとえば、containers はストレージアカウントと Azure Cosmos DB データベースの両方の子の型です。名前は同じですが、これらは異なるリソースであり、完全修飾された型名が異なります。

子リソースはどのように定義されていますか。

Bicep を使用すると、いくつかの異なる方法で子リソースを宣言できます。それぞれの方法には固有の長所があり、特定の状況には適していますが、他の状況には適していません。それぞれのアプローチを見てみましょう。

ヒント

次のどの方法を使用しても、Azure では同じデプロイアクティビティが行われます。何かが中断してしまうことを気にすることなく、ニーズに最適なアプローチを選択できます。また、テンプレートを更新して、使用しているアプローチを変更することもできます。

入れ子になったリソース

子リソースを定義する方法の 1 つは、親内に子リソースを入れ子にすることです。仮想マシンと仮想マシン拡張機能をデプロイする Bicep テンプレートの例を次に示します。仮想マシン拡張機能は、仮想マシンに追加の動作を提供する子リソースです。この場合、拡張機能はデプロイ後に仮想マシン上でカスタムスクリプトを実行します。

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }

  resource installCustomScriptExtension 'extensions' = {
    name: 'InstallCustomScript'
    location: location
    properties: {
      // ...
    }
  }
}

入れ子になったリソースのリソースの種類は通常よりも単純であることに注意してください。完全修飾型名は Microsoft.Compute/virtualMachines/extensions ですが、入れ子になったリソースは親のリソースの種類を自動的に継承するため、子リソースの種類 extensions のみを指定する必要があります。

また、入れ子になったリソースに API バージョンが指定されていないことにも注意してください。 Bicep では、親リソースと同じ API バージョンを使用することを前提としていますが、必要に応じて API バージョンをオーバーライドできます。

入れ子になったリソースを参照するには、:: 演算子を使用します。たとえば、拡張機能の完全なリソース ID を返す出力を作成できます。

output childResourceId string = vm::installCustomScriptExtension.id

リソースを入れ子にすることは、子リソースを宣言する簡単な方法です。リソースを入れ子にすることで、テンプレートを読むすべてのユーザーに親子関係が明らかになります。ただし、入れ子になったリソースが多数ある場合、または入れ子にするレイヤーが複数ある場合は、テンプレートが読みにくくなる可能性があります。最大 5 レイヤーの深さまでリソースを入れ子にすることもできます。

親プロパティ

2 つ目の方法は、入れ子にせずに子リソースを宣言することです。次に、parent プロパティを使って、Bicep に親子関係について指示します。

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
  parent: vm
  name: 'InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

子リソースが parent プロパティを使用して、その親のシンボリック名を参照していることに注意してください。

親を参照するこのアプローチは、子リソースを宣言するもう 1 つの簡単な方法です。 Bicep では親リソースと子リソースの関係が理解されているため、完全修飾リソース名を指定したり、リソース間の依存関係を設定したりする必要はありません。さらに、このアプローチにより、入れ子が多すぎるために読みにくくなる可能性が回避されます。ただし、parent プロパティを使用して子リソースを定義するたびに、完全なリソースの種類と API バージョンを明示的に指定する必要があります。

parent プロパティで宣言された子リソースを参照するには、通常の親リソースの場合と同じように、そのシンボリック名を使います。

output childResourceId string = installCustomScriptExtension.id

リソース名の作成

入れ子になったリソースや parent キーワードを使用できない状況もあります。たとえば、for ループ内で子リソースを宣言する場合や、複雑な式を使用して子の親リソースを動的に選択する必要がある場合などです。このような状況では、次に示すように、子リソースの名前を手動で作成してそこに親リソース名を含めることで、子リソースをデプロイできます。

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
  name: '${vm.name}/InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

この例では、文字列補間を使用して、仮想マシンリソースの name プロパティを子リソース名に追加していることに注意してください。 Bicep では、子リソースと親リソースの間に依存関係があることが認識されます。代わりに、vmName 変数を使用して、子リソース名を宣言できます。ただし、これを行うと、子リソースの前に親リソースをデプロイする必要があることを Bicep が理解できないため、デプロイが失敗する可能性があります。

この状況を解決するには、次に示すように、dependsOn キーワードを使って依存関係について Bicep に手動で指示します。

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
  name: '${vmName}/InstallCustomScript'
  dependsOn: [
    vm
  ]
  //...
}

ヒント

Bicep でリソース間の関係について認識されると、提供可能な多くの利点が失われてしまうため、通常は、リソース名を作成しないことをお勧めします。このオプションは、子リソースを宣言するために他のアプローチのいずれも使用できない場合にのみ使用してください。

子リソース ID

子リソース ID の作成を開始するには、その親のリソース ID を含め、子リソースの種類と名前を追加します。例として、toyrnd という名前の Azure Cosmos DB アカウントについて考えてみましょう。 Azure Cosmos DB リソースプロバイダーは、デプロイする親リソースである databaseAccounts と呼ばれる型を公開します。

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd

同じリソース ID の視覚的な表現を次に示します。

Azure Cosmos DB アカウントのリソース ID。キーと値のペアは別々の行に分割されます。

このアカウントにデータベースを追加する場合は、子リソースの種類 sqlDatabases を使用します。 FlightTests という名前のデータベースを Azure Cosmos DB アカウントに追加して、子リソース ID を見てみましょう。

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd/sqlDatabases/FlightTests

視覚的には次のように表示されます。

Azure Cosmos DB データベースの子リソース ID。キーと値のペアは別々の行に分割されます。

複数のレベルの子リソースを使用できます。 2 つのレベルの子を持つストレージアカウントを示すリソース ID の例を次に示します。

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.Storage/storageAccounts/secrettoys/blobServices/default/containers/glitterspecs

同じリソース ID の視覚的な表現を次に示します。

BLOB コンテナーを持つストレージアカウントの子リソース ID。キーと値のペアは別々の行に分割されます。

このリソース ID には、いくつかのコンポーネントがあります。

secrettoys まではすべて親リソース ID です。
blobServices は、リソースが blobServices という子リソースの種類内にあることを示します。

Note

自分で blobServices リソースを作成する必要はありません。ストレージアカウントを作成すると、Microsoft.Storage リソースプロバイダーによってこのリソースが自動的に作成されます。この種類のリソースは、暗黙的なリソースと呼ばれることもあります。これらはかなり珍しいものですが、Azure 全体に存在します。
default は blobServices 子リソースの名前です。

Note

場合によっては、子リソースの 1 つのインスタンスだけが許可されます。この種類のインスタンスはシングルトンと呼ばれ、多くの場合、default という名前が付けられています。
containers は、リソースが containers という子リソースの種類内にあることを示します。
glitterspecs は BLOB コンテナーの名前です。