我正在组合一个结构来运行 Rails 应用程序。应用程序本身在 Heroku 上运行。但是，它向集群发出请求，集群通过 C 中的程序执行调用。
为了能够更快地从崩溃中恢复，我想使用 Chef 创建一个例程。我设法写了一本安装你需要的一切的“食谱”，当我使用 Vagrant 虚拟机时它工作得很好。
但是，当我申请真实服务器时，它失败了。另外我用的是Chef Solo，运行脚本前需要在机器上手动安装一些东西，不太实用。
我不知道在这种情况下我是否应该使用 Chef Server。恐怕这是满足“小”需求的“大”工具。
这个集群只有三台机器组成，这个应该不会增加太多。然而，该应用程序也向另一个稍大的集群（6 台机器）发出请求，尽管安装速度非常快，但也可以使用 Chef 服务器。
应该和 Chef 还是 Chef Solo Server 一起去？有没有关于它的教学指南？开发人员文档非常混乱。
这个问题似乎很主观，但我会尽量客观地回答这个问题。
Chef 服务器通过 RESTful API 提供发布系统和搜索索引。
这意味着您可以：
通过具有 API 的单个位置和用于创建版本约束、检索以及您可能期望从发布系统获得的所有内容的原语分发节点的说明书。
存储有关您正在管理的节点的数据（属性）。不管是1个还是1000个，都可以直接通过API获取节点信息。您还可以使用它来告诉节点运行不同的配方。
在 Opscode 所谓的“数据包”中存储关于您的基础设施的任意信息。这是您喜欢的任何信息，例如用户信息、应用程序信息或您能想到的有关您的基础架构的任何其他信息。
向服务器查询有关节点的信息，“生产中的网络服务器是什么？”
这与 Chef Solo 有何不同？很高兴你问！
使用 Chef Solo，您必须自己将食谱、节点属性、数据包等获取到节点。这意味着将它们发布到多个节点可以获取它们的地方，或者将存储库 rsync/scp 到每个受管理的节点。节点数据没有集中存储，也没有任何节点数据的搜索索引。
一开始，它们都非常小，而且易于分发。在 1 个、3 个甚至 5 个节点之间，这通常不是问题。但是大多数人发现自己遇到了一些问题。
清单还在继续。发生的情况是，许多人不想“运行厨师服务器”，因此他们在 git repos、http 服务器等之上构建自己的服务器。
你说的用例（大约5个节点）是Opscode Hosted Chef的“5节点免费”计划的目标，那么你不必管理一个特殊的系统来作为你的Chef Server，至少看看它是不是适合您的基础架构的东西。然后，您可以继续发展成更大的付费计划，或者在未来将您的数据（通过 API 轻松地）移动到您自己的 Chef Server。