Ansible Course
Why Configuration Management Matters
In this lesson
Configuration management is the practice of defining the desired state of your infrastructure in code and using tools to enforce that state consistently across every server you manage. It exists because systems left to themselves drift — engineers make one-off changes, packages get updated manually, files get edited by hand — and over time no two servers look alike, even when they are supposed to be identical. Configuration management tools like Ansible exist to reverse that drift, prevent it from recurring, and give every change a traceable, reviewable history.
The Drift Problem
Configuration drift happens gradually and invisibly. A developer SSHs into a production server to debug an issue and edits a config file without telling anyone. An automated process installs a dependency that was never in the original specification. A security patch updates a library on half the fleet but not the other half because a server was offline during the maintenance window.
Each individual change seems harmless. Over weeks and months, the cumulative effect is a fleet of servers that are all slightly different from one another — and from any documented specification. When something breaks, nobody can be certain which server's configuration caused the failure, or when the divergence happened.
Hours
spent debugging incidents caused by untracked manual changes to production servers
Unknown
state of servers managed entirely by hand — you can never be sure what is actually running
Minutes
to enforce a correct configuration across an entire fleet when using a CM tool like Ansible
Git
becomes the source of truth — every infrastructure change is reviewed, versioned, and auditable
The Fleet of Cars Analogy
Imagine a taxi company with 200 identical cars. Each driver makes small adjustments over time — one tweaks the mirror angle, another replaces a part with a cheaper alternative, a third disables a warning light. After a year, no two cars are truly identical, and the mechanics have no idea what "standard" looks like anymore. Configuration management is the service manual that says exactly what every car should look like — and the inspection process that catches deviations before they cause accidents.
Snowflake Servers
A snowflake server is one that has been configured so manually and so inconsistently over time that it has become unique — like a snowflake. Reproducing it exactly is impossible because nobody documented every change made to it. Snowflake servers are the direct consequence of managing infrastructure without a configuration management tool. The industry distinguishes between two approaches to handling servers:
Pets 🐾
Servers that are hand-crafted, individually named, and nursed back to health when they break. Every one is precious and irreplaceable. Losing one is a crisis. Common in teams that manage infrastructure manually.
Cattle 🐄
Servers that are identical, numbered, and disposable. When one fails, you replace it — not fix it. Configuration management tools make this possible by rebuilding any server from code in minutes.
The Desired State Model
The central idea behind configuration management is desired state: you declare what your infrastructure should look like, and the CM tool continuously works to make reality match that declaration. This is fundamentally different from writing scripts that perform actions — instead you describe an outcome and let the tool decide how to achieve it.
Step 1
Define desired state in code
Write a playbook or role that describes exactly what every server should look like — packages installed, files present, services running, users configured. Commit it to version control.
Step 2
Run the tool against your fleet
Ansible connects
to every managed node and compares current state against desired state. Servers that
already match report ok. Servers that have drifted get corrected
automatically.
Step 3
Review the change report
Every run produces a play recap showing which hosts changed, which were already correct, and any failures. This is your audit trail — proof of what the infrastructure looked like at any point in time.
Step 4
Repeat on a schedule or trigger
Run the playbook on a schedule or as part of a CI/CD pipeline. Drift that crept in since the last run is corrected automatically — no human intervention required. This is the self-healing infrastructure model.
Infrastructure as Code
Infrastructure as Code (IaC) is the broader practice of managing and provisioning infrastructure through machine-readable definition files rather than manual processes or interactive configuration tools. Configuration management is the subset of IaC concerned specifically with keeping running systems in a defined state.
When your infrastructure is expressed as code it inherits all the benefits of software engineering: version history, peer review via pull requests, automated testing, rollback to any previous state, and the ability to reproduce any environment exactly from scratch. Ansible playbooks stored in a Git repository are a direct application of this principle.
What IaC gives you
Configuration Management Tools
Ansible is not the only configuration management tool — Chef, Puppet, and SaltStack are the other widely-used options. Each takes a different architectural approach. The most important distinction is the push model vs the pull model.
Neither model is universally superior. Ansible's push model wins on simplicity and speed of adoption — there is nothing to install, and you can start automating existing servers immediately. The pull model wins on continuous compliance in very large environments where you want nodes to self-correct without human intervention. For most teams starting out, Ansible's approach is the right choice.
Configuration Management Is Not a Backup Strategy
A common misconception is that being able to rebuild a server from a playbook means you don't need backups. This is wrong. Ansible recreates configuration — the state of your software, packages, and settings. It does not restore data — your databases, user uploads, and application state still require a dedicated backup and recovery strategy. Never confuse the two.
Key Takeaways
Teacher's Note
If you have ever fixed a production incident by SSHing directly into a server and editing a file by hand — that was drift in the making. The discipline of configuration management is simply making sure you never have to do that again.
Practice Questions
1. What term describes the gradual divergence of a server's actual state from its intended, documented state?
2. What two-word term describes a server that has been so heavily customised by hand that it cannot be reproduced?
3. Ansible uses a push or pull model? Give a single word.
Quiz
1. Puppet and Chef use a pull model. What does this mean?
2. A colleague says: "We use Ansible, so we don't need backups — we can just rebuild any server." What is wrong with this reasoning?
3. Configuration management enables the "cattle not pets" model of server management. What does this model mean in practice?
Up Next · Lesson 3
Ansible Architecture
See how Ansible's components — control node, inventory, modules, and playbooks — fit together into a coherent system.