<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-03-05T17:10:24.177Z
2017-03-06T23:09:44.943Z
2017-03-06T23:09:44.943Z
Assaf Lavie
<p>Until Puppet 4.0 there was no easy way to <a href="https://docs.puppet.com/pe/latest/app_orchestration_overview.html" rel="noreferrer">orchestrate application</a> spread over multiple servers or services, as it was hard to specifically order actions in Puppet, which was a <a href="http://radar.oreilly.com/2015/04/the-puppet-design-philosophy.html" rel="noreferrer">design choice</a>. 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.</p>

<p>That is no longer an issue and so the distinctions are largely preference based.</p>

CC BY-SA 3.0
2017-03-06T21:32:32.047Z
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
CC BY-SA 3.0
2017-08-07T12:05:39.917Z
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
CC BY-SA 3.0
2017-08-08T22:41:31.803Z
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.
Jiri Klouda
CC BY-SA 4.0
2018-12-07T16:28:56.577Z
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
CC BY-SA 3.0
2017-03-05T22:31:48.897Z
2017-03-05T22:37:15.510Z
2017-03-05T22:37:15.510Z
Jiri Klouda
<p>There are of course several pro and cons for each of Puppet, Ansible, Chef and <em>add your favorite tool here</em> as well. So I'll try to stay away from opinion, and share what is great in Ansible as a matter of fact.</p>

<p>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.</p>

<p>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 <code>chef-solo</code>, 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.</p>

CC BY-SA 3.0
2017-03-06T21:31:05.040Z
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
CC BY-SA 3.0
2017-03-30T17:32:19.773Z
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.
Woodland
CC BY-SA 3.0
2017-08-07T12:08:31.050Z
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
CC BY-SA 3.0
2017-12-08T08:46:46.170Z
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
CC BY-SA 4.0
2020-10-14T13:04:42.410Z
@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](https://docs.ansible.com/ansible/latest/network/getting_started/network_differences.html) for more.
RichVel
CC BY-SA 3.0
2017-03-05T21:58:41.910Z
2017-03-07T00:54:09.687Z
2017-03-07T00:54:09.687Z
ᴳᵁᴵᴰᴼ
<p>I would like to understand the differences between Puppet and Ansible, especially what kind of Puppet limitations has in comparison to Ansible.</p>

<p>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?</p>

CC BY-SA 3.0
2017-03-05T22:00:15.520Z
I kept my answer well separeted from this, one of reasons may be all the money redhat is investing in it.
ᴳᵁᴵᴰᴼ
<ansible><comparison><puppet>
What are the limitations of Puppet in comparison to Ansible?
kenorb
# What are the limitations of Puppet in comparison to Ansible?

(Asked by: username_0 on 2017-03-05)

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?

**Tags:** ansible, comparison, puppet

> **Comments:**
> **username_1**: I kept my answer well separeted from this, one of reasons may be all the money redhat is investing in it.  

---

## 3 answers

### Answer by username_1 on 2017-03-05. Score: 21 | Accepted answer

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.

> **Comments:**
> **username_4**: 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  
> **username_7**: 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.  
> **username_5**: 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.  
> **username_8**: 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?  
> **username_5**: @username_8 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](https://docs.ansible.com/ansible/latest/network/getting_started/network_differences.html) for more.  

---

### Answer by username_2 on 2017-03-05. Score: 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.


---

### Answer by username_3 on 2017-03-05. Score: 8

Until Puppet 4.0 there was no easy way to [orchestrate application](https://docs.puppet.com/pe/latest/app_orchestration_overview.html) spread over multiple servers or services, as it was hard to specifically order actions in Puppet, which was a [design choice](http://radar.oreilly.com/2015/04/the-puppet-design-philosophy.html). 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.

> **Comments:**
> **username_4**: 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.  
> **username_5**: 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.  
> **username_3**: 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.  
> **username_6**: 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.  

---

