Using the BICEP CIDR Function

Intro

In this blog post, I’ll demonstrate how to utilise the CIDR function within BICEP to streamline the calculation of necessary subnets for your infrastructure deployment. This approach aims to minimize the “bloating” of your Infrastructure as Code (IAC), thereby simplifying the provisioning of subnets within a Virtual Network (VNET).

All code presented in this blog can be found in my GIT HUB DataOpsDon/DataOps (github.com)

I hope you enjoy this blog and find the contents of this topic useful!

The Challenge..

So taking a step back the reason that this function was developed was because of a lot of Platform Engineers were not Network Engineers and thus developing the function simplified the process of provision subnets in a VNET for those who did not come from a strong networking background.

Ultimately the CIDR function in BICEP streamlines code deployment by simplifying the calculation of required subnets for infrastructure provisioning. It helps reduce code complexity and improves efficiency by automating the process of determining subnet configurations within a Virtual Network (VNET).

By using the CIDR function, developers can generate subnet definitions dynamically based on specific CIDR block allocations, meaning that you can simply pass in VNET address space and the CIDR function will calculate the subnets for you.

Anyway let’s get into it…..

The Fun Stuff… (IAC)

For this Blog I have developed my own subnet template, which will subsequently be called via a module deployment. The subnet template file can be seen below.

As you can see I have highlighted the key points within this template that contribute to the enablement of the BICEP CIDR function.

1. This starts a for loop that iterates over the snetAdressPrefix parameter which can be see is defined as an Array. For each iteration, it assigns the current subnet address prefix to sn and the current index to index.
2. The name property is also defined in a loop which means that name is set to the corresponding name in the subnetNames collection.
3. Again like the name property, the subnet address prefix is set to the corresponding address prefix in the address prefix collection which is also defined as an array.

Essentially, what we’re accomplishing here is assigning the subnet name and address prefix to an array element. This allows us to input multiple values without the need for redundant configuration code.

So now that we have the template defined, we can now call this via a module where we can inject the CIDR function for our address prefix parameter to generate the subnets we require…

As can be seen from the image above we are declaring 2 modules but we will be actually be provisioning 4 subnets. On the first line marked with the arrow we can see that we are providing the values for our first lot of subnets, and instead of hardcoding out all the subnets we require we can see that there is very little code here to define the subnets we want…

1. for i in range(0, 2): This is a loop that iterates over a range of numbers from 0 to 2 (exclusive). So, it will iterate over 0 and 1, meaning that only two values (2 address prefixes are being requested)
2. cidrSubnet(addressPrefixes, 26, i), this is where we declare our CIDR function and we are passing our VNET adrress prefix which might be 10.0.0.0/24 and asking declaring we would like a /26 subnet address prefix for every subnet declared in the range, which basically means give me 2 /26 subnets.

The output of this module will be 2 /26 subnets that start at the beginning of the VNET address range.

In the second module (called subnets 27), we’re essentially following a similar approach. However, this time, I require 2 /27 subnets. Consequently, I adjust my range starting from 4 because a /26 subnet is twice the size of a /27. Essentially, I’m instructing the the module to allocate 2 /27 subnets starting at the end of the last /26 subnet from the array utilising the BICEP CIDR function.

The output of this deployment is as follows..

Isn’t that much more cleaner and simpler than defining every single subnet you want, hey?

Wrap Up

So to wrap up, I’ve shown you how you can easily provision the subnets you require with a lot less code and need for manual calculations.

The other real benefit that I’ve found from using this method is deploying subnets from environment to environment becomes a lot more efficient, as you simply just pass in your VNET address prefix and voilà you have all your subnets! 🙂

As I mentioned all the IAC templating can be found in my GH DataOpsDon/DataOps (github.com) so you don’t need to re-invent the wheel, use my ode and make your life easier by using the BICEP CIDR Function!

I hope you found this Blog useful and best of luck using BICEP CIDR Function to define your subnets.