LinkedIn:扩展 Salt 以解决大规模机器命令执行需求

Himanshu Chandwani 2023-04-23 09:06:10

在 LinkedIn,站点工程师喜欢自动化各种基础设施层面的运营任务,以最小化手动干预,并且可以扩展得很好并易于操作。某些自动化是通过按需作业执行来完成的。

LinkedIn工程师已经使用Salt超过十年了,这是一款基于Python的开源软件,用于在主机上执行任务,因为它具有高性能和可插拔性。由于它配备了丰富的执行模块,可以直接使用或通过自定义模块使用,因此适用于诸如操作系统升级、自动修复、应用程序分析、流量转移、固件升级、交换机管理等任务。

Salt 中的基本主从流程如图1所示。Minion(主机上的代理)通过订阅由 master 服务发布在事件总线上的事件来获取作业、上报结果。它使用 ZMQ(ZeroMQ)实现高速异步通信。目标 minion 在主机上执行作业并返回到 master。Master 和 minion 使用 AES 密钥加密通信以确保安全性。

LinkedIn:扩展 Salt 以解决大规模机器命令执行需求 - 图1:通过事件总线的Salt主从通信流程

图1:通过事件总线的Salt主从通信流程

在这篇文章中,我们将分享如何包装并将其与 LinkedIn 基础设施集成来扩展 Salt,以实现比以前更高效的可伸缩性,并获得 10 倍以上的远程执行能力,从而自动化任何类型的即时操作工作。

背景

在过去的十年中,LinkedIn已经实现了巨大的增长。为了支持这种增长,LinkedIn工程师将基础设施从一个数据中心扩展到多个数据中心。随着成千上万的微服务不断增加,对更多硬件的需求也在预期之内。近年来,它已经发展到超过300,000个应用程序主机。这种巨大的增长要求工具堆栈在最近4-5年内以10倍速度扩展。这种10倍速度的增长促进了每天构建、发布和部署、应用程序配置推送、网络策略、系统配置等许多方面的高数量级需求。

在过去的十年中,LinkedIn 的许多基础设施工具都在不断发展,以解决各种规模挑战。这包括为数千个应用程序提供的部署系统、容器化、持续集成和交付、服务发现以及应用程序的密钥管理。无论是针对数据/应用程序/用户的授权管理的 RBAC 系统,还是面向服务和用户身份验证与安全性的 PKI 基础架构,或者主机状态/配置管理或应用程序配置,工程师们设计了出色的体系结构和自动化流水线,在大规模运作方面表现出色。

除了 Salt,LinkedIn 还使用其他工具来配置和管理主机的状态,例如cfengine和puppet。拥有多个类似场景的工具会带来操作上的挑战。此外,LinkedIn 的现有解决方案都没有通过 Rest API 提供远程执行功能,可以像 Salt 一样即时和异步响应。

Salt 在 LinkedIn 的情况

在2019年之前,Salt被不同的团队用于不同的用例,例如配置管理、状态管理、日志管理、远程执行作业、制品分发、应用部署、应用性能分析工具、自动修复、用户账户管理、网络设备维护和流量转移等。

LinkedIn:扩展 Salt 以解决大规模机器命令执行需求 - 图2:老的单集群 Salt

图2:老的单集群 Salt

在图2中,单主机用于编排集群中的所有从节点。许多从节点经常将执行结果返回到单个主机,导致由于负载过高而出现停机时间。

直到2018年中期,在每个生产的数据中心每个业务网,我们仍然使用单 Salt master 的部署结构,每个 master 大概管理 55-60k 的 minion。其他数据中心大概还有 6k-10k 的机器,总共加起来大概有 180k 的业务机器,最终有 15 套 salt master(master 一主一备),部署在 24 台机器上。由于执行请求数量过多,Salt 主控节点经常会严重超载,导致作业失败、不可用性增加、停机时间增加,并影响依赖它的各种自动化。除了单一主控节点设置带来的性能影响外,还存在各种运维和性能方面的挑战,例如:

  • Salt 开发几乎没有代码覆盖;我们在构建和维护多个产品时面临着各种挑战,例如我们定期升级的 6 个 RPM、有问题的客户端库、令人困惑的客户端 cli、监控 Salt 服务和日志,以及更多的痛点
  • 手动管理 Salt Master 故障转移
  • 通过一组复杂的 cfengine 策略管理 minions 和 master 配置
  • 为每个数据中心的 Salt 管理 Salt API SSL 证书
  • 配置管理每个数据中心的 Salt master 的 cname
  • 缺少对客户端 Salt 模块的安全检查,并且缺少模块所有权
  • Salt 组件通过自行生成的 RPM 进行管理,这使得升级具有挑战性且耗时
  • 在生产环境中,每个 master 的单个 master 达到近 65K 个 minions,有时会导致性能不佳

仅通过 REST API 远程执行

