看到 Salt 这个词不同背景的人会联想到完全不同的东西。在视频标题里它可能是一段航海生存冒险在运维和开发同学的终端里Salt 更多时候指 SaltStack一个基于 Python 的自动化配置管理与远程执行工具。这篇内容只讨论后者聊清楚 SaltStack 怎么搭起来、怎么用 State 管理服务器配置、怎么排查一台 Minion 为什么没执行到期望的结果。适合刚接触自动化运维的开发者也适合已经会用 Ansible 但想对比和理解 Salt 工作方式的人。读完你会得到一套最小可复现的实验环境以及一份可以直接搬进项目里的排错清单。1. 先搞清楚 SaltStack 是什么以及它和“Salt”这个关键词的关系1.1 同一个名字两种语境“Salt”在中文里最常见的意思是盐在游戏圈里可能指向某个开放世界生存游戏在技术圈里则大概率指 SaltStack。很多初学者会因为这个名字产生困惑搜索时也容易混进大量不相干内容。实际项目里的 SaltStack 是一套自动化运维工具核心能力有四个远程执行在一台管理机上批量给上千台服务器下发命令。配置管理用声明式文件描述服务器应该处于什么状态例如“安装 Nginx”“配置文件内容是……”事件驱动Salt 内部有事件总线可以监听服务器上报的事件并触发自动操作。编排与 API通过 Salt API、reactor 等机制把“发现配置漂移”和“自动修复”串成流程。本文约定后面提到的 Salt默认都指 SaltStack不再解释游戏语境。如果你是因为其他语境点进来的也可以把这篇文章当成一次“自动化配置管理”的技术冒险从两台虚拟机开始搭建出一个能管理多个节点的最小系统。1.2 SaltStack 的核心组件Master、Minion、Syndic 与 Salt SSHSaltStack 最常见的部署形态是 Master/Minion 架构。Master 是中心节点负责下发命令、保存返回结果Minion 是安装在每台被管理服务器上的轻量代理主动连接到 Master并执行 Master 下发的任务。这种“Minion 主动连接 Master”的设计和普通主从架构不同。它带来的好处是即使被管理节点在内网或 NAT 后面只要它能访问 Master 的端口就能完成注册和管理不需要在防火墙上给 Master 开返回通道。核心组件可以用一张表概括组件角色说明Salt Master中心管控节点调度任务、保存 job 结果、维护 state 和 pillar 数据Salt Minion被管理节点代理接收任务并执行把结果返回给 MasterSalt Syndic级联代理支持多层级联把下层 Master 的 Minion 汇总到上层 MasterSalt SSH无代理模式不安装 Minion通过 SSH 批量执行命令和 stateSalt API对外接口把 Salt 的能力封装成 HTTP 接口便于集成到运维平台实际使用中最常见的还是 Master/Minion。下面所有实验都围绕这个模式展开。1.3 适用场景与选型边界在选型时很多人会拿 Salt 和 Ansible 对比。两者都能做配置管理和远程执行但设计取向不同。Ansible 默认无代理依赖 SSH适合临时批量操作和不喜欢在机器上装额外进程的环境。Salt 默认需要装 Minion Agent但换来的是更快的通信速度、更精细的事件机制、更灵活的状态收敛能力。对比维度SaltStackAnsible默认模式Master/Minion 代理SSH 无代理通信方式ZeroMQ 或 TCPSSH大规模并发较强适合千级节点受 SSH 并发限制需要调整 forks配置语言YAML JinjaYAML Jinja学习曲线较陡概念多相对平缓事件驱动内置 event bus较弱依赖回调插件需要注意Salt 不适合做过于复杂的 workflow 编排。如果你要写“先发布 A 服务再等健康检查再发布 B 服务”这种强依赖流程建议把编排逻辑放到 GitLab CI、Jenkins Pipeline 或专门的流程引擎里Salt 负责执行单点状态和命令即可。2. 环境准备从两台虚拟机开始搭建最小集群2.1 实验环境规划学习 Salt 不需要重型集群两台 Linux 虚拟机就够。一台做 Master一台做 Minion。下面以 Rocky Linux 9 为例。如果你使用 Ubuntu/Debian安装命令和软件源会略有区别但整体流程相同。主机名角色假设 IP建议配置salt-masterMaster192.168.56.102C4Gsalt-minion-01Minion192.168.56.111C2G安装前先确认几点两台机器都能互相访问 IP。主机名尽量不要带大写和下划线Minion 默认以主机名作为 id。防火墙端口要提前规划Master 的 4505 端口用于 Minion 拨号4506 端口用于任务执行和结果返回。关闭 SELinux 会造成学习环境不验证最好把 SELinux 调整到 permissive并确认没有系统安全策略阻断。注意生产环境不要轻易关闭 SELinux。遇到连接问题时先看审计日志确认是状态还是端口策略导致。2.2 安装 SaltStack MasterSaltStack 官方提供了软件源安装时建议使用发行版对应的 repo 包。Rocky Linux 9 上可以这样安装# 安装 epel 和 salt 官方仓库 sudo dnf install -y epel-release sudo dnf install -y https://repo.saltproject.io/salt/py3/redhat/9/x86_64/latest/salt-repo-latest.el9.noarch.rpm sudo dnf clean expire-cache # 安装 master sudo dnf install -y salt-master安装完成后先在主配置里做最小化调整。Salt Master 默认配置文件在/etc/salt/master常见的几个参数如下# /etc/salt/master interface: 0.0.0.0 publish_port: 4505 ret_port: 4506 # 提高 worker 数量实验环境默认值即可 worker_threads: 5 # 日志级别 log_level: info保存后启动服务sudo systemctl enable --now salt-master sudo systemctl status salt-master检查 4505 和 4506 端口是否监听sudo ss -lntp | grep salt看到4505和4506处于 LISTEN 状态说明 Master 已经准备好。这里要理解一个关键点4505 端口负责接收 Minion 的长连接4506 端口负责接收 Minion 返回的执行结果。两个端口职责不同生产环境配置安全组时不要只放行其中一个。2.3 安装并注册 Minion在第二台机器上安装 salt-minionsudo dnf install -y epel-release sudo dnf install -y https://repo.saltproject.io/salt/py3/redhat/9/x86_64/latest/salt-repo-latest.el9.noarch.rpm sudo dnf clean expire-cache sudo dnf install -y salt-minion修改 Minion 配置指定 Master 地址并给 Minion 设置固定 id。这个 id 一定要稳定因为之后所有 target 匹配、证书授权都会以它为准。# /etc/salt/minion master: 192.168.56.10 id: minion-node-01在较新版本中也可以把配置放在/etc/salt/minion.d/99-salt-minion.conf这样主配置升级时不容易被覆盖。# /etc/salt/minion.d/99-salt-minion.conf master: 192.168.56.10 id: minion-node-01启动 Minionsudo systemctl enable --now salt-minion sudo systemctl status salt-minion启动后Minion 会生成密钥对并把公钥发送给 Master等待管理员授权。2.4 确认 Master 与 Minion 通信状态回到 Master 上查看待授权的 keysudo salt-key -L预期输出里有Unaccepted Keys下面能看到minion-node-01。接受 keysudo salt-key -a minion-node-01再次查看sudo salt-key -Lminion-node-01出现在Accepted Keys中就说明注册完成。用 test.ping 验证通信sudo salt minion-node-01 test.ping返回true说明 Master 与 Minion 之间的网络、密钥、端口全部正常。这一步最常见的坑是Minion 启动后没有出现在 Unaccepted Keys 里。原因通常是网络不通或者 Minion 配置里 master 地址写错。可先在 Minion 上手动执行salt-minion -l debug观察日志确认它是否在持续尝试连接4505端口。3. 第一个最小闭环用 Salt 远程执行命令3.1 test.ping 为什么是第一个要跑的命令test.ping 并不是真正去 ping 某个 IP而是 Master 向目标 Minion 发送一个 UTF-8 字符Minion 原样返回。它能通过代表整条链路已经打通Minion 能连接 Master 的 4505 端口。Master 的密钥认证通过。Minion 能接收任务并返回结果。所以它是排查一切问题时的“链路自检”。执行方式sudo salt minion-node-01 test.ping输出minion-node-01: True如果 Minion 数量多可以一次对所有节点执行sudo salt * test.ping这个命令会返回所有在线 Minion 的结果。3.2 远程执行命令的语法与 target 匹配Salt 远程执行命令的通用格式是salt target module.function [参数]target 用来选择要执行任务的 Minion 集合。最常用的匹配方式匹配方式示例说明通配符salt minion* test.ping按 Minion id 通配列表salt -L minion-01,minion-02 test.ping指定多个 id正则salt -E ^minion-node-\d$ test.ping按正则匹配 idGrainssalt -G os_family:RedHat test.ping按系统属性匹配Pillarsalt -I role:web test.ping按 Pillar 数据匹配CIDRsalt -S 192.168.56.0/24 test.ping按 IP 网段匹配例如批量查看所有 Minion 系统信息sudo salt * grains.item os os_family oscodename在真实环境中target 匹配非常关键。如果目标写得太宽可能会把生产环境所有机器都执行一遍写得太窄又可能漏掉该执行的节点。建议先在最小范围用--outjson测试确认目标节点后再执行。3.3 把结果看懂返回结构、jid 与耗时字段默认输出适合人看但脚本化处理时最好使用 JSON 输出sudo salt * test.ping --outjson输出{ minion-node-01: true }执行远程命令时Master 会给每次任务生成一个 job id简称 jid。哪怕执行结果返回超时也可以从 job cache 里找到这次任务日志。查看已执行的任务sudo salt-run jobs.list_jobs这会列出所有历史任务包括 jid、执行时间、target、执行的函数和参数。当 Minion 掉线导致结果没有返回时这种查询方式非常有用。远程执行 cmd.run 时要注意谨慎使用。比如sudo salt * cmd.run uptime输出minion-node-01: 10:00:32 up 1 day, 2:33, 2 users, load average: 0.00, 0.01, 0.05不过cmd.run 是强命令生产环境不建议开放给所有用户。如果有可能优先使用 Salt 提供的模块函数例如pkg.install、service.start、file.replace而不是写一段任意 shell。原因是模块函数会校验参数、返回结构化结果出错信息也更明确。注意在批量执行 cmd.run 前一定要确认目标范围否则一条 rm 命令可能影响大量节点。4. 用 State 管理配置从“执行命令”走向“声明期望状态”4.1 State 文件、Top File 和 highstate 的关系只靠远程执行命令自动化程度还不够。真正有价值的是“声明期望状态”用文件描述每台机器应该装什么包、配置文件写成什么、服务应该启动。Salt 会负责把当前状态收敛到期望状态。这里涉及三个概念State 文件SLS用 YAML 写的最小状态描述。Top File把不同的 Minion 节点和不同的 State 文件关联起来。Highstate让 Master 根据 Top File 对所有目标 Minion 应用所有状态的过程。默认目录结构/srv/salt/ ├── top.sls └── nginx/ └── init.slstop.sls 示例# /srv/salt/top.sls base: *: - nginx这个文件的意思是在 base 环境中匹配到所有节点时应用nginx这个 State。4.2 用 file.managed 管理 Nginx 配置一个 State 文件可以描述多个资源。下面用 Nginx 配置管理作为示例。先准备一个 Nginx 配置源文件。实际项目中通常会把文件放在 Salt 根目录的nginx/files/下。mkdir -p /srv/salt/nginx/files创建一个最小 Nginx 配置# /srv/salt/nginx/files/nginx.conf user nginx; worker_processes auto; error_log /var/log/nginx/error.log; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; } } }然后编写 State 文件# /srv/salt/nginx/init.sls nginx_config: file.managed: - name: /etc/nginx/nginx.conf - source: salt://nginx/files/nginx.conf - user: root - group: root - mode: 0644 - watch_in: - service: nginx_service解释一下关键参数name目标机器上的最终文件路径。source文件来源salt://协议表示从 Master 的/srv/salt目录取文件。mode文件权限注意用字符串0644避免 YAML 把 0644 解析成数字。watch_in当文件内容变化时触发等待的服务。这里关联到nginx_service这个 service 状态。4.3 用 pkg.installed 和 service.running 写一个完整 state完整的 Nginx state 应该包含三件事安装包、下发配置、启动服务。把init.sls扩展成完整版本# /srv/salt/nginx/init.sls nginx_install: pkg.installed: - name: nginx nginx_config: file.managed: - name: /etc/nginx/nginx.conf - source: salt://nginx/files/nginx.conf - user: root - group: root - mode: 0644 - watch_in: - service: nginx_service nginx_service: service.running: - name: nginx - enable: True - require: - pkg: nginx_install这里用到了两个关键顺序requirenginx_service依赖nginx_install保证先安装再启动服务。watchnginx_config通过watch_in监听服务状态文件变化后自动重启 Nginx。在 Salt 里watch和require区别很大。require只控制顺序而watch会在被监听对象发生变化时触发行为的额外反应例如重启服务。服务重启逻辑不放在 shell 脚本里而是由 State 系统管理这样更容易追踪变更。4.4 执行 highstate 与按需应用指定 state在 Master 上执行sudo salt minion-node-01 state.apply nginx这条命令表示只对目标节点应用nginx这个 State不依赖 top.sls。如果希望按 top.sls 全量应用sudo salt minion-node-01 state.highstate返回结果会包含三个部分pkg_|-nginx_install_|-nginx_|-installedfile_|-nginx_config_|-/etc/nginx/nginx.conf_|-managedservice_|-nginx_service_|-nginx_|-running每部分都有result: True、changes: {}、comment字段。第一次执行时changes里会明确写出安装了什么、修改了什么nginx_install: ---------- new: nginx old:再次执行时changes应该为空说明系统已经处于期望状态没有配置漂移。这就是状态收敛和幂等性的表现。5. 深入理解 Pillar、Grains 与 Jinja 模板5.1 GrainsMinion 的静态属性Grains 是 Minion 启动时收集的静态信息包括操作系统、CPU 核数、内存、IP 地址等。它不会频繁变化适合做条件判断和节点分组。查看所有 Grainssudo salt minion-node-01 grains.items只看某几个字段sudo salt minion-node-01 grains.item os os_family ipv4在 State 文件里可以用 Grains 做分支判断。例如{% if grains[os_family] RedHat %} nginx_package: nginx {% elif grains[os_family] Debian %} nginx_package: nginx {% endif %}这样同一个 State 就能兼容不同发行版。5.2 Pillar敏感的定向配置Pillar 和 Grains 最大的区别是Pillar 由 Master 维护可以按 Minion 定向下发并且适合存储密码、密钥、差异化配置等数据。Pillar 内容也通过 Salt 加密通道传输比明文写在 minon 端的文件安全得多。默认 Pillar 目录是/srv/pillar需要创建一份 top.sls# /srv/pillar/top.sls base: minion-node-01: - nginx创建对应的 Pillar 数据文件# /srv/pillar/nginx.sls nginx: server_name: www.example.com listen_port: 8080 max_workers: 4查看 Minion 收到的 Pillarsudo salt minion-node-01 pillar.items输出里会包含nginx下面的所有键值。Pillar 里的数据可以直接被 Jinja 模板读取从而让不同节点生成不同的配置文件。注意不要用 Pillar 暴露不必要的信息到大范围节点上。写入密钥时建议结合 Salt 的外部 Pillar 或 sdb 模块避免密钥出现在版本控制系统的纯文本文件里。5.3 Jinja 模板让 state 不再写死前面 Nginx 配置是静态文件。在真实场景中不同服务器往往需要不同的 server_name、端口和 worker 数量可以把 Nginx 配置改成 Jinja 模板。先修改 State 文件把source指向模板文件并告诉 Salt 这个文件需要模板渲染# /srv/salt/nginx/init.sls nginx_config: file.managed: - name: /etc/nginx/nginx.conf - source: salt://nginx/files/nginx.conf.j2 - template: jinja - user: root - group: root - mode: 0644 - watch_in: - service: nginx_service模板文件内容# /srv/salt/nginx/files/nginx.conf.j2 user nginx; worker_processes {{ pillar.get(nginx, {}).get(max_workers, auto) }}; error_log /var/log/nginx/error.log; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server { listen {{ pillar.get(nginx, {}).get(listen_port, 80) }}; server_name {{ pillar.get(nginx, {}).get(server_name, localhost) }}; location / { root /usr/share/nginx/html; index index.html; } } }这样修改 Pillar 数据后重新 apply State配置文件就会按新值渲染出来。使用 Jinja 模板时一个常见坑是模板变量取不到值时直接报错。建议所有 Pillar 取值都带上默认值例如pillar.get(nginx, {}).get(listen_port, 80)。这样即使某台 Minion 没有配置对应 Pillar也不会导致渲染失败。5.4 参数速查表数据来源存放位置主要用途敏感信息更新方式GrainsMinion 端收集系统属性、分组、条件判断不存放重启 Minion 或刷新PillarMaster 端维护节点差异化配置、敏感数据适合存放修改后继续 apply 或刷新StateMaster 端维护描述系统期望状态不存放修改 SLS 后 applyGitFS外部 Git 仓库存放 State 和 Pillar 文件结合 git roles提交代码后 refresh生产环境建议把 State 和 Pillar 统一放到 Git 仓库再通过 GitFS 或 CI 流程同步到 Master。这样配置变更可以走 Code Review比直接在 master 上改文件更可控。6. 运行验证与结果分析6.1 查看执行结果和返回码Salt 命令本身返回 0 不代表所有 Minion 都成功。看结果要关注每个 Minion 返回体里的result字段。以 state.apply 为例sudo salt minion-node-01 state.apply nginx --outjson输出片段{ minion-node-01: { pkg_|-nginx_install_|-nginx_|-installed: { comment: Package nginx is already installed, result: true, changes: {} }, file_|-nginx_config_|-/etc/nginx/nginx.conf_|-managed: { comment: File /etc/nginx/nginx.conf is up to date, result: true, changes: {} } } }判断执行是否成功不能只看命令是否返回也不能只看result: True还要确认changes是否符合预期、comment是否合理、有没有某个资源被跳过。可以写一个简单脚本批量检查所有 Minion 的结果sudo salt * state.highstate --outjson | jq to_entries[] | {name: .key, result: .value.result}如果result是 false就用--outhighstate查看更详细的失败信息。6.2 用 event bus 和 job cache 观察执行过程Salt Master 内部有事件总线所有 Minion 的连接、任务执行、返回结果都会以事件形式在总线上流动。查看实时事件sudo salt-run state.event listen执行一条命令Event Bus 里会出现salt/job/20250301.../new、salt/job/.../ret/minion-node-01等类型的事件。当任务执行得非常慢或者有大量 Minion 没有返回时可以用 job cache 查找sudo salt-run jobs.lookup_jid 20250301120000123456把 jid 替换成目标任务的 ID就能看到该任务在各 Minion 上的返回结果。如果某些 Minion 返回为空可以判断是执行超时还是 Minion 掉线。6.3 幂等性验证再次执行 highstateSalt 设计上要求 State 是幂等的同一个状态反复执行结果不应该产生副作用。验证方法很简单sudo salt minion-node-01 state.apply nginx然后再次执行sudo salt minion-node-01 state.apply nginx第二次执行时changes应该是空comment应该是类似 “Package nginx is already installed” 或 “File is up to date” 的信息。如果第二次执行仍然产生大量 changes说明 State 写得有问题。常见原因包括写的不是期望状态而是每次执行都会追加内容的脚本。模板渲染结果不稳定每次生成的文件内容都不同。cmd.run里执行的命令本身每次都会返回变化。幂等性不是 Salt 自动保证的而是靠写 State 的人的约束。这是配置管理工具和普通跑脚本之间最大的区别。7. 常见问题排查7.1 Minion 一直处于离线状态现象salt-key -L里能看到 Minion但执行salt * test.ping时返回Minion did not return. [No response]或者 Minion 显示为离线。可能原因4505 或 4506 端口被防火墙拦截。Minion 上master地址配置错误。Minion 进程没有启动或启动后退出。Master 上的 worker 线程耗尽。排查步骤在 Minion 上检查进程ps aux | grep salt-minion。查看 Minion 日志journalctl -u salt-minion -f。在 Minion 上测试连接timeout 5 bash -c /dev/tcp/192.168.56.10/4505 echo ok。在 Master 上检查端口ss -lntp | grep 4505。查看 Master 日志journalctl -u salt-master -f。处理建议如果是防火墙问题放行 4505/4506如果是配置问题修正/etc/salt/minion或/etc/salt/minion.d/下的配置如果是 worker 线程问题适当调大worker_threads。7.2 Minion key 认证失败现象执行命令时看到类似Minion did not return. [No response]或者日志里出现Authentication attempt of minion-node-01 failed.。可能原因Minion 被重新安装过密钥对发生了变化。Master 上保留了旧的 Unaccepted/Denied Keys。Minion 的 id 被另一台机器抢用。检查方式sudo salt-key -L处理建议先删除旧 key再重启 Minion然后重新接受新 keysudo salt-key -d minion-node-01 sudo systemctl restart salt-minion sudo salt-key -a minion-node-01预防方法是给每台 Minion 设置固定且唯一的 id不要依赖可能重复的 hostname。7.3 state 执行报错定位现象state.apply nginx后返回结果里某个资源的result: false。常见错误错误现象可能原因处理方式Source file salt://nginx/files/nginx.conf not foundstate 中的 source 路径错误检查/srv/salt/nginx/files/下是否有文件Data failed to compile: Rendering SLS failedYAML 缩进或 Jinja 模板语法错误使用python -c import yaml; yaml.safe_load(open(...))或salt-run fileserver.file_list检查Job 20250... failed with return code: 1模块执行失败先手动在 Minion 上执行对应的命令确认系统情况After rendering, state was shown as {file: ...}SLS 结构不完整检查 state 是否包含名称、模块函数和参数排查顺序先看报错信息里的comment它通常已经写明原因。在 Master 上确认文件是否存在sudo salt-run fileserver.file_list在 Minion 上手动执行模块函数比如salt minion-node-01 pkg.install nginx或salt minion-node-01 service.status nginx。用--outhighstate输出更完整的结果而不是只看默认样例。7.4 配置变更不生效现象修改了 State 文件或 Pillar 数据重新执行state.apply但目标机器上的配置没有变。可能原因修改的是文件但没有重新 apply。top.sls 没有包含这个 State导致state.highstate没有执行它。文件权限或 watch 条件没有触发服务重启。Minion 和 Master 的 fileserver 缓存没有刷新。检查方式sudo salt minion-node-01 file.get_managed /etc/nginx/nginx.conf sudo salt minion-node-01 pillar.items处理建议先执行salt-run fileserver.clear_cache清理缓存。确认salt minion-node-01 state.apply nginx中file_managed状态是否有 changes。如果changes为空说明文件内容没有变化需要检查模板是否用了正确的变量。检查watch_in是否挂到了 service 状态上。从根本上预防可以把 State 文件、模板文件、Pillar 数据全部纳入 Git 版本库。每次变更都走 Review并在 CI 里做一次state.apply --test语法检查能减少大量“改了没生效”的问题。8. 生产环境最佳实践与扩展方向8.1 从单 Master 到多 Master 高可用学习环境用一个 Master 没有问题生产环境则要考虑单点故障。常见做法有两种运行多个 MasterMinion 配置里可以指定多个master地址自动切换。使用 Salt Syndic 做层级架构上层 Master 管理多个区域 Master适合跨机房、跨网络边界的场景。多 Master 部署的重点不在安装而在配置同步。所有 Master 上的 state、pillar、配置文件必须保持一致。建议用 Git 作为唯一数据源通过 CI/CD 推送到各个 Master避免不同 Master 上配置不一致导致执行结果漂移。8.2 Salt SSH 和 Salt API 的使用场景如果目标机器不能安装 Agent可以使用 Salt SSH。它的用法和 Master/Minion 模式基本一致只是通过 SSH 执行。sudo salt-ssh 192.168.56.12 test.pingSalt SSH 适合做临时接管、短期批量命令和硬件原因不方便装 Agent 的场景。但因为每次执行都要走 SSH 握手并发和速度会比代理模式差。如果团队想自动化执行 Salt而不是每个人都能登录 Master可以提供 Salt API。启用前先配置认证# /etc/salt/master.d/api.conf rest_cherrypy: port: 8000 host: 0.0.0.0 debug: False ssl_crt: /etc/pki/tls/certs/localhost.crt ssl_key: /etc/pki/tls/private/localhost.key生产环境使用 Salt API 时要把端口放在内网并通过统一认证网关代理避免直接暴露。API 调用还需要做权限控制区分哪些用户可以执行只读命令、哪些用户可以执行高权限命令。8.3 发布前检查清单在把新 State 发布到生产环境前建议逐项检查[ ] 所有 State 文件已经过state.apply语法校验。[ ] top.sls 中引用的 SLS 文件都存在。[ ] 模板文件中所有变量都有默认值。[ ] Pillar 中的敏感信息没有硬编码在普通 State 里。[ ] 目标节点范围是否最小化先灰度一批节点。[ ] 执行前是否备份关键配置文件。[ ] 是否提前确认 Nginx、MySQL 等服务的 reload 方式。[ ] 是否监控执行日志和异常事件。[ ] 是否有回滚方案旧文件版本、旧服务版本、旧 Pillar 数据。[ ] 是否记录变更前后差异便于审计。8.4 下一步可以扩展的方向SaltStack 的入门不难难在把很多基础能力组合成完整的自动化体系。学完 state、pillar、grains、jinja 之后可以按下面几个方向继续深入自定义 module 和 state当内置模块不能满足需求时用 Python 编写自己的模块。event reactor利用 Salt event bus 监听文件变更、服务异常、Minion 上线等事件自动执行修复。schedulers让 Minion 或 Master 定时执行任务例如每小时校验一次 Nginx 配置。MySQL 和数据库模块用它管理系统账号、数据库权限。与 CI/CD 集成在 GitLab CI 或 Jenkins 中触发 Salt highstate实现配置变更的自动化发布。配置管理工具的价值不在于能执行多少条命令而在于把服务器最终状态固化成可审查、可回滚、可重复验证的代码。从两台测试机开始把一条 test.ping、一个 Nginx state、一次 highstate 弄明白后面再管理几百台机器时思路会清晰很多。
看到 Salt 这个词不同背景的人会联想到完全不同的东西。在视频标题里它可能是一段航海生存冒险在运维和开发同学的终端里Salt 更多时候指 SaltStack一个基于 Python 的自动化配置管理与远程执行工具。这篇内容只讨论后者聊清楚 SaltStack 怎么搭起来、怎么用 State 管理服务器配置、怎么排查一台 Minion 为什么没执行到期望的结果。适合刚接触自动化运维的开发者也适合已经会用 Ansible 但想对比和理解 Salt 工作方式的人。读完你会得到一套最小可复现的实验环境以及一份可以直接搬进项目里的排错清单。1. 先搞清楚 SaltStack 是什么以及它和“Salt”这个关键词的关系1.1 同一个名字两种语境“Salt”在中文里最常见的意思是盐在游戏圈里可能指向某个开放世界生存游戏在技术圈里则大概率指 SaltStack。很多初学者会因为这个名字产生困惑搜索时也容易混进大量不相干内容。实际项目里的 SaltStack 是一套自动化运维工具核心能力有四个远程执行在一台管理机上批量给上千台服务器下发命令。配置管理用声明式文件描述服务器应该处于什么状态例如“安装 Nginx”“配置文件内容是……”事件驱动Salt 内部有事件总线可以监听服务器上报的事件并触发自动操作。编排与 API通过 Salt API、reactor 等机制把“发现配置漂移”和“自动修复”串成流程。本文约定后面提到的 Salt默认都指 SaltStack不再解释游戏语境。如果你是因为其他语境点进来的也可以把这篇文章当成一次“自动化配置管理”的技术冒险从两台虚拟机开始搭建出一个能管理多个节点的最小系统。1.2 SaltStack 的核心组件Master、Minion、Syndic 与 Salt SSHSaltStack 最常见的部署形态是 Master/Minion 架构。Master 是中心节点负责下发命令、保存返回结果Minion 是安装在每台被管理服务器上的轻量代理主动连接到 Master并执行 Master 下发的任务。这种“Minion 主动连接 Master”的设计和普通主从架构不同。它带来的好处是即使被管理节点在内网或 NAT 后面只要它能访问 Master 的端口就能完成注册和管理不需要在防火墙上给 Master 开返回通道。核心组件可以用一张表概括组件角色说明Salt Master中心管控节点调度任务、保存 job 结果、维护 state 和 pillar 数据Salt Minion被管理节点代理接收任务并执行把结果返回给 MasterSalt Syndic级联代理支持多层级联把下层 Master 的 Minion 汇总到上层 MasterSalt SSH无代理模式不安装 Minion通过 SSH 批量执行命令和 stateSalt API对外接口把 Salt 的能力封装成 HTTP 接口便于集成到运维平台实际使用中最常见的还是 Master/Minion。下面所有实验都围绕这个模式展开。1.3 适用场景与选型边界在选型时很多人会拿 Salt 和 Ansible 对比。两者都能做配置管理和远程执行但设计取向不同。Ansible 默认无代理依赖 SSH适合临时批量操作和不喜欢在机器上装额外进程的环境。Salt 默认需要装 Minion Agent但换来的是更快的通信速度、更精细的事件机制、更灵活的状态收敛能力。对比维度SaltStackAnsible默认模式Master/Minion 代理SSH 无代理通信方式ZeroMQ 或 TCPSSH大规模并发较强适合千级节点受 SSH 并发限制需要调整 forks配置语言YAML JinjaYAML Jinja学习曲线较陡概念多相对平缓事件驱动内置 event bus较弱依赖回调插件需要注意Salt 不适合做过于复杂的 workflow 编排。如果你要写“先发布 A 服务再等健康检查再发布 B 服务”这种强依赖流程建议把编排逻辑放到 GitLab CI、Jenkins Pipeline 或专门的流程引擎里Salt 负责执行单点状态和命令即可。2. 环境准备从两台虚拟机开始搭建最小集群2.1 实验环境规划学习 Salt 不需要重型集群两台 Linux 虚拟机就够。一台做 Master一台做 Minion。下面以 Rocky Linux 9 为例。如果你使用 Ubuntu/Debian安装命令和软件源会略有区别但整体流程相同。主机名角色假设 IP建议配置salt-masterMaster192.168.56.102C4Gsalt-minion-01Minion192.168.56.111C2G安装前先确认几点两台机器都能互相访问 IP。主机名尽量不要带大写和下划线Minion 默认以主机名作为 id。防火墙端口要提前规划Master 的 4505 端口用于 Minion 拨号4506 端口用于任务执行和结果返回。关闭 SELinux 会造成学习环境不验证最好把 SELinux 调整到 permissive并确认没有系统安全策略阻断。注意生产环境不要轻易关闭 SELinux。遇到连接问题时先看审计日志确认是状态还是端口策略导致。2.2 安装 SaltStack MasterSaltStack 官方提供了软件源安装时建议使用发行版对应的 repo 包。Rocky Linux 9 上可以这样安装# 安装 epel 和 salt 官方仓库 sudo dnf install -y epel-release sudo dnf install -y https://repo.saltproject.io/salt/py3/redhat/9/x86_64/latest/salt-repo-latest.el9.noarch.rpm sudo dnf clean expire-cache # 安装 master sudo dnf install -y salt-master安装完成后先在主配置里做最小化调整。Salt Master 默认配置文件在/etc/salt/master常见的几个参数如下# /etc/salt/master interface: 0.0.0.0 publish_port: 4505 ret_port: 4506 # 提高 worker 数量实验环境默认值即可 worker_threads: 5 # 日志级别 log_level: info保存后启动服务sudo systemctl enable --now salt-master sudo systemctl status salt-master检查 4505 和 4506 端口是否监听sudo ss -lntp | grep salt看到4505和4506处于 LISTEN 状态说明 Master 已经准备好。这里要理解一个关键点4505 端口负责接收 Minion 的长连接4506 端口负责接收 Minion 返回的执行结果。两个端口职责不同生产环境配置安全组时不要只放行其中一个。2.3 安装并注册 Minion在第二台机器上安装 salt-minionsudo dnf install -y epel-release sudo dnf install -y https://repo.saltproject.io/salt/py3/redhat/9/x86_64/latest/salt-repo-latest.el9.noarch.rpm sudo dnf clean expire-cache sudo dnf install -y salt-minion修改 Minion 配置指定 Master 地址并给 Minion 设置固定 id。这个 id 一定要稳定因为之后所有 target 匹配、证书授权都会以它为准。# /etc/salt/minion master: 192.168.56.10 id: minion-node-01在较新版本中也可以把配置放在/etc/salt/minion.d/99-salt-minion.conf这样主配置升级时不容易被覆盖。# /etc/salt/minion.d/99-salt-minion.conf master: 192.168.56.10 id: minion-node-01启动 Minionsudo systemctl enable --now salt-minion sudo systemctl status salt-minion启动后Minion 会生成密钥对并把公钥发送给 Master等待管理员授权。2.4 确认 Master 与 Minion 通信状态回到 Master 上查看待授权的 keysudo salt-key -L预期输出里有Unaccepted Keys下面能看到minion-node-01。接受 keysudo salt-key -a minion-node-01再次查看sudo salt-key -Lminion-node-01出现在Accepted Keys中就说明注册完成。用 test.ping 验证通信sudo salt minion-node-01 test.ping返回true说明 Master 与 Minion 之间的网络、密钥、端口全部正常。这一步最常见的坑是Minion 启动后没有出现在 Unaccepted Keys 里。原因通常是网络不通或者 Minion 配置里 master 地址写错。可先在 Minion 上手动执行salt-minion -l debug观察日志确认它是否在持续尝试连接4505端口。3. 第一个最小闭环用 Salt 远程执行命令3.1 test.ping 为什么是第一个要跑的命令test.ping 并不是真正去 ping 某个 IP而是 Master 向目标 Minion 发送一个 UTF-8 字符Minion 原样返回。它能通过代表整条链路已经打通Minion 能连接 Master 的 4505 端口。Master 的密钥认证通过。Minion 能接收任务并返回结果。所以它是排查一切问题时的“链路自检”。执行方式sudo salt minion-node-01 test.ping输出minion-node-01: True如果 Minion 数量多可以一次对所有节点执行sudo salt * test.ping这个命令会返回所有在线 Minion 的结果。3.2 远程执行命令的语法与 target 匹配Salt 远程执行命令的通用格式是salt target module.function [参数]target 用来选择要执行任务的 Minion 集合。最常用的匹配方式匹配方式示例说明通配符salt minion* test.ping按 Minion id 通配列表salt -L minion-01,minion-02 test.ping指定多个 id正则salt -E ^minion-node-\d$ test.ping按正则匹配 idGrainssalt -G os_family:RedHat test.ping按系统属性匹配Pillarsalt -I role:web test.ping按 Pillar 数据匹配CIDRsalt -S 192.168.56.0/24 test.ping按 IP 网段匹配例如批量查看所有 Minion 系统信息sudo salt * grains.item os os_family oscodename在真实环境中target 匹配非常关键。如果目标写得太宽可能会把生产环境所有机器都执行一遍写得太窄又可能漏掉该执行的节点。建议先在最小范围用--outjson测试确认目标节点后再执行。3.3 把结果看懂返回结构、jid 与耗时字段默认输出适合人看但脚本化处理时最好使用 JSON 输出sudo salt * test.ping --outjson输出{ minion-node-01: true }执行远程命令时Master 会给每次任务生成一个 job id简称 jid。哪怕执行结果返回超时也可以从 job cache 里找到这次任务日志。查看已执行的任务sudo salt-run jobs.list_jobs这会列出所有历史任务包括 jid、执行时间、target、执行的函数和参数。当 Minion 掉线导致结果没有返回时这种查询方式非常有用。远程执行 cmd.run 时要注意谨慎使用。比如sudo salt * cmd.run uptime输出minion-node-01: 10:00:32 up 1 day, 2:33, 2 users, load average: 0.00, 0.01, 0.05不过cmd.run 是强命令生产环境不建议开放给所有用户。如果有可能优先使用 Salt 提供的模块函数例如pkg.install、service.start、file.replace而不是写一段任意 shell。原因是模块函数会校验参数、返回结构化结果出错信息也更明确。注意在批量执行 cmd.run 前一定要确认目标范围否则一条 rm 命令可能影响大量节点。4. 用 State 管理配置从“执行命令”走向“声明期望状态”4.1 State 文件、Top File 和 highstate 的关系只靠远程执行命令自动化程度还不够。真正有价值的是“声明期望状态”用文件描述每台机器应该装什么包、配置文件写成什么、服务应该启动。Salt 会负责把当前状态收敛到期望状态。这里涉及三个概念State 文件SLS用 YAML 写的最小状态描述。Top File把不同的 Minion 节点和不同的 State 文件关联起来。Highstate让 Master 根据 Top File 对所有目标 Minion 应用所有状态的过程。默认目录结构/srv/salt/ ├── top.sls └── nginx/ └── init.slstop.sls 示例# /srv/salt/top.sls base: *: - nginx这个文件的意思是在 base 环境中匹配到所有节点时应用nginx这个 State。4.2 用 file.managed 管理 Nginx 配置一个 State 文件可以描述多个资源。下面用 Nginx 配置管理作为示例。先准备一个 Nginx 配置源文件。实际项目中通常会把文件放在 Salt 根目录的nginx/files/下。mkdir -p /srv/salt/nginx/files创建一个最小 Nginx 配置# /srv/salt/nginx/files/nginx.conf user nginx; worker_processes auto; error_log /var/log/nginx/error.log; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; } } }然后编写 State 文件# /srv/salt/nginx/init.sls nginx_config: file.managed: - name: /etc/nginx/nginx.conf - source: salt://nginx/files/nginx.conf - user: root - group: root - mode: 0644 - watch_in: - service: nginx_service解释一下关键参数name目标机器上的最终文件路径。source文件来源salt://协议表示从 Master 的/srv/salt目录取文件。mode文件权限注意用字符串0644避免 YAML 把 0644 解析成数字。watch_in当文件内容变化时触发等待的服务。这里关联到nginx_service这个 service 状态。4.3 用 pkg.installed 和 service.running 写一个完整 state完整的 Nginx state 应该包含三件事安装包、下发配置、启动服务。把init.sls扩展成完整版本# /srv/salt/nginx/init.sls nginx_install: pkg.installed: - name: nginx nginx_config: file.managed: - name: /etc/nginx/nginx.conf - source: salt://nginx/files/nginx.conf - user: root - group: root - mode: 0644 - watch_in: - service: nginx_service nginx_service: service.running: - name: nginx - enable: True - require: - pkg: nginx_install这里用到了两个关键顺序requirenginx_service依赖nginx_install保证先安装再启动服务。watchnginx_config通过watch_in监听服务状态文件变化后自动重启 Nginx。在 Salt 里watch和require区别很大。require只控制顺序而watch会在被监听对象发生变化时触发行为的额外反应例如重启服务。服务重启逻辑不放在 shell 脚本里而是由 State 系统管理这样更容易追踪变更。4.4 执行 highstate 与按需应用指定 state在 Master 上执行sudo salt minion-node-01 state.apply nginx这条命令表示只对目标节点应用nginx这个 State不依赖 top.sls。如果希望按 top.sls 全量应用sudo salt minion-node-01 state.highstate返回结果会包含三个部分pkg_|-nginx_install_|-nginx_|-installedfile_|-nginx_config_|-/etc/nginx/nginx.conf_|-managedservice_|-nginx_service_|-nginx_|-running每部分都有result: True、changes: {}、comment字段。第一次执行时changes里会明确写出安装了什么、修改了什么nginx_install: ---------- new: nginx old:再次执行时changes应该为空说明系统已经处于期望状态没有配置漂移。这就是状态收敛和幂等性的表现。5. 深入理解 Pillar、Grains 与 Jinja 模板5.1 GrainsMinion 的静态属性Grains 是 Minion 启动时收集的静态信息包括操作系统、CPU 核数、内存、IP 地址等。它不会频繁变化适合做条件判断和节点分组。查看所有 Grainssudo salt minion-node-01 grains.items只看某几个字段sudo salt minion-node-01 grains.item os os_family ipv4在 State 文件里可以用 Grains 做分支判断。例如{% if grains[os_family] RedHat %} nginx_package: nginx {% elif grains[os_family] Debian %} nginx_package: nginx {% endif %}这样同一个 State 就能兼容不同发行版。5.2 Pillar敏感的定向配置Pillar 和 Grains 最大的区别是Pillar 由 Master 维护可以按 Minion 定向下发并且适合存储密码、密钥、差异化配置等数据。Pillar 内容也通过 Salt 加密通道传输比明文写在 minon 端的文件安全得多。默认 Pillar 目录是/srv/pillar需要创建一份 top.sls# /srv/pillar/top.sls base: minion-node-01: - nginx创建对应的 Pillar 数据文件# /srv/pillar/nginx.sls nginx: server_name: www.example.com listen_port: 8080 max_workers: 4查看 Minion 收到的 Pillarsudo salt minion-node-01 pillar.items输出里会包含nginx下面的所有键值。Pillar 里的数据可以直接被 Jinja 模板读取从而让不同节点生成不同的配置文件。注意不要用 Pillar 暴露不必要的信息到大范围节点上。写入密钥时建议结合 Salt 的外部 Pillar 或 sdb 模块避免密钥出现在版本控制系统的纯文本文件里。5.3 Jinja 模板让 state 不再写死前面 Nginx 配置是静态文件。在真实场景中不同服务器往往需要不同的 server_name、端口和 worker 数量可以把 Nginx 配置改成 Jinja 模板。先修改 State 文件把source指向模板文件并告诉 Salt 这个文件需要模板渲染# /srv/salt/nginx/init.sls nginx_config: file.managed: - name: /etc/nginx/nginx.conf - source: salt://nginx/files/nginx.conf.j2 - template: jinja - user: root - group: root - mode: 0644 - watch_in: - service: nginx_service模板文件内容# /srv/salt/nginx/files/nginx.conf.j2 user nginx; worker_processes {{ pillar.get(nginx, {}).get(max_workers, auto) }}; error_log /var/log/nginx/error.log; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server { listen {{ pillar.get(nginx, {}).get(listen_port, 80) }}; server_name {{ pillar.get(nginx, {}).get(server_name, localhost) }}; location / { root /usr/share/nginx/html; index index.html; } } }这样修改 Pillar 数据后重新 apply State配置文件就会按新值渲染出来。使用 Jinja 模板时一个常见坑是模板变量取不到值时直接报错。建议所有 Pillar 取值都带上默认值例如pillar.get(nginx, {}).get(listen_port, 80)。这样即使某台 Minion 没有配置对应 Pillar也不会导致渲染失败。5.4 参数速查表数据来源存放位置主要用途敏感信息更新方式GrainsMinion 端收集系统属性、分组、条件判断不存放重启 Minion 或刷新PillarMaster 端维护节点差异化配置、敏感数据适合存放修改后继续 apply 或刷新StateMaster 端维护描述系统期望状态不存放修改 SLS 后 applyGitFS外部 Git 仓库存放 State 和 Pillar 文件结合 git roles提交代码后 refresh生产环境建议把 State 和 Pillar 统一放到 Git 仓库再通过 GitFS 或 CI 流程同步到 Master。这样配置变更可以走 Code Review比直接在 master 上改文件更可控。6. 运行验证与结果分析6.1 查看执行结果和返回码Salt 命令本身返回 0 不代表所有 Minion 都成功。看结果要关注每个 Minion 返回体里的result字段。以 state.apply 为例sudo salt minion-node-01 state.apply nginx --outjson输出片段{ minion-node-01: { pkg_|-nginx_install_|-nginx_|-installed: { comment: Package nginx is already installed, result: true, changes: {} }, file_|-nginx_config_|-/etc/nginx/nginx.conf_|-managed: { comment: File /etc/nginx/nginx.conf is up to date, result: true, changes: {} } } }判断执行是否成功不能只看命令是否返回也不能只看result: True还要确认changes是否符合预期、comment是否合理、有没有某个资源被跳过。可以写一个简单脚本批量检查所有 Minion 的结果sudo salt * state.highstate --outjson | jq to_entries[] | {name: .key, result: .value.result}如果result是 false就用--outhighstate查看更详细的失败信息。6.2 用 event bus 和 job cache 观察执行过程Salt Master 内部有事件总线所有 Minion 的连接、任务执行、返回结果都会以事件形式在总线上流动。查看实时事件sudo salt-run state.event listen执行一条命令Event Bus 里会出现salt/job/20250301.../new、salt/job/.../ret/minion-node-01等类型的事件。当任务执行得非常慢或者有大量 Minion 没有返回时可以用 job cache 查找sudo salt-run jobs.lookup_jid 20250301120000123456把 jid 替换成目标任务的 ID就能看到该任务在各 Minion 上的返回结果。如果某些 Minion 返回为空可以判断是执行超时还是 Minion 掉线。6.3 幂等性验证再次执行 highstateSalt 设计上要求 State 是幂等的同一个状态反复执行结果不应该产生副作用。验证方法很简单sudo salt minion-node-01 state.apply nginx然后再次执行sudo salt minion-node-01 state.apply nginx第二次执行时changes应该是空comment应该是类似 “Package nginx is already installed” 或 “File is up to date” 的信息。如果第二次执行仍然产生大量 changes说明 State 写得有问题。常见原因包括写的不是期望状态而是每次执行都会追加内容的脚本。模板渲染结果不稳定每次生成的文件内容都不同。cmd.run里执行的命令本身每次都会返回变化。幂等性不是 Salt 自动保证的而是靠写 State 的人的约束。这是配置管理工具和普通跑脚本之间最大的区别。7. 常见问题排查7.1 Minion 一直处于离线状态现象salt-key -L里能看到 Minion但执行salt * test.ping时返回Minion did not return. [No response]或者 Minion 显示为离线。可能原因4505 或 4506 端口被防火墙拦截。Minion 上master地址配置错误。Minion 进程没有启动或启动后退出。Master 上的 worker 线程耗尽。排查步骤在 Minion 上检查进程ps aux | grep salt-minion。查看 Minion 日志journalctl -u salt-minion -f。在 Minion 上测试连接timeout 5 bash -c /dev/tcp/192.168.56.10/4505 echo ok。在 Master 上检查端口ss -lntp | grep 4505。查看 Master 日志journalctl -u salt-master -f。处理建议如果是防火墙问题放行 4505/4506如果是配置问题修正/etc/salt/minion或/etc/salt/minion.d/下的配置如果是 worker 线程问题适当调大worker_threads。7.2 Minion key 认证失败现象执行命令时看到类似Minion did not return. [No response]或者日志里出现Authentication attempt of minion-node-01 failed.。可能原因Minion 被重新安装过密钥对发生了变化。Master 上保留了旧的 Unaccepted/Denied Keys。Minion 的 id 被另一台机器抢用。检查方式sudo salt-key -L处理建议先删除旧 key再重启 Minion然后重新接受新 keysudo salt-key -d minion-node-01 sudo systemctl restart salt-minion sudo salt-key -a minion-node-01预防方法是给每台 Minion 设置固定且唯一的 id不要依赖可能重复的 hostname。7.3 state 执行报错定位现象state.apply nginx后返回结果里某个资源的result: false。常见错误错误现象可能原因处理方式Source file salt://nginx/files/nginx.conf not foundstate 中的 source 路径错误检查/srv/salt/nginx/files/下是否有文件Data failed to compile: Rendering SLS failedYAML 缩进或 Jinja 模板语法错误使用python -c import yaml; yaml.safe_load(open(...))或salt-run fileserver.file_list检查Job 20250... failed with return code: 1模块执行失败先手动在 Minion 上执行对应的命令确认系统情况After rendering, state was shown as {file: ...}SLS 结构不完整检查 state 是否包含名称、模块函数和参数排查顺序先看报错信息里的comment它通常已经写明原因。在 Master 上确认文件是否存在sudo salt-run fileserver.file_list在 Minion 上手动执行模块函数比如salt minion-node-01 pkg.install nginx或salt minion-node-01 service.status nginx。用--outhighstate输出更完整的结果而不是只看默认样例。7.4 配置变更不生效现象修改了 State 文件或 Pillar 数据重新执行state.apply但目标机器上的配置没有变。可能原因修改的是文件但没有重新 apply。top.sls 没有包含这个 State导致state.highstate没有执行它。文件权限或 watch 条件没有触发服务重启。Minion 和 Master 的 fileserver 缓存没有刷新。检查方式sudo salt minion-node-01 file.get_managed /etc/nginx/nginx.conf sudo salt minion-node-01 pillar.items处理建议先执行salt-run fileserver.clear_cache清理缓存。确认salt minion-node-01 state.apply nginx中file_managed状态是否有 changes。如果changes为空说明文件内容没有变化需要检查模板是否用了正确的变量。检查watch_in是否挂到了 service 状态上。从根本上预防可以把 State 文件、模板文件、Pillar 数据全部纳入 Git 版本库。每次变更都走 Review并在 CI 里做一次state.apply --test语法检查能减少大量“改了没生效”的问题。8. 生产环境最佳实践与扩展方向8.1 从单 Master 到多 Master 高可用学习环境用一个 Master 没有问题生产环境则要考虑单点故障。常见做法有两种运行多个 MasterMinion 配置里可以指定多个master地址自动切换。使用 Salt Syndic 做层级架构上层 Master 管理多个区域 Master适合跨机房、跨网络边界的场景。多 Master 部署的重点不在安装而在配置同步。所有 Master 上的 state、pillar、配置文件必须保持一致。建议用 Git 作为唯一数据源通过 CI/CD 推送到各个 Master避免不同 Master 上配置不一致导致执行结果漂移。8.2 Salt SSH 和 Salt API 的使用场景如果目标机器不能安装 Agent可以使用 Salt SSH。它的用法和 Master/Minion 模式基本一致只是通过 SSH 执行。sudo salt-ssh 192.168.56.12 test.pingSalt SSH 适合做临时接管、短期批量命令和硬件原因不方便装 Agent 的场景。但因为每次执行都要走 SSH 握手并发和速度会比代理模式差。如果团队想自动化执行 Salt而不是每个人都能登录 Master可以提供 Salt API。启用前先配置认证# /etc/salt/master.d/api.conf rest_cherrypy: port: 8000 host: 0.0.0.0 debug: False ssl_crt: /etc/pki/tls/certs/localhost.crt ssl_key: /etc/pki/tls/private/localhost.key生产环境使用 Salt API 时要把端口放在内网并通过统一认证网关代理避免直接暴露。API 调用还需要做权限控制区分哪些用户可以执行只读命令、哪些用户可以执行高权限命令。8.3 发布前检查清单在把新 State 发布到生产环境前建议逐项检查[ ] 所有 State 文件已经过state.apply语法校验。[ ] top.sls 中引用的 SLS 文件都存在。[ ] 模板文件中所有变量都有默认值。[ ] Pillar 中的敏感信息没有硬编码在普通 State 里。[ ] 目标节点范围是否最小化先灰度一批节点。[ ] 执行前是否备份关键配置文件。[ ] 是否提前确认 Nginx、MySQL 等服务的 reload 方式。[ ] 是否监控执行日志和异常事件。[ ] 是否有回滚方案旧文件版本、旧服务版本、旧 Pillar 数据。[ ] 是否记录变更前后差异便于审计。8.4 下一步可以扩展的方向SaltStack 的入门不难难在把很多基础能力组合成完整的自动化体系。学完 state、pillar、grains、jinja 之后可以按下面几个方向继续深入自定义 module 和 state当内置模块不能满足需求时用 Python 编写自己的模块。event reactor利用 Salt event bus 监听文件变更、服务异常、Minion 上线等事件自动执行修复。schedulers让 Minion 或 Master 定时执行任务例如每小时校验一次 Nginx 配置。MySQL 和数据库模块用它管理系统账号、数据库权限。与 CI/CD 集成在 GitLab CI 或 Jenkins 中触发 Salt highstate实现配置变更的自动化发布。配置管理工具的价值不在于能执行多少条命令而在于把服务器最终状态固化成可审查、可回滚、可重复验证的代码。从两台测试机开始把一条 test.ping、一个 Nginx state、一次 highstate 弄明白后面再管理几百台机器时思路会清晰很多。
