Skip to main content
RunBook Academy

AnsibleI · Why Configuration Management ExistsCourse introduction

Welcome to Ansible for Production Sysadmins

Foundation⏱ ~9 minbashsshgit

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

Not yet marked complete on this device.

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:

ComponentVersion
ansible-core2.21.x
ansible community package14.x
Python (controller)3.12+
ansible-lint26.x
Molecule26.x
Managed nodesUbuntu 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.

Read-only / Safewhat the controller thinks it is
$ ansible --version
ansible [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.4

Illustrative 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

  1. Q1. Why does this course order targeting and variables before rolling deployments?

  2. Q2. ansible-core 2.21 requiring Python 3.12 means managed nodes must also run Python 3.12 or newer.

  3. 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.