Rolling Ansible Patch Wave with Health Gates

Patch your server fleet safely with Ansible, one inventory group at a time, with an automated health gate between every wave. This blueprint runs an Ansible patch playbook against the first wave, probes a health check endpoint, and only advances to the next wave once the service comes back healthy. Because waves run strictly in sequence and a failed health check stops the run, a bad OS update never cascades across the entire fleet. When every wave is patched, the flow reports completion to Slack. It solves the classic rolling-update problem: how to apply apt upgrade dist style patches at scale without taking down production all at once.

How it works

• The patch_waves task (io.kestra.plugin.core.flow.Loop) iterates over the ordered waves input with concurrencyLimit: 1, forcing strictly sequential, one-wave-at-a-time execution.
• For each wave, the patch task (io.kestra.plugin.ansible.cli.AnsibleCLI) runs on the io.kestra.plugin.core.runner.Process runner. It writes an inventory.ini and a patch.yml playbook as inputFiles, then executes ansible-playbook -i inventory.ini patch.yml --limit {{ item.value }} to apply OS updates via ansible.builtin.apt.
• The health_check task (io.kestra.plugin.core.http.Request) issues a GET against health_check_url. A non-2xx response fails the task, which halts the loop before the next wave starts.
• Once all waves succeed, the notify task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a completion message including the wave count.
• A disabled monthly Schedule trigger (cron: "0 2 8 * *") is included so you can switch on recurring patch windows when ready.

What you get

• Sequential, blast-radius-limited patching across as many inventory groups as you define.
• An automatic health gate that stops the rollout on the first unhealthy wave.
• A Slack notification on successful completion.
• A ready-to-enable monthly patch schedule.

Who it's for

• Platform and infrastructure engineers running fleet-wide OS patching.
• SRE and DevOps teams who need safe, gated rolling updates.
• Anyone replacing brittle shell scripts or manual patch runbooks.

Why orchestrate this with Kestra

Ansible runs a playbook, but it has no native scheduler, no event triggers, no retry policy, and no run history across waves. Kestra adds declarative YAML orchestration around your existing playbook: schedule patch windows or fire from external events, gate progression on a live HTTP health check, retry transient failures, and capture per-wave execution lineage and logs in one place. The Loop with concurrencyLimit: 1 enforces the rolling-wave guarantee that Ansible alone cannot express, and downstream notifications keep your team informed without extra glue code.

Prerequisites

• Ansible installed on the Kestra worker, since the patch task uses the Process runner.
• A dynamic or static inventory that resolves each wave group name to real hosts.
• SSH reachability and privilege escalation (become: true) on the target hosts.
• A reachable health check endpoint that returns 2xx when the service is healthy.

Secrets

• SLACK_WEBHOOK_URL: Slack incoming webhook URL used by the notify task.

Quick start

1. Add SLACK_WEBHOOK_URL to your Kestra namespace secrets.
2. Replace the inline inventory.ini placeholder with your real dynamic inventory source.
3. Run the flow, passing the ordered list of inventory group names in waves and a health_check_url.
4. When you are confident, enable the monthly_patch Schedule trigger for recurring patch windows.

How to extend

• Swap the ansible.builtin.apt task for yum, dnf, or a custom remediation playbook.
• Add a smoke-test or canary task between patch and health_check for deeper validation.
• Replace or augment the Slack notification with PagerDuty, email, or a ticketing webhook.
• Add automatic rollback by triggering a restore playbook on health-check failure.
• Parameterize the playbook to target specific package sets or reboot policies.

Links

• Ansible plugin documentation
• Ansible orchestration with Kestra