选择流浪供应者
问题
任何人都可以解释为什么选择木偶或厨师流浪供应者而不是外壳供应者更好？
背景
我正在开始使用 Vagrant。我遇到的麻烦之一是决定使用哪个配置程序。到目前为止，我已经使用 shell 配置程序取得了一些成功，但是要让它可靠地运行，工作量比我预期的要多。
目前，我不熟悉 ruby、puppet 或 Chef，但如果需要的话，我很乐意学习其中任何一个或全部。我早期玩木偶和厨师的经验是，如果其他人有一个完全符合你想要的菜谱，它的效果非常好，但做一些非标准的事情意味着退回到用 ruby 编写解决方案。
我知道有一些文章比较puppet 和 Chef，而且我不太担心其中的哪一个使用，而不是知道何时以及为什么应该使用它们。
Question
Can anyone explain why it would be better to choose the puppet or chef vagrant provisioners, rather than the shell provisioner?
Background
I'm in the process of getting started with Vagrant. One of the things I'm having trouble with is deciding which provisioner to use. So far, I've had some success using the shell provisioner, but it has been more work than I expected to get it to run reliably.
At the moment, I'm not familar with ruby, puppet or chef, but I'm happy to learn any or all of them if I have to. My early experience playing with puppet and chef is that if someone else has a recipe that does exactly what you want, it works really well, but doing something non-standard means falling back coding up solution in ruby.
I'm aware of articles comparing puppet and chef, and I'm less worried about which of them to use, rather than knowing when and why I should use them at all.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
全面披露：我是 Puppet Labs 的员工。但在加入他们之前的两年多时间里，我选择了 Puppet 作为产品。
如果您的配置将a）具有任何程度的复杂性并且b）将随着时间的推移而变化 - 或者您希望您的安装环境本身以可能改变方式的方式发生变化，我建议您使用Puppet或Chef over shell您的部署执行。您的脚本可能非常好，但最终，除非您遵循围绕它们的出色的编程实践，对它们进行测试和质量检查等，否则它们在某些时候将会失败。
有很多围绕 DevOps 的知识分子都在讨论这个概念，但这归结为“技术债务”的原则——我们现在倾向于以简单的方式做事，因此认为它们更简单，但代价是增加了复杂性和难度之后。
Puppet 的优势之一是其确定性本质 - 您编写的清单必须能够由 Puppet 以编程方式转换为您正在构建的服务器的模型。人们认为这更“困难”，但我认为，如果沿着技术生命周期的曲线对其进行平均，难度就会减轻。换句话说，Puppet 迫使您现在就思考，然后轻松部署以扩展规模，而不是稍后思考并边做边重新设计。现在就用现金支付，而不是通过信用卡支付，稍后再支付利息。
如果你纯粹是拉取其他人的清单，那么你在某些时候会遇到麻烦 - 尽管我们不希望这样，但今天与 Puppet 合作确实是这样，因为他们写这些清单是为了解决一般情况，而不是您的特定系统。仅当您更好地了解 Puppet 时，许多通用清单才会变得有用。
因此，我不会从这里开始，而是通过出色的学习 Puppet 指南来开始掌握基础知识。 Puppet 的学习曲线很陡峭，但很快就会趋于平稳。
使用其他配置程序或工具还有其他原因，但我肯定会认为，使用 Puppet 或 Chef 比尝试确保 shell 脚本完全按照您认为它们应该执行的操作更好，只要您需要产生新的环境。
Full disclosure: I'm a Puppet Labs employee. But I chose Puppet as a product over 2 years before joining them.
I would recommend that you use Puppet or Chef over shell if your configurations are going to a) have any degree of complexity and b) going to change over time - or you expect your installation environment itself to change in a way that might alter the way your deployment performs. Your scripts may be very good, but ultimately, unless you are following terrific programming practices around them, testing and QA'ing them, etc they are going to fail at some point.
There's an entire body of literate around DevOps discussing this notion, but it comes down to the principle of "technical debt" - we tend to do things the easy way now, and thus perceive them as simpler, at the cost of increasing complexity and difficulty later.
One of Puppet's strengths is its deterministic nature - the manifest you write must be able to be programmatically transformed by Puppet into a model of the server you are building. This is perceived by people as being more "difficult" but I would argue that the difficulty is lessened if you average it out along the curve of your technology's lifecycle. In other words, Puppet forces you to do your thinking now, but then deploy to scale with ease, rather than thinking later and re-engineering as you go. Pay in cash now, rather than by credit, with interest, later.
If you're purely pulling down other peoples' manifests, you're going to run into trouble at some point - although we would like it not to be so, working with Puppet today that's certainly the case, because they are writing them to address the general case, and not your particular system. Many general-purpose manifests become useful only when you reach a better understanding of Puppet.
So rather than start there, I'd work my way through the excellent Learning Puppet guide to start to grasp the basics. Puppet's learning curve is steep, but it levels off after a short while.
There are other reasons to use other provisioners or tools, but I'd surely argue that you are better with Puppet or Chef than trying to ensure that your shell scripts are doing exactly what you think they are supposed to do, for as long as you need to spawn new environments.
啊，随着选择的自由而来的是选择适合你的东西的复杂性。
Chef Solo - 如果您刚刚开始使用厨师，或者厨师服务器对于您的情况来说太重，那么 Chef Solo 是最理想的选择。 Chefolo 还允许您将所有食谱嵌入到项目中，这对于想要在同一存储库中跟踪其食谱的项目来说非常有用。 Chef Solo 独立运行——它不需要 Chef 服务器或任何其他服务器与之通信；它只是在虚拟机上自行运行。
Chef Server - Chef 服务器对于管理多个项目的公司或个人非常有用，因为它允许您跨多个项目共享食谱。食谱本身存储在服务器上，客户端在运行时下载食谱。
Puppet - Puppet 配置程序运行独立的 Puppet 清单，这些清单存储在服务器上，并在创建客户端 VM 时下载到客户端 VM。配置器不需要 Puppet 服务器并在 VM 本身上运行。
Puppet 服务器 - Puppet 服务器配置程序连接到 Puppet 服务器并使用该服务器上的节点配置来配置您的客户端 VM。
其他工具、shell 脚本等 - 除了 Vagrant 内置的工具之外，您还使用其他工具吗？
Provisioners 只是 Vagrant::Provisioners::Base 的子类，这意味着您可以在需要时轻松构建自己的。
您还可以查看文档，docs.vagrantup.com/v2
Ah, with the freedom of choice comes the complication of choosing what is right for you.
Chef Solo - Chef solo is most ideal if you’re just getting started with chef or a chef server is simply too heavy for your situation. Chef solo allows you to embed all your cookbooks within your project as well, which is nice for projects which want to keep track of their cookbooks within the same repository. Chef solo runs standalone – it requires no chef server or any other server to talk to; it simply runs by itself on the VM.
Chef Server - Chef server is useful for companies or individuals which manage many projects, since it allows you to share cookbooks across multiple projects. The cookbooks themselves are stored on the server, and the client downloads the cookbooks upon running.
Puppet - The Puppet provisioner runs stand-alone Puppet manifests that are stored on the server and downloaded to the client VM when it is created. The provisioner does not require a Puppet server and runs on the VM itself.
Puppet Server - The Puppet Server provisioner connects to a Puppet server and configures your client VM using node configuration on that server.
Other tools, shell scripts, etc. - Do you use something other than that which is built into Vagrant?
Provisioners are simply subclasses of Vagrant::Provisioners::Base, meaning you can easily build your own, should the need arise.
You can also check out the documentation, docs.vagrantup.com/v2
我会选择 Shell 配置程序，然后让 shell 脚本从 github 或 bitbucket 克隆您的 puppet/chef 存储库。该脚本可以设置 ssh 密钥以允许自动 git 克隆。好处是大多数云提供商也支持这一点，因此您可以使用相同的脚本。这篇博客很好地解释了 git、puppet 和 vagrant，一个人和云博客
I would choose the Shell provisioner, then let the shell script clone your puppet/chef repository from github or bitbucket. The script can setup a ssh key to allow automated git clone. The benefits are most cloud providers support this as well so you can use the same script.This blog is explains git, puppet and vagrant well, one man and the cloud blog