Till now, we have seen multiple features from Azure Bicep. In this article, we can understand what are modules and how they can be used while authoring the bicep files.

What are modules ?

Basically every bicep file is a module. A bicep file is basically transpiled into a JSON template. And every ARM template (i.e. JSON template) is a module. Both these types of files can be imported as modules in a bicep file.

Why to use modules ?

Modules help to keep the code maintainable. It also helps in increasing the reusability of the code. We can break creating the resources into multiple bicep files. Then, every application has needs for different resources, some resources may need to be created one for each application, some resources may be specific to applications and some resources may be shared resources.

Based on infrastructure / environment / application needs, the bicep files can be composed from the existing modules. This will also help to reduce the duplication of the code, by keeping the code at one place.

To share modules with other people in your organization, create a template spec, public registry, or private registry. Template specs and modules in the registry are only available to users with the correct permissions.

Multiple levels of nesting of modules should be kept to minimal (or I would say, it shoudl be avoided). It generally would make debugging very difficult if something goes wrong. It may be good idea to deploy multiple templets, instead of deploying a single template with nested modules.

What is the syntax to trigger a module ?

The code snippet given below shows how a module can be triggered. We need to use module keyword, we need to specify the module path (either local or remote) and we also need to specify the parameters.

The code snippet given below shows the syntax for including a module. The included module can either be deployed to the same target scope or it can be deployed to another scope. Also, we can specify the conditional logic using the if keyword, as shown in the code snippet given below.

Demo

We already have created a file, first.bicep. As per definition of module, this bicep file is also a module. For ready reference, the bicep file is shown in the code snippet given below.

Now, let’s add another bicep file (module-demo.bicep) in the same directory. This bicep file would reference the above mentioned file. In this file, we are going to provide only two parameter values – the environment name and storage account name.

Then we can can right click on the new bicep file and select option to deploy it. I am assuming the file is opened in Visual Studio Code and you have Bicep extension installed.

Once deploy option is selected we can go through the wizard to specify subscription, resource group and do not select any parameters file as it is not needed now. The deployment should be successful and if you browse storage accounts in the portal, you should be able to view the newly created storage account.

I hope this article provides sufficient information about bicep modules to get you started. Let me know your thoughts.