Publish Bicep modules to registries with the source.

Bicep offers the ability to store your modules in a registry in Azure. This is based on storing them in an Azure Container Registry (ACR).

This approach offers several advantages, especially regarding DevOps practices, version control, shared access, and reusability.

Let’s consider the module below, which creates several Azure Virtual Desktop (AVD)- related resources, such as host pools, workspaces, and application groups.

Publishing your modules to an ACR is quite easy. In this example, I’ll use Azure CLI. First, create an ACR in case you don’t have one yet. Since an ACR is just another resource in Azure, you can use Bicep to create one, as shown below.

Now use the publish command, provide the bicep module you want to publish, and provide the target location, the ACR, and where you want to store it.

The result looks like the below: a container repository is visible under repositories.

You can now start using modules inside your Bicep templates. In the example below, I’m referencing the module stored in the ACR that creates the Azure Virtual Desktop resources.

Today, you already have the ability in VScode to view the source of the module; simply hit F12, and you are provided with the source.

This is, however, the transpiled version based on ARM Templates in JSON. Wouldn’t you rather want to see the Bicep module instead? You now can.

There is an experimental feature called publishSource that you can add to your bicepconfig.json. Afterward, you can add the option — with-source to your publish command.

Based on the header image of this article, what country will I be visiting this month? Reply to this post with your answer to win a copy of my book!

When you now press F12 you can see the original Bicep module containing our AVD resources! 💪 When you hover over the file name, you can see the source location, the ACR, module name, and version.

This makes working with Aure Container Registries a lot more convenient!

📖 Looking to get started with Bicep? I authored and published the book Getting started with Bicep: Infrastructure as code on Azure

Exporting and importing variables between Bicep files: compileTimeImports

 

Infrastructure as Code (IaC) has revolutionized how we manage and provision IT infrastructure. Azure’s adoption of this concept through Bicep, a domain-specific language, has made it easier and more efficient.

In case you’re (still) wondering what Bicep is, it is an open-source language developed by Microsoft for declaratively deploying Azure resources. It aims to simplify the authoring experience and provide a cleaner syntax compared to ARM templates. Bicep files are transpiled into ARM templates, making it a powerful yet user-friendly tool for Azure deployments.

In this blog, I cover how to use a feature (experimental) that allows you to export and import variables, user-defined functions, and user-defined types.

It has been in the Bicep builds for some time, but it’s a very useful feature, and I have never published on this before. Before you dive deeper into the functionality of exporting and importing variables between Bicep files, it’s important to highlight that this feature is currently experimental. To use this experimental feature of exporting and importing variables in Bicep, you need to enable it explicitly. This is done by modifying the bicepconfig.json. The configuration to add or modify is compileTimeImports, which should be set to true.

Now consider the Bicep module below. This module deploys a few Azure Virtual Desktop (AVD) resources like a host pool, application group, and workpace.

Note that you can use the @export() decorator. This makes the variable ‘prefix’ importable by other Bicep files or Bicep modules. As a result, we reuse the value without declaring it across multiple files. This is a simple example, but you can imagine adding multiple variables or even user-defined functions and user-defined types.

You can now use the exported variables in other Bicep files in a couple of different ways. To import a single value, use the import state as shown below. You use the keyword Import, followed by the name of the variable, followed by the source Bicep file. Super easy, right? You can now use the ‘prefix’ variable inside this Bicep file. In this example, we use it in line 23 to generate a name for the network interface.

If you want to import it using another name or alias, simply use the method below. You can now use the variable by referring to the alias you defined. In this case, ‘i_prefix’.

You can, of course, also import multiple variables at once using the code above by referring to them all individually.

Finally, an even easier way is to import all exported variables by using the ‘*’ sign as shown below. You can now use ‘imported’ as the name and specify the variable after the ‘.’ sign, and the Bicep VSCode extension even picks up on this, providing you with an auto-complete.💪

The great thing is you can also import inside .Bicepparam files in the same way. In the example below, I import the values and use them as values for my parameter files. If you are new to Bicepparm files, follow a previous article where I explain how this works.

It might seem like a simple feature, but to me, it is a super welcome addition to the language. It avoids declaring certain variables or types multiple times and improves reusing code. I like it, and the possibilities and use cases are endless! What do you think?

📖 Looking to get started with Bicep? I authored and published the book Getting started with Bicep: Infrastructure as code on Azure