bash - 选择一个 vagrant provisioner

Question

问题

谁能解释为什么选择 puppet 或 chef vagrant provisioner 而不是 shell provisioner 会更好？

背景

我正在开始使用 Vagrant。我遇到的问题之一是决定使用哪个供应商。到目前为止，我已经使用 shell provisioner 取得了一些成功，但是要让它可靠地运行比我预期的要多。

目前，我不熟悉 ruby​​、puppet 或 chef，但如果需要的话，我很乐意学习其中的任何一个或全部。我早期使用 puppet 和 chef 的经验是，如果其他人的 Recipe 完全符合您的要求，那么它的效果非常好，但是做一些非标准的事情意味着退回到用 ruby​​ 编写解决方案。

我知道比较 puppet and chef 的文章，而且我不太担心使用它们中的哪一个，而不是完全知道何时以及为什么应该使用它们。

Answer 1

完全披露:我是 Puppet Labs 的员工。但在加入他们之前的 2 年多时间里，我选择了 Puppet 作为产品。

如果您的配置将 a) 具有任何程度的复杂性并且 b) 将随着时间而改变，或者您希望您的安装环境本身以可能发生的方式改变，我建议您在 shell 上使用 Puppet 或 Chef改变部署的执行方式。您的脚本可能非常好，但最终，除非您围绕它们遵循出色的编程实践、对其进行测试和 QA，否则它们最终会在某个时候失败。

围绕 DevOps 有很多有文化的人在讨论这个概念，但它归结为“技术债务”的原则——我们现在倾向于以简单的方式做事，因此认为它们更简单，但代价是增加复杂性和难度稍后。

Puppet 的优势之一是其确定性 - 您编写的 list 必须能够由 Puppet 以编程方式转换为您正在构建的服务器模型。人们认为这更“困难”，但我认为，如果您沿着技术生命周期的曲线对其进行平均，难度就会降低。换句话说，Puppet 迫使您现在就思考，然后轻松部署以扩大规模，而不是事后思考并在进行时重新设计。现在用现金支付，而不是以后用信用卡支付利息。

如果你纯粹是拉下其他人的 list ，你会在某个时候遇到麻烦 - 虽然我们不希望这样，但今天使用 Puppet 肯定是这样，因为他们正在写它们是为了解决一般情况，而不是您的特定系统。只有当您更好地理解 Puppet 时，许多通用 list 才会变得有用。

因此，与其从那里开始，我会努力完成出色的 Learning Puppet指导开始掌握基础知识。 Puppet 的学习曲线很陡峭，但很快就会趋于平稳。

使用其他配置器或工具还有其他原因，但我肯定会争辩说，使用 Puppet 或 Chef 比尝试确保您的 shell 脚本完全按照您认为它们应该做的做更好，因为只要您需要产生新的环境。