Templated deployment is one of the key value propositions of moving from the Azure classic to Resource Manager (ARM) deployment model. This is probably one key feature that made a big stride towards Infrastructure as a Code (IAC). Personally, I have been looking forward to this feature since it’s a prominent feature on the other competing platform.
Now that this feature is live for a while, one aspect which I found interesting is the ability to link templates in Azure Resource Manager. This post is part of a three-part series highlighting ways you could deploy linked templates. The first part of the series describes the basics – building a template that creates the base environment. The second part will demonstrate the linked template. Third part will delve into a more advanced scenario with KeyVault and how we can secure our linked templates.
Why linked templates? We could get away with one template to build our environment, but is it a good idea? If your environment is pretty small, sure go ahead. If the template becomes un-manageable for you which is mostly the case if you are serious about ‘templating’, then you come to the right place – linking or nesting templates is a way for you to de-couple your templates to manageable chunks. This allows you to ‘branch’ out templates development, especially when you have more than one person; resulting in smaller, manageable templates than a one big template. Plus, this would make testing / debugging a little easier as you have a smaller scope to work off.
Linking or nesting templates is a way for you to de-couple your templates to manageable chunks. This allows you to ‘branch’ out templates development, especially when you have more than one person; resulting in smaller, manageable templates than a one big template. Plus, this would make testing / debugging a little easier as you have a smaller scope to work off.
OK, so let’s start with the scenario that demonstrates linked templates. We will build a two-tier app consisting of two web servers and a database server. This includes placing the two web servers in an availability set with a virtual network (VNET) and storage account to host the VMs. To decouple the components, we will have three templates, one template that defines the base environment (VNET, subnets, and storage account). The second template will build the virtual machines (web servers) in the front-end subnet, and finally the 3rd template will build the database server.
First template (this blog post)
The building process
First, create a resource group, this example relies on a resource group for deployment. You will need to create the resource group now or later during deployment.
Once you have a resource group created, set up your environment – SDK, Visual Studio, etc. You can find more info here. Visual Studio is optional but this demo will use this to build & deploy the templates.
Create a new project and select Azure Resource Group. Select Blank template.
This will create a project with PowerShell deployment script and two JSON files: azuredeploy and azuredeploy.parameters. The PowerShell script is particularly interesting as it has everything you need to deploy the Azure templates.
We will start by defining the variables in the azuredeploy template. Note this can be parameterised for a better portability.
Then we define the resources – storage account and virtual network (including subnets).
We then deploy it – in Visual Studio (VS) the process is simply by right-clicking project and select New Deployment… then Deploy. If you didn’t create a resource group, you can create it here also.
The template will deploy and a similar message should be displayed once it’s finished.
Successfully deployed template ‘w:\github-repo\linkedtemplatesdemo\linkedtemplatesdemo\templates\azuredeploy-base.json‘ to resource group ‘LinkedTemplatesDemo‘.
On the Azure portal you should see the storage account and virtual network created.
The next part in the series describes how we modify this template to call the web and db servers templates (linked templates). Stay tuned :).