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:
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.
Puppet is built on Ruby and the Ruby ecosystem of tools for testing
Ansible is built upon Python
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
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.
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
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
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
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
Age, Language, and Community
% by 1
% by 6
Terms used in the above chat
Age: It referes to the age of the CM from when it was found to 2015, based on the “first release” dates found on wikipedia.
Language: referes to the language CM tools are written in
People: shows how many people have contributed in GitHub repository
Commits: Total number of Commits to the sourse code of each CM