Banner
Reading Time: 3 minutes

Hey everyone! Hope everyone is safe and healthy 🙂

It’s been a while now, that I’ve trying to make the switch from ARM templates to Bicep language. My daily routine nowadays involves the use of authoring tools such as VSCode and azure resource deployments using IaC with Bicep language. To be honest, I come from a ‘SysEngineer’ world, where I am struggling to find my way through the future world of CloudOps. To be honest, I totally love it because it got me to step out of my comfort zone.

This post will Illustrate how we could use Bicep language to create repeatable deployments of storage accounts. Why storage accounts? What is so unique with this particular resource? The name of the resource ofc! A storage account name must be unique within Azure.

Our Bicep template consists of two parts, in the first part we define the custom properties of the resource using parameters, and in the second part, we describe the deployment of the Azure resource. Do not get confused, both parts will be contained within a single Bicep template.

Part one – Customizable properties using parameters

In this section, we define the custom properties that will be referenced as parameters. In each parameter we need to define the property of our own preference and in which is required. The use of parameters will allow us to construct this template in a way that we could reuse it for future deployments.

Required properties such as:

  • Storage Account Name
  • Storage Account Type
  • Resource Location
  • Storage Account Access Tier
  • Storage Account SKU
  • Resource Tags (Optional)

All these properties are the minimum required ones to deploy a Storage Account. Nevertheless, you could always add additional ones.

Part two – Definition of the resource deployment

In this section, we describe the storage account deployment. Values that are subject to change are the following:

  • batchsize() resource decorator – this resource decorator and value will set the mode to serial deployment and issue deployment in batches. If removed then the deployments will default to run in parallel.
  • range() function – this is where we declare a range number of copy loop deployments, meaning of the number of storage accounts that we are going to deploy. In our situation this will result to a total number of 5 storage account resources that will be created.
  • name property – this where you can define a prefix of your own preference instead of the defined sa prefix (sa is the resource abbreviation for storage accounts according to CAF resource naming best practices). In this example, value is placed at the beginning of the interpolation string. The interpolation string will result to a unique resource name that will consists of <prefix><resourceGroupId><incrementNumber>.

Last but not least, instead of using string values for each property, we reference the parameter name.

As said, we could also examine the possibility to add additional properties.

If we put it all together,

Let’s see how the output looks like.

As you have already figured out, the resultant storage account names are globally unique!

Below you will find the complete Bicep template syntax that we used.

Thanks for reading my blog!

Feel free to drop your comment or question below.

Banner