Configuration Management Tools : Ansible vs Puppet

There is always a debate spinning around which configuration management tool to use Ansible or Puppet?

According to me, there is no clear winner, it all depends on your team’s requirements and choice. In this blog, I will discuss both the configuration management tools without being biased.

Let’s start with:

Server Nodes

Puppet infrastructure generally contains 1 (or more) “puppetmaster” servers, along with special agent packages installed on each client node
Ansible has neither a special master server, nor special agent executables to install. The executor can be any machine with a list (inventory) of the nodes to contact, the Ansible playbooks and proper SSH keys/credentials to connect to the nodes

Push vs Pull

Puppet nodes have special client software, which periodically check puppet master server to “pull” resource definitions
Ansible follows a “push” workflow. The machine where Ansible runs from SSH’s into the client machines and uses SSH to copy files, remotely install packages, etc. The client machine requires no special setup outside of a working installation of Python 2.5+

Resources & Ordering

Puppet: Resources defined in a Puppet manifest are not applied in order of their appearance (ex: top->bottom). Instead, resources are applied randomly, unless explicit resource ordering is used. Ex: “before”, ”require”, or chaining arrows
In Ansible, the playbooks are applied top-to-bottom, as they appear in the file

Resource Dependency Graphs

Puppet internally creates a directed graph of all of the resources to be defined in a system along with the order they should be applied in. This is a robust way of representing the resources to be applied. Puppet can even generate a graph file so that one can visualize everything that Puppet manages. On the down side, building this graph is susceptible to “duplicate resource definition” errors (ex: multiple definitions of a given package, user, file, etc)
Ansible is basically a thin-wrapper for executing commands over SSH, there is no resource dependency graph built internally. One could view this as a weakness as compared with Puppet’s design, but it also means that these “duplicate resource” errors are completely avoided. The simpler design lends itself to new users understanding the flow of the playbook more easily.

Batteries Included vs DIY

Puppet provides a series of primitives (File, User, Package, Service, etc) which can be used to compose modules with. Modules are either written in-house or downloaded from PuppetForge. Some modules from Puppetforge are exceptionally well written (ex: puppet-docker)
In Ansible, there is an extensive STDLIB of Ansible modules automatically included as part of the Ansible installation. There is also a site for community written “roles” called Ansible Galaxy.

Language Extensibility

Puppet is built on Ruby and the Ruby ecosystem of tools for testing
Ansible is built upon Python

Syntax

Puppet has its own DSL, which is a subset of Ruby. It’s not a Turing-complete language and was specifically designed to “be accessible to sysadmins“
Ansible playbooks are YAML files

Template Language

Puppet templates are based upon Ruby’s ERB
Ansible templates are based upon Jinja2, which is a superset of Django’s templating language

DevOps Tool Support

Both Puppet & Ansible are well supported by other DevOps tools like Vagrant, Packer and Jenkins

These were the features of both Puppet and Ansible. Now, lets discuss a little about the pros and cons of using them.

Puppet

Pros:

- Has the biggest community
- Arguably carries the most mature Windows support
- Puppet is well established and you have some quality paid support options if you want to go that route
- Forge provides rich knowledge of resourses

Cons:

- Puppet comes with its own DSL called PuppetScript, which is unique in its own form.
- Puppet’s error reporting has been always a pain point and one of the reasons for people switch

Ansible

Pros:

- Basically automates configuration via pushing commands through SSH. No agents are required for managing clients
- It has a very active community and it is very easy to pick up because of both YAML & Agentless architecture

Cons:

- For advanced operations, it uses Jinja2 template language for python, for complex infrastructure code this is used a lot and it makes it much less readable and more complex.
- Because of the agentless architecture, management on bigger scales are extremely painful.
- It has a very immature Windows support.

Community Metrics: Comparing Ansible, Chef, Puppet and Salt