I published two articles critical of Ansible
dependencies and
handlers. If
you read those articles, you might be surprised that I really like Ansible. I
spent 10 years bumping into all the sharp corners. In that time, I managed
to create one of the most successful projects of my career, full lifecycle
management of on-prem hardware with Ansible. It started as a playbook of
re-usable tasks to perform firmware, kernel, and OS upgrades on hosts in our
infrastructure. It soon grew with my help from my colleagues to provision,
audit, decomission, and manage servers, switches, and firewalls.
Ansible made it possible for a small team of 8 to manage over 1,500 devices
with enough capacity to support development efforts and innovate our own
services and tooling. The support for remote management of blackbox devices
like firewall, load balancers, routers, and switches provide capabilities to
synchronize server changes with network and routing devices. The serial
functionality and error sensitivity make it safe to point at a big batch of
hosts and say “take these potentially destructive actions” and have it bail on
the first sign of a problem.
Ansible is an amazing orchestration framework, but it is a poor choice for
traditional CM systems where you want continual evaluation and correction to a
determined baseline. In this article, we’ll explore the strengths and
weaknesses.
In our last installment, we talked about the problem with Ansible dependency
tracking. While
annoying, the only side effect is longer run times. Ansible’s
handlers
are far more dangerous and problematic. I learned Ansible after spending 10
years working with Puppet. Ansible’s handlers seemed like a great way to
emulate Puppet’s notify API. Unfortunately, Ansible’s handlers are not
reliable and scoping means they may not cut back on repetitive processes.
Join me for a walk into madness as we collectively learn why you should avoid
handlers and what you might try instead.
I spend a great deal of time using Ansible for
both orchestration and configuration management. The Just-In-Time template
evaluations unlock elegant and efficient workflows. I automated the full
lifecycle of hardware in our datacenters, including provisioning, upgrading
firmware on devices, and safely deleting and deprovisioning devices with
Ansible. Due to the weight I ask Ansible to bear, I routinely uncover
unexpected behaviors.
One of those quirks caused slow playbook run times. When using roles with
dependencies, some parent roles execute multiple times per run. This
increases run times unnecessarily due to Ansible’s linear execution. I
developed a work-around to address it and thought you may enjoy it!