Wednesday, May 24, 2023

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

No alt text provided for this image

The sample below shows how to use the new property.

No alt text provided for this image

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.

No alt text provided for this image

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

No alt text provided for this image

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!?

Sunday, May 7, 2023

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

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!

Monday, February 13, 2023

5 fun and easy ways to transition to Bicep and save time!

In you are into Infrastructure as Code for Azure, you probably have heard about Bicep by now, or maybe (hopefully) you're actively using it. If not, this blog post provides some guidance to help you with your personal transformation (or should I say transpilation 😊) towards Bicep. In other words, if you’ve been developing ARM Templates (JSON) a lot, here are some cool and fast ways to learn Bicep using VSCode.

Just in case you’ve never heard about Bicep, what is it in a nutshell? Bicep is like having a magic wand for Azure infrastructure as code. It's a new language that makes it super easy to create and manage Azure resources in a declarative manner. You simply write down what you want your Azure environment to look like, and Bicep takes care of the heavy lifting for you. It's like ordering a pizza, but instead of pizza, you get a fully configured Azure environment, and instead of a delivery guy, you have Bicep! Just wave your Bicep wand and poof, your Azure resources appear exactly as you specified.* * Full disclose I had ChatGTP write this fun description of Bicep! 😊

1. Decompile Right click any existing ARM Template based on JSON and simply select “Decompile to Bicep”. Within a second you are presented with the Bicep equivalent of your ARM Template. This is a super easy way of reverse engineering and learn Bicep. Note, decompile is always based on best effort. If the template can be decompiled, it will always result in a valid Bicep Template but might not be 100% optimized. It can however provide you with a great head start. In case you are wondering, yes you can also decompile using the Az CLI, PowerShell and the Bicep executable.

No alt text provided for this image

2. Paste JSON as Bicep If you have any existing JSON code in your clipboard, for example copied from any resource online, you can directly copy it as Bicep code in VSCode. How cool is that? 😊. With a flick of a wand (or rather, a paste into VSCode), your JSON code is transformed into beautiful, readable Bicep code.

No alt text provided for this image

It's important to note that this feature is currently in its experimental phase, and as such, may have limitations or unfinished elements.

No alt text provided for this image

3. Insert Resource To utilize this feature, you will need to follow these steps:

- Copy the resource ID of an existing resource within your Azure environment. - In your Bicep file, perform a right-click and select "Insert Resource" from the context menu. - Paste the copied resource ID into the designated field. - Upon executing these steps, the resource will be instantly available in Bicep, ready for use within your infrastructure as code deployment.

No alt text provided for this image

4. Local ARM Template (JSON) as a module If you have existing ARM Templates in JSON and, for whatever reason, don’t want to decompile to Bicep, you can also use an ARM Template as a module. Below is the syntax to use, this is the exact same syntax as Bicep modules. Very convenient and easy to use!

No alt text provided for this image

5. Template Spec as a module Similar to option 4, you can also leverage an ARM Template as a module directly from a Template Spec resource in Azure. Create a Template Spec resource in Azure, paste your ARM Template in there, and now you can reference it as a module as shown below.

No alt text provided for this image

To conclude If you are currently developing ARM Templates and it brings you everything you need, nothing is stopping you from continuing to use it, its fully supported. I’m not saying ARM Templates are bad and you must switch to Bicep. If you currently are using ARM Templates and you are struggling with the complexity and limitations…it's never too late to learn Bicep. And if you're already familiar with Visual Studio Code (VSCode), it's a great tool to get started with Bicep. VSCode offers a wide range of plugins and extensions that make it easier to write, debug, and deploy Bicep templates. You can use the VSCode IntelliSense feature to get suggestions and auto-completion as you type, making it easier to write correct Bicep code, including a way to visualize as you type. Bicep removes a lot of the syntax overhead of ARM Templates, providing clean coding experience, and also provides better options to reuse code based on modules and registries.

There is much more to the story of course. If you are interested in getting started with Bicep, I published a book to help you jump start on Bicep, posted lots of example code on my GitHub, and created a collection links to on demand sessions on Bicep that I (co)presented in the past.

Questions? Feel free to reach out via Twitter, LinkedIn, or E-mail!