我即将启动一个新项目，该项目部分需要部署大约三个不同类别的许多相同节点：
- 数据节点，它将运行 MongoDB 的分片实例。
- 应用程序节点，它将运行 Ruby on Rails 应用程序和较旧的 ASP.NET MVC 应用程序的实例。
- 处理节点，它将运行应用程序节点请求的作业。
所有节点都将在 Ubuntu 10.04 实例上运行，尽管它们安装的软件包不同。
虽然我不认为自己是专家，但我通过以前的项目对 Chef 有所了解。为了尽职尽责，我一直在研究其他可能性。我们公司内部有很多人是 Puppet 的长期用户，他们鼓励我去了解一下。
不过，我很难评估这两种选择。Chef 和 Puppet 有许多相同的领域术语——包，资源，属性等等，它们有着共同的历史，源于对同一问题采取不同的方法。所以在某种意义上，它们非常相似。但我找到的许多比较信息，比如本文，有点过时了。
如果您今天开始这个项目，您会问自己什么问题来决定是否应该使用 Chef 或 Puppet 进行配置管理？（注：我不想要“我应该使用 Chef 还是 Puppet？”这个问题的答案
答案1
Puppet 和 Chef 都可以很好地完成您想要的工作。您最好的选择是开始做您想做的事情，然后决定您最喜欢哪种工具。我认为您必须问的大问题是：
您想要 DSL 吗？- Chef 食谱是用 ruby 编写的，而 Puppet 有 DSL。DSL 是好是坏是 Chef 和 Puppet 之间最大的区别之一。您发布的链接bitfield consulting 的比较有一些关于这个的很好的评论，如果你还没有读过的话，你应该读一读。我还发现这篇博文有用，请确保你也阅读了评论。
你认识红宝石吗？- 如果你不懂 ruby，那么开始使用 chef 可能会更难，或者需要投入更多的时间，因为你需要学习一门新语言。Puppet 有自己的自己的语言入门非常简单。从 puppet 2.6 开始，清单可以用 ruby 编写也。
在 2009 年的 Open Source Bridge 上，他们有一个由 chef、puppet、bcfg2、cfengine 和 automatedit 的作者和代表组成的小组，您可以在 bliptv 上观看其中有 1.75 小时的有关配置管理实用程序的讨论。
Opscode/Chef 谈其与 puppet 的区别在他们的常见问题解答中也一样。
我认为你不知道该问什么问题可能是因为你没有太多使用它们的经验，一旦你开始使用它们，你就会开始看到它们之间的差异。我建议你先想出一些你将用 chef 或 puppet 解决的现实问题，然后开始尝试解决它们，看看你喜欢/不喜欢它们的地方。使用 Opscode/Chef，他们提供托管解决方案您可以免费设置 5 个节点来开始使用。
答案2
首先我要说的是——如果你不使用 Puppet 或 Chef，那么就没有错误的答案。两者都会比你现在做的好得多。
作为团队领导，我为我的团队选择了 Puppet。如果我的团队只有我一个人，我会选择 Chef。原因如下：
虽然我的专长是系统管理，但我的背景是编程。这是我上学时学的专业，我对编写完整的应用程序（而不仅仅是脚本）并不陌生。虽然我不懂 Ruby，但我想学，而 Chef 会是一个很好的借口去学习两者。
然而，我的团队里全是几乎没有编程经验的系统管理员，除了偶尔使用 shell 脚本。对他们来说，编写 puppet 模块就像编写配置文件一样。它是声明式的，没有迭代器，总体来说更便于管理。
从事系统管理活动的开发人员组成的团队往往更喜欢 Chef。由于 Puppet 的 DSL 是声明性的，因此顺序（即使在单个文件内）并不重要，这让许多习惯使用更典型编程语言的人感到沮丧。
我也听过很多次有人说 Chef 比 Puppet 更适合云环境，但 Puppet 在过去一年中已将云环境作为其 Puppet Enterprise 产品的重点。我无法根据经验评价这两种产品的云能力。
由于上述这些特点，人们的刻板印象（通常是正确的）是，您会发现 Puppet 在企业物理机器上更为普及，而 Chef 则在云端主导着初创企业。当然也有例外，但我所看到的情况肯定支持这种刻板印象。
如果是单人团队，那么请评估两者并选择您喜欢的那个。但是，如果您像我一样拥有一个团队，请确保将团队的需求置于任何个人偏好之上，这将在您尝试获得认同时为您节省时间。
答案3
坦白说，我们不会使用其中任何一种，尽管我们在决定配置管理系统时对它们进行了内部评估。所以，不要认为我是其中任何一种方面的专家。
- 设置实例有多容易？
- 客户端需要进行哪些设置才能与服务器进行通信？
等等。但您可以自己轻松回答这些问题：设置它们！每个产品都需要花费几个小时来启动和运行示例，考虑到您使用它的任何产品都可能要使用很长时间，所以这段时间非常值得。您不仅可以了解它们如何处理特定于平台的事情（即基于 Debian 和 apt、基于 RPM 和 yum），而且它肯定会帮助您了解应用程序。
还要记住，世界上所有的功能都无法弥补困难的界面，此外，它可能会暴露特定于您的基础设施的问题 - 例如，如果配置文件的更新顺序与预期不同，会发生什么？
所以我的建议是：Chef 和 Puppet 并不难安装一台服务器和一两个客户端，而且可以让你亲身体验两者。另外，如果你开始安装并意识到它非常麻烦，那么在开始安装之前你已经掌握了相关知识。
答案4
以上绝对是一个很好的指导方针，每当我考虑新的第三方依赖时，我也喜欢问这些一般性问题。
- 项目已有多少年了？
- 社区有多活跃（邮件列表、bug、irc 等）？
- 是否提供了符合标准实践的良好且可靠的文档？
这些都是项目整体成功的良好指标，并可以在某种程度上预测其寿命。