DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog Puppet Vs Ansible

Puppet Vs Ansible

I have realised that people still struggle to find differences between Ansible and Puppet. As more of a Puppet person myself, when I had to switch entirely from using Puppet to Ansible within my role, I found that sometimes I started to favour Ansible over Puppet.

In this blog I’ll explain the pros and cons for each with some technical examples.

In short… the differences.

In very, very, short, there are some differences between Ansible and Puppet.

I would normally classify both as different use cases really (more about this below) but in general, before you start, you need to know what Puppet and Ansible is. However, Puppet is more of a configuration management tool, whereas Ansible is more of a provisioning, configuration and deployment tool. Despite the fact Puppet now can provision infrastructure, I would really think hard about whether I would consider Puppet for that task. Anyway… let’s start.

Ansible is simple! (They said)

As a side note, Ansible uses YAML language, whereas Puppet has its own declarative language. If you make a mistake in Puppet, it can be easily highlighted and in many cases Puppet Lint or Puppet Run will just fail.

In Ansible, tasks are executed in specific order, if you have syntax errors in plays or roles, they tend to fail once you hit them, not before you execute the entire play. Playbooks waiting for a feedback can take a long time. In this case I actually favour Puppet more because it won’t compile a catalog if there are issues with the syntax.

Some may say “Okay but Puppet also uses YAML”… yes it does for hiera and at the same time if you make YAML errors in Puppet you may hit similar issues with Ansible.

To illustrate what I’m thinking of have a look at the data structure below:

YAML lint won’t drop any errors or warnings but in general the above breaks the entire structure. Have a look at this play:

If we Lint it and run it:

As you can see in the example above, the first item has been found with correct key value pair, the second item was just null. This is because of the wrong indentation which completely changed your data structure. You may say now “Yes but that’s pretty obvious!” it is and it’s not, especially for beginners and this is quite a common mistake that people make (including myself). I also experienced much more serious YAML hierarchy errors in the bigger plays because of this type of indentation mistakes, which haven’t been picked up by YAML lint at all. People who worked with YAML a lot, know this is not the easiest language to debug.

Ansible needs to know what to run where…

…as well as Puppet. Ansible is strictly tied into an inventory which you have to manage as a flat file, (or) dynamic inventories or smart inventories. If you want to run a task against the server which is not in your inventory, Ansible simply won’t run anything. Puppet agent checks in with the master and the master manages “the inventory”, but you need to declare nodes (servers) configuration as well, unless you use default node declaration which will then apply for all the hosts. Puppet also requires nodes certificates to be signed (manually) on the master. This gives you some confidence that the code won’t run or be executed against the servers that are not trusted (or configured). You can use autosign.conf if you want your master to sign certificates automatically (can be limited to certain hostnames or wildcards).

Don’t reinvent the wheel…

Modules. Both solutions come with a great bunch of modules and/or roles already written by people and are kept in certain “repositories”. For Puppet you should look at Puppet Forge and Ansible Galaxy for Ansible.

When I have to write something I always go and check these resources to simply save some time and hassle. If I can find a module which is doing something for me that I want, I pick it up (instead of writing it on my own because there is a big chance someone has already done that better than me anyway).

Based on my experience I would say Puppet is an unbeaten champion when it comes to the module choice and quality. Puppet Forge is a huge module library and what actually helps is that PuppetLabs manages some of the modules themselves. Modules which are written in accordance to some PuppetLabs best practices can be rewarded by the Puppet team with Supported or Approved marks/grades. This really helps in making your decision on which module to use, simply because you want the best ones which are being actively developed every day. You also want modules that are tested and they are proven to work.

For me, this is the main reason why Ansible lost the battle. I tried some modules recently from Ansible Galaxy and 2 out of 3 I used required some manual changes and modifications to do what I wanted. I don’t want to name and shame here but I was using some collected and zabbix agent modules.

* RE stars marks above: I would have to spend quite a significant amount of time to write supported or approved Puppet module.

But Puppet needs extra components!

