Sebastian Schütze
Recently I had to make another ARM-Template for a project which only lives on Azure. Unfortunately all resources were already created on Azure and I needed to kind reverse engineer all configurations. Within that I came along some problems. I could solve those problem and they now pop out as tips in this article. I hope this will help you!
1. Do not (mostly) start with the Automation Script
Azure has this nice thing called “Automation Script, which allows you to get the ARM template for the resources within a resource group. But it has a big problem: Chaos. Basically the following problems apply
- Parameters getting reused for resources that you would not use as a parameter
- Parameter names can confuse you, because they are created from the given names of the resources. If there are resources with similar names, then you have parameters with similar names
- configuration is exported, which is default. This means either properties that are simply “null” or configuration settings that have a default value. If you don’t know the default value, you will probably useless information in your template.
- Naming patterns custom to your company or best practices are not followed.
This all will lead to the problem, that you try to refactor the template, which takes more time then just starting from scratch. Hey, but wait. There is one thing you can use that for. At least you know, what you need. You can take it as a reference in your project, until you are sure that everything works as expected.
2. Use Visual Studio instead of VS Code
I know that VS Code is one of the most popular code editors currently out there, but for specialized tasks it lacks some features. Microsoft concentrated pretty much on Visual Studio as a commercial tool. It has also the community edition, which includes all the nice ARM development features that you get, when you use Visual Studio 2017.
Firstly, you have the nice JSON Outline panel, which helps you navigating through the template and adding the most common features.
Secondly, the UI experience is much better. You have wizards that makes it easier for you to add new resources and you have a project template with a solution file, that gives you more distinctive options.
Thirdly, the deployment experience is much better. You have also the option to easily use a storage account if you use nested templates. Nested templates always need a accessible location to access them, since the main parent template is accessing them threw an URL and not from the same location where they are executed. This is done so easily in VS 2017.
3. Use the Region of the Resource Group
I always try to use the location of the resource group. This solve several problems.
- You have one parameter less
- all resources have the same region
- less error prone
This is pretty simple and easy but effective. If you are wondering how you could use it, look at the following example
"variables": {
"location": "[resourceGroup().location]",
}
So you just use the location of the resource group and put it in a variable and the reuse the variable in your resources. Boom. You just made it easier.
4. Think about if you need Nested Templates
When I started using ARM templates, I thought: Of course I use nested templates. I am a developer and I want to cut my templates into pieces for this project. But then I noticed that I need a storage account and need to care about secure access to the blob of the storage account. This is all fine. If you need it, then you need it. But nested templates are more about reusability rather than structuring you templates. You can still do it and it is completely fine, but if this creates more costs, time and complexity for just a small project, then maybe you can think about putting it just in one template.
5. Resources.azure.com is your friend
Think about tip one for a second. Azure is generating the script for you. But maybe you want to know how some things are working that you need to add. And maybe you want it in detail. The address https://resources.azure.com is giving you all you need. There you can browse through all kinds of resources and find out how configuration in the portal is influencing the ARM template that you want to edit.
Use this site regularly to expand your knowledge and you can probably learn more than reading some books and blogs (except this one! ;-))
The End?
So friends that’s it! Of course there is much more, but I will give more tips later. Some tips I have in mind are more related to CI / CD pipelines with ARM-Templates. I gonna write some more on what to think about when you use VSTS to automate your deployment of infrastructure code!
