Ansible vs Puppet – An Overview of the Solutions

This is part 1/2 in a series. For part #2 see: Ansible vs Puppet – Hands-On with Ansible.

Having recently joined Delphix in a DevOps role, I was tasked with increasing the use of a configuration management tool within the R&D infrastructure. Having used Puppet for the past 3 years at VMware and Virtual Instruments I was inclined to deploy another Puppet-based infrastructure at Delphix, but before doing so I thought I’d take the time to research the new competitors in this landscape.

Opinions From Colleagues

I started by reaching out to three former colleagues and asking for their experiences with alternatives to Puppet, keeping in mind that two of the three are seasoned Chef experts. Rather than giving me a blanket recommendation, they responded with questions of their own:

  • 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 eng team be involved in writing recipes, manifests, or playbooks?

After describing Delphix’s infrastructure and use-cases (in-house VMware; not a SaaS company/product but there are some services living in AWS; less than 100 nodes; I expect the Engineering team to be involved in writing manifests/cookbooks), I received the following recommendations:

Colleague #1: “Each CM tool will have its learning curve but I believe the decision will come down to what will the engineers adapt to the easiest. I would tend to lean towards Ansible for the mere fact thats it’s the easiest to implement. There are no agents to be installed and works well with vSphere/Packer. You will most likely have the engineers better off on it better since they know Python.”

Colleague #2: “I would say that if you don’t have a Puppet champion (someone that knows it well and is pushing to have it running) it is probably not worth for this. Chef would be a good solution but it has a serious learning curve and from your details it is not worth either. I would go with something simple (at least in this phase); I think Ansible would be a good fit for this stage. Maybe even with some Docker here or there ;). There will be no state or complicated cluster configs, but you seem to not need that. You don’t have to install any agent and just need SSH.“

The third colleague was also in agreement that I should take a good look at Ansible before starting with deployment of Puppet.

Researching Ansible on My Own

Having gotten similar recommendations from 3/3 of my former colleagues, I spent some time looking into Ansible. Here are some major differences between Ansible & Puppet that I gathered from my research:

  • 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:
  • 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
  • Language Extensibility
  • Syntax
  • 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

Complexity & Learning Curve

I wanted to call this out even though it’s already been mentioned several times above. Throughout my conversations with my colleagues and in my research, it seemed that Ansible was a winner in terms of ease of adoption. In terms of client/server setup, resource ordering, “batteries included”, Python vs Ruby, and Jinja vs ERB, I got the impression that I’d have an easier time getting teammates in my R&D org to get a working understanding of Ansible.

Supporting this sentiment was a post I found about the Taxi startup Lyft abandoning Puppet because the dev team had difficulty learning Puppet. From “Moving Away from Puppet”:

“[The Puppet code base] was large, unwieldy and complex, especially for our core application. Our DevOps team was getting accustomed to the Puppet infrastructure; however, Lyft is strongly rooted in the concept of ‘If you build it you run it’. The DevOps team felt that the Puppet infrastructure was too difficult to pick up quickly and would be impossible to introduce to our developers as the tool they’d use to manage their own services.”

Getting Hands-On

Having done my research on Puppet vs Ansible, I was now ready to dive in and implement some sample projects. How did my experience with Ansible turn out? Read on in Part #2 of this series: Ansible vs Puppet – Hands-On with Ansible.

20 thoughts on “Ansible vs Puppet – An Overview of the Solutions

  1. Pingback: Ansible vs Puppet – Hands-On with Ansible | Dan Tehranian's Blog

  2. Pingback: How Should I Get Application Configuration into my Docker Containers? | Dan Tehranian's Blog

  3. Nice post. Thank you 🙂
    Otherwise, one of the key feature to compare such kind of tools is testing. I would say that puppet ecosystem ease building robust modules especially using tools/frameworks such as rspec-puppet (for unittests) and puppet-beaker (for acceptance tests).

  4. Pingback: Encrypting Login Credentials in Ansible Vault | Dan Tehranian's Blog

  5. Pingback: Came across a nice blog about differences between… | #NoBS

  6. Pingback: Came across a nice blog about differences between... - #NoBS

  7. Pingback: Ansible vs Puppet – An Overview of the Solutions « Aryan Nava

  8. Pingback: Checking out Ansible. Sorry Puppet | Blog of Leonid Mamchenkov

  9. Thanks for sharing.
    I’m happily using Puppet since more than 4 years (was already in place when I join the project) and never really spend time looking at Ansible or Chef.
    Just wanted to react on the Lyft comment: “Our DevOps team”! This looks already wrong to me as you better not have a team for that, but rather have Dev and Ops teams involved…
    But I agree Puppet requires a bit more knowledge about infrastructure (Ops side) as it comes with the agent-pull-from-master feature.
    This being said, it is not required to use it all: it appears to me that writing some simple manifests to be run locally (in combination with git/svn for instance) also make sense to help Dev team(s) being involved faster from the moment they are building a new app.
    Later, Ops team(s) will re-use those local manifests to integrate them in modules.
    Plus, I’ve personally chosen to disable the background agents and run them on demand via ssh (i.e.: via a Jenkins Pipeline). So I guess my Puppet setup looks a bit more like an Ansible one.

    Now, I wonder if no one tried to combine both approaches. I remember testing GitLab integration via Puppet which triggered a Ansible cookbook. The Ansible logs end up in the Puppet report :-p

  10. resource ordering is a false reasoning in my opinion.
    class { ‘1’: } ->
    class { ‘2’: } ->
    class { ‘3’: } ->
    class { ‘4’: }
    and you got top-to-bottom ordering with puppet. Puppet resource dependency gives you more flexibility (which at times, translate into more “hassle”).

  11. Dan,
    This is a very informative article, thank you! I do have a question. Does Puppet require root privileges? If so, are there ways to work around that to minimize security risk? Any details you may have on implementing Puppet in a secure manner would be very helpful.


  12. Hi.
    there is a well defined solution to puppetize the puppet master: create a recipe to run puppet masterless 🙂
    Speaking about packer, it’s not true that integrates better with one CM or the other. Packer is really agnostic and I can’t figure how it integrates better with Ansible. I started using it with Ansible, then I migrated to puppet. It’s up to you.
    I see other problems.
    Puppet, compared to ansible and even saltstack, has too many single points of failure, and lot of cumbersom setup to carry on. I really have having to deal in Puppet with a lot of confiugration files, which become stale and obsolete from one version to another. Salt-stack has ONE configuration file.
    Mcollective requires ActiveMQ: another single-point of failure. Saltstack is way easier.
    PuppetDB: requires Postgres, and is a critical singles point of failure, if not clustered. If the puppet master is configured to talk to puppetdb, puppet run will fail if puppetdb is not available (clustering Postgres, increase complexity… and you’re gonna cluster a DB, which contains data which are not even important).
    Puppet master is a single point of failure, and clusterization is not straight forward: clusterization of the CA is not straight forward. Salt-Master clusterization should work out of the box.

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 )

Connecting to %s