If you are reading this, you probably already know that Azure Resource Manager should be able to access linked ARM templates via the provided URI while deploying the master template. You cannot use local files or URI locations that require some form of password-based authentication or HTTP authentication headers.
A Microsoft-suggested approach to working with linked templates is to copy them to a storage account and make them externally accessible with SAS tokens. Sounds simple enough! However, the official samples are somewhat inconsistent from my point of view: some parts are performed in ARM templates, some require PowerShell scripting, and the life cycle of the storage account for linked templates is not addressed at all.
So, how do we create a deployment solution for “private” linked ARM templates that is simple, consistent, easily repeatable and fully automated with Azure DevOps pipelines?
Prerequisites
You will need four primary building blocks for your solution:
main or “master” ARM template for deploying the services you need from corresponding linked templates;
linked ARM templates for your specific Azure services or sub-parts of your infrastructure;
an ARM template to create a storage account for deployment artifacts, i.e., linked templates and other needed files;
an ARM template for the resource group you are going to deploy into.
That’s all. No PowerShell is required unless you must perform some pre- or post-deployment tasks that might be relevant in your specific case.
Deployment order
The whole deployment process will be performed according to the following order:
Create an empty resource group for your deployment.
Create a storage account in that resource group to store deployment artifacts.
Copy linked templates and any other needed deployment artifacts to a container(s) in that storage account. Get the storage account URI and SAS token.
Deploy your main ARM template that references linked templates in the storage account.
The sample Azure DevOps pipeline to implement such deployment might look like the following:
Let’s look at the pipeline flow in detail.
First of all, pay attention to the job type – it is a good practice to run your tasks that perform actual deployment inside a deployment job. With this job type, you can implement different deployment strategies, target the environment for deployment, create gated deployments that require manual approval, etc.
Secondly, to pass the outputs of ARM deployments in the pipeline, you should specify an environment variable in Azure Resource Manager (ARM) Template Deployment tasks and use simple PowerShell to parse those outputs and create pipeline variables you can reference in the following steps. This might be very handy if you dynamically create disposable environments for testing or implement a versioned immutable infrastructure.
Thirdly, the Azure File Copy task provides options to create pipeline variables for storage account URI and SAS token. Plus, you can set an expiration time for the SAS to generate, so it is relatively short-lived and valid only for the time needed to run your deployment.
Lastly, you can use the ‘overrideParameters’ option in the Azure Resource Manager (ARM) Template Deployment task to override the deployment parameters for the storage account URI and SAS token on the fly.
The steps to test and validate ARM templates are not included in the example for the sake of simplicity. As a rule of thumb, remember to extend this starter pipeline with additional stages to perform automated testing.
Optionally, you can also add tasks to delete deployment artifacts from the storage account if performing incremental deployments or a task to remove the storage account itself.
Template linking
To repeat the described approach for deploying linked ARM templates, you should design your main templates to take the storage account URI and SAS token as input parameters. Besides, to make the templates more readable, you can construct the URIs for linked templates based on those parameters in the variables section:
Implementing this approach as a standard for your main templates will help you repeat this deployment pattern confidently and spend less time debugging referencing errors.
Boilerplate
You can use the approach described in your Azure DevOps pipelines or use the sample repository on GitHub as a draft solution for your deployment stages.
P.S. Depending on your requirements, you might decide to keep the storage account for deployment artifacts outside the deployment resource group, adding unnecessary complexity to your deployment process. If I were you, I would use a single resource group as a logical boundary for your deployments whenever possible.
