Template Specs: Storing ARM templates on Azure

Comments 0

Share to social media

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

References

About the author

Dennes Torres

See Profile

Dennes Torres is a Data Platform MVP and Software Architect living in Malta who loves SQL Server and software development and has more than 20 years of experience. Dennes can improve Data Platform Architectures and transform data in knowledge. He moved to Malta after more than 10 years leading devSQL PASS Chapter in Rio de Janeiro and now is a member of the leadership team of MMDPUG PASS Chapter in Malta organizing meetings, events, and webcasts about SQL Server. He is an MCT, MCSE in Data Platforms and BI, with more titles in software development. You can get in touch on his blog https://dennestorres.com or at his work https://dtowersoftware.com

Dennes's contributions