在决定使用Chef或Puppet时，有哪些正确的问题要问？

我将开始一个新项目，该项目将部分需要部署大约三个不同类的许多相同节点：

• 数据节点，它将运行MongoDB的分片实例。
• 应用程序节点，它将运行Ruby on Rails应用程序和较旧的ASP.NET MVC应用程序的实例。
• 处理节点，它将运行应用程序节点请求的作业。

所有节点将在Ubuntu 10.04实例上运行，尽管它们将安装不同的软件包。

尽管我不认为自己是专家，但我对以前项目中的Chef有所了解。为了尽职调查，我一直在研究其他可能性。我们内部有很多人是Puppet的长期用户，所以他们鼓励我看看。

我在评估这两种选择时遇到了麻烦。Chef和Puppet共享许多相同的领域术语- 包，资源，属性等，它们有着共同的历史，源于对同一问题采用不同的方法。因此从某种意义上说它们非常相似。但是，像本文一样，我发现的许多比较信息都有些过时。

如果您今天开始这个项目，您会问自己哪些问题来决定应该使用Chef还是Puppet进行配置管理？（注：我不想要回答这个问题：“我应该用厨师或木偶？”）

木偶和厨师都可以做您想要的事情。最好的办法是开始做您想做的事情，然后确定最喜欢的工具。我认为您必须提出的主要问题是：

您要DSL吗？-厨师食谱用红宝石编写，木偶有DSL。DSL的好坏选择是厨师与chef之间最大的区别之一。您发布到bitfield咨询公司的比较的链接对此有一些不错的评论，如果您尚未阅读，则应阅读。我还发现此博客文章很有用，请确保您也阅读了评论。

你知道红宝石吗？-如果您不懂红宝石，由于需要学习一门新语言，因此开始厨师比较困难，或者需要花费大量时间。Puppet有自己的语言，很容易上手。从puppet 2.6开始，清单也可以用ruby编写。

在2009年的Open Source Bridge中，他们有一个由Chef和puppet，bcfg2，cfengine和automateit的作者和代表组成的小组，您可以在bliptv上观看，该小组讨论了有关配置管理实用程序的1.75个小时。

Opscode / Chef 在其常见问题解答中也谈到了它与人偶之间的区别。

我认为您不知道要问的正确问题可能是由于您对它们中的任何一个都没有太多的经验，一旦开始使用它们，您将开始看到它们之间的差异。我建议您与厨师或木偶一起解决一些现实生活中的问题，然后开始尝试解决它们，看看您对它们的喜欢/不喜欢什么。通过Opscode / Chef，他们提供了一个托管解决方案，您可以免费设置5个节点来开始使用。

首先让我说-如果您既不使用Puppet也不使用Chef；没有错误的答案。哪一种都会比您现在做的要好得多。

作为团队负责人，我为团队选择了Puppet。如果我只是一个自己的团队，我会选择厨师。原因如下：

虽然我的专长当然是系统管理，但是我的背景是编程。这就是我上学的目的，并且我对编写完整的应用程序（不仅仅是脚本）并不陌生。虽然我不了解Ruby，但我想知道，而Chef将是学习两者的绝妙借口。

但是，除了偶尔的shell脚本外，我的团队中还充满了几乎没有编程经验的系统管理员。对他们来说，编写a模块很像编写配置文件。它是声明性的，没有迭代器，总体而言，它对管理员更友好。

充满系统管理员开发人员的团队通常更喜欢Chef。由于Puppet的DSL是声明性的，因此顺序（即使在单个文件中）也无关紧要，这使许多习惯于更典型的编程语言的人感到沮丧。

我还听说过很多时候，Chef比Puppet对云友好得多，但是Puppet在过去一年中一直将重点放在其Puppet Enterprise产品上。我不能从任何一种产品的云功能的经验谈起。

由于具有上述品质，因此刻板印象（通常是正确的）是，您会发现Puppet在物理计算机上的企业中更加普及，而Chef在这里管理着云计算中的初创企业。当然也有例外，但是我所看到的肯定支持定型观念。

如果是一个单人团队，则对两者进行评估，然后选择您喜欢的人。但是，如果像我这样有一群人，请确保您将团队的需求优先于任何个人喜好，这将在以后尝试购买时节省您的时间。

完全公开，尽管试图在配置管理系统上进行内部评估，但我们并未使用这两种方法。所以，无论如何，不​​要以我为专家。

• 获得实例设置有多容易？
• 客户端需要什么设置才能使其与服务器通信？

等等。但是您可以自己轻松地回答这些问题：设置它们！每个产品的样本获取和运行需要花费几个小时，并且考虑到将其用于任何用途都可能需要很长时间，因此花时间是值得的。您不仅可以了解它们如何处理特定于平台的事物（即，基于Debian和apt，基于RPM和yum），而且肯定可以帮助您了解应用程序。

还要记住，世界上的所有功能都无法弥补困难的界面，此外，它可能会暴露特定于您的基础结构的问题，即，如果以不同的顺序更新配置文件会发生什么情况超出预期？

这就是我的建议；Chef和Puppet并不难获得一台服务器和一两个客户端的安装程序，它们将为您提供两种方面的第一手经验。另外，如果您开始设置它并意识到它的巨大痛苦，那么在致力于它之前您已经具备了知识。

如果您的项目中已经有Puppet经验的人，那么我建议您只使用Puppet。

Chef和Puppet非常相似，并且两个项目的质量都一样。如果您可以访问已经有Puppet经验的人员，请使用Puppet。

以上绝对是一个很好的指南，每当我考虑新的第三方依赖关系时，我也想问这些一般性问题。

• 项目的年龄是多少？
• 社区的活跃程度（邮件列表，错误，irc等）？
• 标准实践提供了良好的可靠文档吗？

这些是项目总体成功的良好指标，可以预测寿命。

尝试找到已经使用Chef或Puppet超过几个月的人，并询问他们的经历。

对我来说，这与特定社区的传统紧密相关。从历史上看，Chef更接近RubyOnRails家伙。厨师在ROR社区中也很受欢迎，因为Engineyard在厨师的基础上建立了他们的基础架构。