Automation · Unattended Operations
Ansible is how it gets done. What it achieves is patch nights, server builds, firewall resets and out-of-hours changes that test themselves, roll themselves back, and tell you how it went in the morning.
web
app
db
edge
last run
ok · 20/20
drift fixed
3 changes
humans woken
0
Patch night, replayed
Anyone can run 'yum update' on a loop. This is what a patch night looks like when the runbook raises its own change, silences its own alerts, proves each host works, and deals with the one that doesn't.
02:00:00 · ready
fleet · 12 hosts · rolling batches of 4
web
idle
idle
idle
idle
app
idle
idle
idle
idle
db
idle
idle
idle
idle
patched
0
rolled back
0
pages sent
0
runbook
Step 2 and step 10 are the same test. If a host cannot pass after patching what it passed before, it is rolled back and named in the notification. Nothing silently limps on.
The change record is created before the first host is touched and closed with the recap. Auditors get a trail; engineers do not get a form.
Rolling batches by role and availability zone mean the service stays up throughout. A failure in one batch never spreads to the next.
Beyond patching
The patch run is the showcase. The same discipline, a test before and after every change, applies to everything on this list.
01
A new host is a playbook run away from production-ready: fail2ban, firewalld, dnsmasq, hardened sshd, users and keys, time sync, agents. Rebuild a box and it comes back identical. Drift is a bug, not a state.
02
Rules drift because people are helpful at 4pm. A scheduled run puts every host back to the nominal rule set each night and reports what it had to undo. Emergency holes close themselves.
03
Because each change is followed by the same test that proved the service worked before it, the playbook can apply, verify and regress on its own. Change at 02:00, read the summary at 09:00.
04
Restart a service, rotate a cert, add a vhost: wrapped as a job with a form, role-based access and a full execution history in AWX or Rundeck. The ticket queue shrinks because people can do it themselves, safely.
05
Every run raises its own change in ServiceNow or Jira, puts the affected hosts into downtime in the monitoring platform, and lifts it when the verification passes. Audit trail included, nobody typed it.
06
Vendor appliance with only a clunky web UI? Internal tool with no API? We write the module. Custom Python modules and lookup plugins are how the last 10% stops being manual.
Automate the automation
Ansible on its own is a very good command-line tool. Put AWX or Rundeck in front of it and it becomes a system: schedules, approvals, role-based access, execution history, and a browser where the playbook can be read and run by people who never open a terminal.
The interesting part is the edges. The scheduler can be a cron entry, a webhook from your CI, or a ticket reaching a certain state. The run talks to the CMDB before it starts and to the monitoring platform while it works. The result lands in chat, email and the ticket without anyone copying and pasting.
Combine the two and you get pipelines that apply a change out of hours, test it, and regress it if the test fails, with no user input at all.
Pick your control plane
Chef and Puppet ship a nice interface because they need an agent on every host. Ansible does not need the agent, so it does not ship the interface. These two put it back.
| AWX | Rundeck | |
|---|---|---|
| Best for | Teams standardising on Ansible end to end | Ops teams orchestrating many tools, not just Ansible |
| Heritage | Upstream of Ansible Tower / Automation Platform | Java-based operations console with its own job engine |
| Ansible integration | Native: projects, inventories, credentials, surveys | Plugin: runs playbooks alongside scripts, SSH, HTTP |
| Talks to other tools | Limited by design | Wide: plugins for most things you already run |
| Exposure | Keep it internal | Built with public exposure in mind, with access control to match |
| Our take | Pick it when Ansible is the whole story | Pick it when Ansible is one of many actors |
Agentless, on purpose
Nothing to install, nothing to keep patched on 400 hosts, nothing that can fall over and take your automation with it. SSH and WinRM already exist; Ansible uses them. The trade-off is the missing interface, and that is exactly what the control plane restores.
Questions
Yes. Ansible manages Windows over WinRM or SSH with the same playbooks, inventories and scheduling. Patch nights covering mixed Linux and Windows estates in one run are normal.
No. Working scripts become tasks inside a playbook, gain idempotency checks, logging and a place in the schedule. We rewrite what is fragile and keep what is not.
The same thing that happens in the replay above: the post-change test fails, that host is rolled back or fenced, and the run continues with the rest. Before it ever gets there: check mode, a canary batch, and a review on every change to the playbook itself.
That is the point. Playbooks live in your git, jobs run in your AWX or Rundeck with role-based access, and the hand-over includes a walkthrough. We would rather you did not need us for the routine parts.
Ansible Vault, or your existing secret store (HashiCorp Vault, cloud secret managers) via lookups, injected at run time by the control plane. Nothing in plain text in a repo, nothing on a developer laptop.
Open source across the board: Ansible, AWX and Rundeck are free to run. The ongoing cost is a small VM or container for the control plane and the time to review changes, which the execution history and reports keep short.
Next step
We'll show you what it looks like when it doesn't. A short call, then a prototype in your environment.