Infrastructure as code is evolving in large steps to improve the way we build and manage cloud infrastructure. ARM templates is the Azure way to code the infrastructure, besides the fact it’s evolving towards BICEP.
Since January, a new feature to manage ARM templates is being tested and made available in Azure Portal: ARM Template Specs.
The Template Specs allow us to store ARM templates in Azure Portal and re-use them. These ARM templates will work as a model to build resources in our company cloud environment. In this way, we can set standards for many resources and re-use their ARM templates to make it easier to follow those standards.
Sample Template
Let’s use a sample template for a Log Analytics workspace. It’s possible that your company would like each solution to have its own log analytics workspace, so we can use an ARM template to define one.
A sample template like this can be generated from an existing service in Azure Portal, on the left menu, choose Export Template item and on the following screen we have the option to download the template.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"workspace_name": {
"defaultValue": "logs",
"type": "String"
}
},
"variables": {},
"resources": [
{
"type": "microsoft.operationalinsights/workspaces",
"apiVersion": "2021-06-01",
"name": "[parameters('workspace_name')]",
"location": "uksouth",
"properties": {
"sku": {
"name": "pergb2018"
},
"retentionInDays": 398,
"features": {
"enableLogAccessUsingOnlyResourcePermissions": true
},
"workspaceCapping": {
"dailyQuotaGb": -1
},
"publicNetworkAccessForIngestion": "Enabled",
"publicNetworkAccessForQuery": "Enabled"
}
}
]
}
Of course, this template is too simple. It could be way better, for example, include many saved queries defined as a pattern in your company.
A template like this needs to be parameterized, otherwise it would have low to no value. This sample has its name parameterized.
Creating the Template Specs
Creating a template spec is very simple, like any other simple resource in the Azure Cloud. The template spec has a versioning system, so we can control the versions of the template.
Once specified the basic information, we edit the template and that’s it, no additional secret.
It would be nice if when editing the template we could load a file from our local machine or if we could link the template spec with a git repository, maybe these could be future resources in this feature.
Creating new Versions
We can use the Create New Version button to create new versions changing the existing ones. If we already have more than a single version the UI will ask us what version we would like to use as a start point for the new one. We will be able to edit the template in the portal, creating the new version.
Deploying the Template Spec in the Portal
The deployment using the portal is very simple. Once clicked on Deploy button, we will face some typical questions about the deployment. The only difference is the parameters included on this screen.
Deploying the Template Spec in Cloud Shell
We have a few rules we need to follow to deploy the template using Powershell:
- It’s a resource group deployment, we use New-AzResourceGroupDeployment
- The resource group needs to already exist, we are deploying resources inside it
- We need to use the Id of the template spec following some syntax rules
- The parameter can be inline on the powershell statement.
- We can pass the parameter using a parameter file
This example is using the parameter inline:
$id = "/subscriptions/4d72480d-0adb-4df7-b5e3-866c027fe3e0/resourceGroups/Templates/providers/ Microsoft.Resources/templateSpecs/LogAnalyticsModel/versions/1.0" New-AzResourceGroupDeployment ` -TemplateSpecId $id ` -ResourceGroupName demoRG ` -workspace_name myLogs
We can upload a parameter file to the cloud shell storage and use it. The parameter file would be like this:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"workspace_name": {
"value": "myLog"
}
}
}
The statement to make the deployment using the parameter file would be like this:
New-AzResourceGroupDeployment ` -TemplateSpecId $id ` -ResourceGroupName demoRG ` -TemplateParameterFile ./parameters.json
Deploying as a Template Link
I believe this is the most useful one. We can use a template link to deploy the template spec as part of another template. By doing so, we can use the template spec to hold pieces of standard services and deploy them together bigger applications.
Let’s consider an example, deploying an Azure SQL Database. We only need to add to the template one additional resource to deploy the template spec:
{
"type": "Microsoft.Resources/deployments",
"apiVersion": "2020-10-01",
"name": "createStorage",
"properties": {
"mode": "Incremental",
"templateLink": {
"id": "/subscriptions/4d72480d-0adb-4df7-b5e3-866c027fe3e0/resourceGroups/Templates/providers/
Microsoft.Resources/templateSpecs/LogAnalyticsModel/versions/1.0"
},
"parameters": {
"workspace_name": {
"value": "myLog"
}
}
}
}
In this way we can use the regular template deployment in marketplace to deploy the Azure SQL Database together the Log Analytics workspace specified by the Template Spec.
What do We Miss
There are some details that would be great on this feature but they aren’t present yet:
- Integration with a code repository
- Deployment without specifying version – using the most recent
- Update the deployed services when a new version is available
Let’s see what the future has for us.
What’s around
There are many features that go to a similar result than we have here. There are different reasons to choose than. Let’s have a small summary:
Blueprints
Blueprints go way beyond, creating a link between the definition and the resources deployed. We also can use the template specs together blueprints.
However, blueprints have some strange needs and are considered deprecated. Microsoft is focusing on BICEP
BICEP
Bicep is evolving everyday. However, it doesn’t have a UI yet, it’s all code. It may have many benefits, but with the entire Azure Portal UI integrated with ARM templates, in my humble opinion it’s not time yet to replace ARM by BICEP.
Terraform
Terraform achieves the same result as blueprints, with a language accepted across multiple cloud services. However, even working in Azure it’s not so integrated on Azure Portal as the ARM templates
Load comments