Build an AAP Self-Service Template: RHEL Patch Servers Maintenance Window

Why Patching Needs a Self-Service Front End

Patching RHEL fleets is one of the most routine — and most risky — jobs in any operations team. Get the timing wrong and you break a customer-facing service. Get the access model wrong and every change request turns into a ticket-and-wait cycle. At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed how Ansible Automation Platform 2.7 solves this with a new Automation Portal: a self-service template gallery where operators click Start on a card labeled RHEL - Patch Servers (Maintenance Window) without ever knowing which playbook runs, which inventory it targets, or how the job template is wired up underneath.

This article walks through what that template looks like on the platform engineering side, and how to design one that is genuinely safe to hand to a broader audience.

See also: Build an AAP Self-Service Template: After Hours Branch Access Report

What the Operator Sees vs. What You Build

The whole point of the Automation Portal catalog is to separate the consumption experience from the engineering effort. In the live demo catalog, "RHEL - Patch Servers (Maintenance Window)" sat alongside templates like "CVE Patch," "Branch - Network Health Check," and "Cloud - Provision AWS EC2 Instance" — each exposed as a simple card with a one-click Start button. The operator never touches Job Templates, Surveys, or credentials directly.

Step 1: Define the Job Template

Start with a standard AAP Job Template pointed at a patching playbook, scoped to a RHEL host group, and using a credential with least-privilege sudo access limited to patch-related commands. Because this template will be self-service, lock the inventory selection and credential at the template level — do not let the survey override them. The survey should only expose safe, business-relevant choices: which patch group to hit, whether to reboot, and the maintenance window label.

A minimal survey might ask for:

• Target group (e.g., rhel_web_tier, rhel_db_tier)
• Maintenance window (a scheduled label matching your change calendar)
• Reboot after patch (yes/no)
• Dry run (yes/no — runs dnf check-update only)

Step 2: The Patching Playbook

The playbook itself should be idempotent, respect the maintenance window, and always report what it did. Here is a representative example of the kind of task list that sits behind this template:

---
- name: RHEL - Patch Servers (Maintenance Window)
  hosts: "{{ target_group }}"
  become: true
  serial: "25%"
  vars:
    reboot_after_patch: true
    dry_run: false

  tasks:
    - name: Check for available security updates
      ansible.builtin.command: dnf check-update --security
      register: security_updates
      changed_when: false
      failed_when: security_updates.rc not in [0, 100]

    - name: Report pending updates without applying (dry run)
      ansible.builtin.debug:
        msg: "{{ security_updates.stdout_lines }}"
      when: dry_run | bool

    - name: Apply latest security patches
      ansible.builtin.dnf:
        name: "*"
        security: true
        state: latest
      when: not (dry_run | bool)
      register: patch_result

    - name: Determine if a reboot is required
      ansible.builtin.command: needs-restarting -r
      register: reboot_check
      changed_when: false
      failed_when: reboot_check.rc not in [0, 1]
      when: not (dry_run | bool)

    - name: Reboot host if required and approved
      ansible.builtin.reboot:
        reboot_timeout: 600
      when:
        - not (dry_run | bool)
        - reboot_check.rc == 1
        - reboot_after_patch | bool

    - name: Record patch run summary
      ansible.builtin.set_fact:
        patch_summary:
          host: "{{ inventory_hostname }}"
          window: "{{ maintenance_window }}"
          changed: "{{ patch_result.changed | default(false) }}"
          rebooted: "{{ reboot_after_patch | bool and reboot_check.rc == 1 }}"

The serial: "25%" batching is deliberate — it keeps the blast radius small if a patch set introduces a regression, and it maps naturally onto the "maintenance window" framing operators expect from the template name.

See also: Build an AAP Self-Service Template: Backup Network Switch Configs to Git

Step 3: Wire It Into the Automation Portal

Once the Job Template and survey are validated in Automation Controller, publishing it as a self-service card in the Automation Portal is largely a naming and description exercise:

• Card title: RHEL - Patch Servers (Maintenance Window) — matches exactly what was shown at Red Hat Tech Day Netherlands 2026, so operators searching the catalog find it immediately.
• Card description: something operator-facing like "Apply the latest security patches during a scheduled window."
• Access control: grant the requesting team's RBAC role only the Start permission on this template, not edit rights on the underlying Job Template — this is what makes the model self-service rather than self-managed.
• Audit trail: every Start action still produces a normal Job run in Controller, so approvals, logs, and job output remain fully auditable even though the operator experience is a single click.

Comparing Approaches to Exposing This Template

Key Takeaways

• The "RHEL - Patch Servers (Maintenance Window)" card is a thin, safe front end over a normal AAP Job Template — all the real control lives in the survey and template configuration, not the portal card.
• Lock inventory and credentials at the Job Template level so self-service only ever exposes business-safe choices like target group, window, and reboot behavior.
• Use serial batching in the underlying playbook so a scheduled patch run stays contained even when triggered by a non-platform team.
• Every self-service Start action still generates a fully auditable Controller job, which is what makes this pattern viable for regulated RHEL estates.
• This pattern generalizes: the same card-plus-locked-survey approach that works for patching also works for the "CVE Patch" and network remediation templates shown in the same Automation Portal catalog.