Devops means something different to different people. To me it’s about using automation to deliver value. Also looking at your system of automation (or work pipeline) and continually optimising the slowest steps, and if we can reduce dead time and queues by making as much as possible self service, all the better!
I’ve been working with Microsoft Azure for two years now and I wanted to walk through how you can use scripting technologies and Azure DevOps to push out infrastructure quickly, safely and easily.
But what underpins all of this?
Azure Resource Management Templates are Microsoft’s technology for achieving declarative repeatable deployments.
Its also easy to start using them without having to do a great deal of scripting too. If you go to the marketplace, point and click through to create a Windows VM for example. Just before you finalise the details, you should be able to see the following link:
Coding without code, nice.
If you click on download you end up with about five files, of which two are the most important, a template.json and a parameters.json file.
The template contains the definition of all of the resources you’ve just requested and the parameters are things that can change on different re-runs of the same template.json.
If you wanted to re-run this using powershell, (with the AzureRM module installed on your machine you’d do the following command:
new-azurermresourcegroupdeployment -resourcegroupname singlevm -templatefile .\template.json -TemplateParameterFile .\parameters.json
We can simplify this a bit further, and move everything into one file instead of two. I’ve done this previously to build an environment up from building blocks. (See here in my Github repo).
Before we tackle what I did, just a quick breakdown of a template:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
},
"variables": {
"comment": "Azure QuickStarts"
},
"resources": [
],
"outputs": {
}
}
Above is a blank ARM template. We can see sections for “parameters” (ie. User input), “variables” (things we can call further down in the resources section), “resources” (where the bulk of the declarative code is) and “outputs” (things you might want to pass out to other automations afterwards.
I usually start by creating stuff in Azure then downloading and cleaning up afterwards. Microsofts auto-created scripts are wordy, but work well. I always aim to reduce the number of parameters a user is required to specify to build something (particularly when we start building on top of this base).
Now scripts are great, but not particularly user friendly. In our next part we’ll show how to create a quick and easy front end that users can use to expand and create resources to your defined blueprint.