True. A common argument I hear against Puppet is the infrastructure needed to support your automation processes. If you want to fully utilise Puppet… it needs infrastructure. If you want an access to the node’s facts, reports, etc you need puppet master(s), puppet db(s). In many cases people link this argument with an overhead which Puppet brings in. I cannot answer which is better, as in my opinion Puppet and Ansible serve slightly different purposes but are very similar to each other.

Another argument against Puppet is that to run it you need X puppet. In fact, to run ansible-playbook, you need Ansible. The difference is that ansible-playbook can be run from centralised places, whereas Puppet needs an agent to run on each node. Unless you run masterless configuration and you execute your puppet manifests locally on the box, then it also requires puppet to be installed on that server + source code of your all modules and manifests.

In short, Puppet will always require an extra component/package to be installed on the destination server to make it all work, regardless if you go masterless or not.

Ansible can deploy and configure stuff at the same time…

Yes. This is true. You can use built-in Ansible modules to provision your infrastructure by plugging in directly to the infrastructure providers (AWS, VMWare, Azure, etc). You can describe your infrastructure as a code, and configure it on a run as well.

As long as Puppet has similar modules and abilities (for example AWS ) I would really feel uncomfortable running Puppet code to deploy AWS instance… but this is entirely my personal opinion. I would more than likely use terraform or Ansible instead for that task.

Provisioning complex infrastructure and configurations…

As I mentioned above Ansible (or terraform) would be my choice of tool for provisioning infrastructure. If you have an environment which needs to be built in certain order you can design your play to wait for certain components to be present, or work in your infrastructure before you start configuring bits and pieces. I’m not sure if you can do that with Puppet. I personally have never done it simply because of the reasons mentioned above.

Complex configurations can be equally hard or equally simple in Ansible as well as in Puppet. If complexity is the case you would probably have to write something on your own, with your own set of templates or flat files, so the chosen tool here can be a personal preference.

Task scheduling…

Sometimes you want to run your tasks every so often. Puppet agent runs every 30 minutes by default making sure the state of the checked in node (server) is in the desired (described) state. Ansible doesn’t have that mechanism so if you want a scheduler you need to look at Ansible Tower which has recently become Open Source. Puppet just have it all by default. So, when we talked about the extra infrastructure above and an overhead… if you need some Ansible fireworks, you should start look at Ansible Tower (or AWX).

Puppet is a devil’s tool because…

“It doesn’t allow me to make manual changes on the servers”

– Yes as when Puppet Agent runs it will revert all your changes if they differ from what is described in Puppet manifests. Right but this is exactly what you want, is it not?

“Not really, I want to make manual changes so I think I will stop or disable Puppet Agent”

– You can yes, but this is definitely not something you want.

For some people, the above sounds familiar. The main purpose of scheduled run is to make sure your code reflects the current configuration on the destination systems and enforces that configuration. I think a lot of people are guilty here as everyone (including myself) was in the situation when you needed to turn puppet agent off to test or change (and then test) something on the live system. In many cases this behaviour is enforced by the test infrastructure which doesn’t exist. Live is not ideal unfortunately and in some cases you have to do that.

Different code base per environment…

Puppet has one of the best tools I have ever seen and used and it’s called r10k. I absolutely loved it when (first of all) I worked out how to use it! In short, r10k is a tool to manage your modules depending on the branches or your specific environment configurations.

It builds your entire Puppet module ‘code base’ based on what is described in Puppetfile for that specific environment. This means you won’t have any accidental modules within your module inventory and each module is kept in separate git rep. Full win! This makes module management and development much easier and also testing your changes. You can also refer different modules from different branches, versions, commit points, etc to your production or QA environment (for future promotion).

For example, let’s say this is my Puppetfile in production:

When you run r10k deploy environment production -p assuming my above Puppetfile is in production branch in git, it will download all the modules listed from Puppet Forge and the profiles module from my personal GitLab server, but with the certain commit number. So if I want to test my profiles on the QA environment assuming I have QA branch in my local GitLab where I make all my changes I just do this:

After running r10k and your puppet agent pointed to the qa branch… you will test these changes. r10k is definitely worth a separate article.

I cannot imagine the way I could do similar things in Ansible.


