Automate Infra deployment with ARM
Migration to the cloud enables tons of new capabilities to manage IT infrastructure. Not using these features is not a crime, but makes you someone who uses only one blade of a brand new Swiss army knife. One of the most powerful “blades” of Microsoft Azure is ARM – Azure Resource Manager. This service allows deployment automation and scaling of your Azure infrastructure, saves hundreds of your operations teamwork hours, and even gives your organization an opportunity to implement the best DevOps practices.
Our DevOps team in VIAcode designed and deployed few interesting solutions and want to share their experience related to Azure Resource Manager. Recently they presented “Automate Infrastructure Deployment with Azure Resource Manager” webinar. Based on the webinar session, we prepared this reading material.
We’d like to split our article in two parts (two articles):
- In first part, we will review Azure Resource Manager and – what is more important - its templates. This is our baseline to see how this service will help us.
- And in the second part, we will discuss two case studies from real world projects where VIAcode team implemented automated IaaS and PaaS infrastructure deployment based on Azure Resource Manager templates.
Introduction to Azure Resource Manager.
Before jumping to Azure Resource Manager templates discussion - or abbreviated, we can call it
ARM templates, we need to answer two questions:
- What is Azure Resource Manager?
- What are the key ARM elements?
At the beginning, let’s demonstrate the value of ARM on a simple example of house building. Imagine that a builder Joe needs to dig a pit for house foundation and he tries to work with a shovel.
How long will he be digging? Is it an effective method?
What if this builder uses another tool? Excavator!
Its bucket looks like a big operational ARM!
So now, things are much better and faster!
Azure Resource Manager is our automation excavator, which helps to deploy and configure resources in Azure faster and easier! With this mindset, let’s go further.
So the first question:
What is Azure Resource Manager?
ARM is a management layer in the middle between actual resources and user’s tools.
ARM API is used to access the resources through providers.
ARM is a single point of management and it does not matter what supported tools are used – they just request ARM API and the APM engine does the entire marvel behind the scenes.
Consider ARM as a clever automation orchestrator service which helps manage either single resource or resources grouped together to deliver business application.
The next question we need to answer:
What are the key ARM elements?
Resource provider - Each resource provider offers operations and resource types for working with the resources that are deployed. Some common resource providers’ namespaces are
- Microsoft.Compute, to manage the virtual machine resource type
- Microsoft.Storage to manage the storage account resource type,
- Microsoft.Web, to manage web apps resource types.
On the current state, there are about 146 providers, 31 developed by partners and 115 by Microsoft. Be aware, in time of the article reading, actual list of resource providers available may vary. If you want to know what resource providers available in your Azure Subscription, just run PowerShell cmdlet “Get-AzureRmResourceProvider –ListAvailable” from the “AzureRM.Resources” module.
Resource - A manageable item/instance that is produced through corresponding resource provider. Some common resources are a virtual machine (Microsoft.Compute), storage account (Microsoft.Storage), web app (Microsoft.Web), database (Microsoft.Sql), and virtual network, log analytics workspace, diagnostics settings, alerts and so on.
And the third element:
Resource group - A container for Azure resources.
The resource group can include all the resources for the particular application, or only those resources that you want to manage as a group. For example, for the demonstration or testing application environment, simply to use one resource group and clean up after the experiments. However, for production application, which consists of few tiers and may be change separately, better solution to split application tiers to different resource groups (web tier to one resource group, database tier to another)
Important! Be aware, one resource can reside on one resource group! Resource can be moved from one resource group to another.
Another vital role of the resource groups to act as is a unit of management Resources lifecycle operations like deployment or update are always targeted at Resource group level. Note! On the moment of the article writing, Microsoft introduced Subscription level deployment. The intention of such management trick, to create initial resource group programmatically through ARM templates and then run deployment of resources from the same template targeted at the newly created resource group. So, the actual resources (like Azure virtual machine or Azure SQL database) ultimately deploying to the particular resource group.
Ok. Now we are ready to move on to the ARM templates overview.
ARM Templates overview
Think of an ARM template as a detailed construction plan, which Joe will investigate and use to build the house.
Syntax of the ARM templates is declarative.
What does it mean?
You focus only on the intention, like “I need a big white house with 2 floors” instead of particular steps and checks during every step.
You can see it on the image diagram below.
Storage Account properties, next Virtual Machine properties and dependency on Storage Account (which means, that VM will not be deployed until Storage Account has not been provisioned) and finally Extension resource dependent on Virtual Machine deployment. The “DependsOn” property used here to orchestrate the order of the deployment and the extension applied to configure the deployed resources.
As a result of this example, ARM will deploy Storage Account and Virtual machine as a complete application, rather than just a bunch of Azure resources.
By the way, right now ARM supports several popular configuration management tools as extensions. Among them are PowerShell Desired State Configuration, Chef, Puppet Agent, and Octopus Tentacle agent.
In addition, one important note about ARM templates!
What does it mean?
Simply it means, when the same template is executed, the result should be the same each time. Only the required changes are applied to the resource. Therefore, ARM templates perfectly fit into the DevOps “Infrastructure as Code” practice.
Now let’s review the template structure.
As you can see on the upper image – by the way it is an empty template – on this particular example there are six blocks inside the curly braces.
“$schema” – Defines the template language file URL. It is mandatory element. “contentVersion” – Version of the Template itself. It is mandatory element, but increment of the version value is not required.
“parameters” – Inputs values, like in scripts. Not required.
“variables” – Used to simplify deployment through creation of needed strings, again like in traditional scripts. Not required. You can leave it unfilled.
“resources” – This block is dedicated to declare the resource types which will be deployed or updated. It is a mandatory element.
“outputs” – Results after deployment can be seen in outputs section. Not required.
There is another element - “functions”, which is not shown here. Basically, “function” is a user defined named expression that can be called in the template body.
Let’s see a simple example from a virtual machine template.
On the upper image is a minimized example of a simple Windows virtual machine template (186 lines of code).
This template contains storage account, virtual network, network interface, public IP address and virtual machine resources definitions.
To examine VM related resource, we can view image below.
Do you remember we discussed resource providers and resource types? As you see here, the “type” property contains value, which consist of resource provider name “Microsoft.Compute”, slash, and resource type. In this case “virtualMachines”. In addition, the virtual machine will not be deployed until storage account and network interface are created (“depensOn” section). There are others properties related specifically to VM deployment, such as VM size, admin user name and password, provisioning image profile and so on.
Ok. Now you know what ARM and templates are. One last question might be interesting to us:
How to run execution of the template?
Many tools can be used.
Some of them we will discuss in the case studies article (part 2).
Here is a list. Use what is comfortable or applicable in your environment.
- Azure CLI v2
- Azure Portal (GUI)
- Azure Resource Manager API
- SDK (.NET, Python, Java)
- Visual Studio Team Services
- 3d party tools (Ansible, Terraform and others)
That is all we wanted to share as an introduction to ARM and its templates. On the next article we will discuss two real world Azure projects, ARM benefits and projects pitfalls.
If you have any questions related to Azure Resource Manager, please, send us email to email@example.com and visit azure.DO – DO stands for DevOps.