这次我们来看一个和 SaltStack 有关的“社区招人帖”。标题是“salt公会招人50级以上就行等级接近的我会带”翻译成运维语言就是如果你已经能管理 50 个以上的节点欢迎加入如果等级还没到接近也行社区里愿意带。这句话放在配置管理工具圈子里其实是在说一件事SaltStack 的核心价值就是批量管理大量节点节点规模上去了才真正体现它的威力。SaltStack 不是一个新的概念它主打的是 Master/Minion 架构、远程命令批量执行、状态管理和自动化编排。和 Ansible 相比它走的是“常驻 agent 消息通道”路线minion 启动后连接 mastermaster 可以秒级向所有 minion 下发命令不需要每次都建立 SSH 连接。这种设计决定了它在节点数量多、需要频繁操作、对实时性有要求的场景里会更顺手。这篇文章我会带你把 SaltStack 从零跑起来包括环境准备、Master 和 Minion 安装、密钥认证、批量命令测试、状态管理、API 接口调用、资源占用观察以及最容易踩的坑。如果你是想入坑 SaltStack 的运维或者正打算用 Salt 管理一批服务器这篇可以直接收藏。1. SaltStack 核心能力速览能力项说明项目类型开源自动化运维与配置管理工具核心架构Master / Minion基于 ZeroMQ 消息通道主要功能批量命令执行、状态管理、配置下发、定时任务、事件驱动、API 集成节点规模适合几十到上千级别的节点管理50 个节点属于起步门槛支持平台Linux、Windows、macOS主流发行版均可安装启动方式systemd 服务启动命令行交互是否支持 API支持通过 salt-api 暴露 REST 接口是否支持批量任务支持目标匹配 批量执行是核心能力适合场景服务器初始化、软件批量部署、配置统一管理、云资源编排从上面的表能看出SaltStack 的价值集中在“批量”和“自动化”。单一台服务器用 Salt 有点大材小用但当你手上超过 50 台机器要统一改配置、统一装监控、统一执行升级命令时Salt 的效率就会明显体现出来。2. 适用场景与使用边界SaltStack 适合解决几类问题一是重复性操作过多比如 50 台机器都要创建一个用户、改一个 SSH 配置、部署一个 Nginx二是配置漂移不同机器上的软件版本和配置文件不一致用状态管理把目标状态固化下来三是需要快速响应的场景比如批量重启服务、临时大规模下发命令、分批发布等。它不适合的场景也很清楚如果你只有三五台机器而且很少改动那 Ansible 的直接 SSH 模式可能更轻量不需要额外维护 agent如果你的网络环境复杂、机器无法主动连回 masterSalt 的默认架构会很难受需要额外搭代理或换用 Salt SSH。另外SaltStack 的 state 模块和 pillar 体系有学习成本不建议在没有任何设计的情况下直接把业务服务器全部接入容易因为误操作批量改坏配置。这里必须强调安全边界SaltStack 可以对节点执行任意命令权限等同于 root。它的 API 一旦暴露到公网等于把服务器控制权交出去。生产环境使用时必须开启认证、限制访问来源、使用防火墙规则并且对最小权限做严格规划。涉及密钥、密码、隐私数据的内容要放到 pillar 中加密管理不能直接写在版本库里。任何自动化变更都应该先在测试环境验证再分批应用到生产节点。3. SaltStack 本地部署环境准备以一台 Linux 服务器作为 master另外准备至少一台机器作为 minion。如果只有一台机器也可以在一台机器上同时运行 master 和 minion用来学习完整流程但更推荐至少两台这样能看出密钥认证和远程执行的真实逻辑。检查清单如下操作系统Ubuntu 22.04、CentOS Stream、Rocky Linux 等主流 Linux 发行版都可以。语言环境Salt 基于 Python但官方仓库安装方式不需要手动处理 Python 依赖直接使用系统包管理器安装即可。网络通信master 默认需要开放 TCP 4505 和 TCP 4506 两个端口。4505 用于 minion 和 master 之间的消息通道4506 用于命令返回结果。时间同步master 和 minion 之间时间偏移太大会导致认证失败建议提前配置 chrony 或 systemd-timesyncd。磁盘空间安装包很小日志和缓存会逐渐增长预留 5GB 以上比较稳妥。防火墙与代理如果使用代理需要确认 ZeroMQ 流量是否受影响生产环境建议直连内网。端口占用是新手最容易忽略的问题。安装完成后先用下面命令确认端口监听状态ss -lntup | grep -E 4505|4506如果端口没监听说明 salt-master 服务没有正常启动优先看/var/log/salt/master日志。4. SaltStack 安装部署与一键启动在 Debian/Ubuntu 系上安装 master 和 minion只需要安装对应包名sudo apt update sudo apt install -y salt-master salt-minion在 RHEL/CentOS/Rocky 系上使用 yumsudo yum install -y salt-master salt-minion安装完成后先配置 minion 的 id 和 master 地址。minion 的主配置在/etc/salt/minion但实际配置时更推荐在/etc/salt/minion.d/目录下新建配置文件避免直接改主文件。创建/etc/salt/minion.d/local.confmaster: 192.168.1.10 id: node01这里的master填 master 机器的 IPid是这台 minion 的唯一标识建议用主机名加上业务角色比如web-node01、db-node02后面做目标匹配会方便很多。master 端如果不需要特殊配置默认配置就能跑。需要调整的关键参数主要是worker_threads、auto_accept和file_roots。生产环境不建议开启auto_accept要人工确认每一台 minion 的密钥是否可信。启动并设置开机自启sudo systemctl enable --now salt-master sudo systemctl enable --now salt-minion启动 master 后在 master 上查看未接受的 minion 密钥sudo salt-key -L你会看到类似这样的输出Accepted Keys: Denied Keys: Unaccepted Keys: node01如果 minion 的密钥出现在Unaccepted Keys里说明密钥请求已经到达。接受所有当前未接受的密钥sudo salt-key -A接受后再次查看应该变成Accepted Keys: node01这一步成功后master 和 minion 的连接就算打通了。接下来可以先跑一遍最基础的连通性测试salt * test.ping如果返回node01: True说明整套架构已经可以正常通信后面就可以往实际运维场景扩展了。5. SaltStack 功能测试与效果验证5.1 批量命令执行salt 命令的基本格式是salt 目标 模块.方法 [参数]目标可以使用通配符、正选列表、grains 匹配、nodegroup 匹配等多种方式。最常用的几个测试如下# 所有节点运行 uptime salt * cmd.run uptime # 所有节点查询当前系统发行版 salt * grains.item osfinger # 指定主机名匹配 salt node0* test.ping # 使用 grains 匹配特定系统 salt -G os:Ubuntu test.ping批量执行命令时Salt 默认会等所有目标节点返回结果。节点越多等待时间可能越长。如果只需要部分节点返回可以指定超时时间salt --timeout10 * cmd.run uptime判断是否成功的标准很简单返回结果里每个 minion id 都对应一个 JSON 结构True或retcode: 0就是正常。如果某个节点超时输出里会出现Minion did not return这种时候检查该节点的 minion 服务是否存活、网络是否通、日志里有没有异常。5.2 状态文件与环境创建Salt 的 state 系统可以用 YAML 描述目标状态。先创建状态根目录sudo mkdir -p /srv/salt创建/srv/salt/top.slsbase: *: - common这个文件意思是所有节点都应用common状态。再创建/srv/salt/common.slsinstall_nginx: pkg.installed: - name: nginx nginx_running: service.running: - name: nginx - enable: True - require: - pkg: install_nginx然后对全部节点应用状态salt * state.applySalt 会检查每个节点的状态如果 nginx 没有安装就安装没有运行就启动。再跑一次结果会显示Succeeded和Unchanged的数量这就是幂等效果。Salt 的状态管理不会每次执行都重复改一遍而是对比当前状态和目标状态只处理差异部分。5.3 分组管理节点多了以后需要按角色分组。在 master 配置里添加 nodegroupsnodegroups: web: - web* - node0* db: - db*然后通过-N参数匹配分组salt -N web test.ping分组的设计建议和业务保持一致web、db、cache、monitor这样后续批量操作会非常方便。50 个节点的规模下分组管理不是可选项而是必须项。没有分组的话一个误操作可能把所有机器都带上风险很高。6. SaltStack 接口 API 调用示例SaltStack 官方提供了 salt-api 组件可以暴露 REST API方便和内部运维平台、CI/CD 系统对接。安装sudo apt install -y salt-api或者sudo yum install -y salt-api然后配置认证和 API 服务。创建/etc/salt/master.d/api.confexternal_auth: pam: saltuser: - .* rest_cherrypy: port: 8000 debug: False这里的saltuser是 Linux 系统用户需要提前创建sudo useradd -m saltuser sudo passwd saltuser创建用户后启动 salt-apisudo systemctl enable --now salt-api确认端口监听ss -lntup | grep 8000API 调用流程是先登录拿 token再用 token 执行 Salt 命令。登录请求curl -sS -X POST -H Content-Type: application/json \ -d {username: saltuser, password: 你的密码, eauth: pam} \ http://127.0.0.1:8000/login返回结果里会包含token字段。执行 test.pingcurl -sS -X POST \ -H Content-Type: application/json \ -H X-Auth-Token: 替换成你的token \ -d { client: local, tgt: *, fun: test.ping } \ http://127.0.0.1:8000/Python 调用示例import requests base_url http://127.0.0.1:8000 def salt_login(username, password): resp requests.post( f{base_url}/login, json{ username: username, password: password, eauth: pam }, timeout30 ) resp.raise_for_status() return resp.json()[return][0][token] def salt_run(token, target*, funtest.ping, argsNone): payload { client: local, tgt: target, fun: fun, } if args: payload[arg] args resp requests.post( base_url, jsonpayload, headers{X-Auth-Token: token}, timeout300 ) resp.raise_for_status() return resp.json() if __name__ __main__: token salt_login(saltuser, 你的密码) result salt_run(token, target*, funtest.ping) print(result)用 API 的时候要注意几个点API 暴露的端口绝对不能直接放到公网。要么绑定内网要么用防火墙限制来源 IP必要时加一层反向代理和 TLS。API 用户如果有.*权限等同于 root 命令执行权限调用方需要严格管控。大批量调用 API 时要给每个请求设置合理的超时时间避免任务阻塞。返回结果是 JSON 结构适合接入内部自动化平台但是要做异常捕获和重试逻辑。7. SaltStack 资源占用与性能观察SaltStack 的资源开销需要分开看。master 端主要吃内存和文件描述符minion 端因为是常驻进程也会有固定内存占用。具体占用多少取决于节点数量、模块加载情况、任务频率和日志量不能一概而论。观察内存占用常用的命令ps aux | grep salt-master ps aux | grep salt-minion更直观的方式是用 systemd 查看服务状态systemctl status salt-master systemctl status salt-minionmaster 在处理批量任务时CPU 占用会有一个短暂的峰值。如果你管理的节点数量达到几百上千需要调整 master 的worker_threads参数。这个参数控制同时处理 minion 请求的线程数量配置在/etc/salt/master中worker_threads: 20改完配置后重启sudo systemctl restart salt-masterminion 端如果只是执行低频任务资源占用很小。如果 salt-minion 所在机器的负载长期很高要看是不是定时任务schedule跑得太频繁或者 state.apply 拉取的文件太大。性能优化建议批量执行命令时尽量用目标匹配缩小范围不要每次都跑*。不要在大批量节点上同时执行state.apply全部状态文件先用state.apply 某个state精确执行。日志定期清理不然/var/log/salt/会越来越大。大批量任务分批次执行比如 50 台一批观察结果后再跑下一批降低 master 瞬时压力。8. SaltStack 常见问题与排查方法问题现象可能原因排查方式解决方案salt-key 看不到 minionminion 没启动、网络不通、id 配置错误检查 minion 服务状态和日志确认 minion 配置和 master 地址重启服务minion 连接后马上断开时间不同步、密钥不匹配执行 ntpdate 或查看 minion 日志同步时间删除/etc/salt/pki后重新认证命令返回 Minion did not return目标节点不在线、网络抖动salt-key -L 查看状态检查节点存活和网络必要时使用 --timeout 延长等待端口 4505/4506 被占用已有 salt-master 实例或其它程序占用ss -lntup 查看端口停掉冲突进程或修改/etc/salt/master端口批量任务执行失败部分节点模块缺失或权限不足单点执行同一命令看返回单独排查该 minion安装对应模块API 登录 401用户密码错误、PAM 认证配置问题检查 salt-api 日志确认系统用户存在重启 salt-apistate.apply 报错YAML 缩进错误、模块参数错误单节点执行 state.show_sls修正 YAML 和模块参数macOS/Windows agent 连接异常防火墙或版本兼容问题查看 minion 日志关闭本地防火墙或调整策略最常见的问题集中在密钥认证和时间同步。很多新手部署完成后salt-key 一直看不到 minion第一反应是网络问题但实际上往往是 minion 配置里的 master 地址写错了或者 minion 进程没有启动。建议每次排查都按这个顺序走先看 salt-minion 是否存活再看/etc/salt/minion配置最后看日志。时间不同步的问题在云服务器上比较常见。master 和 minion 时间差超过几十秒消息签名就过不了表现就是 minion 连接不稳定。部署前先统一配置 chrony能省很多事。9. SaltStack 最佳实践与使用建议第一次接触 SaltStack 的人不要急着把所有机器接入。建议按下面这套节奏推进第一步搭一台 master一台 minion把 test.ping 和基础命令跑通。第二步用 state 写一个不影响业务的场景比如创建用户、部署 Nginx 配置。第三步把配置放到 Git 仓库设计好目录结构。第四步批量扩大到 50 台左右再开始接入业务系统。目录结构上建议按环境区分/srv/salt/ ├── top.sls ├── common.sls ├── nginx.sls └── app/ ├── app.sls └── files/ └── app.conf.jinjapillar 的数据要单独管理不要把密码、密钥直接写进 state 文件。# pillar/top.sls base: *: - app_config# pillar/app_config.sls app: user: deploy home: /home/deploy引用 pillar 的时候在 state 文件里写{{ pillar[app][user] }}这样可以把配置和实现分开。操作安全方面至少做到以下几点不用 root 直接跑 salt 命令维护一个专门的运维账号。生产环境关闭auto_accept密钥自动化接受只适合测试环境。高风险的批量命令先取一台节点验证再全部执行。API 的调用账号只给最小权限不要用.*一把梭。任何涉及真实业务数据的变更都要有回滚方案。10. 总结与下一步SaltStack 最值得尝试的点是它的批量执行和状态管理能力。50 台机器用人工去 SSH 操作会非常痛苦但用 Salt 一条命令就能完成。而且 state 系统的幂等设计让配置变更可以被版本化管理而不是每次改完都不知道哪些机器改成功、哪些改失败。如果你第一次上手最先应该验证的是salt * test.ping和批量cmd.run把这两条跑通说明核心链路已经建立。最容易踩的坑是密钥认证和时间同步遇到问题优先看这两个方向。后续可以继续扩展的方向包括用 pillar 管理敏感配置、用 schedule 做定时巡检、和内部 API 平台对接或者结合 CI/CD 做发布流程。总之先把测试环境的最小链路搭起来剩下的交给需求驱动。