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