Consuming Bicep modules from a private registry

4 mins read

Learn how you can easily consume Bicep Modules stored in a private registry.

💪Consuming Bicep modules from a private registry

In a previous article, we reviewed how you could share Bicep files within your organization using a private registry. This article will examine how you can consume a Bicep module published in a private registry.

Pre-requisites:

Bicep installed in your local machineA private registry in your Azure subscriptionA Bicep file(module) in the private registry

The solution will consist of the following files:

main: This fill will contain the definition of the parameters, a resource group, and will consume two modules.appService: This is a Bicep module that will be consumed from a local sourceappServicePlan — This is a Bicep module that will be consumed from the private registry.

Consuming a Bicep module from a private registry

In the following example, we will create a web application using Bicep and consume a Bicep module from a private registry.

To consume a module, we provide the name for the Azure container registry and a path to the module as shown below:

module <Your-Module-Symbolic-Name> ‘br:<registry-name>.azurecr.io/<file-path>:<tag>’ = {

First, we will pull the information from the Bicep module in the private registry; in this case, the name of the private registry is:

azinsidercr.azurecr.io/bicep/modules/app-service-plan:v1.0

You can get the information from your private registry using the Azure Portal or Azure PowerShell, or Azure CLI.

Bicep private registry

The next step is to define our main.bicep file. This file will contain the definition of parameters and resources.

https://medium.com/media/80097f4d4389981c9c69c68586aba516/href

Note we consume two modules: one is consumed from the private registry, and the second module is consumed from a local Bicep file.

When referencing a module in a registry, the Bicep extension in Visual Studio Code will perform calls using the bicep restore command. This command gets copies of all the required modules from the registry and stores those copies in a local cache.

Now we will define the appService.bicep module. The code below shows the definition of this Bicep module.

param appServicePrefix string
param location string = ‘eastus’
param appServicePlanId stringresource appService ‘Microsoft.Web/sites@2021-01-15’ = {
name: ‘${appServicePrefix}site’
location: location
properties:{
siteConfig:{
linuxFxVersion: ‘DOTNETCORE|3.0’
}
serverFarmId: appServicePlanId
}
}
// Set an output which can be accessed by the module consumer
output siteURL string = appService.properties.hostNames[0]

Now we will proceed to deploy the main.bicep file using the command below:

New-AzDeployment -Name $deploymentName -TemplateFile .main.bicep -Location eastus

Note we target to a subscription scope. Why? We will create a new resource group and then deploy the resources in the new resource group.

The image below shows the deployment output:

Deployment output.

You can also go to the Azure Portal and verify that the new resource group has been provisioned along with the App Service Plan and the App Service as shown in the image below:

Azure Portal — Deployment

Working with modules in Bicep is straightforward, and you can easily reuse modules for different deployments.

👉 Join the AzInsider email list here.

-Dave R.

đź’ŞConsuming Bicep modules from a private registry was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leave a Reply

Your email address will not be published.

Follow Us