21

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?

030
  • 13,383
  • 17
  • 76
  • 178
kenorb
  • 8,011
  • 14
  • 43
  • 80

3 Answers3

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.

Stephen C
  • 203
  • 1
  • 6
ᴳᵁᴵᴰᴼ
  • 1,173
  • 10
  • 22
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.

Pierre.Vriens
  • 7,225
  • 14
  • 39
  • 84
Assaf Lavie
  • 1,251
  • 11
  • 17
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.

Jiri Klouda
  • 5,867
  • 1
  • 22
  • 54