Skip to main content

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.



Comments

Popular posts from this blog

Deploying an Automation Account with a Runbook and Schedule Using Bicep

Introduction Automation is a key component in many organizations' cloud strategy. Azure Automation allows you to automate the creation, deployment, and management of resources in your Azure environment. In this post, we will walk through the process of deploying an Automation Account with a Runbook and Schedule using Bicep, a new domain-specific language for deploying Azure resources. Intention My intention at the  end is to run a PowerShell  script to start and shutdown Azure VMs based on tag values. PowerShell  script that I have used is from below l ink.  And two  of me   collogue s ( Michael Turnley   and Saudh Mohomad helped to modify the  PowerShell  script. Prerequisites Before we begin, you will need the following: An Azure subscription The Azure CLI installed on your machine. The Azure Bicep extension for the Azure CLI Creating the Automation Account The first step in deploying an Automation Account with a Runbook and Schedule is to create the Aut

Migrating Azure DevOps Variable Groups

Howdy Folks, I was working on an application modernization project. And there was a requirement to migrate application deployments from one project to another in Azure DevOps. deployment pipelines were heavily dependent on variable groups. So, we wanted to migrate these variables group to the new project. Couldn't find any solutions in internet for this, so came up with the below scripts. You can grab the scripts from the below GitHub URL. DaniduWeerasinghe911/Migrate-Azure-DevOps-Variable-Groups: This Repo Include PowerShell Scripts relating to Migrating Azure DevOps Variable Groups (github.com) Azure DevOps Variable Groups Azure DevOps Variable Groups are a way to store and manage sets of variables that can be used across multiple pipelines in Azure DevOps. These variables can include secrets, connection strings, and other sensitive information that is needed for builds and releases. Variable Groups provide a centralized way to manage these variables and ensure that they are cons

Securing Azure Services with Fetian FIDO

Hey Folks  Here again with another security topic with Fetian Fido. And once again Fetian devices proved their excellent quality and stability. For this I choose Fetian K33 -  AllinPass FIDO Security Key – FEITIAN (ftsafe.com) and  K39 -  Single-button FIDO Security Keys | FEITIAN (ftsafe.com) Use case  In an organization following changes needs to be implemented.  1. Update the password policy 2. Update the user session time out to 30 minutes Once these changes being implemented, the following issues need to be addressed 1. Users' complaint new passwords need to be so long 2. Users complain sessions time out makes them work so much slower with the longer passwords 3. Etc... Solution  One of my friends reached out to me to help solve this problem. All I could think of was using passwordless auth with FIDO devices. We have decided to use Fido2 keys for better security and flexibility for the users. The FIDO (Fast IDentity Online) Alliance helps to promote open authentication stand