Chapter 33 Ansible: Configuration as Code
Four servers, one control node, no snowflakes: inventories, playbooks, idempotent modules, variables and facts, Jinja2 templates, handlers, roles, ansible-vault, rolling deploys behind a load balancer, debugging and ansible-lint - against real hosts over SSH.
In plain words
Imagine you run ten identical coffee shops and want the same menu board, the same opening hours and the same coffee machine settings in all of them. You could drive to each shop and change things by hand, and by the third shop you would forget a detail. Or you could write one checklist that says how every shop must look, and send someone who visits each shop, compares it with the list, and fixes only what is different.
Ansible is that checklist and that visitor for servers. You describe the desired state in YAML files (packages, files, users, services), and Ansible connects to each server over SSH, checks, and changes only what does not match. Run it again and nothing changes, because everything already matches.
Why it matters on call
Platform work is mostly about many servers being the same, and staying the same. Hand changes over SSH do not scale past a few hosts, cannot be reviewed, and leave servers that drift apart until one of them fails in a way nobody can reproduce. With Ansible every change is a file in git, reviewed like code, applied to a whole group with one command, and checked with --check --diff before it runs.
It is also the tool behind a lot of on-call work: rolling restarts, rotating a certificate on forty hosts, adding an engineer's key everywhere. And it is a common interview topic: idempotency, variable precedence, handlers, secrets in a vault, and rolling deploys behind a load balancer.
Lessons
- Why configuration management
- Inventory and ad-hoc commands
- Playbooks: plays, tasks, modules and idempotency
- Variables, facts and precedence
- Templates (Jinja2) and files
- Handlers, tags, check and diff
- Roles, collections and project layout
- Secrets: ansible-vault and no_log
- Rolling changes: serial, health checks and delegate_to
- Debugging and linting
- Ansible next to the other tools: who owns what
23 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Do the managed servers need an Ansible agent?
No. Ansible is agentless: the control node (your box) connects over plain SSH, copies a small Python program for each task, runs it with the host's Python and removes it. The managed hosts need sshd, Python 3 and a user that can sudo. That is why the lab hosts are ordinary Ubuntu servers with nothing extra installed.
What is the difference between ansible and ansible-core?
ansible-core is the engine: the ansible, ansible-playbook, ansible-vault and related commands plus the builtin modules (ansible.builtin.*). The ansible package adds a curated set of collections on top, such as ansible.posix and community.general. On Ubuntu 26.04, apt install ansible gives ansible 13.1.0 with ansible-core 2.20.1.
Is Ansible declarative or a script runner?
Mostly declarative: a task says the end state (this package present, this file with this content, this service started) and the module works out whether to act. Plays still run in order, task by task, so the order matters. The command and shell modules are the imperative escape hatch, and the chapter shows why they break idempotency unless you guard them.
Where do I run Ansible from in a real team?
From a control node: your laptop for experiments, and for real changes a shared runner (a job runner, AWX or Red Hat Ansible Automation Platform) that keeps the vault password, the SSH keys and a log of every run. Running from a shared place means everyone uses the same versions and the same inventory, and nobody's laptop is the only copy of a secret.
What happens to the lab servers after this chapter?
The chapter creates lb-1, web-1, web-2 and db-1 (and web-3 for one incident) as simulated hosts reachable from your box over SSH (simulator). When every lab of the chapter is done, the last lesson removes them, so the saved box stays small. A redo of any lab creates the hosts it needs again.