Learning path · 5 lessons · about 3 h
Ansible in depth: automation at scale
You've written a playbook that set up two servers the same way, twice, with nothing changing the second time. That's the moment automation clicks. This path takes you from “a playbook that works” to automation a team can trust with a whole fleet: settings in the right places, reusable roles, encrypted secrets, careful rollouts, and tests that catch mistakes before production does.
Is this path for you?
You're ready if these sound familiar (each links to the lesson that teaches it):
- Inventories, ad-hoc commands, playbooks, templates and idempotence (Linux DevOps, lesson 4)
- Services, unit files and config tests on both families (Linux Basics, lesson 14, Linux SRE, lesson 4)
- Keeping secrets out of git (Linux DevOps, lesson 5)
- CI pipelines and linting (Linux DevOps, lesson 3)
The first one matters most. Everything here builds on that playbook.
What's ahead
| Lesson | You'll learn to… | The challenge |
|---|---|---|
| Structure | ||
| lesson 1: variables, loops & handlers | use group_vars and host_vars, understand precedence, loop, and restart only when needed | Two titles, one admin list, zero wasted restarts |
| lesson 2: roles & collections | package a setup as a role, use defaults, read module docs offline | Turn your playbook into a five-line playbook and a reusable role |
| Operate | ||
| lesson 3: Ansible Vault | encrypt secrets that live in git, and run playbooks with a vault password | A database password in plain text. Lock it up. |
| lesson 4: fleets & rolling updates | environments, groups of groups, serial rollouts with health checks | Roll version 2 across three servers, and survive a broken one |
| lesson 5: testing & linting | syntax checks, ansible-lint, idempotence and smoke tests, tags | Clean up a rushed role until every check is green |
How this path is different
- More machines. Up to four managed servers, mixing Rocky and Ubuntu, like a small real fleet.
- Less typing, more reading. You'll work with real project layouts: folders of YAML, roles and inventories. Reading someone else's automation is half the job.
- Mistakes are planted. A leftover config file, a forgotten firewall rule, a task that's never idempotent. Finding them is the point.
A note from me
Good automation is boring: it does the same thing every time, and a second run changes nothing. Aim for boring. When a playbook surprises you, slow down and find out why before you run it anywhere that matters.