We often find in the working world, that time is regularly spent just waiting for the next team to start their work. It’s a natural consequence of having teams of people with a specialised skill, and that team having to prioritise their work. But what if we turn that on it’s head. Treat that skill as a service, how do we make it easy and quick to enable another team get their work done without our intervention. If you can do that, we get rid of the queue straight away.
In the previous article, we looked at moving away from the point and click nature of the Azure Portal, to Azure Resource Management (ARM) templates. We use automation to standardise our cloud resources, but calling scripts by hand is only really good for people that are comfortable running scripts. I’ll describe what to do first, then walk through an example.
So first job, define your ARM template to make the thing that you want in the Azure Cloud. It could be a web app, a database instance or a server, the choice is endless here. Like in the first article, we can do the first one by hand and save off the template files.
Second take your template.json and parameters.json, anything you can put in the “variables” section of the template.json do so. Keep the number of parameters, the input you’re expecting your user to provide, to a minimum.
Now for the magic! We’re going to use GitHub to host our project and the recommendation is to create a readme.md file at the root of your project using a markup language called Markdown. Its a simpler way of doing HTML, that’s for another post tho…
The magic happens with this line of code:
[](https://azuredeploy.net/)Let’s break this down.
! – denotes an image
[Deploy to Azure] – is to display some text
(http://azuredeploy.net/deploybutton.png) – is a link to the image that will merge with the previous text to make a button
(https://azuredeploy.net/) is a link to the Azure Deploy website.
It’ll end up looking like this when viewed in Github:
When the button is clicked, the AzureDeploy.net service takes the referrer http header (basically where you clicked from), downloads the GitHub repo and then wraps its own code around it to come up with a form that’ll take your user input:
Before you see the page, it’ll authenticate to Azure so that it can read in the Directory, Subscription and Resource Group fields. The rest is all user-defined. Click Next, it’ll verify that the ARM all hangs together and then provision it for you.
You can even use the button and it host it on your own web server somewhere (as long as the ARM code stays in Github). The Markdown to do this would like this:
[](
https://azuredeploy.net/?repository=https://github.com/user/repo)…or the HTML which might be useful:
<a href="https://azuredeploy.net/?repository=https://github.com/user/repo" target="_blank">
<img src="http://azuredeploy.net/deploybutton.png"/>
</a>With these parts you can start to build up your own catalog of standardised user requested services that people can just click on to provision.
So I promised and example. I’ve got a server 2016 deployment which will insert itself into a pre-prepared network, so first thing we have to do is deploy the shared resources to make sure it works. I’ve done this the traditional way using scripts. Git clone the repo below and run the Azure Powershell script. It simply creates a VNET and a first subnet for resource to go into.
git clone https://github.com/r3adm3/AzureInfraAtPace/tree/master/sharedResources
new-azurermresourcegroupdeployment -resourcegroupname sharedResources -templatefile .\azuredeploy.jsonNow in a browser head over to and click the deploy to azure button https://github.com/r3adm3/AzureInfraAtPace/tree/master/w16server
You can create a new resource group if you like or put the resources in an existing one. The network resource group name field, enter in “sharedResources”
Everything else you can fill in.
Click Next and the deploy….and a new VM comes out the other side after 10-15 minutes.
This example VM won’t have a public IP address you can access, if you need that use this repo instead.
There are limitations with this service, you can’t deploy to the same resource group with the same template at the same time, however the next article in this series will show how we scale this up using nested ARM templates!