Skip to content
adatum
  • Home
  •  About adatum
  •  Learn Azure Bicep
  •  SCOM Web API
Azure Bicep

Speaking at Nordic Infrastructure Conference

  • 18/05/202218/05/2022
  • by Martin Ehrnst

Nordic Infrastructure Conference is back! This is NICs tenth anniversary, and I am glad to say I am once again able to speak at this conference.

This year I have one session on Azure Bicep, where I will go through (almost) everything you need to know in order to be productive + some bonus tricks and real world scenarios from working with Bicep.
As always with NIC, there’s less slides and more demos!

Share this:

  • LinkedIn
  • Twitter
  • Reddit
Azure Bicep

Share Bicep modules with private registry

  • 08/11/202106/11/2021
  • by Martin Ehrnst

A common problem for many organizations is to share and consume infrastructure templates. Many ended up with a storage account in Azure, but that had some limitations around versioning and sharing of secrets. Directly consuming templates from a Git repository is another option. However, that’s not exactly problem-free either. For example, what happens if a colleague makes changes, and you reference the template without knowing what has changed. In the best case, a missing parameter will fail your pipeline. In the worst case, you have downtime.

The key concept of having Bicep modules in a common store is for everyone inside your organisation to use these modules when they’re provisioning infrastructure. Picture this scenario. Multiple development team is often using the same type of resource, like Azure SQL, Azure Functions, storage accounts, etc. Your organization likely have a few governance rules applied. Like tagging strategy, allowed SKU, different configuration for test and production and so on. Pre-created and easially consumable modules taking care of this is what you need. Azure Container Registry for Bicep files is now available.

Azure Bicep private registry

With Azure bicep version 0.4.1008 you have a built-in option to publish your Bicep modules to a private registry. The private registry is not a new resource type, in fact, you are uploading your Bicep files to Azure Container Registry which allows you to leverage versioning which will make sure you do not break templates for everyone each time people make changes. Once your Bicep module is uploaded to ACR everyone with permission to pull images can use your modules.

Azure bicep private registry

Upload Bicep modules to ACR

A shared bicep module is used in the same way as a local module, but instead of the local path, you specify the URL and version of the file within the registry. More on that later.

Assuming you already have one Bicep module or a set of them, you only need to provision a container registry. To push the “image” you need acrPush permissions and to consume you need acrPull. Below is the syntax used for uploading a bicep file to ACR.

az bicep publish storage.bicep --target br:exampleregistry.azurecr.io/bicep/modules/storage:v1

I am using this code base against my existing registry, so my command to upload is as follows;

bicep publish .\Bicep\3.modules\sql.bicep --target "br:acrbicepehrnst.azurecr.io/modules/azuresql/sql:v0.1"

No response is given on successful upload, but to make sure everything is alright we can confirm with this PowerShell command, which will list all repositories in your registry.

upload Bicep module to Private registry
Get-AzContainerRegistryRepository -RegistryName acrbicepehrnst

Using modules from the registry

Including modules from a private registry is as easy as using local modules. With Bicep extension enabled in VSCode, you also get validation of the remote modules.

pssst… if you by any change use EMACS you can have the same through LSP and Bicep Lang server

upload Bicep module to Private registry - syntax highlight
var tags = {
  'owner': 'Martin Ehrnst'
  'purpose': 'Bicep demo'
}

module SQL 'br:acrbicepehrnst.azurecr.io/modules/azuresql/sql:v0.1' = {
  name: 'sqlDeploy'
  params: {
    databaseName: 'moduletest'
    dbAdId: '8776fb6e-5de0-408c-be03-c17a67b079d0'
    dbAdLoginName: 'name@company.com'
    env: 'prod'
    tags: tags
  }
}

Summary

In this post I have showed you the core concept, how you upload and how you consume the modules. To me this is only half the story. In my next post I will go through how we can put everything inside a pipeline and add a better versioning to the modules.
Azure Bicep private registry is probably here to stay. Upuntil now it is the best solution to share infrastructure templates within an organization.

Share this:

  • LinkedIn
  • Twitter
  • Reddit
Azure Bicep

