Introduction
These days we can define infrastructure as code (ARM template)and CI/CD pipeline as code (YAML pipelines) in the Azure ecosystem. But why do we want to do these tasks as code?
There are good reasons apart from just a cool thing to do.
- Consistency. The outcome in the production environment should be exactly the same as the dev environment.
- Scalability. Imagine managing 20+ services for a large solution. You wouldn’t want to do it on the UI.
- Code review. Because they are done via code now. It can fit into the standard code review process just like the application code.
It’s relatively straight forward to deploy a simple ARM template to a single Azure environment via a YAML pipeline. But in a commercial project, it’s most likely more complex than that.
Mission Statement
At the end of this article, you should be able to:
Deploy complex ARM templates with dependencies between resources, to multiple environments.
Note: if you would like to see the full files as a reference, they are available in my GitHub repo.
Hypothesis Application
The hypothesis application is simple: an Azure function that reads a secret named Secret (yes I’m that creative) from an Azure key vault and then displays it.
For such a simple project, we need to deploy the following resources:
- An Azure function app that runs business logic.
- A storage account that is required for function apps.
- Application Insights for monitoring.
- An Azure key vault to store sensitive data.
The tricky part is the dependency between these resources. The function app should be created last because we need to set its app settings to use app insights and the key vault.
However, the key vault needs the function to exist with an identity so that it can grant the function app access to the secrets…
Which one to create first, then? The function app, or the key vault? This becomes a chicken first or egg first problem.
Or does it?
#infrastructure-as-code #devops #programming #azure-devops #software-engineering