To summarise this article, both offerings are definitely worth considering. If you are a storage or network engineer then I think you should not look any further and go straight for Ansible. I think Ansible wins a lot in terms of the provisioning side of things. If your deployment requires ordering or some special tasks which have to be well planned and rely on each other. I also think Ansible is good for short-lived environments as it takes the headache away of managing Puppet node SSL certificates etc. It’s not a big deal though and I think Puppet can be as good as Ansible here. Puppet is definitely more mature and in terms of support, I believe it has more to offer. Ansible can be simple to start, but when you get into more complex tasks you may find it very difficult to manage these tasks. Ansible without Tower is not really ‘idiot proof’ (or safe) as it simply allows you to run playbooks on your entire inventory. Imagine the situation that you declare new root password in your Ansible Vault, run your play and halfway through you realise that password is something that you don’t know as simply you mixed up SHA256 hash. If you use password authentication to access your servers (which is kind of stupid anyway as you should use SSH key authentication only), you have just lost an access to some of your infrastructure irreversibly.

If you use key authentication and you have to change the key for your account (to the wrong one), you again lost an access irreversibly to (part of) your infrastructure. With puppet that situation can be reverted as agent runs every so often, so you can correct your mistake in your code, deploy it to puppet master and wait for another puppet agent run. In my opinion, Puppet have more and better-written modules which just work and is a more enterprise-ready solution. Unlike tasks scheduling in Ansible without Tower which leaves you only with few options.

Written by RedHat Certified Engineer (RHCSA, RHCE) Jarek Grzabel (@JarekGrzabel) who is the Lead DevOps Engineer at DevOpsGroup. He is a fan of clouds and automation (Ansible and Puppet).

Like the idea of working with these technologies? Why not check out our current job vacancies?