Azure Bicep modules, variables, and T-shirt sizing

  • 02/07/202102/07/2021
  • by Martin Ehrnst

With infrastructure as code, we strive to parameterize, re-use as much as possible, and make our code as modular as possible. As your application infrastructure grows, it might become too much work to have everything decoupled and modular. But for ad-hoc deployments, “bread and butter” resources we can make things very agile. Azure Bicep modules, variables and parameters are here to help

At the moment I am collaborating on rewriting some of our infrastructures to use Azure Bicep. This infrastructure is set up multiple times for different environments like test and production, but they are mostly identical when it comes to the resources used. Therefore all resources now exist as Azure Bicep Modules. The modules themselves handle the different configurations based on the environment being provisioned. test environments using a smaller number of nodes in the AKS for example.

Bicep Modules

Bicep modules are here to help us abstract the complexity of our deployment templates. Make it easier to re-use and share the templates across environments, applications, and teams. It is totally up to you how you create and structure your modules, as all .bicep files can be used as a module. You can also include as many individual resources you like. In the end, bicep will combine all module files and create a nested deployment.

If you have ever worked with nested deployments in ARM templates, you will be glad Bicep modules now exist.

Below I have added a fairly simple module that will provision a storage account with the inputted storageName parameter. In my main.bicep file I will ask for this parameter, and pass it down to my module. The main file is actually more complex than the module file, as its also provisioning a resource group that the storage account will be in.

Environment sizing with Bicep modules

With the above example in mind. How can we move from that to a more complex and re-usable scenario? First of all, we need to accept a few more inputs in our main file. But the complexity will need to be handled inside our storage account module. Our goal is to re-use the module regardless of the environment being provisioned. Therefore we need to handle scenarios like name, storage SKU, and so on. I use a storage account as an example here, but the concept is the same regardless of resource types.

Configuration variables

To extend my module’s modularity (sorry) I am expanding the required input parameters, but I also added an object variable to hold my configuration settings for the different environments. Looking at the storage account module now, you can see the new variable, and also how I get the data from within the object variable by using the inputted name for environment.

I also added more smartness to the module, by using the toLower function and concatenating the storage account name with a unique string based on our resource group. This way we move the complexity of naming the storage account from the user to the code it self. Storage accounts only accepts lower case in its name, and it needs to be globally unique.

The main file changed slightly as well. As you can see, I added environment parameter, with two allowed values, prod and test. I also have a tags variable that I pass down to the module as input parameter together with the environment. The resource group name now has environment represented in the name as well.

Tags and naming conventions is of course very domain specific, but this example show how you can use the different functions available in Azure Bicep to create a more elastic code for your specific environments where resource types is shared.

Summary

In the above examples, I showed how you can use Bicep Modules, parameters and variables to re-use your templates cross multiple environments with different properties. If you like me, have multiple environments that on the technology side is identical, but properties like network addresses, virtual machine families, etc differs. You can use modules and custom variable to handle it.

Stay tuned for more Bicep posts in the near future.

Share this:

  • LinkedIn
  • Twitter
  • Reddit

Posts navigation

1 2 3

Popular blog posts

  • Azure Application registrations, Enterprise Apps, and managed identities
  • SCOM 1801 REST API Interfaces
  • Creating Azure AD Application using Powershell
  • Automate Azure DevOps like a boss
  • Access to Blob storage using Managed Identity in Logic Apps - by Nadeem Ahamed

Categories

Automation Azure Azure Active Directory Azure Bicep Azure DevOps Azure Functions Azure Lighthouse Azure Logic Apps Azure Monitor Azure Policy Community Conferences CSP Monitoring DevOps Guest blogs Infrastructure As Code Microsoft CSP MPAuthoring OMS Operations Manager Podcast Powershell Uncategorised Windows Admin Center Windows Server

Follow Martin Ehrnst

  • Twitter
  • LinkedIn

RSS feed RSS - Posts

RSS feed RSS - Comments

Microsoft Azure MVP

Martin Ehrnst Microsoft Azure MVP
Adatum.no use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Cookie Policy
Theme by Colorlib Powered by WordPress