This week we saw a significant update to the ARM template for Cosmos DB, which now allows us to create databases and containers. Up until now, we’ve only been able to create Cosmos DB accounts using templates, we then had to create the databases, containers, tables etc. through PowerShell or the portal etc.
With this update, we are now able to deploy much more of our Cosmos setup with ARM templates, including databases, containers, graphs, namespaces and tables.
This is a relatively new feature in Azure Resource Manager Templates that I wasn’t aware of until someone mentioned it to me today. It is now possible to catch the failure of an ARM template deployment and then trigger running a previous version of the template when this happens. I’m hesitant to call this a roll-back (even though the docs do), as there are some limitations that mean it’s not really a full roll-back, but it could be a useful tool to deal with failed deployments.
Generate SAS Tokens in ARM Templates Without much fanfare, MS recently updated the ARM template spec to allow the creation of SAS tokens inside a template. This is excellent news for anyone who is deploying resources with ARM templates that rely on storage accounts and need a SAS token to access them.
For those not familiar with SAS tokens, you can read more on them here but essentially Shared Access Signatures (SAS) provide a way to generate a key to undertake operations on a storage account, without needing the actual storage account key.
If you are writing ARM templates to deploy your Azure Infrastructure, then it’s more than likely you are utilising some of the functions provided by the ARM language. Functions allow you to perform simple operations inside your template to transform or creation values that you use in your deployment. Some of the most common ones you’ll see include:
Concat - for joining strings, regularly used to join parameters, variables and constants together to form resource names, app settings, connection strings and so on.
If you are working with Azure then ARM templates are a great way to define your resource and deploy them declaratively. However, if you find you need to do anything other than creating Azure resources as part of your deployment, then you are a bit stuck, as ARM templates don’t offer any way to call external resources or run scripts.
An example that we will use for this rest of this article is something I needed to do recently.
While you can create an Azure Storage account with an ARM template very quickly, it’s not been possible to create anything inside this storage account, such as blob containers, tables, queues, using the same ARM template. If you wanted to do this, you either needed to look at running scripts after your template completes, or using something like Terraform, which does allow you to create these things.
However, a recent update to the ARM schema means you can now create Blob containers in your template.
Last weeks Ignite conference came with lots of new Azure announcements if you want to see them all make sure to check out my announcement summary. One of these announcements that seem to go somewhat under the radar was Azure Resource Graph, but I think this could be a handy tool for Azure administrators.
Resource graph as a new service which allows you to explore your Azure resources using a command line tool and a new query language.
Ever since they were released, ARM templates required you to supply the name of the Resource Group you want to deploy to as part the deployment command. This restriction meant that the Resource Group always needed to exist before running your deployment. I mentioned in my article on Terraform that one of the advantages of this is that you can create the resource group as part of your deployment template, no need to create it separately.
Some new functionality for ARM templates was announced at the recent Build conference, one of these was user-defined functions. What this lets you do is create re-useable functions that you can call inside your template. You’re still limited to using the built-in ARM functions inside your function, but you can use functions to help simplify your templates and reduce errors.
Let’s look at an example, in a lot of my templates I am feeding in a “prefix” string which I then use for naming my resources.
Most example ARM templates use a single JSON file to contain all of the deployment details in a single file. This works fine for smaller deployments, but once you start doing larger deployments, working in teams, or wanting to re-use parts of your deployment templates then you really need to start looking at nested templates.
Nested templates describes the process of calling an ARM template from inside another. In this way you can separate your logic into multiple files, call these files as required and pass parameters and results between templates.
