Bicep 0.5 Released

Overview

On 2022/4/9, the long-awaited Bicep 0.5 was released, so I decided to try it out. The highlight of this update is the Bicep Public Registry^[1]. I'll try using it with an existing template.

Currently, the source for the public modules is available at Bicep Registry Modules. Although the number of modules is still small, I found a VNet module, so I tried integrating it into azure-bastion01.

Replacing with the VNet Module

Before the change, the VNet was defined using Bicep like this.

resource vnet 'Microsoft.Network/virtualNetworks@2020-06-01' = {
  name: virtualNetworkName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        addressPrefix
      ]
    }
    subnets: subnets
  }
}

I'll replace this with the Virtual Networks module (below), which is an example of a public module with minimal parameters. Although there are some clever bits like ensuring the module name doesn't collide, it feels like it should mostly work just by swapping it out.

module vnet 'br/public:network/virtual-network:1.0' = {
  name: '${uniqueString(deployment().name, 'WestEurope')}-minvnet'
  params: {
    name: virtualNetworkName
    addressPrefixes: [
      '10.0.0.0/16'
    ]
  }
}

When I ran this through Bicep, I immediately got an error. How disappointing.

$ bicep build ./vnet.bicep
vnet.bicep(10,13) : Error BCP192: Unable to restore the module with reference \
  "br:mcr.microsoft.com/bicep/network/virtual-network:1.0": The module does not exist in the registry.
vnet.bicep(22,26) : Error BCP062: The referenced declaration with name "vnet" is not valid.

The error is The module does not exist in the registry. It seems the module is missing from the repository, so I'll check if it exists in MCR. Whenever I encounter this type of issue, I use the methods described in the Microsoft Container Registry (MCR) documentation to investigate. It's not particularly convenient, but it gets the job done.

First, I'll check if it's actually registered in the repository. It seems it is.

curl -s https://mcr.microsoft.com/v2/_catalog | grep bicep
    "bicep/samples/hello-world",
    "bicep/samples/array-loop",
    "bicep/compute/availability-set",
    "bicep/deployment-scripts/import-acr",
    "bicep/network/virtual-network",

In that case, the tag might be different, so I'll check the tags. It turns out that 1.0 doesn't exist, and it's actually 1.0.1.

$ curl -s https://mcr.microsoft.com/v2/bicep/network/virtual-network/tags/list
{
  "name": "bicep/network/virtual-network",
  "tags": [
    "1.0.1"
  ]
}

I'll use that and change the module path to 'br/public:network/virtual-network:1.0.1'. With the subnet definition included, it looks like this (below).

module vnet 'br/public:network/virtual-network:1.0.1' = {
  name: '${uniqueString(deployment().name, location)}-vnet'
  params: {
    name: virtualNetworkName
    location: location
    addressPrefixes: [
      addressPrefix
    ]
    subnets: subnets
  }
}

Adjusting the Subnet Definition

There is one more change. In this VNet module, the format accepted for subnets is slightly different from native ARM templates. Elements that were originally structured like properties.addressPrefix are now written by omitting properties and moving the property up one level. While this depends on the implementation of the VNet public module, I suspect this is being standardized as a design pattern. This point is unconfirmed.^[2]

"name": "subnet",
"properties": {
  "addressPrefix": "10.1.0.0/24",

In the case of the VNet public module:

"name": "subnet",
"addressPrefix": "10.1.0.0/24",

You can deploy it by making corrections like this.

Conclusion

While there are some stumbling blocks for first-time users, perhaps because the documentation hasn't quite caught up yet, I feel it will become quite usable with improvements such as being able to browse the repository through the VSCode extension. Since the number of modules is still small, I'm looking forward to seeing more added. Until then, we will likely continue to make good use of the Common Azure Resource Modules Library.
I have also updated my personal devcontainer to 0.5.6.

脚注

1. The official documentation for the Public module registry is available at docs.microsoft.com/Public module registry. GitHub Bicep #62 and GitHub Bicep #2128 might also be useful references.

2. Discussions regarding flattening (lifting up?) items inside properties seem to be happening around here: GitHub Bicep #2052. Naturally, comments like "names might collide" are appearing.