Azure IAC Resource Manager Parameter Options

Hey Folks,

This time I wanted to talk about different types of parameters passing options and my opinion on each possible method. Having said that, there is no right or wrong answers here. It's purely depending on the solution that you are working on.

There are few different parameter options we can use with Bicep especially when you are using Azure DevOps

• Json Files
• YML Files
• Variable Groups
• In-line Parameters
• Define Parameters within Bicep

In this very blog post I'm not going to go into detail about in-line parameters, parameters within biceps or variable groups in Azure Devops. Cause I assume we are much more familiar with those. and my key highlight on this is yaml parameter files.

JSON Parameter Files

We all know what Json parameter files are. Following is one of the examples from Microsoft documentation.

{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "<first-parameter-name>": { "value": "<first-value>" }, "<second-parameter-name>": { "value": "<second-value>" } } }

All you need to do it format the parameter file according to the syntaxes and pass the entire parameter file into the deployment task. Following are some of the Pros and Cons

• Maintainability: Separating parameter values into a JSON file can make it easier to manage and maintain code, as the parameters are isolated from the main Bicep code.
• Flexibility: JSON parameter files allow for flexible configuration of parameters, as they can be easily updated without needing to modify the Bicep code.
• Scalability: JSON parameter files can be used to manage parameters for large-scale Bicep deployments, making it easier to manage changes across multiple files.

Some of the cons as follows.

• Complexity: JSON parameter files can add complexity to Bicep code, particularly for smaller deployments where a single file might be sufficient.
• Version control: JSON parameter files can make it more difficult to manage version control, as changes to parameter values might need to be tracked separately from changes to Bicep code.
• Security: JSON parameter files can contain sensitive information such as passwords or access keys, and so need to be carefully managed to avoid security risks.
• Overhead: JSON parameter files can add additional overhead to Bicep deployments, particularly if they need to be retrieved from a remote source at runtime.

but the biggest disadvantage with Json file for me is we have to define same details or variable multiple time and we won't be able to reuse across files. And we cannot easily re-provision environment with these files unless we change all the reference points. 

How to Deploy Bicep with Json Parameter Files

To deploy a Bicep file, we can simply use the below. commands

                az deployment sub what-if -l ${{ variables.location }} `

                --template-file 'bicep/main/workloads/workload.bicep' `

                --parameters 'configurations/parameters.json' `

And if you have multiple workloads, you may have multiple parameters files against multiple Bicep files.

What do we have to do to re-deploy multiple workloads in a solution to a different region or environment with different names?

You have to go through all your parameter file and change the naming convention or the references to the names and run the template in your new environment. This can be a painful process if there are more resources are if you have complex resources like APIM. 

YAML Parameter Files

YAML Parameter files in the other hand has much more flexibility and easily tackle the issues or problems around naming conventions. The unique feature to call other yaml parameter files within yaml parameters files makes things much easier when you want to deploy resources into different environments.

YAML Parameters:

• YAML stands for "YAML Ain't Markup Language," and it is a human-readable data serialization language.
• YAML has a more complex syntax compared to JSON, but it is still easy to read and write.
• YAML parameters are often represented in a key-value format, where the key is a string and the value can be a string, number, Boolean, array, or another YAML object.
• YAML parameters can be used for a wide range of applications, including configuration files, data exchange, and structured data representation.

When I'm using YAML variables I use it as in a higher achy

1. Global Variables

2. Sub Variables

Here is why.

Global Variable File will contain all the common variables across the environment and the variable names will be unique across

Sub Variable

Sub variable files will always have a reference to the global files. as below

So, this YAML variable files are really convenient for defining naming stuff. And if you are using yaml variable files, all you got to do is referring the variable template in you DevOps pipeline.

as below

but there are some limitations too if you decide to use yaml files.

1. You can use them when you are deploying resources using pipelines.

2. If you want to define an object or an array it's not straight forward, you need to use a PowerShell command to construct the object/array.

3. And we have to feed the parameter details individually as below.

How to Deploy Bicep with YAML Parameter Files

To deploy a Bicep file, we can simply use the below. commands and pass each value separately. And also make sure you call the variable files at the top.

Summary

So having said all of these, here is my preferred method. If deploying resource using pipelines and If I need to redeploy the same template into multiple environments, I like to use YAML variables wherever possible. And I've being using mix of things in each deployment. Having YAML variables files as the primary, when its complex, I normally use JSON files and pass it as full, Also I use bicep parameter values to hardcode or none changing values.