运行厨师服务器而不是厨师独奏有什么好处？

Question

我正在为我的团队寻找自动化部署解决方案，并且过去几天一直在与 Chef 一起玩。我已经能够使用 Chef-solo 从基础 Red Hat VM 运行一个简单的 Web 应用程序。

我们的最终目标是使用 Chef（或其他系统）在我们运行构建时自动将应用程序拓扑部署到云中。我们的流程基本上是这样运行的：

1. 我们的 Web 应用程序代码、依赖项和厨师食谱存储在 SCM 中
2. 执行构建并为要获取和测试的图像创建单个包
3. 然后构建引擎部署新​​的云镜像，运行一个 Chef 客户端来安装包。
4. 图像从 SCM 或 Chef 服务器获取食谱并安装所有内容以启动和运行

让 Chef 服务器运行有什么好处和/或用例？

与使用 Chef-solo 并拥有从 SCM 提取食谱的脚本相比，使用 Chef 服务器持有并从 SCM 获取食谱有什么主要好处吗？

Answer 1

我将这个答案定位为好像问题是“Chef-solo 的优势是什么”，因为这是我所知道的涵盖方法之间差异的最佳方式。

我的总结建议与其他人一致：如果您需要管理动态的、虚拟化的环境，您将经常添加和删除节点，请使用厨师服务器。如果您需要，厨师服务器也是一个很好的CMDB。如果您有一个不太动态的环境，其中节点不会经常更改，但角色和食谱会更改，请使用厨师独奏。您的环境的大小和复杂性或多或少无关。这两种方法都可以很好地扩展。

如果您部署 Chef-solo，请使用带有 rsync、'git pull' 或其他幂等文件传输机制的 cronjob 来维护每个节点上的 Chef 存储库的完整副本。cronjob 应该很容易配置为 (a) 根本不运行和 (b) 运行，但不同步本地存储库。在您的 Chef 存储库中添加一个 nodes/ 目录，并为每个节点添加一个 json 文件。在识别正确的节点文件方面，您的 cronjob 可以像您希望的那样复杂（尽管我只推荐 $(hostname -s).json。除了能够使用刀下载社区食谱并创建骨架之外，没有其他原因。

除了明显的“不必管理服务器”之外，这种方法还有几个优点。您的源代码管理将是所有配置更改的最终仲裁者，存储库将包含所有节点和运行列表，并且每个服务器完全独立有助于一些方便的测试场景。

Chef-server 引入了一个漏洞，您可以在其中使用“刀上传”来更新食谱，您必须自己修补这个漏洞（例如使用 post-commit 钩子）或风险站点更改被“刀上传”的人默默覆盖s 来自他笔记本电脑上过时的本地存储库的过时配方。Chef-solo 不太可能发生这种情况，因为所有更改都将直接从主存储库同步到服务器。这里的问题是纪律和合作者的数量。如果您是一个单独的开发人员或一个非常小的团队，通过 API 上传食谱风险不大。在较大的团队中，如果您没有实施良好的控制，则可能会出现这种情况。

此外，使用chef-solo，您可以将所有节点的角色、自定义属性和运行列表作为node.json 文件存储在您的主厨师存储库中。使用chef-server，可以使用API​​ 动态修改角色和运行列表。使用chef-solo，您可以在修订控制中跟踪此信息。在这里可以清楚地看到静态和动态环境之间的冲突。如果您的节点列表（无论它有多长）不经常更改，则将此数据置于修订控制中非常有用。另一方面，如果您经常生成新节点并销毁旧节点（永远不会再看到它们的主机名或 fqdn），将其全部保持在版本控制中只是不必要的麻烦，并且拥有一个 API 来进行更改非常方便。Chef-server 还具有面向管理动态云环境的完整功能，例如“knife bootstrap”上的名称选项，它允许您将 fqdn 替换为识别节点的默认方式。但是在静态环境中，这些功能的价值有限，尤其是与在版本控制中具有其他所有功能的角色和运行列表相比。

最后，几乎无需额外工作即可即时设置配方测试环境。您可以禁用在服务器上运行的 cronjobs 并直接对其本地存储库进行更改。您可以通过运行 Chef-solo 来测试更改，您将确切地看到服务器在生产中如何配置自身。测试完所有内容后，您可以签入更改并重新启用本地 cronjob。但是，在编写配方时，您将无法使用“搜索”API，这意味着如果您想编写动态配方（例如负载均衡器），则必须绕过此限制，从 json 文件中收集数据您的节点/目录，这可能不太方便，并且缺少完整 CMDB 中可用的一些数据。再一次，更动态的环境将有利于数据库驱动的方法，对于本地磁盘上的 json 文件，较少的动态环境会很好。在厨师运行必须对中央数据库进行 API 调用的服务器环境中，您将依赖于管理该数据库中的所有测试环境。

最后一个也可以在紧急情况下使用。如果您正在对生产服务器上的关键问题进行故障排除并通过配置更改来解决它，您可以立即在服务器的存储库上进行更改，然后将其推送到主服务器。

这些是 Chef-solo 的主要优势。还有一些其他的，比如不必管理服务器或支付托管厨师的费用，但这些都是相对较小的问题。

总结一下：如果您是动态且高度虚拟化的，chef-server 提供了许多很棒的功能（在别处涵盖），而大多数 Chef-solo 的优势将不那么明显。然而，主厨独奏有一些明确的、通常未被提及的优势，尤其是在更传统的环境中。请注意，部署在云上并不一定意味着您拥有动态环境。例如，如果您不能在不发布新版本软件的情况下向系统添加更多节点，则您可能不是动态的。最后，从高层次的角度来看，CMDB 可用于任何与系统管理和配置相关的事物，例如会计和团队之间的信息共享。仅就该功能而言，使用 Chef-server 可能是值得的。

Answer 2

披露：我为 Opscode 工作。

Chef Server 相对于 Solo 的主要优势是能够在您的基础架构中使用搜索。经典示例是带有 Web 服务器的负载均衡器。负载均衡器可以在网络服务器添加和删除到基础架构时自动更新其配置，只需搜索它们即可。Solo 就是这样，单台机器，而 Chef Server 带来了查询诸如“所有具有超过 4 GB RAM 的机器”或“数据库主机”之类的功能。

Chef Server 还使您能够在不复制 tarball 的情况下管理您的基础设施，使用管理控制台可视化您的基础设施，并通过 Environments 管理哪些机器正在运行哪些版本的食谱。还有其他好处，但这些都是我最想知道的。如果您想在不安装的情况下试用 Chef Server，只需注册一个 Opscode Hosted Chef 帐户，前 5 个节点是免费的。