Using the principles we’ve used in earlier articles we’re now going to build on the foundations we’ve codified. We’ll use the simple lego blocks we developed in part 1 to make something much more complicated using nested ARM templates.
First lets reaquaint ourselves with our repos….
The main repo we have is this one: https://github.com/r3adm3/AzureInfraAtPace
It contains folders for:
- “sharedResources” – firewalls, VNETs, subnets etc.
- “w16build” – spins up a Windows 2016 server in Azure, and installs some tools on it
- “w16server” – same as above, but with the self service deploy to azure button in the readme.md we can use on our web pages.
- “w16serverwpip” – a slightly modified version of w16server that includes a public IP we can use to RDP to the server rather than it being in an isolated network.
Say we wanted to build out a network of machines in Azure of say twenty machines with a variety of different toolsets or configurations on each server. Most of the servers can stay off the internet, with one server configured to be on the edge. If we just use the above, each template takes about 15-20min to run, we know that there is a limitation using the https://deploy.azure.com website in that we can only run one deployment at a time for a server, that means 400 min ( 6 and a bit hours) to deploy all of this stuff. Bit slow if you ask me. We can do this in script quicker and make one humongous ARM template, that’s not going to be easy to support tho and its a very big file.
When I’m coding I try to follow DRY (ie. Don’t Repeat Yourself) as much as possible. Most of the servers we’re going to put in this network are going to be the same so lets use the building blocks we’ve already created with the magic of Nested ARM Templates.
Let’s start with our base builds azuredeploy.json‘s. Note down the parameters section so in the below we’ve got networkResourceGroupName, virtualMachineName, adminUserName and adminPassword.
Now we create a new ARM template that calls into our base build:
A few notes
- we’ve defined a variable called windowsTemplateURI and pointed it our simplest ARM template using the field templateLink in the resources section.
- The parameters at the top are the inputs we provide to the nested template, the information in those can be used throughout the rest of the nested template.
- The parameters within the resources section, refer to the information that the building block template will need to build the server, ie. each of the four parameters we noted down earlier. You can see from the example that three of the parameters we’ve inherited from the nested template and one we specify an actual value.
So technically scaling this up should be easy. Lets add a second server:
As you can see we’ve just added another section of json, called the next server, “testserver2” and shared the details of username, password and network resource group with the first server.
…because of how ARM works when this script is invoked, both machines will build at the same time, not in serial, so in theory we could scale this up as much as we want (Microsoft would probably have something to say about it tho or just charge you lots of money).
Now lets add in a another ARM template so that we can build more than just simple Windows servers. (In the below example I’ve changed server two to call a different ARM template instead of the same as the first).
…and there we have it, we can in as many base templates as we want by just adding more pointers in the variables section of the nested templates, and in parallel, call for more and more resources to get built.
…and because the nested template just follows the same rules as normal templates, we can front this one with https://deploy.azure.com just as in part 2. So you could define an infrastructure and just deploy as many times as you want into different resource groups, but it’ll be the same as the original (test environments anyone?).
This will get very complicated very quickly and if we don’t put in some form of automated testing, things are going to break very easily….but that’s another story for another article.