Automated provisioning with ARM Templates
Azure provides multiple services for cloud computing. One of the most used are VMs that serve as the hosts for your applications or databases. The existing offer of resources is incredibly high and each of them has its own configuration possibilities.
Some years ago, Azure published a feature called the Azure Resource Manager Templates, or ARM templates for short. These templates serve as a blueprint for a certain product that is intended to be hosted on the cloud.
The templates are in JSON format and define the specifications for the services you require from Azure, which can be submitted through HTTP requests to allow for integration with an application or script to further automate its usage.
This blogpost intends to provide a small overview on its most relevant features and advantages. This should help you understand how you may be able to accelerate and automate your deployment processes with Microsoft’s Azure Cloud services.
Properties of ARM templates
Declarative Syntax: ARM Templates define the whole infrastructure for your project, and you can declare not only VMs and Databases but also any other Azure resource. The number of possible options to integrate into an ARM Template can be quite overwhelming, but Azure provides its own ARM Template editor on the Azure Portal.
Automation and repeatable results
The definition of your cloud infrastructure will be declarative and in a JSON format, not requiring any UI interaction. To this effect, you can integrate the environment definition with your code-base and version it. Depending on how you set-up your build and delivery pipelines, you may deploy or upgrade infrastructures with a single “git push”
Orchestration
The ARM Templates only require the definition for each service/operation. The Azure’s Resource Manager fully handles the deployment process and also sets the most efficient order and timing for each service. In this way, your product is deployed as quickly as possible whilst avoiding any dependency errors.
Modular Files
Templates can be separated into multiple files, and they can even be encapsulated inside of each other to extend them and provide as much re-usability as possible.
Extensibility
You can integrate deployment scripts into your templates to get even more customization. For example, PowerShell and Bash scripts can be used for this effect. Subsequently, you can either keep these scripts in your template definition or save them in an external resource, which you can reference from your template. Deployment scripts give you the ability to further customize and adapt the ARM Templates to any system or setup of your liking.
There are many other advantages than to list on this post (more on the official MS documentation).
ARM Templates in action
I will try and summarize the most interesting properties:
ARM templates can be tested using a tool kit, so you can assert if your template follows the recommended guidelines. Furthermore, your templates are always validated by Azure before going through with the deployment process. Deployments can also be tracked through the Azure portal.
Microsoft also provides blueprints if you are not sure of how everything is defined. The best part of this, is that these templates can be used by Azure DevOps and your CI/CD pipelines. Further automating a project’s deployment process.
Additionally, the Azure Portal also allows you to see a resource that you created and reuse it through the UI, as an ARM Template. This is useful, when you wish to start incorporating ARM Templates in your projects, which already have configured environments to deploy on.
Example – Configuration:
Using simple ARM Template example from Microsoft Docs
Here is an example of an ARM Template, which can take parameters to extend its definition. In this case, we will make the ressource’s name a parameter:
{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "resources": [ { "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2021-09-01", "name": "{provide-unique-name}", "location": "eastus", "sku": { "name": "Standard_LRS" }, "kind": "StorageV2", "properties": { "supportsHttpsTrafficOnly": true } } ] }
This template defines a new storage account as simply as possible. Since the property „name“ needs to be unique for all resources on Azure and cannot be reused, we can define a parameter and assign it to this property:
{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "storageName": { "type": "string", "minLength": 3, "maxLength": 24 } }, "resources": [ { "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2021-09-01", "name": "[parameters('storageName')]", "location": "eastus", "sku": { "name": "Standard_LRS" }, "kind": "StorageV2", "properties": { "supportsHttpsTrafficOnly": true } } ] }
Now there is a parameter called „storageName“ available to us, to define for the template’s deployment.
Example – Deployment
Finally, if you were to deploy this template to Azure using PowerShell:
New-AzResourceGroupDeployment ` -Name addnameparameter ` -ResourceGroupName myResourceGroup ` -TemplateFile $templateFile ` -storageName "{your-unique-name}"
You would need to define:
- „-Name„
- „-ResourceGroupName“ to be created in (must be created beforehand on Azure, used to categorize billing information)
- „-TempateFile“ as the path to the ARM Template
- Additionally, you can now define the „-storageName“.
And this way you can automatically generate a new storage group on Azure, and make sure it is given a unique name.