我已经在谷歌上搜索并阅读了“木偶还是厨师，这是个问题”文章。
我对用例、现实世界的实现感兴趣，其中人们根据实际问题选择其中一个。
我特别感兴趣的是与 cobbler 集成问题（我知道木偶是这个方向的标准方法）；任何人都有经验cobbler-chef 集成？
提前致谢
答案1
老实说，我认为这可以归结为简单的观点：Chef 似乎更像是一种命令式、程序化的解决方案，使用 ruby 作为语言让我立刻希望有人将它移植到 python，因为这是 ruby 所有想法的世界规律。
但这并不是你想要的。你想谈论系统所在的虚空，宣布：
“在80端口从北方召唤一个叫nginx的守护进程。它的任务就是提供服务。”
“应该存在一个用户，他的名字应该是chiggsy，他应该是wheel组中的强者之一，”
“筑起一道火墙，在 80,443,8080 处变薄”
等等，尽管语言可能不那么华丽。
在我看来，Puppet 更好地支持该范例。我会使用其中任何一种，我没有偏好，但归根结底，声明式更适合我。
木偶。
答案2
我在这里对 Chef 和 Puppet 进行了详细的比较：Puppet 与 Chef 对比：Puppet 胜出的 10 个理由。虽然它没有包括用例，但我希望它能为那些想知道选择哪种工具来实现基础设施自动化的人们提供一些有用的起点。
答案3
抱歉说得太啰嗦了。使用那些能让你轻松完成工作的工具吧。这就是自动化的意义所在，对吧？
历史：我在过去的工作中使用过 Puppet，上个月我花了大约一周的时间尝试适应 Chef，看看我是否会在新的工作中做出改变。
我没跳。
术语：这两个系统的一个不幸问题是术语过多。（配方、模板、节点、角色、属性、提供商）术语太多了。我发现 Chef 更进了一步。（Knife、Shef 等）
代码成熟度：可以说，我发现 Chef 有点太过原始。它的感觉很像 3-4 年前 .21/.22 时间段内的 puppet。有很多变化在发生。
并不是说这在 Puppet 中没有发生过。（我重新发现了 Puppet 中许多在过去几年中才出现的优秀功能——正则表达式匹配！）
Ruby：我不喜欢 Chef 中的所有 ruby 重载。（在开始之前你需要 gem 和 rake）你可以使用 ruby 来解决 puppet a'la facter 中的复杂问题，但如果你不想的话你不必这样做。
复杂性：我不喜欢 Chef 的 GUI 焦点。我知道它很漂亮，而且 Puppet 有一个正在开发的 Web 界面作为附加组件，但我觉得应该更加分离。
Chef 的架构要复杂得多。它的扩展性可能更好，但也存在许多潜在的故障点。
http://wiki.opscode.com/display/chef/Architecture
除了 API 服务器和 Web 界面之外，Chef 还需要 Couchdb、Rabbitmq 和 solr。
我只想要一个简单的客户端/服务器界面，它不需要其上的 MVC 框架和其后的复杂数据存储。
在这方面，Puppet 要简单得多。（并不是说没有很多附加组件让它变得更混乱）
完成工作：最后，我选择了我所了解的。在花了一周时间进行业余黑客攻击并几乎无法使用 Chef 完成基本工作之后，我能够回到 Puppet 并在几个小时内完成我的基本需求。（包管理、用户管理、配置文件模板）
关于模块的警告：Puppet 最近转向使用第三方提供的“模块”。我最终没有使用这些模块，我发现它们的质量参差不齐。在深入研究这些模块之前，请务必先查看一下内部情况，看看它们的作用是什么以及如何工作。
答案4
我自己就见过使用 puppet 管理 1000 个具有不同配置的主机的情况，这要容易得多。事实上，像谷歌这样的公司使用 puppet 进行部署。
puppet 的主要设计架构是这样的，如果你以正确的方式配置它，它会比其他产品更好用。例如，为你的自定义配置添加自定义事实等。以下链接可能会提供一些信息 http://slashroot.in/puppet-tutorial-installing-puppet-master-and-puppet-agent