Introduction

Welcome back to the next chapter of our journey with Azure Bicep, the declarative language for deploying Azure resources with elegance and precision. In our previous article, we unravelled the intricacies of Azure Bicep and promised to demystify the notorious ‘Squiggly Line’ in Visual Studio Code that perplexed us earlier. Staying true to our word, we will now provide you with the essential knowledge to effectively use parameters in your Bicep templates to create clear and powerful code to efficiently manage your infrastructure.

Understanding Parameters in Infrastructure as Code (IaC)

In IaC, a parameter is like a customizable field in a form that allows for different data entries, making scripts reusable for various scenarios. Think of a parameter as a fill-in-the-blanks in a form: it allows you to reuse the same form multiple times for different use cases without altering the core code.

The Importance of Parameters

Let’s say you have a Bicep script for creating a resource group. Typically, a resource group requires a name and a location for creation. Without parameters, you would write a separate script for each unique combination of name and location. That’s both inefficient and cumbersome.

By introducing parameters, you:

• Maintain a single script that can handle various inputs.
• Save time and reduce errors because you’re not juggling multiple versions of essentially the same script.

How to Define Parameters in Azure Bicep

So, how do we actually declare a parameter in Azure Bicep? Here’s a simple breakdown of defining parameters:

• Type Declaration: The type of a parameter tells Bicep what kind of value to expect. The most common types include string for text, int for integers, and bool for true/false values. For example:

  1	param myParameter string

  Here, myParameter is a string type, so it will accept any text as input.

• Naming Parameters: The name you give a parameter is how you’ll reference it in your script later on and when you deploy it. For instance:

  1 2	//Define a parameter named 'resourceGroupName' of type 'string' param resourceGroupName string

  In this case, resourceGroupName is a logical name that clearly indicates its purpose.

• Setting Default Values: To make things even smoother, you can assign default values to parameters. This means that if no value is provided during deployment, Bicep will use the default.

  1 2	//Define a parameter named 'location' of type 'string' with default value of 'australiaeast' param location string = 'australiaeast'

  With location set to australiaeast, this value will be used unless you specify otherwise when deploying.

Using Default Values Wisely

Default values are not mandatory but are helpful for common scenarios, such as frequently deploying to a primary location while retaining the flexibility to deploy elsewhere as needed.

For example, you do not have to pass the value of australiaeast each time you deploy your code, yet you have the flexibility to override the default when you need to deploy to an alternative location like eastus.

Creating a Resource Group with Parameters

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

targetScope = 'subscription'
// Define a parameter for the resource group location with a default of 'australiaeast'
param location string = 'australiaeast'

// Define a parameter named 'resourceGroupName' of type 'string'
param resourceGroupName string

// Create a Resource Group using the location and resourceGroupName parameters
resource myResourceGroup 'Microsoft.Resources/resourceGroups@2022-09-01' = {
  location: location
  name: resourceGroupName
}

With just these few lines, you’re ready to deploy your Resource Group, and no more ‘Squiggly Line’ in Visual Studio Code. Yay 🥳🎉

When you’re ready to deploy your Azure resources with the Bicep template above, save it to a main.bicep file in VS Code, we will reference this file when we deploy our code with Azure CLI next.

Passing Parameters with Azure CLI

Using parameters in your deployment scripts is just the first step. To effectively use these parameters, you need to understand how to pass them during deployment using Azure CLI. This process is crucial for customizing your deployments on the fly without modifying the actual Bicep files.

Using the Parameter Argument in Azure CLI

To deploy your code with Azure CLI, you can specify the values for your parameters directly in the Azure CLI command. This is done using the --parameters or (-p for short) argument followed by the parameter names and their respective values.

Here’s an example of passing multiple parameters, including the location:

1

az deployment sub create --location australiaeast --template-file main.bicep --parameters resourceGroupName='MyResourceGroup' location='westus'

Here, resourceGroupName is a parameter we’ve previously set up in our Bicep template. Including --parameters resourceGroupName='MyResourceGroup' assigns the value MyResourceGroup directly during deployment.

Notice that resourceGroupName is the parameter from our Bicep file, and by including --parameters resourceGroupName='MyResourceGroup', we’re passing the specific value to be used by Azure.

Now, take a closer look at the usage of the second location: location='westus' at the end of the command. It lacks the double dashes (--) because it’s not a separate Azure CLI option to the command az deployment sub create but rather a value assigned to the location parameter in our template. This illustrates the flexibility of the --parameters argument to pass multiple values for different parameters, all within the same command line.

It’s important to distinguish between these uses of location:

• --location specifies where Azure records the deployment’s metadata.
• location='westus' sets where the actual resources, like your resource group, will be created.

Demystifying the Metadata Location in Azure Deployments

In Azure’s ecosystem, every deployment action has its own footprint, referred to as deployment metadata. This metadata is as essential as the resources themselves but serves a different purpose.

The Role of the --location Parameter

The --location parameter in the az deployment sub create command might seem like just another location setting, but it has a unique role. It’s not about where your resources end up; instead, it’s about how Azure tracks deployments.

Putting Parameters to Work

Experience the power of Parameters firsthand as we deploy resource groups to multiple locations 🚀 Deploying our Resource Group in the default location Australia East is straightforward. Simply run the following command:

1

az deployment sub create --location australiaeast --template-file main.bicep --parameters resourceGroupName='myResourceGroupAUE'

In this instance, Azure Bicep automatically applies australiaeast as the location parameter value, thanks to the default value we’ve defined earlier. Note that the australiaeast in the above command is not where your resource group necessarily goes—it’s where the deployment’s metadata is stored.

Should you need to deploy your resource group to a different physical location, you can override the default set in your Bicep template within your command, a quick parameter adjustment is all it takes:

1

az deployment sub create --location australiaeast --template-file main.bicep --parameters resourceGroupName='myResourceGroupWUS' location='westus'

Even though we specify australiaeast for the metadata, the resource group will be deployed in westus. Passing the location parameter like this signals Azure to provision your infrastructure in an entirely new region. It’s that simple to steer your deployments across the globe with just a few keystrokes, as you can see below:

Tips for Parameter Best Practices

As you start getting hands-on with Azure Bicep and parameters, here are some tips to keep in mind:

• Keep Names Simple: Use names for parameters that clearly tell you what they’re for, like serverName or storageSize.
• Use Defaults Wisely: Set default values for parameters that won’t change often. This makes running your scripts faster because you don’t have to enter these values every time.
• Documentation is Key: Write a short comment above each parameter to explain what it does. This helps anyone reading your code to understand it better.
• Secure Sensitive Data: Never put passwords or keys directly in your script. Use parameters to input these values when you run the script.
• Test Your Inputs: Make sure the values you input for parameters make sense. For example, if you have a parameter for size, check that it’s a number and not a letter.

By following these tips, you’ll create clearer, more effective Bicep templates as you learn. Keep practicing, and you’ll quickly get the hang of it!

Wrapping Up

The more you work with Bicep, the more you’ll appreciate how parameters contribute to scalable and manageable infrastructure. They are the cornerstone of customizing your deployments without rewriting your code.

As we wrap up this discussion on parameters, remember that they are just one part of the equation. In our next exploration, we’ll dive into the world of Bicep variables—a powerful feature that further refines and simplifies our infrastructure as code practices. Stay tuned to uncover how variables can streamline your Bicep templates even further. Until then, keep coding smart and efficiently with Azure Bicep. See you soon, and happy coding! 👨‍💻👩‍💻