2018 年,在网站工程组织的协调努力下,我们的工程师决定减少工具堆栈中的噪音,只为每个特定任务保留一个工具。我们的团队还决定将 Salt 客户端的其他用例转移到 LinkedIn 的其他扩展和管理良好的解决方案,这些解决方案专门为此类用例而设计,并通过 REST api 将 Salt 限制为仅用于远程执行用例。我们的计划主要受到 Tim Peters 的 19 句格言之一(即 The Zen of python)的启发。

There should be one and preferably only one obvious way to do it.

我们重建 Salt 基础架构的目的不仅仅是扩展它,还在于简化其所有操作方面并改善客户体验。2019 年年中,我们决定重新构建 LinkedIn Salt 生态系统,将其与 LinkedIn 开发和部署基础架构集成。我们想利用它的众多优势,例如 LinkedIn 的 CI/CD、部署工作流系统、服务发现、应用程序配置管理、密钥管理、容器化和托管服务认证。好处是巨大的。

新产品

我们通过创建五个新的 python multiproduct 来重新构建 Salt 的开发,其中 li-salt-master 和 li-minion 使用上游 python Salt 作为主要依赖项。Multiproduct 模板是一个开发框架,它有助于应用程序开发的各个方面,即使用 pygradle 构建包、依赖管理、应用程序配置管理(它也可以捕获应用程序的密钥)、通过单元测试的代码覆盖率、用于类型的 mypy 检查,以及 flake8 用于样式和语法检查。我们创建的每个 multiproduct 的用途简要说明如下:

  • li-salt-master: 可部署的 Master & API 服务,用于编排 minions 并为客户端公开新的 Salt rest API 端点
  • li-minion: 可安装在所有 300K + 主机上的 python agent。它被包装并打包为带有自定义代码的 RPM,可自动发现相关的 master 主机并在每次启动时生成 minion 配置
  • lipy-lisaltmaster: 客户端的 Python 库。对于非 python 客户端,即 java 或 go lang,记录了简单的 curl 示例
  • lisaltmaster-fileroot: 包含所有 Salt 客户端 ACL 和自定义模块。该产品对客户端模块强制执行安全检查,以确保客户端遵循安全编码实践
  • salt-execute: 此 CLI 命令行工具允许团队通过 api 端点执行他们的模块,即我们的新设计公开的 /execute

新的设计

上游 Salt 的灵活性使我们能够插入自定义插件/模块以实现新的架构流程

Li-salt-master

它是一个充当整体服务的 python 应用程序;它将上游 Salt 库固定为直接依赖项。在部署时,它会启动 3 个服务,Salt-master、Salt-api 和 Nginx。

LinkedIn:扩展 Salt 以解决大规模机器命令执行需求 - 图 3:带有少量 li-minion 的单独 li-salt-master

图 3:带有少量 li-minion 的单独 li-salt-master

  • Salt-master 对批准的客户端进行身份验证和授权,向 minions 发布工作指令,并收集 minions 的工作响应
  • Salt-api 使用 python cherrypy 框架并为客户端公开 rest API;它写在 Salt netapi 之上。它还公开了一个用于服务健康和发现的端点
  • Nginx 主要用作实现 mTLS 的反向代理

我们通过插入自定义模块来覆盖一些 Salt 函数。这项工作利用了上游 multimaster 教程提供的一些知识。

配置:Salt 和 Nginx 配置是使用 jinja 模板动态生成的。模板中的占位符使用来自应用程序配置的值和主私钥、路径、mysql 数据库密码等秘密值进行更新。为了确保 master 冗余,所有 master 主机将具有相同的私钥/公钥对,以便任何 minion 都可以连接到已部署集群中的任何 master 主机。

授权模块:我们插入了自己的 Salt PKI 授权模块。这允许客户端/服务使用其客户端证书进行身份认证和鉴权。

Netapi 模块:我们修改了现有的 Salt 的 rest_cherrypy 代码并添加了新的 API 端点,即:

  • /execute 包装现有的 Salt rest_cherrypy API,即 /minions/jobs,用于在目标 minions 上执行作业并汇总它们的响应
  • /connected 获取连接到集群中每个 master 的 minions 数量,这用于运维目的或者收集监控指标
  • /login 被修改为依赖 Nginx 级别的 mTLS
  • /stats,这个现有的 Salt api,围绕 Salt master & API、Salt Auth QPS / Failures、每秒请求数、每个请求字节数等,扩展了更多的监控指标
  • 添加 /admin 以公开集群的整体健康检查,它还允许通过 DNS 发现服务。 Nginx 被用作反向代理,mTLS 也是通过它强制执行的
  • 客户端无法访问其余所有其他 api 端点

LinkedIn:扩展 Salt 以解决大规模机器命令执行需求 - 图4:Li-salt-master 认证和执行 API 的流程

