drA*_*erT 55 rhel5 configuration-management puppet cobbler chef
我已经用谷歌搜索并阅读了“to-puppet-or-to-chef-that-is-the-question”文章。
我对用例感兴趣，在现实世界的实现中，人们根据实际问题选择了一个或另一个。
我对与 cobbler问题的集成特别感兴趣（我知道 puppet 是这个方向的标准方法）；作为任何人在鞋匠 - 厨师整合方面的任何经验？
提前致谢
chi*_*gsy 62
老实说，我认为这归结为简单的观点：Chef 似乎更像是一种命令式的程序化解决方案，使用 ruby 作为语言立即让我希望有人将其移植到 python，就像世界上所有的方式一样红宝石的想法。
不过，这不是你想要的。你想对系统所在的虚空说话并声明：
“在80端口从北方召唤了一个名为nginx的守护进程。他的任务是服务。”
“一个用户应该存在，他的名字应该是chiggsy，他应该是车轮组中的强者之一，”
《筑起火墙，薄处八万四十四万三千八千八十》
等等，虽然在语言上可能不那么花哨。
Puppet 更好地支持 IMO 范式。我会使用任何一种，我没有偏好，但归根结底，声明式更适合我。
木偶。
小智 18
我在此处详细比较了 Chef 与 Puppet：Puppet vs Chef：Puppet 获胜的 10 个原因。虽然它不包括用例，但我希望它为那些想知道为他们的基础设施自动化选择哪种工具的人提供一些有用的起点。
Joe*_*l K 14
抱歉冗长。使用可以轻松完成工作的工具。这就是自动化的重点，对吧？
历史：我在过去的演出中使用过 puppet，上个月我花了大约一周的时间尝试适应厨师，看看我是否会在我的新演出中进行转换。
我没有跳。
行话：这两个系统的一个不幸问题是行话过载。（食谱、模板、节点、角色、属性、提供者）它一直在继续。我发现厨师更进一步。（刀，Shef 等）
代码成熟度：可以说我发现 Chef 有点太原始了。感觉很像 3-4 年前 .21/.22 时间范围内的 puppet 感觉。有很多流量正在发生。
并不是说这在傀儡中也没有发生过。（我重新发现了 puppet 中许多最近几年才出现的强大功能。--正则匹配！）
Ruby：我不喜欢 Chef 中所有的 ruby 重载。（在开始之前，您需要 gem 和 rake）您可以使用 ruby 解决 puppet a'la facter 中的复杂问题，但如果您不想，则不必这样做。
复杂性：我不喜欢 GUI 专注于厨师。我意识到它很漂亮，并且木偶在作品中有一个 Web 界面作为附加组件，但我觉得应该更加解耦。
Chef 的架构要复杂得多。它可能会更好地扩展，但有很多潜在的故障点。
http://wiki.opscode.com/display/chef/Architecture
除了 API 服务器和 Web 界面外，Chef 还需要 couchdb、rabbitmq 和 solr。
我只想要一个简单的客户端/服务器接口，它不需要 MVC 框架和复杂的数据存储。
Puppet 在那个部门要简单得多。（并不是说没有很多附加组件可以使它变得更加混乱）
完成工作：最后，我按照我所知道的去做。在花了一周的时间进行黑客攻击并且几乎无法与 Chef 一起完成基本操作之后，我能够在几个小时内回到 Puppet 并解决我的基本需求。（包管理、用户管理、配置文件模板）
关于模块的警告：Puppet 最近转向使用由第三方提供的“模块”。我最终没有使用这些，我发现它们的质量范围很广。在深入研究这些内容之前，请务必先窥视一下幕后情况，看看它们的工作原理和方式。