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
  • Ansible gets a win for having real loops: http://docs.ansible.com/playbooks_loops.html#loops
  • As I mentioned in part 1 of this series, the Puppet DSL is a stripped-down version of Ruby that is not Turing-complete. See the lively discussion of the Puppet DSL in: http://blog.smartbear.com/devops/a-taste-of-salt-like-puppet-except-it-doesnt-suck/#comment-2109
• Noop Mode
  • Puppet gets a win for having a real “–noop” mode. Apparently the author of Ansible (Michael DeHaan) has a strong prefereance against this: https://groups.google.com/forum/#!msg/ansible-project/H_d6_cdvKjk/5EFy_GGc4kkJ
  • Later in the thread you can see that he concedes and Ansible has since added a semi-working dry-run mode: http://docs.ansible.com/playbooks_checkmode.html
  • I see this as a major disadvantage for Ansible because when trying to Ansible-ize existing “brown field” machines, it’s extremely helpful to be able to test your configuration manager with a 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.

Conclusions

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.