图4:Li-salt-master 认证和执行 API 的流程

  • 令牌:我们插入了自定义模块来管理身份验证令牌,定义令牌创建、检索、列出和从存储中删除。它使用 MySQL DB 作为存储
  • 引擎:我们插入了自定义引擎,用于监控所有执行并同步来自 lisaltmaster-fileroot 数据包的 ACLS 和模块。监控各种 Salt master 和 api 指标,例如连接的 minions 数量或与 Salt 服务的各种组件相关的指标,包括所有 Salt 子进程的内存使用情况、cpu 使用情况、磁盘 I/O、API 2xx/4xx/5xx, QPS、指标等
  • Reactor & Runner:添加了一个自定义的 runner 模块,当 minion 与 master 认证失败的时候,该模块就会触发,认证失败大部分情况都是因为机器重新做了镜像用了一个新的 key 而服务端仍然使用了一个老的 key。在每次重启时,minion 都会与 master 交换其密钥以建立 TLS 连接。 Runner 在接受 master 主机上的新公钥之前验证 minion。

Li-minion

它是一个使用 LinkedIn python gradle 构建的 python 产品,它构建了 RPM 包,安装在所有 LinkedIn 主机上。它包装了默认的 salt-minion agent。它在启动之前生成 minion 配置(配置可能因集群而异),用于在主机上运行 li-minion 代理的 systemd service 文件,用于管理 minion 日志的 logrotate 配置,在本地生成 minion 指标以供稍后离线分析。模块同步作业计划每 10 分钟从各自的 lisaltmaster-fileroot 获取新的/修改的模块。Li-minion 还定义了自己的资源限制,如文件操作数和活动内存,以避免干扰生产服务。它使用主机上可用的事实(如fabric、tag等)发现 master 主机,并且 li-salt-master DNS 记录通过 LinkedIn 服务发现暴露出来。

LinkedIn:扩展 Salt 以解决大规模机器命令执行需求 - 图5:Li-minion 流程图

图5:Li-minion 流程图

LinkedIn:扩展 Salt 以解决大规模机器命令执行需求 - 图6:Li-salt-masters <&ndash;> Li-minions 架构流图,使用 mysql 作为认证 token 的存储(minion 通过 DNS 记录发现 master)

图6:Li-salt-masters <–> Li-minions 架构流图,使用 mysql 作为认证 token 的存储(minion 通过 DNS 记录发现 master)

Lisaltmaster-fileroot

它是一个 python 产品,它生成数据包(数据包是一个可部署的包,只包含要放置在主机上某个位置的静态文件)。它包含客户端 Salt ACL 和 Salt 模块。在持续集成期间,每次代码更改后都会运行 python Bandit,以查找客户端模块中的常见安全问题。ACL 或模块中的每个更改都会构建一个新的数据包,并在几分钟内通过 LinkedIn 部署工作流自动推送到所有 Salt Master 主机,因此不需要手动干预。

监控和日志分析

所有指标都发送到 Kafka 管道,这些管道在 LinkedIn 的内部工具“inGraphs”中可视化。异常通过 Autoalert 发出警报,并通过 Iris 通知值班工程师。除了所有 Salt 应用程序和系统指标外,所有 Master/API 日志都通过 Apache Kafka 流式传输到 Azure Data Explorer。日志使用 Azure Kusto 查询语言查询进行分析,并使用 Azure 数据资源管理器可视化以进行实时分析。

LinkedIn:扩展 Salt 以解决大规模机器命令执行需求 - 图7:Li-salt-master 事件仪表板屏幕截图

图7:Li-salt-master 事件仪表板屏幕截图

总结

新的 Salt 架构支持每天在 LinkedIn 基础设施的主机上执行超过 15000 个远程作业,从而可以轻松扩展和操作,解决以前的挑战。它现在执行的作业数量增加了 10 倍,可靠性和可扩展性也比以前更高。

致谢

非常感谢基础设施工具 SRE 团队的所有同事,除了 Himanshu Chandwani 的贡献外,该项目还得到了 Aastha Nandwani、Bhavik Patel、Ritish Verma 和 Sergii Shchypa 的大力贡献。我们还要感谢 Nidhi Mehta 成为该项目的 TPM 合作伙伴。此外,我们非常感谢我们在 LinkedIn 上的合作伙伴团队,即 Production SRE、Traffic SRE、Espresso SRE、LPS SRE、OSUA 团队、Monitoring infra、On-demand Profiling 团队、InfoSec 团队,以及 LinkedIn 内支持我们的其他站点工程团队努力。最后,如果没有我们的工程负责人 Senthilkumar Eswaran 和 Xi Chen 的支持,这个项目是不可能完成的。

英文地址:https://engineering.linkedin.com/blog/2023/scaling-salt-for-remote-execution-to-support-linkedin-infra-grow


译者注:看起来 LinkedIn 虽然做了很多改造,但是 Salt 的核心没有改,这个基于 ZMQ 的方案看起来性能杠杠的。各位运维同仁,你们用的什么命令执行工具?遇到什么坑和心得?欢迎在评论区交流:)

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat
FlashDuty
Flashduty