19

I would like to understand the differences between Puppet and Ansible, especially what kind of Puppet limitations has in comparison to Ansible.

Are there any things you cannot do it in Puppet, but you can in Ansible? In other words, why some people moving away from Puppet to Ansible?

1
  • I kept my answer well separeted from this, one of reasons may be all the money redhat is investing in it. Mar 5 '17 at 22:00
21

There are of course several pro and cons for each of Puppet, Ansible, Chef and add your favorite tool here as well. So I'll try to stay away from opinion, and share what is great in Ansible as a matter of fact.

The main capability that puts Ansible above the others is not having to rely on some custom/additional agent running on the target nodes, instead being founded on ssh connections only. Yes, it still requires an ssh server, Python and a bunch of Python libraries on the nodes, and if your distro of choice (or, good luck, there are some windows nodes) does not ship with them, it will be a little bit painful to bootstrap. But that's unlikely, and may well even make you think again about your distro.

That will simplify monitoring, not eat additional resources, not force the system to run a daemon as root all the time, and in general feels better inside the UNIX philosophy. Chef has chef-solo, Puppet can be run master-less, but they both work "the other direction," by cloning and via hooks respectively. While with Ansible, a merge in the source repository can trigger the deployment in a fashion we all are comfortable with, be it in Jenkins, in the git master, or in some other tool like Rundeck for instance.

5
  • Worth noting that if you've messed up your ssh configuration with ansible you're locked out of your machine, that's the drawback of the push model. Puppet or chef can work on à crontab job so they won't impact more the system than ansible Python code at all
    – Tensibai
    Mar 6 '17 at 21:31
  • 2
    A note on agents: I was approved to onboard Ansible in a HSE (high security environment) by a security team that had declined Chef and Puppet, even in masterless configuration. Agentless is a winning factor in some cases. Mar 30 '17 at 17:32
  • 2
    If you break your SSH setup, you have problems beyond Ansible in any case. It's good DevOps practice to test things like SSH changes in various environments before they get to production, and it's also possible to validate the SSH config is correct as part of writing it - the Ansible template module makes this quite easy.
    – RichVel
    Aug 7 '17 at 12:08
  • I've heard people made the argument that Ansible's agent-less architecture makes it more suitable for managing e.g. routers, where you could not install a Puppet agent, say. But do such devices come with Python interpreters? Perhaps not, so is Python really a strong requirement on every component managed by Ansible?
    – Drux
    Dec 8 '17 at 8:46
  • @Drux Ansible doesn't always require a Python interpreter on the target system (including routers). Where the target is a server, almost all modules do need Python (or PowerShell for Windows). For network devices, it can use SSH, HTTPS, NETCONF or other protocols, and many network vendors have officially-supported Ansible modules - see Ansible docs on network automation for more.
    – RichVel
    Oct 14 '20 at 13:04
11

No, people moving away from Puppet to Ansible (or vice versa) has nothing to do with what can or cannot be accomplished with either tool. Puppet/Chef/Ansible - it's mostly a matter of taste.

For example, Ansible is based on Python, and Python developers typically feel more at home with it (no need to learn a DSL), or Ruby (for Chef)). Easier for Python developers to extend Ansible as well.

But in essence they're all very similar in terms of what you can achieve. Some have relative strengths in some areas, and weaknesses in others, but typically the choice between them is made by style/culture/preference of the team.

8

Until Puppet 4.0 there was no easy way to orchestrate application spread over multiple servers or services, as it was hard to specifically order actions in Puppet, which was a design choice. Ansible was better at orchestrating and ordering the steps, especially across multiple servers. This was especially significant in applications where the wrong order of steps could lead to errors unrecoverable through repetition of those steps until an eventual consistency could be reached.

That is no longer an issue and so the distinctions are largely preference based.

4
  • 2
    The design choice of puppet was one of the reason Chef started, and the main I did move to Chef for our infrastructure and CD system few years ago.
    – Tensibai
    Mar 6 '17 at 21:32
  • 2
    Puppet orchestration is a Puppet Enterprise (commercial) feature only, whereas orchestration in Ansible is in the open source version. Generally, Ansible is much easier to install and learn than Puppet - having done some evaluation of both, I now use Ansible. There are other differences too, so it's not just a matter of personal preference.
    – RichVel
    Aug 7 '17 at 12:05
  • 1
    I am using Ansible both in my former and current job, but it has its own issues. The more I use Ansible the more I am interested in learning another alternative. I'd prefer this alternative to not use Python for module development and to have an active vital open source community. Out pull requests for Ansible take almost a year to be even reviewed. At this rate, it could be as well proprietary. Aug 8 '17 at 22:41
  • 1
    Many people complain about the puppet agent, but when you are on cloud and you autoscaling group and you don't want to rebuild the image of your vm, is good that vm connect to the puppet master, I don't see any problem to have an small agent.
    – c4f4t0r
    Dec 7 '18 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.