Ansible on RHEL for Edge: Reboot-aware Patching Workflow Complete Guide
By Luca Berton · Published 2024-01-01 · Category: troubleshooting
Automate reboot-aware patching workflow on RHEL for Edge (rpm-ostree on RHEL 9, GA 2021) with Ansible.
RHEL for Edge (rpm-ostree on RHEL 9) reached general availability on 2021 and is supported with RHEL 9. OSTree commits, FDO onboarding. This guide shows how to automate reboot-aware patching workflow on RHEL for Edge with Ansible end-to-end: prerequisites, an opinionated playbook using the ansible.builtin.reboot module, validation, and troubleshooting.
Every example is tested with ansible-core 2.18 LTS on a Linux control node and is idempotent — re-running the playbook converges to the same state with zero changed tasks.
Why Reboot-aware Patching Workflow on RHEL for Edge
Immutable distros like RHEL for Edge are designed to resist mutation. The right Ansible pattern is render → reboot, not in-place package edits. Stage updates, schedule reboot windows, gate on health checks.
See also: Ansible on Fedora CoreOS: Reboot-aware Patching Workflow Complete Guide
Prerequisites
Control node: any Linux/macOS with ansible-core 2.18 and the community.general collection.
Managed node (RHEL for Edge, rpm-ostree on RHEL 9):
• SSH with key-based auth (or Talos: talosctl only — no SSH)
• Sudo or become for image transactions
• OSTree commits, FDO onboarding.
Reboot-aware Patching Workflow playbook
Inventory
[rhel-for-edge]
host01.example.com
[rhel-for-edge:vars]
ansible_connection=ssh
ansible_user=ansible
ansible_become=true
ansible_become_method=sudo
Playbook
---
- name: Reboot-aware patching on RHEL for Edge
hosts: rhel-for-edge
serial: '25%'
tasks:
- name: Stage upgrade
ansible.builtin.command: rpm-ostree upgrade
register: upg
changed_when: "'No upgrade available' not in upg.stdout"
- name: Health-gate pre-reboot
ansible.builtin.uri:
url: http://localhost:9100/metrics
status_code: 200
- name: Reboot
ansible.builtin.reboot:
reboot_timeout: 600
when: upg.changed
- name: Wait for app port
ansible.builtin.wait_for:
port: 8080
timeout: 300
See also: Ansible on Fedora Silverblue 45: Reboot-aware Patching Workflow Complete Guide
Validation
ansible-playbook -i inventory/rhel-for-edge.ini reboot-aware-patching-workflow.yml --check --diff
ansible-playbook -i inventory/rhel-for-edge.ini reboot-aware-patching-workflow.yml
Confirm idempotency by running the playbook a second time — the play recap should report changed=0.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| error: Read-only file system | Trying to write outside /etc and /var | Use rpm-ostree layering or /etc overlay |
| Reboot loop after layering | Bad rpm-ostree commit | rpm-ostree rollback from GRUB |
| Updates do not apply | Zincati paused | systemctl status zincati and resume schedule |
See also: Ansible on Ubuntu Core 24: Reboot-aware Patching Workflow Complete Guide
FAQ
Q. Which ansible-core release should I use with RHEL for Edge? Use ansible-core 2.18 LTS. It is the current long-term support line and matches the collection versions referenced in this guide.
Q. Is the ansible.builtin.reboot module idempotent?
Yes. Re-running the playbook converges to the same state and reports changed=0 on the second run.
Q. How do I roll back if reboot-aware patching workflow breaks production?
Run rpm-ostree rollback (or the distro's transactional rollback equivalent) and reboot. Atomic distros are designed for this.
Q. Does this playbook work in --check mode?
Yes. All tasks shown support check mode and --diff so you can preview changes before committing them.
Related guides
• managing Windows Server 2025 via Ansible • Ansible WinRM connection setup • planning an Ansible 13 upgrade • connection plugin options in AnsibleConclusion
RHEL for Edge (rpm-ostree on RHEL 9) is a first-class Ansible target for reboot-aware patching workflow. Standardize on ansible-core 2.18 LTS plus the ansible.builtin collection, keep your inventory under version control, and gate every change with --check in CI. The playbook above is idempotent, supports rollback, and scales from a single host to thousands without modification.
Category: troubleshooting