What are the Differences between Ansible and Puppet

When we start looking for best Continuous Management (CM) Tools, its bit complex to choose one, because there are 3 major players on the market Chef, Puppet & Ansible. Here we are work around with some interesting comparison between Puppet and Ansible, which is little east and fast access and more reliability. Before discuss about it, will see what are pre-requites/scenarios we should go for a CM tool. Here are some interesting Questions from some our folks which keep discussed about the get most suitable answer,

• How does the application stack look? Is is a typical web server, app, and db stack or more complex?
• Are you going to be running the nodes in-house, cloud, or hybrid? What type of hypervisors are involved?
• What is the future growth? (ie. number of nodes/environments)
• How much in-depth will the engineering team be involved in writing recipes, manifests, or playbooks?

Differences between Ansible and Puppet

Here are some major differences between Ansible & Puppet;

• Server Nodes
  • Puppet infrastructure generally contains 1 (or more) “puppetmaster” servers, along with a special agent package installed on each client node. (Surprisingly, the Puppetization of the puppetmaster server itself is an issue that does not have a well-defined solution)
  • 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 the proper SSH keys/credentials in order to connect to the nodes.
• Push vs Pull
  • Puppet nodes have special client software and periodically check into a 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 VM 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) which is confusing for people who come from conventional programming languages (C, Java, etc). Instead resources are applied randomly, unless explicit resource ordering is used. Ex: “before”, ”require”, or chaining arrows.
  • Ansible: The playbooks are applied top-to-bottom, as they appear in the file. This is more intuitive for developers coming from other languages. An example playbook that can be read top-down: https://gist.github.com/phips/aa1b6df697b8124f1338
• Resource Dependency Graphs
  • Internally, 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 and 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). Also, conflicting rules from a large collection of 3rdparty modules can lead to circular dependencies.
  • Since 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 itself provides a series of primitives (File, User, Package, Service, etc) that one can compose modules with. Modules are either written in-house or downloaded from PuppetForge. Some of the modules from Puppetforge are exceptionally well written (ex: puppet-docker), but many are quite poorly done.
  • Ansible follows Python’s “batteries included” philosophy. 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 upon Ruby and the Ruby ecosystem of tools for testing (ex: rspec) . Adding complex functionality is done through Ruby modules. Ex: https://github.com/puppetlabs/puppetlabs-cloud_provisioner/blob/master/lib/puppet/cloudpack.rb
  • Ansible is built upon Python for which most R&D orgs will have some experience. See Ansible module development example: http://docs.ansible.com/developing_modules.html#reading-input. Also this example for managing the PostgreSQL database: https://github.com/ansible/ansible-modules-core/blob/devel/database/postgresql/postgresql_db.py#L154-L165
• 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. Most R&D orgs will have more experience with Django.
• DevOps Tool Support
  • Both Puppet & Ansible are well supported by other DevOps tools like Vagrant, Packer, and Jenkins.