Hello Cloud Marathoners,
In my previous Azure Bicep post, I wrote about four parameterization options that could be used with Bicep language. We also looked into the Azure Bicep resource templates, and how they help to author and manage Azure resources more cleanly and easily.
Now, I would like to share a couple tips on how to harden your parameter inputs. This will help you to avoid deployment errors that you could easily prevent by restricting and checking Bicep parameter values.
Tip # 1: Min and Max length of resource names
In our previous post, we have built and demoed the webapp-service-w-param.bicep file. It had no parameter input validation. Thus, that template is open for failures when you enter 'a' for the appServiceAppName input parameter. Here is the link to the repo.
However, it is pretty straightforward to avoid such false entries by checking the allowed name length of the Microsoft.Web/serverFarms resource in the Microsoft docs Resource name rules page.
Based on “Resource name rules” page we can add following functions:
The @minLength and @maxLength function are going to define and enforce min and max length of the parameter, while @description will help to define the purpose of the parameter.
Tip # 2: Defining purpose of the parameter
It is always helpful to add meaningful description to your parameters, even though it is not required by Azure Bicep template. Believe it or not, people who are new to your code will appreciate it. For example: we have a location parameter in our template, and adding the following description clarifies the purpose of this parameter for everyone, including myself, later in a month when I am re-visiting my code.
Tip # 3: Restricting parameter value entries that match your organization’s policy
The final tip is already revealed in our screen-shot above. It makes a valid and important sense to enforce your organization’s Azure policies on any provisioning scripts, in addition to the Azure Policies.
In our example: we are restricting deployment of Azure resources only into the following Azure regions to comply with the company policy to make every party happy.
Thus, I have shared a few tips that you could use to harden your Azure Bicep code and avoid some common deployment errors in advance.
Here is the complete view into our hardened webapp-service Bicep file:
Summary
Preventing deployment failures, especially the once that are caused by invalid input parameters are an easy fix on an Azure Bicep language. Checking the resource name restrictions and allowed values is one easy tip to prevent those errors. I would recommend checking the Microsoft documentation on “Naming rules and restrictions for Azure resources” and bookmark it for your reference.
Thank you ๐ for reading this post and learning how to prevent Azure Bicep deployment failures by hardening the input parameter values.
Please check out the Learn Bicep GitHub repo, and follow it.
Thanks, ๐ ๐!
Stay tuned for more Azure automation & Azure Bicep posts.
Fแดสสแดแดก แดแด ๐ฏ แดษดแด become แด #cloudmarathoner โ ๐โโ๏ธ๐โโ๏ธ – ๐๐๐’๐ ๐๐๐๐๐๐๐ ๐
