Configuration Management¶

Overview¶

Configuration management is the practice of defining and maintaining the desired state of systems in a systematic, repeatable way. Instead of manually configuring each server, administrators declare what state they want (packages installed, files present, services running) and let automation tools determine and apply the necessary changes.

This approach — often called Infrastructure as Code (IaC) — enables managing systems at scale, ensures consistency across environments, provides documentation through code, and allows disaster recovery by re-applying the desired state to a fresh machine. The key principle is idempotency: running the same configuration multiple times produces the same result.

How It Works¶

The Problem: Manual Administration at Scale¶

System administration becomes truly challenging at scale. Instead of working on a single server, administrators often manage tens, hundreds, or thousands of machines. Manually configuring each one is:

Time-consuming — even simple tasks take hours across many servers
Error-prone — humans make mistakes, especially under repetition
Undocumented — manual changes are hard to track and reproduce
Inconsistent — servers drift apart over time as different people make different changes

The Solution: Desired State Declaration¶

Configuration management tools solve this by letting you declare the desired state rather than writing step-by-step scripts. Instead of:

"Install Apache, then edit the config file, then restart the service"

You declare:

"Apache should be installed, this config file should have these contents, and the service should be running"

The tool then figures out what changes (if any) are needed to reach that state. This is fundamentally different from scripting:

Scripting: "Do these steps" (imperative)
Configuration management: "This is what the system should look like" (declarative)

The Three Parts¶

Using configuration management effectively requires three things:

Learning the tool (the tricky part) — you need to understand the configuration management language, its modules, and its limitations before writing effective automation.
Understanding the steps (the annoying part) — you can only automate what you know how to do manually. You must know how to set up a web server by hand before you can automate it.
Writing the automation (the easy part) — once you know the tool and the steps, implementing the automation for a single service is straightforward.

Idempotency¶

The most important concept in configuration management is idempotency: running the same configuration multiple times produces the same result. A task should be in the changed state only on the first run and return ok on every subsequent run.

This means:

You can safely re-run your configuration at any time without side effects
You can apply the same configuration to machines in different states and they will converge to the same desired state
The tool only changes what needs to be changed

Push vs Pull Models¶

Configuration management tools use two deployment models:

Push model (used by Ansible): The administrator runs the tool from a control machine, which connects to target machines (usually via SSH) and applies the configuration. No agent software needs to be installed on managed machines.

Pull model (used by Puppet, Chef): An agent running on each managed machine periodically contacts a central server to fetch and apply its configuration. Requires agent installation and a persistent server.

Ansible Architecture¶

Ansible is the configuration management tool most commonly used with Linux servers because:

Agentless — uses SSH, no software needed on managed machines
Easy to start — YAML-based syntax is readable even without experience
First-class Linux support — especially RHEL/CentOS
Uses existing trust — SSH keys or passwords, no separate PKI needed

The core components:

Inventory (hosts file) — lists the machines to manage, grouped logically
Playbook (.yml file) — declares the desired state as a list of tasks
Modules — units of work (e.g., user, file, yum, service) that know how to achieve specific states
Roles — reusable, self-contained packages of tasks, like functions in programming
Variables and Facts — dynamic values that make playbooks adaptable to different environments

Execution flow:

Ansible reads the inventory to determine which machines to manage
It gathers facts about each machine (OS, IP, hostname, etc.)
It processes the playbook top-down, executing each task
For each task, it checks the current state, computes the difference, and applies changes only if needed
It reports results: ok (no change needed), changed (change applied), or failed

Key Terminology¶

Desired State: The declared configuration that a system should have. The tool's job is to make reality match the declaration.
Idempotency: The property that applying the same operation multiple times has the same effect as applying it once.
Infrastructure as Code (IaC): Managing infrastructure through machine-readable definition files rather than manual processes.
Playbook: A YAML file describing a set of tasks to apply to one or more hosts.
Role: A reusable, self-contained collection of tasks, templates, and variables that accomplishes a specific purpose (e.g., "set up the web server").
Inventory: A file or directory that defines the hosts and groups of hosts that Ansible manages.
Module: A unit of code that Ansible runs to perform a specific action (e.g., install a package, copy a file, manage a service).
Fact: Information automatically gathered about a managed host (hostname, IP addresses, OS version, etc.).
DRY (Don't Repeat Yourself): A software principle that applies to IaC: avoid duplicating configuration by using variables, roles, and templates.

Why It Matters¶

As a system administrator, configuration management allows you to:

Scale — manage hundreds of machines as easily as one
Reproduce — rebuild a server from scratch by re-running the playbook (disaster recovery)
Document — the playbook is the documentation of your infrastructure
Collaborate — store configuration in version control (Git) for team review and history
Exam preparation — a well-written playbook can automate an entire exam setup in minutes
Reduce errors — automated steps don't have typos or forget steps

Common Pitfalls¶

Writing scripts instead of declarations — thinking imperatively ("run this command") instead of declaratively ("this state should exist") leads to non-idempotent automation.
Not testing incrementally — write one task, run it, verify, then add the next. Don't write 50 tasks and run them all at once.
Hardcoding values — use variables for hostnames, IPs, paths, and other values that might change between environments.
Ignoring idempotency — if your tasks show changed on every run, something is wrong. Each task should converge to ok.
Not using roles — putting all tasks in one playbook becomes unmanageable. Split into roles by service (web server, mail server, firewall, etc.).
Forgetting to commit to Git — your playbook is your backup plan. If it's not in version control, it might as well not exist.
Storing secrets in plaintext — use Ansible Vault to encrypt sensitive variables (passwords, API keys). Never commit plaintext secrets to Git.