AnsibleI · Why Configuration Management ExistsCourse introduction
Welcome to Ansible for Production Sysadmins
What you'll learn
- Understand what this course means by production-ready automation
- Identify the verified software versions the course targets
- Recognise blast radius as the organising idea of the curriculum
- Know what the course expects you to already be able to do
Prerequisites
None — start here.
Verified against ansible-core 2.21.x · ansible (community package) 14.x · Python (controller) 3.12+ · ansible-lint 26.x · Molecule 26.x · Ubuntu 24.04 LTS · Debian 12 (Bookworm) · RHEL / Rocky / AlmaLinux 9.x · 2026-08-11
Ansible is easy to start and unusually easy to cause damage with. The gap between those two facts is what this course is about.
A first playbook takes about ten minutes to write. The same tool, aimed at the wrong inventory group with the wrong variables, will reconfigure every production server you own in roughly the same ten minutes — and report success while doing it. Nothing in the syntax distinguishes the two runs. The difference lives entirely in the parts most tutorials skip: which hosts were targeted, what the variables resolved to, whether anyone checked first, and how many machines could have been changed before someone noticed.
What this course is not
It is not a syntax reference. The module documentation is excellent, exhaustive, and one search away; reproducing it here would waste your time and go stale faster than this page can be updated.
The course assumes you will look up a module’s options when you need them. It concerns itself with the questions the documentation does not answer:
- Which hosts will this actually change?
- What will it change on them?
- Is it safe to run twice?
- What happens when one host fails, and what happens when fifty do?
- How do I prove afterwards what changed?
- Can I undo it?
Automation multiplies capability and blast radius equally
This is the sentence the rest of the course elaborates.
Writing a shell loop over 500 servers and writing an Ansible play over
500 servers give you the same reach. Ansible gives you better tools for
restricting that reach — inventories, --limit, serial, check mode,
preconditions — but it does not apply them for you. A playbook with no
limit and no serial batching is a fleet-wide simultaneous change with
better error reporting than a shell loop.
So the curriculum is ordered by control, not by feature. Targeting and variables come before rolling deployments, because you cannot safely stage a rollout across hosts you cannot precisely enumerate. Idempotency comes before patching, because a run you cannot repeat is a run you cannot safely resume after it fails halfway.
What is verified here
Every lesson declares the versions it was checked against, and the footer of each page renders them. This course targets:
| Component | Version |
|---|---|
ansible-core | 2.21.x |
ansible community package | 14.x |
| Python (controller) | 3.12+ |
ansible-lint | 26.x |
| Molecule | 26.x |
| Managed nodes | Ubuntu 24.04 LTS, Debian 12, RHEL/Rocky/Alma 9 |
The course teaches ansible-core rather than the bundled community
package, and pins collections explicitly in requirements.yml. That is
a deliberate choice explained in the collections part: it is the
difference between choosing your dependency versions and receiving them
as a batch.
What you should already be able to do
The course assumes working Linux administration: you can manage users and packages, read a systemd unit, find your way around a filesystem, and read a log without help.
It assumes SSH is not mysterious to you — keys, agents, and enough troubleshooting to tell “the host is down” from “my key is wrong”. A large share of Ansible problems are SSH problems wearing an Ansible error message, and the course treats that as a diagnostic skill rather than an obstacle.
It assumes basic Git. Production automation belongs in source control, and the course treats it as production code throughout.
It assumes no prior Ansible knowledge.
How to read a command in this course
Every command carries a severity badge stating what it does to the system. The badge is not decoration; it is the difference between a command you can run on a production host while reading and one you cannot.
$ ansible --versionansible [core 2.21.3]
config file = /home/ops/estate/ansible.cfg
configured module search path = ['/home/ops/.ansible/plugins/modules']
ansible python module location = /home/ops/.venvs/estate/lib/python3.12/site-packages/ansible
executable location = /home/ops/.venvs/estate/bin/ansible
python version = 3.12.7
jinja version = 3.1.4Illustrative output
Read that output as four separate facts, because each one causes its own class of “works on my controller” incident: the core version, the config file actually in effect, the Python interpreter, and the virtualenv the whole thing lives in. The controller part of the course returns to each.
Knowledge check
Knowledge check · 3 questions
Q1. Why does this course order targeting and variables before rolling deployments?
Q2. ansible-core 2.21 requiring Python 3.12 means managed nodes must also run Python 3.12 or newer.
Q3. Which of the following does Ansible give you automatically, without you configuring anything? Select all that apply.
Passing score: 75%. Answers are checked in this browser.