Configuration Management (Ansible)

Ansible is an agentless configuration-management tool that drives a host to a declared desired state over SSH, replacing hand-built snowflake servers. Idempotency is central: a play declares the end state, not steps, so re-running it converges the host and reports changed only when it changed something.

A role is a reusable, self-contained bundle of Ansible automation with a fixed layout, so many playbooks include it by name rather than copy-pasting tasks. Under roles/<name>/ it holds subdirs Ansible auto-loads: tasks/, handlers/, templates/, files/, plus vars/ and defaults/ (lowest precedence) and meta/.

Ansible is push-based and agentless: the control node SSHes into each inventory host, copies the module code over, runs it with the target's Python, and uses become (sudo) for privileged tasks — no daemon is installed. A fresh host needs only SSH and Python. Pull tools like Puppet or Chef instead run an agent per node that polls a central master on a schedule.

Prefer a native module almost always: package, service, copy, file and template are declarative and idempotent — they check the host's current state and act only if it diverges, reporting changed accurately. A raw command/shell just executes and reports changed every run. Use command only when no module fits, and guard it with creates:.

Every task uses shell/command, which just runs and reports changed unconditionally — Ansible cannot see the state behind a raw command, so it never converges. Fix it with native, idempotent modules: file: state=directory, get_url, and apt: name=nginx state=present. When a command is unavoidable, guard it with creates: or changed_when:.

By default Ansible runs a play across all matching hosts in parallel (up to forks), so a bad change hits all at once. serial: batches the rollout — serial: 1 or serial: 25% updates that many hosts per wave, so you canary a batch, verify, then proceed. Pair it with max_fail_percentage to abort on too many failures, and drain each batch from the load balancer.

Ansible Vault encrypts sensitive data at rest with AES-256 so it can live safely in the repo: you ansible-vault encrypt a vars file or values, and Ansible decrypts them at runtime given the vault password (via --ask-vault-pass or a password file). Never commit plaintext — commit only the encrypted form, and keep the vault password out of Git.

Extra-vars passed with -e have the highest precedence — they override every other source, which suits one-off overrides. Role defaults/ sit at the very bottom, the weakest source, overridden by inventory, group_vars, host_vars or play vars. So -e always wins; a defaults/ value applies only when nothing higher sets it.