リソースグループを作成するために（あるいはモジュール化）

昨日少しだけ調べたところ、スコープをサブスクリプションと定義することでリソースグループの作成が可能なことが分かっている。ただ、サブスクリプションスコープだとリソースグループ内のリソースが作れないため、下記のようなスコープの分割が必要になる。

つまり昨日作ったファイルをモジュールとして、サブスクリプションスコープでリソースグループの作成を行った後に、作成したリソースグループをスコープとしてVNET作成モジュールを呼び出す、という形になりそうだ。
ということで今日は左側のファイルを作っていくことにする。

スコープの指定

これは特に考えることはなく、MSLearnの通りでよさそう。

targetScope = 'subscription'

リソースグループの作成

これは昨日作ったけど消したものが使えそう。リソースグループ名だけ変更。

param location string = 'japaneast'

resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-biceptest-02'
  location: location
}

モジュールの呼び出し

まずはドキュメントを読んでみよう。

モジュールを定義して、作成したリソースグループをスコープとして与えればよさそう。ということで下記。

module modVnet 'vnet.bicep' = {
  name: '${deployment().name}-vnetDeploy'
  scope: rg
  params: {
    location: location
  }
}

・前回のファイルは「vnet.bicep」とリネーム。
・仮想ネットワークの場所はリソースグループと同じ場所になるように指定（vnet.bicep側の指定は既定値扱いになる）

デプロイしてみる

右クリックメニューの「Deploy Bicep File…」を選択して、昨日と同じ流れでサインインやデプロイ名などを指定する。

デプロイできてそう。ポータルも確認。

ちゃんと出来ている。
アドレス空間のところで警告が出ているのは、rg-biceptest-01のネットワークと同じアドレス空間で作ってしまったので01と02のネットワークはピアリング出来ないよということ。

まとめ

今回はスコープの指定とモジュール化を行い、リソースグループ作成＋その中にVNET作成を行った。モジュール化はこのレベルだと外から呼び出すだけなのでかなり容易だが、本格的にはもう少し考えた方がよさそうなので、別記事で掘り下げる予定。

コード

main.bicep

targetScope = 'subscription'

param location string = 'japaneast'

resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-biceptest-02'
  location: location
}

module modVnet 'vnet.bicep' = {
  name: '${deployment().name}-vnetDeploy'
  scope: rg
  params: {
    location: location
  }
}

vnet.bicep

targetScope = 'resourceGroup'

@description('モジュール化に伴い、japaneast指定は既定値扱いとなる')
param location string = 'japaneast'

resource hubvnet 'Microsoft.Network/virtualNetworks@2021-01-01' = {
  name: 'vnet-hub-01'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '172.16.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'snet-step-01'
        properties: {
          addressPrefix: '172.16.0.0/24'
        }
      }
      {
        name: 'AzureBastionSubnet'
        properties: {
          addressPrefix: '172.16.1.0/24'
        }
      }
      {
        name: 'GatewaySubnet'
        properties: {
          addressPrefix: '172.16.2.0/24'
        }
      }      
    ]
  }
}

resource spokevnet01 'Microsoft.Network/virtualNetworks@2021-01-01' = {
  name: 'vnet-spoke-01'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '172.17.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'snet-webapp-01'
        properties: {
          addressPrefix: '172.17.0.0/24'
        }
      }
    ]
  }
}

resource peer_hub2spoke 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2021-01-01' = {
  name: 'peer_hub2spoke'
  parent: hubvnet
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
    remoteVirtualNetwork: {
      id: spokevnet01.id
    }
  }
}

resource peer_spoke2hub 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2021-01-01' = {
  name: 'peer_spoke2hub'
  parent: spokevnet01
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
    remoteVirtualNetwork: {
      id: hubvnet.id
    }
  }
}

おまけ（Azureの階層について）

サブスクリプションやリソースグループなどのAzureの階層構造は既知として進めてしまったが、一応ここで補足しておく。
Azureでは下記のようにサブスクリプションとリソースグループは階層構造になっており、親子の関係がある。

・サブスクリプションは請求書の単位
・リソースグループは必ずいずれか1つのサブスクリプションに所属する
・リソースは必ずいずれか1つのリソースグループに所属する
・管理グループはサブスクリプションをまとめるもの（使わないこともあり、その場合はサブスクリプションが最上位）

これとは別にテナントという単位もある。テナントはAzureにサインインしているドメイン（だいたいの場合、xxxxx.onmicrosoft.com）のこと。
上記の図では一番外の枠がテナントにあたり、テナント内で複数の管理グループを持つことができる。

ざっくりイメージだと、ある会社がAzureを使っているとして
テナント：会社
管理グループ：本部（権限などを複数の部署をまとめて管理する）
サブスクリプション：部署（請求先の単位）
リソースグループ：チームやシステム（用途）で分ける
といった感じになると思う。