Slack 改进 Chef 基础设施的全面总结

在最近的一篇博客文章中，Slack Engineering 详细介绍了对其 Chef 基础设施的重大改进。Chef 管理着运行 Slack 服务、数据库和应用程序的数万个 EC2 实例。Slack 最近从单一 Chef 架构迁移到更具弹性的分片基础设施，以解决之前架构中的一些限制。

原有架构的局限性

Slack 之前使用单一的 Chef 栈，涵盖三个环境：沙盒、开发和生产。这种架构存在风险，因为变更会同时部署到所有环境，任何栈的问题都可能影响整个基础设施。系统使用名为 DishPig 的进程每小时处理一次 Cookbook 更新。

改进目标

Slack 希望通过新的架构解决以下问题：

• 节点分配到分片
• 邻居发现
• Chef 搜索
• Cookbook 上传

关键改进措施

1. 多 Chef 栈架构
   Slack 创建了多个 Chef 栈以分散负载并确保系统弹性。通过 AWS Route53 加权 CNAME 记录将新实例分配到特定分片。开发和生产环境的 Chef 基础设施也被分离为独立的栈。
2. 服务发现与节点查找
   团队使用 Consul 解决了新分片架构中的节点发现问题，并开发了自定义 Chef 库函数，以简化基于多种条件的节点查找，替代了之前的 Chef 搜索功能。
3. Sharded Chef Search (Shearch)
   Slack 开发了名为 Shearch 的新服务，用于在多个 Chef 栈之间进行搜索。该服务整合了来自不同分片的查询结果。
4. Gnife 工具
   团队开发了 Gnife 工具，替代传统的 Chef Knife 命令，支持跨多个分片进行操作。
5. Chef Librarian 替代 DishPig
   DishPig 被 Chef Librarian 取代。Chef Librarian 独立管理 Cookbook 版本和环境更新，允许更可控的部署。GitHub Actions 在变更合并时构建包含完整仓库副本的 tarball，Cookbook 版本使用基于时间戳的格式（YYYYMMDD.TIMESTAMP.0）更新。
6. 环境更新与通知
   Chef Librarian 提供 API 端点，用于更新环境到特定版本并匹配环境。Slack 应用通过 Git 提交信息通知用户其变更被推送到环境。Kubernetes CronJob 处理跨环境的版本推送，并包含安全检查以防止检测到问题时推送。
7. 角色管理
   Slack 通过精简角色信息并仅在环境更新时将角色上传到相关 Chef 栈，降低了 Chef 角色的风险。

未来改进方向

Slack 正在考虑进一步改进其 Chef 基础设施，包括按 AWS 可用区细分生产环境，以实现更细粒度的变更部署控制。此外，团队也在探索采用 Chef PolicyFiles 和 PolicyGroups，尽管这将对其现有设置带来重大变化。

Chef 的行业现状

Chef 的流行度相比 2010 年代中期有所下降，可能由于 Ansible 和其他云原生工具的兴起。行业向容器化的转变也改变了配置管理的做法，许多组织转而采用 Docker 和 Kubernetes。2020 年 Chef 被 Progress Software 收购可能也影响了其长期采用率。尽管如此，Chef 仍然在现有实现或特定用例中有稳固的用户基础。