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

Age, Language, and Community

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

WRITTEN BY CloudThat

CloudThat is a leading provider of cloud training and consulting services, empowering individuals and organizations to leverage the full potential of cloud computing. With a commitment to delivering cutting-edge expertise, CloudThat equips professionals with the skills needed to thrive in the digital era.