Sebastian Schütze
Some days ago, I wrote an article about developing ARM-Templates. In this article, I want to focus on ARM-Templates in conjunction with a build and release pipeline. With the „infrastructure as code“ paradigm even administrators need to cope with their own pipelines and make them as save as possible when deploying resources.
Even more, it is essential that you are sure as much as possible, that your declarative code is working properly. So the following tips just give my experience (which could also be limited) on what to focus on. The reader is always inclined to have its own opinion. I can’t wait to get the arguments if somebody does not agree on certain points. 🙂
1. DevOps Pipeline first, Complexity second!
First build your pipeline with a most basic starting point of an arm template that simply works. For Developer who develops any solution with CI / CD pipelines know that that already. But Operations still seem to be very new to this. The biggest problem you can have with automation is that you implement your automation too late. You could ask: “What is the problem?”. Easy, the problem is complexity. If you start early with your pipeline for ARM templates, you reduce sources of errors. This means you can identify the source of errors faster since there are less. When the pipeline is optimized in the beginning, you will have fewer problems later as well.
Imagine having an ARM template which consists of 10 resources. Have fun introducing a CD and CI pipeline to deploy to Azure that works. Especially when the deadline is 1-2 weeks away. You always want to be confident in any code you write. You won’t be if you set up your pipeline at the end of your project.
So, start your project setup with a working CI / CD pipeline!
2. Use Multiple Stage Environments before Deployment to Production
To make sure everything is in order and the actual deployment works, several stages are needed. This is common knowledge for DevOps, but what possibilities do you have regarding ARM templates? If you want to be 100% correct, you should have your own Azure Active Directory for each stage. Meaning that the resources are completely separated and free of any side effects.
But I also understand that not every company can or want to have several AAD just to separate stages. Then in my opinion resource groups are enough. You don’t need to use different subscriptions for that since they are more for billing and departmental chargebacks. In other words: governance.
Resource groups are fine as they are intended to group resources that have the same life cycle. Meaning, usually all resources that stay in context with each other and can be deleted at once if not needed.
So, in that case, you could have one subscription for that application. So you can exactly and easily see how much everything costs.
3. Use the ARM Outputs Extension for VSTS
This tip is short but very helpful. ARM template offers the possibility to return values that you create or that azure generates during resource creation.
This output can also be used with the standard possibilities in your pipeline. But you can make your life much easier. I just quote the description of the task, which says it all!
“This extension enables you to use the ARM Deployment outputs in your VSTS environment. This step will use the last successful deployment within the selected resource group. If this deployent has outputs, all of them are copied to VSTS variables by the ARM Output key. This outputs can then be used by default VSTS ways: $(same-key-as-in-arm-template) Usually this task is ran directly after the ‘Azure Resource Group Deployment’ task.”
And here you can get to the extension
https://marketplace.visualstudio.com/items?itemName=keesschollaart.arm-outputs
4. Generate temporary storage account for nested templates
Disclaimer: to fully understand this tip, I assume that you generally understood how nested templates work. If not, read the check the official documentation.
If you use nested templates, then this is probably mandatory. Probably? Yes! When you use nested templates you would submit the main template to azure. When Azure executes the template, then the portal looks for the URLs of the linked templates. Azure does expect them to be accessible within an endpoint on the internet and not in some local path. That means you either but them on a public location (e.g. GitHub) and link to those or you use for example storage accounts.
A storage account can be made secure with so-called SaS tokens (Shared access Signatures).
But if you just need this storage account temporarily then there is a small trick you can use. At the beginning of your deployment, you would deploy this storage account into Azure in a separate resource group with an ARM template that is separated from your main template. Then you would upload all needed files of the main template to Azure with the task “Azure File Copy”. This would give you the two following output to access these uploaded files:
The content of the file is basically first the absolute URL to the blob and the second would include the full URL parameters with all the tokens that you need. You just need to concatenate them and use these variables as input for your “Azure Resource Group Deployment” task.
after the deployment, you would just delete the resource group, where you deployed the azure account. Since you are recreating it every time and just upload the most recent version of your ARM template, you don’t need to have resources in Azure sitting around that you solely need at deployment time.
