Using Bicep Linter Rules to control allowed resource API versions

Linter rules are a very powerful feature of the Bicep Infrastructure as Code language for Azure. Based on Linter rules, you can check your Bicep templates for syntax errors and best practice violations. Complying with coding standards improves your overall Bicep template quality.

Linter rules were introduced in version 0.4. That already seems like ages ago, but I remember that release coming out as I was working on my Bicep book at the time.

3 weeks ago, Bicep version 0.17.1 was released. Amongst other features and improvements, this version also introduces a new linter rule update. MaxAgeInDays configuration is now added to be used with the use-recent-api-versions linter rule.

The property does what it says, the property MaxAgeInDays allows you to specify how old (how many days) an API version is allowed to be in order to be able to use it. This allows you to put restrictions on the maximum age of API versions in your code. It is always recommended to use the most recent API versions for your resource declarations, but sometimes you might need to allow older API versions, or you might want to enforce a certain API age.

Time to upgrade! The easiest way to upgrade is to run the following command:

az bicep upgrade

The sample below shows how to use the new property.

Simply add the maxAllowedAgeInDays property to your use-recent-api-versions linter rule and provide the number of days as an integer. The default value is 730 days, which is equal to 2 years.

Providing a 0 means the apiVersion must be the latest (non-preview) version, or the latest preview version if there are only previews versions available at that point in time.

Based on the level of the linter rule, a Bicep Template using an ‘oudated’ API version will now get a warning as shown below which still allows you to build the template.

Or an error as shown below, which prevents you from building the template.

The flexibility to be able to configure the allows API versions is a great asset in your Bicep toolbox!

p.s. Microsoft Bing Image Creator Powered by Dall-E created the header image by simply asking "Bicep combined with computer programming", how cool is that!?

Azure Bicep public registry

 

One of the great benefits of Bicep Infrastructure is Code is reusing your code. Leveraging modules within Bicep is the perfect example of that. By using these features of Bicep, you can write reusable code that can be shared and used across multiple deployments. This can save time and effort and help ensure consistency across your Azure resources.

Some examples on how to reuse your code are:

- Parameters: Bicep allows you to parameterize your code so you can define parameters that can be passed in when the code is deployed. This makes it easy to reuse code with different configurations or environments. For example, you might define a parameter for the name of a Vnet, which can be passed in when the code is deployed in different environments.

- loops: Bicep allows you to use loops to create multiple instances of a resource. This is very useful when you need to create multiple resources with similar configurations. For example, you might use a loop to create multiple virtual machines

To me, the most useful example of reusability within Bicep in using Modules. Bicep allows you to create reusable modules that contain a definition of one or more Azure resources. You can define a module once and then reuse it in multiple Azure deployments. Modules can be stored in a separate Bicep file, which makes it easy to share them with others, for example by placing them in registries or template specs.

You might already be familiar with the concept of private registries based on Azure Container Registry (ACR) resources in Azure. You can store Bicep Modules inside in ACR and share those within your team, company, or to anyone who you provide access. To process to create an ACR and add your Bicep modules is very straight forward and explained here: Create private registry for Bicep module — Azure Resource Manager | Microsoft Learn.

But did you know that Microsoft is also continuously working on expanding modules inside their Public Registry? This Public Registry is based on Microsoft Container Registry (MCR).

This is the new location where you can find all Bicep modules provided in the public registry

aka.ms/br-module-index

These are nicely ordered and easy to navigate:

Contributing to these modules is currently limited to Microsoft employees, but you can propose new modules or report bugs by opening an issue via GitHub.

Looking to get started with Bicep? I published a book on how to get started, which covers reusing your code and much more! Available on Amazon in Kindle, Paperback, and hard copy format!