[sdnog] help choosing configuration management utility

Daniel Shaw dshaw78 at gmail.com
Sat Mar 7 21:31:27 SAST 2015


I’ll give my views on Puppet and Ansible (for what it’s worth)..

Background: I’ve played fairly extensively with the basics of puppet in the past, but that was about 3 years ago already. While I’ve followed the online documentation since, I’ve not used it recently.
I’ve very recently started experimenting with Ansible, but have not gone very far with it yet.

So keeping the above in mind, be aware that these facts might be biasing the rest of my view below.

For me, the biggest pro for Puppet is that it’s been around quite a bit longer than Ansible and there is a vast existing library of modules for many many common system configurations and tasks. So far I’ve found much less re-usable code available for Ansible. Also out-of-the-box functionality in Puppet is much more complete. Both are 100% extensible, so you can make Ansible do anything puppet can, but some simple tasks need more coding work.

However, Puppet has a slightly higher barrier to entry: While it can be gotten to work with just ssh or run locally on each server, the most common set up is a central server managing hosts by each host connecting back to the master over https on a non-standard port. And with certificate based authentication. This means firewalls and routers need to allow the port; and host certificates, while 90% automated, still need some manual intervention to activate or revoke. 

Contrast this to Ansible which is designed to work over just ssh, and also unerstands sudo on the remote side. Also nothing other than Python is needed on the managed host. The Ansible tools themselves are only installed on the controlling host, and it generates Python scripts that are temporarily pushed to the remote host as and when needed over ssh.

This means that you only have to install Ansible on one machine that has ssh access to the other ones you want to manage and you’re good to go. Could even be your own workstation. Puppet on the other hand has components that have to be installed on every host before it can work.

In summary: You can get up and running with Ansible much faster. And with less change to your existing infrastructure and no new architectural concepts to learn.
Puppet, to me, has a steeper (initial) learning curve and more system dependencies. But once up and running, it has a lot more power and flexibility built in. Puppet is more mature and has a huge ecosystem and more extensive documentation.

Other differences (neither pros nor cons):
Puppet runs in Ruby (and needs Ruby installed on the master and the managed hosts).
Ansible runs in Python (and needs that installed everywhere).
Puppet code is written in the Puppet Language which is it’s own Ruby-like language with inspiration from Nagios config file formats.
Ansible “playbooks” are written in YAML (wikipedia.org/wiki/YAML).


More information about the sdnog mailing list