8 thoughts on “Puppet Vs Ansible

  1. With respect to using different versions of roles in ansible for testing, you can make use of roles/requirements.yml with which you can set a version or tag to download.

    1. I’m working this out through galaxy but I cannot really find a way how I could achieve similar effect in terms of having code divided into multiple environments like test, dev, qa, production, including all playbooks and group_vars or environment vars as well. I’m really not sure if Ansible Galaxy has the same capabilities. We will definitely update blog if we will be confident it is 100% possible and then I will probably create a blog about r10k and Ansible Galaxy :).

      1. Ansible code runs against different environments/vars by simply pointing to the right inventory path when you run the ansible-playbook command. It’s critical to pull your environment-specific vars out of the playbook and roles and implement your roles with proper default values and without any vaulted values. This means you have playbooks/roles that can be performed against any environment/platform. For example, you could provision a RHEL server on both AWS and VMware with the same playbook/roles.

  2. Before I start: these are my personal remarks – but I do work for Red Hat, and I am actually on the Ansible team. Thus take my words with caution 😉
    First and foremost thanks for the detailed comparison. It is well balanced, and I like the detailed comparison in terms of various use cases! Far too often I see “reviews” with the conclusion that one tool must be used for everything – no matter if it really makes sense or not.
    I’d love to see a direct comparison between r10k and the idea how roles are managed in Ansible. With “roles/requirements.yml” in Tower or the “ansible-galaxy install -r requirements.yml” on command line you do have the possibility to include roles from different sources, even special commits, branches or tags.
    But such a sufficient comparison is a challenge since requirements.yml is used differently: it sits in the same repository – and if you have different branches in that repo you most likely change the requirements.yml as well. If you ever want to share ideas there, feel free to drop me a note. 🙂
    One remark I have in terms of wording: Ansible modules are something different than the Puppet modules. Puppet modules are better compared to Ansible roles. Ansible modules are probably comparable to what Puppet calls resources. Usually the comparison is hard, though: Puppet modules are often more sophisticated than Ansible roles – though Puppet Forge and Ansible Galaxy both contain very good, almost perfect pieces, and a lot of bad examples 😉 At the same time, Ansible has a lot more modules than Puppet has resource – because they work totally different.
    Last but not least, I was missing a bit the features Ansible AWX/Tower offers around Ansible. Role Based Access Control, Auditing features, and stuff like that. Of course Ansible on command line can stand for itself, but if you want to take full advantage of it (working in teams, having visibility), most teams use it together with the UI, that means AWX (the Open Source upstream project to Red Hat’s Tower).
    I am not sure if there is anything comparable in the Puppet ecosystem – at least nothing Open Source – but if, than I would love to see a comparison there.

    1. Hi, thank you for your – also balanced – feedback. Discussion (here, LinkedIn and Twitter) that come out from this blog article led me to a decision to write another blog article comparing r10k and ansible-galaxy. So this will appear soon! Despite the fact both tools have differences I will compare them neutrally – as with everything.
      Regarding the wording I used – you’re right. Modules are more roles in Ansible, the only reason why I used modules because I thought when we talk about Puppet Forge and Galaxy it’s easier to understand what I thought by modules, but you’re absolutely right. Ansible modules are completely different thing.
      I didn’t mention much about Ansible Tower as then I would need to mention much more about what Puppet includes as a standard extensions as well (mcollective, dashboards, facter, hiera). The main comment I hear from people is that Puppet comes with an overhead in a shape of extra infrastructure which is a fact… however if you want basic things which Puppet offer straight out of the box (like in simply words centralised management and execution point of your code and infrastructure) you need an add-on for Ansible.
      Once again thank you for your comment and feedback! I’m more than happy to discuss things further. I can talk about that forever :).

      1. Thanks for the reply! I am looking forward to the comparison of Ansible Galaxy vs r10k – due to the nature (and age) of the programs it will be an interesting challenge 😉
        And of course you are right that there are more tools to explain with Puppet as well – especially mcollective is not too easy to grasp and describe.
        Speaking about the different languages and words (modules, etc.), it would be quite a task to compare both tools in these terms: what is a module, what a resource, how are each of both called, how can things be grouped, what are dependencies, and so on. What a shame that I only have limited time for everything I want to do 😉

  3. Disclaimer: I work for Puppet
    You mentioned “If you have an environment which needs to be built in certain order you can design your play to wait for certain components to be present, or work in your infrastructure before you start configuring bits and pieces. I’m not sure if you can do that with Puppet.” and you’re absolutely right that this is difficult to achieve with the Puppet DSL.

    That is why Puppet has released a separate orchestration tool called Puppet Bolt ( to fill that gap. It can do simple stuff like remotely running commands & scripts over SSH or WinRM, no agents needed ( But it can also orchestrate complex deployments, very similar to an Ansible playbook. In Bolt those are called Plans and they run line by line, top to bottom. So no more complex resource dependency handling, which makes it perfect for provisioning. Bolt plans can be written in YAML for an easy way to get started (, or in a subset of the Puppet DSL for more complex capabilities ( This allows anyone with existing Puppet knowledge to get up to speed quickly and orchestrate deployments with Puppet Bolt, instead of having to learn yet another tool.

    Bolt also integrates nicely with Terraform (), since you are right that Terraform is easier to adopt for cloud resource provisioning. Configuration of the operating system is typically where Terraform stops, and where Bolt picks up. See the two work hand-in-hand here:

  4. I really enjoy how ansible makes the simple tasks so easy and quick to automate.

    Sadly the amount of work needed to automate tasks in ansible doesn’t grow linearly as the complexity increases.

    Somehow ansible gets in my way as the complexity of the task increases – once you need some kind of slightly more complex data structure to hold state/configuration and you want to dynamically manipulate the content it’s really no fun to use ansible, getting the syntax right with all the jinja filters, single and double quotes around your curly brackets can drive anyone to the brink of insanity.

    The sequential nature of ansible playbooks is a good thing, until it isn’t anymore – then you are back to banging your head into a concrete wall, trying to manage exceptions to the normal flow of operations using conditionally included tasks. Then you realize the fragile nature of the sequential approach if some assumed condition no longer is fulfilled, and that end state description instead of sequential operations actually has some advantages as well.

    I haven’t worked with puppet for quite a few years by now, so I really shouldn’t comment on the current state of puppet as of today – but back then I obviously had reasons to switch over to using ansible.

    Just as I now have my reasons for once again googling “ansible-vs-puppet” and finding this blog post.

Leave a Reply

Your email address will not be published. Required fields are marked *