Using Bicep Modules in the Azure Bicep Registry⌗

Introduction⌗

Bicep is a domain-specific language (DSL) designed to simplify Azure resource deployments. It offers a more intuitive syntax and a streamlined development process compared to traditional ARM templates.

The Azure Bicep Registry (ABR) further enhances this experience by allowing developers to store, reuse, and share Bicep modules. This helps teams standardize configurations and automate deployments across various projects.

In this post, we’ll dive into the advantages of using the Azure Bicep Registry, how to utilize pre-built modules, and how to publish and share your own for use within your organization. What is the Azure Bicep Registry?

The Azure Bicep Registry acts as a centralized hub where developers can store Bicep modules for reuse across different projects. These modules can range from individual resource definitions to entire solutions. By storing them in the registry, you can easily incorporate these modules into new Bicep files, eliminating the need to duplicate code.

Here are a few key benefits of the Azure Bicep Registry:

Reusability: Once a module is in the registry, you can reuse it across multiple projects.
Versioning: The registry supports versioning, so you can reference specific module versions.
Collaboration: Share modules within your organization or even make them available to the public.
Consistency: Reusing modules ensures a standardized deployment process across projects.

For setting up a Bicep Registry, please refer to the official documentation:

Create private registry for Bicep modules

Using Pre-built Modules from the Azure Bicep Registry⌗

A major perk of the Bicep Registry is access to pre-built modules. Azure offers a variety of these modules, covering common resources such as virtual networks and storage accounts.

You can quickly pull these into your Bicep files using a simple reference. Example: Deploying a Virtual Network Module

Suppose you need to set up a virtual network (VNet) in Azure. Instead of manually defining the resource, you can reference a pre-built VNet module from the registry.

Find the appropriate module, either from the public Azure Bicep Registry or a private one.
Use the following syntax to reference the module:

module vnet 'br/public:vnet:1.0.0' = {
  name: 'myVnet'
  params: {
    addressPrefix: '10.0.0.0/16'
    location: 'East US'
  }
}

In this example, the reference br/public:vnet:1.0.0 points to the public registry and the VNet module version 1.0.0.

The params block specifies parameters such as the address range and location. When you deploy this file, the module will automatically be pulled from the registry, saving you time by reusing an established configuration.

Not only can you use pre-built modules, but you can also create and share your own. Publishing your custom modules is particularly useful when managing large infrastructures or multiple environments like development, staging, and production.

Reusable modules help maintain consistency across these environments.

Steps to Publish a Bicep Module⌗

Prepare Your Module: First, create the Bicep file that you want to package as a module.
Login to Azure CLI
Publish the Module
Use the Module

Prepare Your Module: First, create the Bicep file that you want to package as a module.

Here’s an example of a module for a storage account:

@minLength(3)
@maxLength(24)
param storageAccountName string

param location string = resourceGroup().location

resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

Login to Azure CLI: Ensure you’re logged in to your Azure account by running

az login

Publish the Module: Use the Azure CLI to publish the module to the registry:

az bicep publish --file ./storage-account.bicep --target br:MyRegistry/myModules/storageAccount:1.0.0

Here, MyRegistry is the name of your registry, and myModules/storageAccount:1.0.0 defines the module’s path and version.

Use the Module: After publishing, you can reference it in any Bicep file:

module storageAccount 'br:MyRegistry/myModules/storageAccount:1.0.0' = {
  name: 'myStorage'
  params: {
    storageAccountName: 'mystorageacct'
    location: 'East US'
  }
}

Versioning and Updating Modules⌗

Versioning is essential for managing updates. If you need to make changes, simply increment the version number and publish the module again:

az bicep publish --file ./storage-account.bicep --target br:MyRegistry/myModules/storageAccount:1.1.0

Existing projects that use version 1.0.0 won’t be impacted, while new projects can adopt version 1.1.0.

To share modules, you can either set up a private registry or make them public. Azure supports various authentication methods to control access. For a private registry, team members will need the necessary permissions to pull modules:


az role assignment create --assignee <user_or_group> --role Contributor --scope /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerRegistry/registries/{registryName}

For public registries, you can share modules with the broader Azure community.

Conclusion⌗

The Azure Bicep Registry offers a powerful way to manage, share, and reuse Bicep modules across projects.

Whether you’re using pre-built modules or publishing your own, it enables efficient, modular deployments, promoting consistency and collaboration.

Embrace Bicep and its registry to modernize your deployment practices and maintain a cohesive cloud infrastructure across your organization.

Using Bicep Modules in the Azure Bicep Registry

Table of Contents