Ansible vs Puppet – reasons for choosing Ansible

We have been using both Puppet and Ansible to configure our servers for several months. I have come to really love Ansible and I wanted to put down my reasons for finally choosing Ansible over Puppet.

Reason 1: Ansible is decentralised. With Puppet you need to maintain a central configuration server and install a Puppet Client (with root permissions) on each machine that you wish to configure. These individual client machines then connect to the configuration server and pull down their configurationa. Personally, as much as I love servers, I don’t want to maintain another server and client software. Ansible doesn’t require any central server. You just install and run it on your local machine. It doesn’t have any client software and configures the machines over ssh. This allows you to configure computers from anywhere, at anytime from any computer which has Ansible installed. This decentralised approach also means that Ansible once has done the configuration – it doesn’t sit there running in the background using power etc.

Reason 2: Ansible instantantly configures and provides feedback. . Puppet is based on a pull system which means the client ‘polls’ the server for changes to configurations. This means that there is a lag between writing a new configuration and having it pulled down to a server. For me this seem too complicated. Once I have written a configuration – I want to push it out immediately and check it worked.

Reason 3: Ansible configurations are ordered
Ansible is a little like a scripting language with commands running in a structured and ordered manner. Puppet on the other hand makes it hard to run ordered commands. It is possible by using dependencies. However, the simplicity of Ansible is, well, much simplier.

Reason 4: Ansible has a much gentler learning curve
It took me a much shorter period of time to learn Ansible compared to Puppet and achieve the same results. I’ve also found that it is much easier to explain Ansible to other people that I work with. For example – I’ve developed an Ansible script which configures a new development enviroment for an application that our team is working on. One of the members of the team saw the script in the repository and used it to configure his development enviroment with no prior knowledge of Ansible after 5 minutes of explaination from me. I’m sure that the reason for this is because Ansible script looks like other types of scripts and sysadmins and developers easierly understand scripts.

What are you thoughts?

9 thoughts to “Ansible vs Puppet – reasons for choosing Ansible”

  1. I generally agree, but do want to point out that #1&#2 only apply when using a puppetmaster. Many people prefer a masterless setup for those and other reasons.

    #3 is tricky. Relying on explicit dependency management instead of assuming the order (of the code) is considered a feature. It can get confusing, but the argument is that the code is easier to refactor/reorder/modularize or even (in the future?) optimize/parallelize then assuming implicit dependencies.

  2. Also worth mentioning is the smooth learning curve of Ansible vs the quite steep one of Puppet/Chef. While it’s easy to justify spending hours on Config Mgmt tool learning when you’re on the systems side of the force it’s not the same when you’re trying to sell CM automation to a small team of already overloaded Java devs…

  3. I wouldn’t say that these 3 points are reasons that either tool is better than the other. It’s more horses for courses. SSH keys versus client agents. Centralised versus decentralised. You could easily sit on either side of those debates and be equally right.

    1. Thanks for your comments. You are correct that there isn’t a right or wrong approach to configuration management – just differences.

  4. Don’t forget the stuff you loose by having no central management server. Exported resources, central catalog inspection, Facter and PuppetDB are extremely powerful tools when managing anything more than a dozen servers. Also, the separation of types and providers in Puppet makes for great modularity and platform independence. Still, Puppet can be overwhelming due to its quite big ecosystem and terminology.

    1. You’re right – having a central management server can be useful. However, for me, it still comes down to the fact the Ansible has a much gentler learning curve.

      1. I’d really love to see an article on masterless facts vs myths. There are definitely features that *feel* like they require a puppetmaster. They’re better documented (and perhaps tested) when using a master.

        However:

        Loggly used exported resources without a puppetmaster
        (http://semicomplete.com/presentations/puppet-at-loggly/puppet-at-loggly.pdf.html)

        Several others have used PuppetDB without a puppetmaster
        (see http://justfewtuts.blogspot.com.br/2013/07/wip-puppet-beginners-concept-guide-part.html, for example)

        It may not be immediately obvious why you would bother with a masterless setup if you have a DB, though contemplating massive deployments with bittorrent* might provide some insight. My point is just there is a disconnect between what we assume requires a Puppetmaster, and what actually does.

        *: http://torrentfreak.com/bittorrent-makes-twitters-server-deployment-75-faster-100716/

  5. Anyone here ever tried puppet masterless using this setup? Puppet+GitlabCE->Jenkins->AWSCodeDeploy? Then EC2 instances will have Codedeploy agents installed. You can use the codedeploy agents to deploy application code as well. Basically leveraging AWS CodeDeploy service to deploy your configuration and developer codes. =)

Leave a Reply to james Cancel reply