问题
有人可以解释一下为什么选择木偶或厨师vagrant provisioners比shell provisioner更好吗？
背景
我正在开始使用Vagrant。其中一件让我感到困惑的事情是决定使用哪个provisioner。到目前为止，我使用shell provisioner取得了一些成功，但我发现使其可靠运行需要比我预期的更多的工作。
目前，我不熟悉ruby、木偶或厨师，但如果必须我很乐意学习任何一个或全部。我的早期经验表明，如果其他人有一个完全符合你要求的recipe，那么它会非常有效，但做一些非标准的事情意味着要在ruby中编写解决方案。
我知道有关puppet和chef的文章进行比较，我不太担心要使用它们中的哪一个，而是要知道何时以及为什么应该使用它们。
完全透明：我是Puppet Labs的员工。但在加入他们之前，我选择了Puppet作为产品超过2年。
如果您的配置具有任何程度的复杂性并且会随时间变化 - 或者您预计安装环境本身会发生改变以一种可能改变部署执行方式的方式，我建议您使用Puppet或Chef而不是shell。您的脚本可能非常好，但是最终，除非您遵循围绕它们的出色编程实践、测试和QA等方面，否则它们将在某些时候失败。
有关DevOps讨论这个概念的整个文献体系，但归结为“技术债务”的原则-我们 tend to do things the easy way now, and thus perceive them as simpler, at the cost of increasing complexity and difficulty later。
Puppet的一个优点是其确定性-ni编写的清单必须能够被Puppet程序化地转换为您正在构建的服务器模型。这被人们认为是更“困难的”，但是我会认为，如果你沿着你的技术生命周期把它平均起来，那么难度就会降低。换句话说，Puppet迫使您现在进行思考，然后轻松地扩展部署，而不是以后思考并随时重新设计。现在用现金支付，而不是以后使用信用卡支付利息。
如果您仅仅拉取其他人的清单，那么您将会在某些时候遇到麻烦-虽然我们希望不是这样，在今天的Puppet中工作肯定是如此，因为他们编写它们以解决一般情况，而不是您的特定系统。许多通用清单只有在您更好地了解Puppet时才变得有用。
因此，与其从那里开始，我会通过优秀的学习Puppet指南逐步掌握基础知识。Puppet的学习曲线陡峭，但一段时间后就会平稳下来。
使用其他的配置管理工具或工具集也有其它原因，但我肯定会认为相比于尝试确保你的Shell脚本正在做你认为它们应该做的事情，你最好使用Puppet或Chef，特别是当你需要生成新环境的时候。
