What if you needed to create a new template for a complex environment from scratch? Even with all the help schemas, it could be really difficult to come up with a template and make sure it does not have any bugs. To make things easier, Microsoft and the Azure community has provided a bunch of quickstart templates which can be downloaded and used freely. Let us take a look into that.

Search for azure GitHub arm in the browser and the very first link should point to the quickstart templates repository for Azure ARM. This repository is hosted on GitHub.

Click on that link to the GitHub repository and you find hundreds of predefined templates. You can clone this repository or download all these templates in a zip format and then you can use them to deploy into your Azure environment. These templates are free to use and they are frequently updated. Also, new templates are being added on a regular basis from contributors.

Find the template with the name 101-vm-simple-windows and click on it.

It will open this folder containing all the artefacts of the template. There are two buttons – the first button helps you either deploy the template directly to Azure and the second button helps you visualize the template in a graphical format. The visualize button will take you to a visualization tool called armviz.io. So, click on Visualize.

Once it gets loaded, it would look like this. It is showing all the resources which will be deployed by this template in a visual format.

Back in GitHub, click on the azuredeploy.json file.

Click on raw.

Copy the JSON.

And paste it in VS Code in a new file. Here we can easily dissect the template. Here you can see that schema of this template is very basic. The default content version is 1.0.0.0. Then there are parameters like adminUsername, adminPassword, dnsLabelPrefix and so on. These are the quickstart templates provided by the community. And so, they need to work in many different configurations and environments. That is why these templates are made as flexible as possible so that you can customize them the way you want.

If you take a closer look, you will see that every parameter here has a metadata element defined. The metadata element explains a number of things and among them is description. The description element gives you basic information about each parameter.

Scroll down a bit and you will see a new property called defaultValue. This defines a default value that will be assigned to this variable automatically if a user doesn’t input anything in this field.

As discussed earlier in the best practices, you can specify a default value for every parameter except for passwords and secure strings. For the password, the type is securestring. This means that these types of values are masked when the templates are copied or passed on. It makes sure that anyone who downloads the template cannot use this data or cannot see the values. Hence, it ensures that the data stays secure and protected.

Scroll down and you will find variables. Variables can either by dynamic where the values are calculated based on specific functions or their values could be hardcoded as well. Variables can use multiple functions such as concat, uniquestring and property of resourceGroup() function.

Scroll down to the next component which is resources. The first listed resource is Microsoft.Storage/storageAccounts. This means that this is a storage account type of resource. The name is taken from the variable storageAccountName. The next is apiVersion. This is the particular API version for Azure infrastructure which this template will use to create the resource.

APIs evolve over time and the best practice is to version each apiVersion and the API clients like Azure ARM. You can also target specific API versions to maintain backward compatibility. These API versions may differ between different providers.

For example, different storage providers can support different API versions. You can see that we have different API versions across the template. However, they are for different resources. The apiVersion tells us what format the parameters in the properties will be in. Because Azure is constantly evolving, the properties in the ARM templates are also changing because the properties of the resource itself are changing. For instance, in the previous versions of Azure apiVersion there was no option of managed disks but now we have managed disks in the VMs. Since these managed disks are present in the virtual machines, the ARM template also needs to reflect those changes.

But, when the Azure ARM template reflectes those changes, how will the end user know? If end users and users deploying the Azure ARM templates are not aware of the new features then this could cause failure during deployment. So, to counteract this, Microsoft releases a new API version for each new update on the properties.