Chef Server vs Chef Solo

Question

我正在构建一个结构来运行 Rails 应用程序。应用程序本身在 Heroku 上运行。但是，它向集群发出请求，集群通过 C 中的程序执行调用。

为了能够更快地从崩溃中恢复，我想使用 Chef 创建一个例程。我设法编写了一个“食谱”来安装您需要的一切，当我使用 Vagrant 虚拟机时，它可以完美运行。

但是，当我申请真正的服务器时，它失败了。另外我用的是Chef Solo，运行脚本之前需要手动在机器上安装一些东西，不太实用。

我不知道在这种情况下我是否应该使用 Chef Server。恐怕这是满足“小”需求的“伟大”工具。

这个集群只有三台机器组成，这个应该不会增加太多。但是，该应用程序还会向另一个稍大的集群（6 台机器）发出请求，尽管安装速度非常快，但也可以使用 Chef 服务器。

应该使用 Chef 还是 Chef Solo Server？有没有关于它的教学指南？开发人员文档非常混乱。

Answer 1

这个问题似乎很主观，但我会尽量客观地回答这个问题。

Chef 服务器通过 RESTful API 提供发布系统和搜索索引。

这意味着您可以：

1. 通过具有 API 的单个位置分发节点的说明书，以及用于创建版本约束、检索的原语，以及您可能期望从发布系统中获得的所有内容。

2. 存储有关您正在管理的节点的数据（属性）。无论是一千还是一千，都可以直接通过API获取节点的信息。您还可以使用它来告诉节点运行不同的配方。

3. 将有关您的基础架构的任意信息存储在 Opscode 所谓的“数据包”中。这是您喜欢的任何信息，例如用户信息、应用程序信息或您能想到的有关基础架构的任何其他信息。

4. 查询服务器以获取有关节点的信息，“生产中的网络服务器是什么？”

这与 Chef Solo 有何不同？很高兴你问了！

使用 Chef Solo，您必须自己将食谱、节点属性、数据包等发送到节点。这意味着将它们发布到多个节点可以获取它们的地方，或者将存储库 rsync/scp 发送到管理的每个节点。节点数据没有集中存储，也没有任何搜索索引。

一开始，它都很小，而且很容易分发。在 1、3 甚至 5 个节点之间，这通常不是问题。但是后来大多数人发现自己遇到了一些问题。

• “有一种方法可以更轻松地将食谱上传到节点肯定会很好”
• “伙计，每次我们更新食谱时，生产都会下降，因为我们不希望在那里进行更改”
• “我们如何将所有节点数据集中在一处并进行查询？”

名单还在继续。发生的情况是，许多人不想“运行厨师服务器”，因此他们在 git repos、http 服务器等之上构建自己的服务器。

您正在谈论的用例（大约 5 个节点）是 Opscode Hosted Chef 的“5 节点免费”计划的目标，那么您不必管理一个特殊的系统来成为您的 Chef Server，至少可以看看它是否是适合您的基础架构的东西。然后，您可以继续发展为更大的付费计划，或者将来将您的数据（轻松通过 API）移动到您自己的 Chef 服务器。