Bicep を使って仮想ネットワーク リソースを作成する
多くの Azure デプロイでは、ネットワーク リソースをデプロイして構成する必要があります。 Bicep を使って、Azure ネットワーク リソースを定義できます。
仮想ネットワークとサブネット
種類が Microsoft.Network/virtualNetworks のリソースを作成して、仮想ネットワークを定義します。
subnets プロパティを使用してサブネットを構成する
仮想ネットワークにはサブネットが含まれます。サブネットは、仮想ネットワーク内の IP アドレスの論理グループです。 Bicep でサブネットを定義するには、仮想ネットワーク リソースの subnets プロパティを使用する方法と、型 Microsoft.Network/virtualNetworks/subnets の子リソースを作成する方法の 2 つの方法があります。
警告
サブネットを子リソースとして定義しないようにします。 この方法では、後続のデプロイ中にリソースのダウンタイムが発生したり、デプロイに失敗したりする可能性があります。
次の例のように、仮想ネットワーク定義内でサブネットを定義するのが最適です。
次の例は、より大きな例の一部です。 デプロイできる Bicep ファイルについては、完全なファイルを参照してください。
param location string = resourceGroup().location
var virtualNetworkName = 'my-vnet'
var subnet1Name = 'Subnet-1'
var subnet2Name = 'Subnet-2'
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-11-01' = {
name: virtualNetworkName
location: location
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
subnets: [
{
name: subnet1Name
properties: {
addressPrefix: '10.0.0.0/24'
}
}
{
name: subnet2Name
properties: {
addressPrefix: '10.0.1.0/24'
}
}
]
}
resource subnet1 'subnets' existing = {
name: subnet1Name
}
resource subnet2 'subnets' existing = {
name: subnet2Name
}
}
output subnet1ResourceId string = virtualNetwork::subnet1.id
output subnet2ResourceId string = virtualNetwork::subnet2.id
どちらの方法でもサブネットを定義して作成することができますが、重要な違いがあります。 子リソースを使用してサブネットを定義すると、Bicep ファイルが初めてデプロイされた場合、仮想ネットワークがデプロイされます。 その後、仮想ネットワークのデプロイが完了すると、各サブネットがデプロイされます。 この順序付けは、Azure Resource Manager が個々のリソースを個別にデプロイするために起こります。
同じ Bicep ファイルを再デプロイすると、同じデプロイの順序付けが起こります。 ただし、subnets プロパティが実質的に空なので、仮想ネットワークは、サブネットの構成なしにデプロイされます。 その後、仮想ネットワークが再構成された後、サブネット リソースが再デプロイされ、各サブネットが再確立されます。 状況によっては、この動作により、デプロイ中に仮想ネットワーク内のリソースの接続が失われることがあります。 その他の状況によっては、Azure により仮想ネットワークの変更が妨げられ、デプロイが失敗することがあります。
サブネット リソース ID にアクセスする
多くの場合、サブネット リソース ID を参照する必要があります。
subnets プロパティを使用してサブネットを定義する場合、existing キーワードを使ってサブネットへの厳密に型指定された参照を取得し、サブネットの id プロパティにアクセスできます。
次の例は、より大きな例の一部です。 デプロイできる Bicep ファイルについては、完全なファイルを参照してください。
param location string = resourceGroup().location
var virtualNetworkName = 'my-vnet'
var subnet1Name = 'Subnet-1'
var subnet2Name = 'Subnet-2'
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-11-01' = {
name: virtualNetworkName
location: location
properties: {
addressSpace: {
addressPrefixes: [
'10.0.0.0/16'
]
}
subnets: [
{
name: subnet1Name
properties: {
addressPrefix: '10.0.0.0/24'
}
}
{
name: subnet2Name
properties: {
addressPrefix: '10.0.1.0/24'
}
}
]
}
resource subnet1 'subnets' existing = {
name: subnet1Name
}
resource subnet2 'subnets' existing = {
name: subnet2Name
}
}
output subnet1ResourceId string = virtualNetwork::subnet1.id
output subnet2ResourceId string = virtualNetwork::subnet2.id
この例では、完全なサブネット リソースを定義する代わりに、existing キーワードを使用してサブネット リソースにアクセスするため、前のセクションで説明したリスクはありません。
また、existing と scope キーワードを組み合わせて、別のリソース グループ内の仮想ネットワークやサブネット リソースを参照できます。
ネットワーク セキュリティ グループ
ネットワーク セキュリティ グループは、サブネットまたはネットワーク インターフェイスからのトラフィックの受信フローと送信フローを制御するルールを適用するために頻繁に使用されます。 Bicep ファイル内で多数のルールを定義し、複数の Bicep ファイル間でルールを共有すると、煩雑になる可能性があります。 複雑なネットワーク セキュリティ グループか大規模なネットワーク セキュリティ グループを使用する場合は、共有変数ファイル パターンの使用を検討してください。
プライベート エンドポイント
プライベート エンドポイントは、承認する必要があります。 場合によっては、承認が自動的に行われます。 ただし、他のシナリオでは、使用する前にエンドポイントを承認する必要があります。
プライベート エンドポイントの承認は操作になるので、Bicep コード内で直接実行することはできません。 ただし、デプロイ スクリプトを使用して操作を呼び出すことができます。 あるいは、パイプライン スクリプトなど、Bicep ファイルの外部から操作を呼び出すことができます。