问题
谁能解释为什么选择 puppet 或 chef vagrant provisioner 比 shell 供应商更好？
背景
我正在开始使用 Vagrant。我遇到的一件事是决定使用哪个配置器。到目前为止，我在使用 shell 配置程序方面取得了一些成功，但要让它可靠地运行，它的工作量比我预期的要多。
目前，我对 ruby、puppet 或 Chef 不熟悉，但如果有必要，我很乐意学习其中的任何一个或全部。我早期玩 puppet 和 chef 的经验是，如果其他人的食谱完全符合您的要求，它会非常有效，但做一些非标准的事情意味着回退使用 ruby 编写解决方案。
我知道比较puppet 和 chef的文章，我不太担心使用它们中的哪一个，而不是知道何时以及为什么应该使用它们。
全面披露：我是 Puppet Labs 的员工。但在加入他们之前，我选择了 Puppet 作为产品超过 2 年。
我建议您使用 Puppet 或 Chef 而不是 shell，如果您的配置将 a) 具有任何程度的复杂性并且 b) 会随着时间的推移而改变 - 或者您希望您的安装环境本身以可能改变方式的方式发生变化您的部署执行。您的脚本可能非常好，但最终，除非您围绕它们遵循极好的编程实践、测试和 QA 等，否则它们将在某些时候失败。
围绕 DevOps 讨论这个概念的有一大群知识分子，但这归结为“技术债务”的原则——我们现在倾向于以简单的方式做事，因此认为它们更简单，但代价是增加了复杂性和难度之后。
Puppet 的优势之一是它的确定性 - 您编写的清单必须能够由 Puppet 以编程方式转换为您正在构建的服务器的模型。人们认为这更“困难”，但我认为如果你沿着技术生命周期的曲线平均它，难度就会降低。换句话说，Puppet 迫使您现在就进行思考，然后轻松地进行部署以扩展，而不是稍后思考并在进行时重新设计。现在用现金支付，而不是用信用卡支付，以后有利息。
如果你纯粹是拉下其他人的清单，你会在某个时候遇到麻烦——尽管我们不希望这样，但今天与 Puppet 合作肯定是这样，因为他们正在写它们来解决一般情况，而不是您的特定系统。许多通用清单只有在您对 Puppet 有了更好的理解时才会变得有用。
因此，我不会从那里开始，而是通过出色的Learning Puppet指南开始掌握基础知识。Puppet 的学习曲线很陡峭，但很快就会趋于平稳。
使用其他配置程序或工具还有其他原因，但我肯定会争辩说，你最好使用 Puppet 或 Chef，而不是试图确保你的 shell 脚本完全按照你认为的那样做，只要你需要产生新的环境。
啊，随着选择的自由而来的是选择适合你的东西的复杂性。
Chef Solo - 如果您刚刚开始使用 Chef，或者 Chef 服务器对您的情况来说太重了，Chef Solo 是最理想的选择。Chef solo 还允许您将所有食谱嵌入到您的项目中，这对于希望在同一存储库中跟踪其食谱的项目非常有用。Chef solo 独立运行——它不需要厨师服务器或任何其他服务器与之交谈；它只是在虚拟机上自行运行。
Chef 服务器- Chef 服务器对于管理许多项目的公司或个人很有用，因为它允许您在多个项目之间共享食谱。食谱本身存储在服务器上，客户端在运行时下载食谱。
Puppet - Puppet 配置器运行独立的 Puppet 清单，这些清单存储在服务器上，并在创建时下载到客户端 VM。Provisioner 不需要 Puppet 服务器并在 VM 本身上运行。
Puppet Server - Puppet Server 供应商连接到 Puppet 服务器并使用该服务器上的节点配置配置您的客户端 VM。
其他工具、shell 脚本等 - 你使用的不是 Vagrant 内置的东西吗？Provisioner 只是 Vagrant::Provisioners::Base 的子类，这意味着您可以在需要时轻松构建自己的。
您还可以查看文档docs.vagrantup.com/v2
我会选择 Shell 配置器，然后让 shell 脚本从 github 或 bitbucket 克隆你的 puppet/chef 存储库。该脚本可以设置一个 ssh 密钥以允许自动 git 克隆。好处是大多数云提供商也支持这一点，因此您可以使用相同的脚本。这个博客很好地解释了 git、puppet 和 vagrant，一个人和云博客