Automated patch management with Ansible and Rundeck
summary
A six-person ops team automates patching of ~700–800 Linux servers using Ansible playbooks triggered from Rundeck jobs, with Icinga downtimes, Rocket.Chat/JIRA notifications, and VM snapshots (95–96% virtualized) for rollbacks. Production follows a four-week window, dev/test weekly, and emergency patches run on demand. Automation records a timestamp in /etc/last_patching, removes old kernels, reactivates load‑balancer checks, and updates an Ansible-generated CMDB. Live demo mostly succeeds but shows one varnish restart hiccup.
AI-written summary · about
chapters (19)
- 0:00Introduction to us
- 1:08Our company and environment
- 4:43Cloud vs on-premise patching
- 5:04Why automate patching
- 7:06Security and audits needs
- 8:50Benefits of mature process
- 9:33Tools used Ansible and Rundeck
- 11:42Patch cycles and emergency updates
- 12:03Automated patching steps
- 14:11Host preparation and service handling
- 16:45Reboot and post-reboot tasks
- 18:12Monitoring and documentation
- 19:36Impediments and recommendations
- 25:31Fixed time slots for patching
- 27:21Live demo overview
- 38:49Handling application errors
- 41:40Pain points and improvements
- 46:03Monitoring and tool limitations
- 47:37Q&A session
related talks
39mContinuous Deployment with Ansible
32mAutomating On-Call Duties with Ansible Tower
43mAutomated server management with open source tools
53mGround Truths of a Rugged DevOps Practitioner
29mGood Practices and Security for your Ansible Automation Platform 2
36mPulling the Puppet Strings with Ansible
36mMake You Ops-Life Easy – ansible usecases you didn´t out of track
42mIcinga2 Automated