In this post I’ll share a set of linked Azure ARM templates (link) that can be used to deploy a number of Azure resources together. This sample uses externally linked ARM templates using a parent to child relationship as well as including a few “complex” scenarios like conditional logic and assigning permissions through role assignments. Note there are also two ways to deploy these templates: 1) at the subscription level (owner) and 2) at the resource group level (contributor).
<Update 2019-04-09>After reading this article on ARM template lifecycle management do’s and dont’s I’m rethinking using externally linked ARM templates. Below example still contains them but I may update to combine into a single ARM template at a later date once I’ve had a chance to test.</Update>
For a recent customer project we had a need to deploy the following resources.
- Resource group
- Azure Storage Account
- Azure Function App
- Azure Application Insights
- Azure Log Analytics workspace
- Azure Automation Account
A few of these resources have dependencies on each other such as the Function App requiring a storage account to store solution data into blobs / queues, Automation Account requiring Log Analytics for pushing diagnostic stream data to a workspace, etc. While it is possible to deploy all of these resources in one (very) large ARM template, we also wanted to be able re-use pieces and parts of this solution in future projects that are going to have a similar (but slightly different) architecture. We decided to create a set of parent-child ARM templates to mimic the first 2 levels of the above hierarchy.
The sample files are stored in my Blog-Samples repo under the ARM-External-Templates folder. There is a brief README file to walk through the necessary steps to update parameter files, upload the linked templates to a storage account, etc. This is not a fully documented process at the moment but if you wish to submit a PR or open an issue I’ll update more as I have time.
A few key pieces to highlight.
- The “Contributor” scenario assumes that the deployment account has contributor permissions to a specific resource group or subscription (more common for production or similar environments)
- The “Owner” scenario assumes that the deployment account has owner permissions to the entire subscription (ex. development environment)
- The “Owner” scenario optionally deploys role assignments (queue sender, workspace reader, and runbook operator) to various resources only if the corresponding parameter values are not empty (otherwise skip assignment)
- The Automation Account is pre-populated with a PowerShell runbook and also configured to send runbook job and stream output to the provisioned log analytics workspace
After running the deployment script the deployment and resource group should look as follows.
The linked ARM templates from this sample are meant for illustration purposes only. Hopefully you’ll find them helpful in terms of what is possible from a deployment and configuration perspective. If you have any feedback or suggestions please submit a PR on the repo or open an issue on GitHub. Good luck with automating your Azure deployments.