在近期的一篇博文中，Slack 的工程部详细介绍了他们在 Chef 基础架构上的重大改进，将管理着上万个 EC2 实例中运行的服务、数据库和应用程序的架构从单一的 Chef 堆栈转移为了弹性更强的分片基础架构。
这次的架构转移，Slack 希望能解决一些之前难以解决的限制问题：
为节点分配分片
发现周围邻居
找寻 Chef
上传常用代码合集（Cookbook）
在先前的设置中，Slack 是在沙盒、开发和生产这三个环境中使用一个 Chef 栈。这种架构风险很高，因为更改是会在不同环境中同时部署的，堆栈中的任何问题都可能影响整个基础架构。这套系统是用一个叫 DishPig 的流程来处理每小时触发的 cookbook 更新。
为了解决这些限制，工程团队进行了以下几项关键改动：首先是创建多个 Chef 堆栈，以便于分散负载并确保系统的弹性，新的实例采用 AWS Route53 加权 CNAME 记录并分配给特定分片。此外，Slack 工程团队还将开发和生产环境的 Chef 基础架构分离成不同的堆栈。
为解决在新分片基础架构中发现节点的难题，Slack 工程团队采用了 Consul 来做服务发现。这点需要仔细地实施，从而避免与 Nebula 重叠网络之间产生循环依赖关系。团队开发了定制的 Chef 库函数，从而简化基于各种条件的节点查询，有效地取代了先前的 Chef 搜索功能。
Slack 还创建了一项名为 Shearch（“分片 Chef 搜索”的简称） 的新服务，用于在多个 Chef 堆栈中进行搜索，还可以整合在不同分片上的搜索结果。Slack 团队还开发了一项叫做 Gnife 的新工具，取代传统 Chef Knife 命令来实现跨多个分片的操作。
团队采用 Chef Librarian 取代了 DishPig 系统，这项服务可以独立管理 cookbook 的版本和环境更新，从而实现更为可控的部署。在合并变更时，GitHub Actions 会生成一个包含全部代码库副本的压缩包，并用时间戳格式（YYYYMMDD.TIMESTAMP.0）更新 cookbook 的版本。
Chef Librarian 提供了更新环境到特定版本和环境相互匹配功能的 API 端点，利用 Chef Librarian，Slack 可以在沙盒和开发环境中对更改进行测试，然后再推送到生产环境，从而降低了出问题的更改影响所有环境的风险。这项服务会将工作版本和部署信息存储到 DynamoDB 中，可以更为方便地跟踪和查看。
当用户的变更被推送到环境中时，Slack 应用会通知用户并使用 Git 中的 commit 备注判断并标注对应的团队成员。Kubernetes CronJob 负责跨环境的版本推送和安全检查，以便在发现问题时阻止推送。
Slack 将角色简化到基本信息和运行列表，让 Chef 角色（无法通过版本控制）的风险降到最低。只有在相关环境更新时，角色才会上载到相关的 Chef 堆栈中。
Slack 在考虑更进一步地改进其 Chef 基础设施，其中一项是按照 AWS 可用性区域划分生产的 Chef 环境，这样可以对变更的部署进行更为细粒化的控制。Slack 还在探索采用 Chef PolicyFiles 和 PolicyGroups 的可行性，不过这将会对他们当前的设置带来巨大的改变。
和十年前的风光不同，Chef 不再是那么地受欢迎，这可能是由于 Ansible 和其他云原生解决方案等替代品的兴起。IT 行业向容器化的转变改变了许多企业的配置管理方式，多数企业转投了 Kubernetes 和 Docker 的怀抱。Chef 在 2020 年被 Progress Software 收购可能也影响了它在长期的采用率。
即使如此，Chef 仍然拥有坚实的用户基础，这在已实施了 Chef 或者是有适合 Chef 方法的特定用例的组织中尤为突出。
查看英文原文：
Slack Evolves Chef Architecture for Safety and Stability (https://www.infoq.com/news/2024/10/slack-chef-architecture/)
声明：本文由 InfoQ 翻译，未经许可禁止转载。