Server configuration goes both ways…

For most of the past decade, I did my server management primarily with Puppet. Servers being orchestrated by Puppet work on a “pull” model — they periodically contact a central server (colloquially called the puppetmaster), and request info on how they should be configured.

The new employer does things very differently — they primarily use Ansible, which works on a “push” model. When you need to make a configuration change, you actively tell the servers what changes to make and what actions to take.

Is one right and the other wrong? Of course not. But they’re very different, both have ups and downs.

The “pull” model (as Puppet implements it) is pretty much automatic. The Puppet agent phones home on a schedule, and downloads updated configs. You don’t have to think too much about it, just set and forget. That also can be a downside, in that changes will be picked up pretty quickly by your servers. A mistake could propagate pretty quickly. (There are ways to mitigate this, but if you’re new to Puppet these pitfalls and their workarounds may not be obvious.) I’ll admit that I got spoiled by the notion of letting things happen in the background, and just checking in on them later.

Ansible’s “push” model means that changes only go to the specific devices to which you send them. This is done by way of playbooks, files that specify your desired configuration. If you only want to make a change on a subset of servers, it’s a bit easier. But this can lead to configuration drift, because unless you regularly run all your Ansible playbooks against all of your servers, different groups of servers in your environment can have wildly varying versions of things.

Puppet isn’t a good choice for initially building a server, because you have to somehow bootstrap the configuration. (It can’t phone in until it knows where and how to do so.) And Ansible isn’t always the best choice for ongoing validation because of the aforementioned drift, and because YAML is so annoying and picky about spaces. But they’re both valuable tools for ongoing management.