问题描述
想要了解Puppet和Ansible的区别，特别是Puppet相对于Ansible有哪些限制。他想知道是否有一些在Puppet中无法实现但在Ansible中可以的事情。换句话说，为什么有些人从Puppet转向Ansible？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
Ansible的优势
Ansible相对于Puppet有一些明显的优势，其中最显著的是它不需要在目标节点上运行自定义/额外的代理(agent)，而是仅依赖于SSH连接。这意味着目标节点需要安装SSH服务器、Python以及一些Python库，如果你选择的发行版（或者，如果你使用的是一些Windows节点）不包含这些组件，可能需要一些初始化的工作来准备节点。然而，这种情况并不常见，而且可能会让你重新考虑你的发行版选择。
这种设计使得监控变得更简单，不会占用额外的资源，也不会强制系统一直以root用户身份运行一个守护进程，总的来说更符合UNIX哲学。虽然Chef有chef-solo，Puppet也可以在无主模式下运行，但它们都是通过克隆或者通过钩子实现的。而使用Ansible，源代码库中的合并可以触发部署，这在我们常常使用的工具中是非常方便的，无论是在Jenkins、git主干还是其他工具（比如Rundeck）中。
值得注意的是，如果你在ansible中弄乱了SSH配置，你会被锁定在机器外面，这是推送模型的缺点。而Puppet或Chef可以在定时任务中工作，因此它们不会像Ansible的Python代码一样对系统产生更大的影响。此外，有人认为Ansible的无代理(agentless)架构使其更适合管理路由器等设备，这些设备可能无法安装Puppet代理。但是这些设备是否配备了Python解释器呢？也许不是，所以Python是否真的是每个被Ansible管理的组件的强制要求呢？
对于网络设备，Ansible可以使用SSH、HTTPS、NETCONF或其他协议，并且许多网络厂商都有官方支持的Ansible模块。更多的信息可以查阅Ansible网络自动化文档。
Puppet中的限制
在Puppet 4.0之前，Puppet没有一个简单的方法来编排跨多个服务器或服务的应用程序，因为在Puppet中难以具体排序操作，这是一个设计选择。而Ansible在编排和排序步骤方面更加优秀，特别是在跨多台服务器时。在一些应用程序中，步骤的错误顺序可能导致无法通过重复执行这些步骤来达到最终一致性。
然而，这个问题在现在已经不再是一个问题，所以区别主要是基于偏好。
总的来说，Puppet和Ansible等工具各有千秋，优点和缺点也都有，但通常的选择取决于团队的风格、文化和偏好。