In this course, I’ll start with an overview of Azure Resource Manager templates. Then I’ll show you how to build a template from scratch and deploy an Azure Storage account with it. Next, I’ll show you how to use a template to deploy a virtual machine, which is a more complicated resource. After that, I’ll explain how to make your templates more usable by adding parameters and variables. Finally, I’ll show you how to make your templates more sophisticated by using functions.
- Describe the structure of Azure Resource Manager templates
- Build an ARM template and use it to deploy a resource
- Use an ARM template to deploy a virtual machine
- Use parameters and variables in an ARM template
- Use functions in an ARM template
- Azure administrators and developers
- Basic knowledge of Azure Virtual Machines, Azure Storage, and Azure Virtual Networks
If there’s a value in your ARM template that’s likely to change for each deployment, such as the name of a resource, then it’s a good idea to use a parameter for that value. That way, you’ll be able to set the parameter’s value on the command line when you deploy the template. It can be a bit of work to turn values into parameters, but fortunately, VS Code makes it much easier.
The most obvious value to turn into a parameter in this template is the name of the virtual machine. If you click on the value, you’ll see a lightbulb come up over here. If you click on it, you’ll see two options: Extract Parameter and Extract Variable. Click “Extract Parameter”, and then type in what you want to call the parameter. Let’s call it “vmName”. Then it asks us to type in a description of the parameter. You don’t have to do this, but it can be useful if you use the Azure Portal to do a deployment, so let’s enter, “Name of the virtual machine”.
It replaced the value with “[parameters('vmName')]”. Then, if we go up to the parameters section, we’ll see that it defined the parameter for us. There’s the name we gave it. There’s the description. And it even turned the original value we had into the default value.
To set this parameter on the command line when doing a deployment, you’d add “--parameters 'vmName'=” and then the value that you want to set the parameter to. If you wanted to use a parameter file instead, then you’d put the name of the parameter file after “--parameters”.
The only problem with creating this parameter is that the VM name appears in lots of places in this template, so we need to replace every instance of it with the parameter. In some cases, we can just copy this and paste it over other occurrences of the VM name. If there were a lot of instances, then we could do a global replace to change it everywhere.
However, in many cases, it wouldn’t work properly if we did that. For example, look at the name of the network interface. It starts with the VM name and ends with “-NetworkInterface”. Here, we need to concatenate the parameter and the additional text. First, we’ll replace the VM name with the parameter.
You’ll notice that this part is underlined in red to show that we have a syntax error. If we hover over it, it says that nothing should exist after the closing square bracket except whitespace. So, we need to move the closing square bracket to just before the ending quote.
It looks better, but it’s still showing an error because we need to do more to fix this. We need to use the “concat” function, so we’ll add “concat open bracket” at the beginning. Then we’ll add a comma after the parameter. It tells us that the concat function is expecting multiple arguments separated by commas. We added a comma, so why is NetworkInterface still underlined in red? That’s because it’s a string, so we need to put single quotes around it. We also need to add a closing bracket to end the concat function. There. The error disappeared, so we know the syntax is valid.
But we’re not done with this yet because there are a couple of other occurrences of this network interface name in the template, so we should change it in those places too. For example, here’s another occurrence of it. We could just copy and paste the code over the other occurrences, but there’s a better way to do it. We could turn it into a variable.
A variable is like a parameter except that you can’t change it on the command line when you do a deployment. So if you can’t change it, why would you use a variable? Well, it makes the code easier to read, and if at some point in the future, you want to change how that value is derived, you only need to change it in one place.
All right, now we can highlight this code, then click the lightbulb, and select “Extract Variable”. Let’s call it “networkInterface”. Now it says, “[variables(‘NetworkInterface’)]”. If we go up to the variables section, we can see that it created the networkInterface variable and set it to the code we wrote.
Now instead of having this complicated piece of code wherever we need to specify the network interface, we just have this straightforward variable.
I’m not going to finish replacing all of the relevant values with parameters and variables because I’m sure you get the idea and can do it on your own.
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).