Ansible playbooks & YAML.
A playbook is desired state written in YAML: plays map hosts to tasks, and tasks call modules that converge the system. Watch a play run and read its ok/changed/skipped output, then run it again and watch `changed` drop to zero — the idempotency that separates Ansible from a shell script.
Ansible playbooks and YAML animated tutorial. What a play is, the anatomy of a play with name, hosts, become, vars and tasks, YAML indentation rules, running ansible-playbook and reading the ok, changed, skipped, failed and unreachable statuses, the PLAY RECAP, idempotency proven on a second run with changed=0, dry runs with --check and --diff, stepping through tasks with --step and --start-at-task, extra vars with -e, and targeting hosts and tasks with --limit and --tags. RHCE EX294 ready.A playbook is desired state in YAML: plays map hosts to tasks, tasks call modules. Watch a play run, read the ok/changed/skipped output, then run it again and watch changed drop to zero — that's idempotency.
- ·You can reach a fleet (control node + inventory + ping)
- ·Comfortable with the Linux shell + dnf/service
- ·Know what YAML looks like — key: value, lists, 2-space indent
Read and write a basic playbook, run it, interpret the ok/changed/skipped output and PLAY RECAP, prove idempotency on a second run, and debug a run with --check, --diff, --step and tags.
pace: 12 minutes
[Gathering Facts]…[install httpd]…[start httpd]…A playbook is desired state, written in YAML
A playbook is an ordered list of PLAYS. A play maps a set of hosts to a list of TASKS, and each task calls a MODULE that does the actual work. It's declarative — you describe the end state you want (httpd installed, service started), not the shell steps to get there. Ansible figures out whether reality already matches and only acts when it doesn't.
$ansible-playbook site.yml$ansible-playbook site.yml --syntax-check$ansible-navigator run site.ymlA playbook describes the desired END STATE, not a sequence of commands — so running it twice is safe and the second run changes nothing. That idempotency is the dividing line between Ansible and a bash script: a script blindly re-runs every command, while a playbook checks reality first and only acts on the drift.
$ansible-playbook site.yml$--syntax-check$--check$--diff$--list-tasks$--list-hosts$--list-tags$-v / -vvvv$--step$--start-at-task="X"$--limit HOST / -l$--tags X / --skip-tags Y$-e "k=v"$play keys: name/hosts/become/vars/tasks$PLAY RECAP: ok / changed / unreachable / failed / skippedWhat does it mean for a playbook to be "idempotent"?
Your playbook fails with a YAML parse error. What's the most likely cause?
What does `ansible-playbook site.yml --check` do?
On the second run of a working playbook the PLAY RECAP shows `changed=0`. Is that good or bad?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
Ansible core modules
Tasks are just names; the modules do the actual work. Meet the everyday verbs — file, user, dnf, service — and the idempotent state= pattern that runs through all of them.
keep going — these pair well with what you just learned.
Ansible control node & inventory
Ansible is agentless — one control node pushes work to a fleet over SSH. Install ansible-core, write an inventory with groups, ping the fleet, and fire ad-hoc commands. RHCE-ready.
Ansible core modules
file, user, copy, dnf, service — the modules that do the real work. Declare the desired state and let Ansible converge to it, idempotently. RHCE-ready.
Ansible variables & facts
Which value wins when the same variable is set in five places? Variable precedence, gathered facts, and ansible_facts — visualized as a ladder. RHCE-ready.