Ansible error handling.
try/catch/finally for your plays. A failed task usually halts the host — but `block`/`rescue`/`always`, `failed_when`, `ignore_errors`, and `assert`/`fail` let you decide exactly when a play recovers, when it cleans up, and when it should stop loudly.
Ansible error handling animated tutorial. Default failure behavior where a failed task halts the affected host while others continue, any_errors_fatal and max_fail_percentage to tune the blast radius, ignore_errors and failed_when to redefine failure, changed_when, block rescue always as try catch finally with ansible_failed_task and ansible_failed_result, assert and fail to guard preconditions, meta end_play, and --force-handlers. RHCE EX294 ready.A failed task usually halts the host — but you decide how brittle a play really is. Watch a deploy fail, jump to rescue, recover, and still run its cleanup, then see what changes when the block succeeds.
- ·You can write and run an Ansible playbook
- ·Comfortable with tasks, register, and when:
- ·Know what a non-zero exit code means
Control failure in a play: tune the blast radius, redefine what counts as failed, recover with block/rescue/always, and stop deliberately with assert and fail.
pace: 9 minutes
block:run theseinstall package✓ oktemplate config✗ failedstart service— skippedrescue:catch — recovery(no rescue defined)○ idlealways:finally — cleanup(no always defined)○ idleWhat failure does by default
When a task fails on a host, Ansible STOPS running further tasks on that host — but keeps going on every other host in the play. The remaining tasks for the failed host are skipped and it drops out of the run. You tune this blast radius with `any_errors_fatal: true`, which aborts the whole play the instant any host fails, or with `max_fail_percentage`, which lets you tolerate a fraction of the fleet failing before bailing out.
$- name: template config
ansible.builtin.template: ... # → FAILED$any_errors_fatal: true$max_fail_percentage: 30By default a failed task halts that host. block/rescue/always give you try/catch/finally — recover in rescue, clean up in always — while failed_when/ignore_errors let you decide what even counts as failure. Together they turn a brittle playbook into one that fails loudly only when it should.
$(default)$any_errors_fatal: true$max_fail_percentage: N$ignore_errors: true$failed_when: COND$changed_when: COND / false$block: / rescue: / always:$ansible_failed_task$ansible_failed_result$assert: that: [..] fail_msg/success_msg$fail: msg="..." (+ when:)$meta: end_play / end_host$--force-handlers$register: resultBy default, a task fails on one of five hosts. What happens?
When do `rescue:` tasks run?
When do `always:` tasks run?
A `command` task exits non-zero, but for your case that's actually fine. How do you stop Ansible treating it as a failure?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
Ansible roles
Once a play is robust, make it reusable. Roles structure your tasks, handlers, vars, and templates into a tidy, shareable package you can drop into any playbook.
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 playbooks & YAML
Plays, tasks, and idempotency. Watch a playbook run task-by-task — ok, changed, skipped — then run it again and watch everything go green with 0 changed. 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.