谁能解释为什么会更好地选择傀儡或厨师流浪者提供者，而不是shell提供者？
背景
我正在开始使用Vagrant。我遇到的问题之一是决定使用哪个供应商。到目前为止，我使用shell提供程序已经取得了一些成功，但是它比我预期的更可靠地运行。
目前，我不熟悉红宝石，木偶或厨师，但我很高兴学习任何或所有的，如果我有。我早期的玩木偶和厨师的经验是，如果别人有一个配方，你想要什么，它的工作原理很好，但做一些非标准的意思是回退编码解决方案在ruby。
我知道比较puppet and chef的文章，我不太担心，他们使用，而不是知道什么时候和为什么我应该使用它们。
我建议你使用Puppet或Chef over shell，如果你的配置将a)有任何程度的复杂性和b)将随时间的变化 – 或者你期望你的安装环境本身改变的方式，可能改变方式您的部署执行。你的脚本可能是非常好的，但最终，除非你在他们周围进行了可怕的编程实践，测试和QA’ing他们等，他们将在某个时候失败。
DevOps讨论这个概念有一个整体，但它归结为“技术债务”的原则 – 我们倾向于现在做容易的方式，因此认为它们更简单，以增加复杂性和困难为代价后来。
Puppet的优势之一是它的确定性本质 – 你编写的清单必须能够由Puppet以编程方式转换为您正在构建的服务器的模型。这被人们认为是更“困难”，但我会认为，如果你沿着技术的生命周期的曲线平均化它的困难减少。换句话说，Puppet强迫你现在做你的想法，但随后部署以轻松扩展，而不是在以后思考和重新设计。以后现在用现金支付，而不是用信用支付。
如果你纯粹拉下其他人的清单，你会在某个时候遇到麻烦 – 虽然我们希望它不是这样，今天使用Puppet，这是肯定的情况，因为他们正在写他们去寻址一般情况下，而不是你的特定系统。许多通用目的清单只有当你更好地理解Puppet时才有用。
所以，而不是从那里开始，我会工作的方式通过优秀的Learning Puppet指南，开始抓住基础。 Puppet的学习曲线是陡峭的，但它在一段时间后就会消失。
还有其他原因使用其他供应商或工具，但我一定会说，你是最好的Puppet或厨师，而不是试图确保你的shell脚本正在做你想的是他们应该做的，只要你需要产生新的环境。
