我正在为我的团队寻找自动化部署解决方案，过去几天一直在使用 Chef。我能够使用 chef-solo 从基础 Red Hat VM 启动并运行一个简单的 Web 应用程序。
我们的最终目标是使用 Chef（或其他系统）在运行构建时自动将应用程序拓扑部署到云中。我们的流程基本上如下：
- 我们的 Web 应用代码、依赖项和 Chef Cookbook 存储在 SCM 中
- 执行构建并创建用于获取和测试图像的单个包
- 然后，构建引擎部署新的云映像，运行 chef 客户端来安装软件包。
- 镜像从 SCM 或 Chef 服务器获取食谱，并安装所有内容以启动和运行
运行 Chef Server 有哪些好处和/或用例？
与使用 chef-solo 并使用脚本从 SCM 中提取食谱相比，使用 Chef Server 保存并从 SCM 获取食谱有哪些主要优势吗？
答案1
我将以这样的方式回答这个问题：“chef-solo 有什么优势”，因为这是我所知道的涵盖两种方法之间的差异的最佳方式。
我的总结建议与其他人的建议一致：如果您需要管理动态、虚拟化的环境，并且经常添加和删除节点，请使用 chef-server。chef 服务器也是一个很好的选择管理数据库，如果需要的话。如果您的环境不太动态，节点不会经常更改，但角色和配方会更改，则使用 chef-solo。环境的大小和复杂性或多或少无关紧要。这两种方法的扩展性都很好。
如果您部署 chef-solo，请使用带有 rsync、“git pull”或其他幂等文件传输机制的 cronjob 来维护每个节点上的 chef 存储库的完整副本。cronjob 应该可以轻松配置为 (a) 完全不运行和 (b) 运行，但不同步本地存储库。在您的 chef 存储库中添加一个 nodes/ 目录，其中包含每个节点的 json 文件。您的 cronjob 可以根据您的需要尽可能复杂地识别正确的节点文件（尽管我建议只使用 $(hostname -s).json）。您可能还想创建一个 opscode 帐户并配置一个带有托管 chef 的客户端，即使只是为了能够使用 knife 下载社区食谱并创建骨架。
除了显而易见的“无需管理服务器”之外，这种方法还有几个优点。您的源代码控制将成为所有配置更改的最终仲裁者，存储库将包含所有节点和运行列表，并且每个服务器完全独立，从而有助于实现一些方便的测试场景。
Chef-server 引入了一个漏洞，您可以使用“knife upload”来更新食谱，并且您必须自己修补这个漏洞（例如使用提交后挂钩），否则站点更改可能会被某人悄悄覆盖，这个人会从他笔记本电脑上的过时本地存储库“knife upload”过时的食谱。使用 chef-solo 时不太可能发生这种情况，因为所有更改都将直接从主存储库同步到服务器。这里的问题在于纪律和协作者的数量。如果您是个人开发人员或非常小的团队，通过 API 上传食谱的风险并不大。在较大的团队中，如果您没有实施良好的控制，则可能会有风险。
此外，使用 chef-solo，您可以将所有节点的角色、自定义属性和运行列表作为 node.json 文件存储在主 chef 存储库中。使用 chef-server，可以使用 API 即时修改角色和运行列表。使用 chef-solo，您可以在修订控制中跟踪此信息。在这里可以清楚地看到静态和动态环境之间的冲突。如果您的节点列表（无论它有多长）不经常更改，那么在修订控制中保存这些数据非常有用。另一方面，如果您经常生成新节点并销毁旧节点（再也看不到它们的主机名或 fqdn），将它们全部保存在修订控制中只是不必要的麻烦，而使用 API 进行更改非常方便。Chef-server 还具有一系列面向管理动态云环境的功能，例如“knife bootstrap”上的名称选项，它允许您将 fqdn 替换为识别节点的默认方式。但在静态环境中，这些功能的价值有限，尤其是与将角色和运行列表与其他所有内容一起放在修订控制中相比。
最后，几乎无需额外工作即可即时设置配方测试环境。您可以禁用服务器上运行的 cronjobs，并直接对其本地存储库进行更改。您可以通过运行 chef-solo 来测试更改，您将确切看到服务器在生产中如何配置自身。测试完所有内容后，您可以签入更改并重新启用本地 cronjobs。但是，在编写配方时，您将无法使用“搜索”API，这意味着如果您想编写动态配方（例如负载平衡器），您将不得不绕过此限制，从节点/目录中的 json 文件中收集数据，这可能不太方便，并且会缺少完整 CMDB 中的一些可用数据。再次强调，更动态的环境将倾向于数据库驱动的方法，而动态性较差的环境则可以使用本地磁盘上的 json 文件。在服务器环境中，chef 运行必须对中央数据库进行 API 调用，您将依赖于管理该数据库中的所有测试环境。
最后一种也可以用于紧急情况。如果您正在排除生产服务器上的严重问题，并通过配置更改解决该问题，则可以立即在服务器的存储库上进行更改，然后将其推送到上游主服务器。
这些是 chef-solo 的主要优势。还有一些其他优势，例如无需管理服务器或支付托管 chef 的费用，但这些都不是那么重要。
总结：如果您是动态的并且高度虚拟化，chef-server 提供了许多很棒的功能（在其他地方介绍过），而 chef-solo 的大多数优势将不那么明显。但是 chef-solo 有一些明确的、通常未被提及的优势，尤其是在更传统的环境中。请注意，部署在云上并不一定意味着您拥有动态环境。例如，如果您无法在不发布新版本软件的情况下向系统添加更多节点，那么您可能不是动态的。最后，从高层次的角度来看，CMDB 可用于许多与系统管理和配置间接相关的事情，例如会计和团队之间的信息共享。仅凭这一功能，使用 chef-server 可能就值得了。
答案2
披露：我在 Opscode 工作。
Chef Server 相对于 Solo 的主要优势在于能够在基础架构中使用搜索功能。典型示例是带有 Web 服务器的负载均衡器。负载均衡器可以在基础架构中添加和删除 Web 服务器时自动更新其配置，只需搜索它们即可。Solo 就是单台机器，而 Chef Server 可以查询“所有具有超过 4 GB RAM 的机器”或“数据库主服务器”等内容。
Chef Server 还使您能够管理基础架构而无需复制 tarball，使用管理控制台可视化基础架构，并使用环境管理哪些机器正在运行哪些版本的食谱。还有其他好处，但这些是我首先想到的。如果您想在不安装的情况下试用 Chef Server，只需注册一个 Opscode Hosted Chef 帐户，前 5 个节点是免费的。
答案3
chef-server 管理您的节点的食谱和配置数据。
您可以使用 Knife 工具将食谱添加到 chef-server，然后为每个节点提供一个食谱运行列表，这样当节点使用 chef-client 进行设置时，它们就可以获取所需的食谱。由于 chef-client 在后台运行，因此您的节点将定期检查 chef-server 中是否有更新的食谱。
chef-server 还保存您的配置数据和变量，以便您可以更改节点的设置以自动获取。这对于不应该或不能在您的配方中硬编码的更多动态设置非常有用。