Learn about the requirements and optional components of an Azure Resource Manager template. The difference between the update methods will also be outlined.
- [Narrator] In the Azure Resource Manager portal, we can go ahead and author our templates to be used for deploying resources into Azure. But before we start jumping into the components of a template, let's go ahead and look at the benefits. First of all, we can deploy multiple resources at one time. We can ensure the same build is deployed over and over and over again. You can build your own templates, or you can use the prebuilt templates that are already available to you. And we can nest our templates, providing us with flexibility over our deployments.
Or, we can have our own repository and deploy from there. When we deploy a template to Azure, we have two update options. The first one is a complete update. When we choose a complete update, the resources in the resource group that are not identified in the template will be deleted. Keep that in mind. It's really important. Next, any resources that are identified in the template but do not exist in the resource group will be created. So we're adding in our resources. And next, resources that have updated settings in the template will be reprovisioned to the resource group.
Our next update type is the incremental update. And just as before, resources that are identified in the template but do not exist in the resource group are created. Therefore, we're adding in those new resources. And the same goes for our reprovisioning. Resources that have updated settings in the template will be reprovisioned to our resource group. The difference in the incremental update is that resources in the resource group are not deleted if that resource is not in the template. Therefore, the resources that are in that resource group are left alone.
We have a specific format that we must follow when creating our templates. First, we'll have our schema, our contentVersion, parameters, variables, resources, and outputs. I'm going to step through each of these in a little bit more detail. Let's start off with our schema. The schema defines the location of the JSON schema. And as of today's recording in May of 2017, you will use the schema that we have outlined here in the slide. If you are listening to this after May of 2017, I'd recommend that you just double-check this to make sure it's still current.
And this is a required component of the template. Next, we have our contentVersion. This is a template versioning. It is not used by Azure, so you can use your own source control to manage your template versions. Even though it's not used by Azure, it is required. Next, we have our parameters, and these are the values for a customized deployment, including location names and properties. They are not required, but it kind of defeats the purpose of a customized deployment. And you can use an external parameters file as well.
But if you are going to use an external parameters file, the parameter name must match the parameter that is defined in the template. Let's go ahead and take a look at a parameters example. Here, we have our environmentName. The type will be a string. And we have two allowedValues. We can either opt for development or production. The user does not have a choice but to use one of these when they go to deploy this template. As you can see, this keeps our naming consistent and correct. Next, we have our variables.
And the variables provide the options that can be used throughout the template. And you can use one value for all instances in that template, such as, your network naming convention on your virtual machine name, and they are not required. I like to use variables to define as much as I can within a script. It's just so much easier than retyping everything over and over again in a script. Let's go ahead and take a look at an example. In our case here, we have our variables. We have a variable of vNetPrefix of 10.0.0.0/16.
Our vNetSubnetName will be Production. And our vNetSubnetPrefix will be 10.0.0.24. Anywhere in the template where these variables are called, the corresponding information will be plugged into the template. And next, we have our resources. And in the resource section, we define the resources that are to be deployed. And this is required. Now, let's go ahead and take a look at a quick example. Again, going back to our virtual network, we have our apiVersion. And our type will be Microsoft.Network/virtualNetworks.
So, we're including that resource. And for name, we're going to refer back to our parameters file in this case under vNetSubnetName. And finally, we have outputs. These specify what is to be returned, and it is not required. Please don't let the code scare you off from templates. Using templates will save you time and ensure your deployments are consistent. And if I can understand and use templates, anybody can.
- Designing virtual machines
- Selecting appropriate VM SKUs
- Designing template deployment
- Deploying ARM templates via PowerShell and CLI
- Designing for availability
- Designing Azure Virtual Networks
- Azure VPN and ExpressRoute architecture and design