Ansible vs Puppet – Hands-On with Ansible

This is part 2/2 in a series. For part #1 see: Ansible vs Puppet – An Overview of the Solutions.

Notes & Findings From Going Hands-On with Ansible

After playing with Ansible for a week to Ansible-ize Graphite/Grafana (via Docker) and Jenkins (via an Ansible Galaxy role), here are my notes about Ansible:

  • “Batteries Included” and OSS Module Quality
    • While Ansible does include more modules out of the box, the “batteries included” claim is misleading. IMO an Ansible shop will have to rely heavily upon Ansible Galaxy to find community-created modules (Ex: for installing Jenkins, dockerd, or ntp), just as a Puppet shop would have to rely upon PuppetForge.
    • The quality and quantity of the modules on Ansible Galaxy is about on par with what is available at PuppetForge. Just as with PuppetForge, there are multiple implementations for any given module (ex: nginx, ntp, jenkins), each with their own quirks, strengths, and deficiencies.
    • Perhaps this is a deficiency of all of the configuration management systems. Ultimately a shop’s familiarity with Python or Ruby may add some preference here.
  • Package Installations
    • Coming from Puppet-land this seemed worthy of pointing out: Ansible does not abstract an OS’s package manager the same way that Puppet does with the “package” resource. Users explicitly call out the package manager to be used. Ex: the “apt” module or “yum” module. One can see that Ansible provides a tad bit less abstraction. FWIW a package installed via “pip” or “gem” in Puppet still requires explicit naming of the package provider. Not saying that either is better or worse here. Just a noticable difference to an Ansible newbie.
  • Programming Language Constructs
  • Noop Mode
  • Agent-less
    • Ansible’s agent-less, SSH-based push workflow actually was notably easier to deal with than a Puppetmaster, slave agents, SSL certs, etc.
  • Learning Curve
    • If I use my imagination and pretend that I was starting to use a configuration management tool for the first time, I perceive that I’d have an easier time picking up Ansible. Even though I’m not a fan of YAML by any stretch of the imagination, Ansible playbooks are a bit easier to write & understand than Puppet manifests.


After three years of using Puppet at VMware and Virtual Instruments, the thought of not continuing to use the market leader in configuration management tools seemed like a radical idea when it was first suggested to me. After spending several weeks researching Ansible and using it hands-on, I came to the conclusion that Ansible is a perfectly viable alternative to Puppet. I tend to agree with Lyft’s conclusion that if you have a centralized Ops team in change of deployments then they can own a Puppet codebase. On the other hand if you want more wide-spread ownership of your configuration management scripts, a tool with a shallower learning curve like Ansible is a better choice.

14 thoughts on “Ansible vs Puppet – Hands-On with Ansible

  1. Pingback: Ansible vs Puppet – An Overview of the Solutions | Dan Tehranian's Blog

    • Fair question. Taking the time to explore SaltStack came down to a few things: time constraints for exploration and the recommendations of my former colleagues. 1 of the 3 mentioned SaltStack as another potential option whereas all 3/3 recommended going with Ansible.

  2. Please note that ansible does indeed have a ‘noop’ mode, just run it with ‘–check –diff’:

    $ ansible –help | grep -A1 check
    -C, –check don’t make any changes; instead, try to predict some
    of the changes that may occur

    • Thanks for the tip, Justin! From what I’d read about “check mode” I’d gotten the impression that since module-level support for check mode was optional, it meant that modules that did not support it would go ahead and blindly make changes.

      What is the behavior of modules that do not support check mode? Do they not make changes but also not report on what the changes they would make?

      • Per the docs linked in your article: “Other modules that do not support check mode will also take no action, but just will not report what changes they might have made.”

  3. Pingback: Testing Ansible Roles with Test Kitchen | Dan Tehranian's Blog

  4. Hi Dan,

    Thanks for your great articles!

    Also for me puppet seems a bit harder to learn, a bit more unhandy than ansible. But very often there are good reasons why a technology is more complex. For example, you would not write applications as a shell script instead of java only because its easier to learn and less complicated.

    So what do you think – are there any advantages with puppet, justifying the higher level of complexity in puppet? Is there a “good reason” for why puppet is harder to learn?

    Thanks and kind regards,


    • Hi Tobias,

      While Puppet does have a steeper learning curve than Ansible, I think it’s still a perfectly good tool to use if you go into it with that understanding.

      Here are some situations where Puppet shines:

      * Very large config management code bases where being able to explicitly manage resource ordering is needed.
      * One needs to have facts exported to a datastore like PuppetDB
      * If one is planning to extend their config management tool, and they are more fluent in Ruby than Python.

  5. Pingback: Ansible vs Puppet – Hands-On with Ansible « Aryan Nava

  6. You may also look at Ironwood Networks network automation assistant. It doesn’t require any vendor module so you include any devices into DevOps. No scripting knowledge required either.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s