Nordlicht Reisen GmbH, a fictional travel agency, is building three environments for the booking portal: development, test and production. Until now someone has created the resources in the portal and kept the differences between the environments in their head. After the third error that occurred only in production, the infrastructure itself is to become source code: in the repository, with review, with tests and with a pipeline that rolls it out. Those are the skills of this lesson: recommend and implement configuration management and design an IaC strategy (source control, automating test and deployment).
Prior knowledge: You know the Bicep language, modules, parameter files and environments with azd from K3, module 3.2 (lessons 3.2.2, 3.2.3 and 3.2.6). What-if, its noise, complete mode and deployment stacks are in K3, lesson 3.2.4; this lesson doesn't repeat them. K3, lesson 3.7.6, shows approvals before the deploy, and lesson 2.2 shows pull request rules. This lesson asks: Which tool for which task, and what does the pipeline look like that rolls out infrastructure safely?
Not run against Azure or GitHub; from Microsoft's reference: All commands, YAML and Bicep files of this lesson come from Microsoft's documentation (some of them adapted) and were not run in this course. Names in angle brackets are placeholders.
Recommending configuration management
Two things are called "configuration" in everyday speech. Infrastructure is which resources exist: network, database, app. Configuration in the narrower sense is how a machine or a service is set up inside: operating system settings, installed software, application settings. Microsoft's guide to tools for virtual machines therefore sorts the tools by task:
- Automate the configuration of VMs: Ansible, Chef, Puppet, Bicep and ARM templates; specifically for VM customization cloud-init (Linux), PowerShell Desired State Configuration (DSC) and the Custom Script Extension.
- Automate the management of the infrastructure: Packer (build your own VM images), Terraform (build the infrastructure), Azure Automation (actions across Azure and on-premises infrastructure).
- Application deployment and delivery: Azure DevOps Services, Jenkins (lesson 4.11).
The tools compared
| Tool | What Microsoft says about it | Typical task |
|---|---|---|
| Bicep | domain-specific language with declarative syntax for Azure resources; concise syntax, type safety, code reuse | create and change Azure resources |
| Terraform | open-source tool from HashiCorp; describes the topology of cloud resources in the configuration language HCL; templates from other platforms can be used with Azure without translating them into an ARM template | infrastructure across several platforms with one format |
| Ansible | automation engine for configuration, VM creation and application deployment; agentless, usually with SSH keys; tasks are written in playbooks | configuring machines from the outside |
| Chef | automation platform; Chef clients on the target machines, one or more central Chef servers store the configurations; Chef InSpec checks compliance | configuration with an agent and a central server |
| Puppet | platform for delivery and deployment; agents on the target machines, the Puppet master runs manifests that describe the desired state | like Chef, with manifests |
| PowerShell DSC, Machine Configuration | establish and check the desired state in the operating system | lesson 4.13 |
| Azure App Configuration | configuration service for PaaS applications that can itself be deployed with IaC | application settings, feature flags (lesson 4.10) |
Microsoft's guide to designing good operational procedures (Well-Architected Framework) says what holds up as a decision: Use the right tool for the job. Bicep for deployment is not the best tool for every management task. For the desired state of VMs, the guide names Ansible as an example, for Kubernetes clusters Flux, for PaaS services the platform's configuration services (such as Azure App Configuration), which in turn you deploy with IaC. SaaS services are often more restricted because the platform controls them more tightly. Standardize on tools that cover all tasks in your scope and fit your development and management practice.
Declarative, imperative, idempotent
Three words come up in every question about IaC. Imperative describes steps ("install this, change that"), declarative the end state ("this is what it should look like"). Microsoft's introduction to IaC recommends declarative definition files where possible: A file describes which components and settings an environment needs, not necessarily how to get there. That leaves the provider room for optimized procedures and reduces the technical debt of imperative deployment scripts. There is no uniform syntax for declarative IaC; it depends on the target platform (formats such as YAML, JSON, XML).
Idempotence is the ability of an operation to always deliver the same result. Microsoft: A deployment command always puts the target environment into the same configuration, no matter what it looked like before. This is achieved by configuring the existing target automatically or by discarding it and creating it fresh. That is why IaC solves the problem of environment drift: Without IaC, every environment becomes a "snowflake," a configuration that can't be reproduced automatically. With IaC, the team changes the source, not the target.