AnsibleByExample

Ansible Orchestrator Example: Rolling Remediation Across Multiple Hosts

Beginner
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

Red Hat's upcoming Automation Orchestrator (coming Q3 2026) wraps AI-driven investigation and human governance around Ansible Automation Platform (AAP), so that "AI isn't improvising against production infrastructure, it's acting through AAP." The pipeline runs five stages — alerts, event-driven trigger, AI analysis, human approval, and automated remediation — and this example focuses on that last stage: Step 5, where the approved plan actually touches hosts.

Step 5 config: rolling remediation job template

# orchestrator-step5-remediation.yml
# Automated remediation stage: executes the human-approved plan
# via an existing AAP job template, in rolling batches.
name: cve-2024-6387-openssh-remediation
step: 5
type: job_template_launch
job_template: "Patch OpenSSH - regresshion (CVE-2024-6387)"
inventory: production-linux-hosts
limit: "host_group_openssh_affected"
credentials:
  - "Production SSH Key"
job_slicing:
  strategy: rolling
  batch_size: 4
  batches: 3
  max_fail_percentage: 0            # abort the workflow on any batch failure
extra_vars:
  target_service: sshd
  package_name: openssh-server
  perform_health_check: true
  rollback_on_health_check_failure: true
notifications:
  on_success:
    - itsm_update: "INC0038291"
      status: "Resolved"
  on_failure:
    - itsm_update: "INC0038291"
      status: "Remediation failed - manual review required"
audit:
  log_execution: true
  attach_to_ticket: "INC0038291"

What it does

This step definition tells the orchestrator to launch an existing AAP job template — not an ad-hoc script — against the host group the AI agent correlated from inventory during Step 3. job_slicing splits the affected fleet into rolling batches instead of a single big-bang push: with 12 hosts across prod, staging, and dev, that's 3 batches of 4. Each batch patches openssh-server, restarts sshd, and runs a health check before the orchestrator proceeds to the next batch. max_fail_percentage: 0 means any failed batch halts the rollout immediately rather than continuing to hammer the rest of the fleet — the deterministic, auditable behavior the platform is built around.

The notifications and audit blocks close the loop back into ITSM: the same ServiceNow ticket that triggered the workflow (INC0038291) gets updated and closed automatically, with the execution log attached for compliance review.

Step 5 only runs after the governance gate in Step 4 clears. That gate has its own configurable shape:

human_review_gate:
  step: 4
  notify_users:
    - "sre-oncall"
    - "security-lead"
  message: "Please approve this deployment to production"
  timeout: 1d
  on_timeout: fail_workflow   # never auto-approve on timeout

In the Red Hat Tech Day Netherlands 2026 demo of this exact CVE-2024-6387 ("regresshion") remediation, that manual review took 38.4 seconds — everything else in the 8-step run (alert ingestion, ITSM ticket creation, vulnerability analysis, remediation execution, ticket close) added up to under 10 seconds of automated time.

Notes

  • job_slicing.batch_size and batches should match your host group's actual size — miscounting here either leaves hosts unpatched or creates an empty final batch.
  • max_fail_percentage: 0 is the safe default for security remediations; raise it only for lower-risk, higher-host-count rollouts where a few stragglers are acceptable.
  • on_timeout: fail_workflow on the review gate is deliberate: the platform never silently auto-approves a production change just because nobody responded in time.
  • Step 5 is only as trustworthy as the job template it launches — the AI agent in Step 3 matches an existing remediation job template rather than generating new automation on the fly.

Takeaway

Step 5 is where governance meets execution: the orchestrator hands a human-approved plan to a rolling AAP job template, batches it across the fleet with a hard failure threshold, and closes the loop in the ticketing system — all without a human ever touching a host directly.

References

All Tutorials