When the topic is IaC (infrastructure-as-code) and Azure DevOps, people get excited. They believe that by just the fact that we are using repos, ARM templates, and pipelines, we are surfing the wave just like everybody else. There are a lot of methods and procedures to implement your IaC in your organization. Unfortunately, the one size fits all does not apply with IaC. Like a diet or financial plan, it has to be right for you (and your organization). We will cover some decisions that you will have to make along your journey, and hopefully, you can clear some of them throughout this article. Do you have more topics to be discussed? Help me out and drop me a line in the comments of this article, and I will do my best to cover those topics in future articles.
The monolithic approach is when a repo has a single ARM template and parameter file to deploy the entire application through the Azure Pipelines. A good example is an ARM that deploys a virtual network, a log analytics, an Azure Key Vault, a couple of VMs, and an application gateway.
This method works well if you have simple applications that don’t require too many changes. You can’t reuse code easily in this method. You can always copy and paste, but it isn’t pleasant because it is a single file with everything.
Modular approach: More freedom for the DevOps teams
The modular approach is better when you have the same Azure resources deployed over and over across your subscriptions and repos.
A simple approach is to have an ARM template to deploy specific components (virtual network, VM, Key Vault, and so forth), and we create a set of parameter files for each environment. Our pipelines will consume the pair of files (Keyvault.json, the template, and the keyvault.prod.json, which is the parameter file) and deploy on the designated subscription.
Suppose we need to deploy in a completely new subscription/environment. We can either create a new Azure Pipeline to deploy the new parameter files to the new subscription or add a stage to the existing pipeline referencing the new environment (parameter files).
You may be asking yourself… How am I going to run all those different objects, right? The answer is simple: Create new steps in your tasks for each environment in the right sequence. For example, you need the virtual network provisioned before your virtual machines.
Azure DevOps allows tons of customization. We could easily use a repo with all the modules that we want to deploy in our organization and reference them from the repo from the application. This way, you have a central location for all your supported applications.
IaC naming convention and Azure DevOps: Take no prisoners!
Another hot topic when using IaC is around the governance applying the naming convention to your infrastructure. It is known that having a good naming convention helps to organize resources, troubleshooting, and so many other areas.
When using IaC, we have different approaches to address the naming convention problem. One method that I like, depending on the maturity of the customer, is where the customer provides general variables when deploying their resources, something like environment and region code, and perhaps application name.
Then in the ARM template, we use variables to concatenate those values and create resources using a well-defined naming convention. It simplifies deployment where just a few parameters are required. However, for unique names like Key Vault, using a third variable (like application name does help avoid conflicts).
In the example below, after creating the names for the Key Vault, we would be using the v_keyvaultName variable when assigning the name for a Key Vault resource.
Parameters: Using pipeline or file
When deploying ARM templates, a simple approach is creating a template file and a parameters file. The parameters file will provide all the information required by the template to provision the resources.
When using a release pipeline, we have both options: template (Item 1) and a parameter file (Item 2) to be selected from the list of files in the repo to be executed.
We also have a third option, which is Override template parameters (Item 3). When we click on the … button, we will have all parameters being requested by the template file. The ones in a dark color are default values in the template (we can select options if they are available in the template file), and the ones in gray are values that were entered in the parameters file. We can replace them during the pipeline execution.
What is the big deal? Well, you may get away with using template files and use variables on your pipeline. We can customize enough to provide a stage name in Azure DevOps to be a parameter for your template file.
If you think from a 5,000-foot-high view of your Azure DevOps, define your environments in the stage name, and you are using that naming convention that we covered in the previous section. You may get most of your resources being created without a single question (well, I should say parameter entry).
Azure DevOps and IaC: Our journey is just beginning
We covered some of the initial discussion points you will face when starting your Azure DevOps journey to deploy your IaC. They will be useful to foment your discussions to find something that helps to improve your process.
This article was written after some discussions with my customers. As I have more topics, I will be creating other ones to help and increase discussion on different scenarios to get more of Azure DevOps. Stay tuned!
Featured image: Shutterstock