Puppet vs Chef，来自用户和用例的赞成与反对意见

我已经在Google上搜索并阅读了“到木偶或主厨这就是问题”一文。

我对用例，现实世界中的实现感兴趣，在现实世界中，人们根据实际问题选择了一个或另一个。

我对与补鞋匠问题的融合特别感兴趣（我知道p是这个方向上的一种标准方法）；作为任何人在皮匠与厨师的融合方面有任何经验吗？

提前致谢

老实说，我认为这可以归结为一个简单的观点：Chef似乎更是一种当务之急的程序化解决方案，使用ruby作为语言立即使我希望有人将其移植到python上，这是世界上所有事物的共同之处。红宝石的想法。

但这不是您想要的那种东西。您想对系统将位于的空白讲话并声明：

“在北部的80号港口召唤一个名为nginx的守护进程。他的任务是服务。”

“用户应该存在，他的名字应该时髦，他应该是轮子中最强大的人之一。”

“抬起一堵火墙，在80,443,8080的地方变薄”

依此类推，尽管在语言上也许没那么花哨。

木偶支持这种范例更好的IMO。我曾经用过任何一个，但我没有偏好，但是当涉及到它时，声明式更适合我。

木偶。

我在这里写了Chef与Puppet的详细比较：Puppet与Chef：Puppet获胜的10个理由。尽管它不包括用例，但我希望它为那些想知道为基础架构自动化选择哪种工具的人们提供了有用的起点。

抱歉，冗长。使用易于完成工作的工具。这就是自动化的重点，对不对？

历史：我在过去的演出中都使用过木偶，上个月我花了大约一周的时间来尝试做厨师，看看我是否会在新的演出中进行转换。

我没有跳。

行话：这两个系统的一个不幸问题是行话过载。（配方，模板，节点，角色，属性，提供程序）。我发现厨师走了一步。（刀，架子等）

代码成熟度：可以说我发现Chef有点太原始了。这感觉很像木偶在3-4年前的.21 / .22时间范围内的感觉。发生了很多变化。

并不是说在木偶中也没有发生过。（我重新发现了木偶的许多重要功能，这些功能仅在最近几年才浮出水面。-正则表达式匹配！）

Ruby：我不喜欢Chef中所有的红宝石超载。（甚至在开始之前，您都需要宝石和耙子）您可以使用ruby解决人偶中的复杂问题，但是如果您不想这样做，则不必这样做。

复杂性：我不喜欢GUI专注于厨师。我意识到这很漂亮，并且该人偶还具有一个Web界面作为附件，但是我认为应该更加分离。

Chef的架构要复杂得多。它可能会更好地扩展，但是存在很多潜在的故障点。
http://wiki.opscode.com/display/chef/Architecture

除API服务器和Web界面外，Chef还需要couchdb，rabbitmq和solr。

我只想要一个简单的客户端/服务器接口，该接口不需要在其顶部的MVC框架，也不需要在其后的复杂数据存储。

木偶在那个部门要简单得多。（并不是说没有很多附加组件可以使它更混乱）

完成工作：最后，我按照我所知道的去做。在花了一周的时间进行侧面黑客攻击后，几乎无法用Chef完成基础知识之后，我得以返回木偶，并在几个小时内满足了我的基本需求。（程序包管理，用户管理，配置文件模板）

关于模块的注意事项：Puppet最近已转变为使用由第三方提供的“模块”。我并没有最终使用它们，但发现它们的质量范围很广。在深入研究这些内容之前，请务必先对其进行窥探，并查看它们的工作方式和工作方式。

这是一个意见：我们已经在公司中尝试了所有这些，并且我们更喜欢木偶。仅仅是因为它易于使用。

我本人也看到过使用puppet轻松管理具有不同配置的1000台主机的情况。像Google这样的事实上的公司使用puppet进行部署。

人偶的主要设计架构是这样的，如果以正确的方式进行配置，它的效果将比其他人好得多。例如，为您的自定义配置等添加您的自定义事实，以下链接可能会提供一些信息 http://slashroot.in/puppet-tutorial-installing-puppet-master-and-puppet-agent

http://slashroot.in/puppet-tutorial-how-does-puppet-work

自上次尝试以来，这种情况可能已更改，但是当我在RHEL上尝试厨师时，没有明确的安装方法。有人创建了一个yum存储库，其中包含所有需要的软件包，但是最终却安装了200个奇数软件包。另一方面，Puppet具有单个rpm（以及几个相关项）。