自动化运维工具——Salt（saltstack）基础概念及安装部署

Salt（原名saltstack:2020 年更名为 Salt，强调开放生态）是一款开源的基础设施自动化与配置管理工具，由 Salt, Inc.（现为 VMware 旗下产品）开发，主要用于大规模服务器、网络设备、云基础设施的配置管理、任务自动化、远程执行和监控。它通过统一的平台实现对基础设施的集中控制，帮助企业和开发者高效管理复杂环境，降低运维成本，提升部署效率。

• 官网地址：https://docs.saltstack.cn/

概述

简单介绍

Salt是一款：

• 一个配置管理系统，能够维护预定义状态的远程节点(比如，确保指定的报被安装，指定的服务在运行)
• 一个分布式远程执行系统，用来在远程节点（可以是单个节点，也可以是任意规则挑选出来的节点）上执行命令和查询数据

核心功能

• 使命令发送到远程系统是并行的而不是串行的
• 使用安全加密的协议
• 使用最小最快的网络载荷
• 提供简单的编程接口

主要使用场景

• 配置管理（Configuration Management）
  • 通过 “状态声明” 定义基础设施的期望状态（如包版本、文件内容、服务状态等），自动检测并修复偏差。
  • 支持模板引擎（Jinja2），动态生成配置文件，适配不同环境。
• 远程执行（Remote Execution）
  • 实时在多台设备上并行执行命令或脚本，支持批量操作（如查看日志、重启服务、更新系统）。
  • 支持灵活的目标选择（按主机名、IP、标签、分组等）。
• 自动化编排（Orchestration）
  • 通过State SLS文件或Pillar数据（分层变量管理）定义复杂部署流程，支持依赖关系和执行顺序控制。
  • 集成 CI/CD 管道，实现应用的持续部署和环境快速复制。
• 云容器管理
  • 支持主流云平台（AWS、Azure、Google Cloud）和容器技术（Docker、Kubernetes），实现跨平台资源编排。
  • 自动扩展、配置云实例，同步基础设施状态。
• 监控与报告
  • 实时收集节点状态数据，生成健康报告，支持异常预警（如磁盘空间不足、服务崩溃）。
  • 与 Prometheus、Grafana 等工具集成，实现可视化监控。

核心架构与通信方式

核心架构组件

• Salt Maszter：Salt 架构中的控制节点，负责接收用户指令、管理 Minion、分发配置和任务。
  • 作用：作为整个 Salt 系统的 “大脑”，协调所有 Minion 的通信、认证、任务调度和状态同步。
  • 特点：通常为一台或多台服务器（支持高可用部署），监听 Minion 的连接请求并处理指令。
• Salt Minion：Salt 架构中的被控节点，运行在需要被管理的服务器、虚拟机或设备上。
  • 作用：主动连接 Master 并维持长连接，接收 Master 下发的指令（如远程命令、状态配置）并执行，执行结果反馈给 Master。
  • 示例：在一台 Web 服务器上安装 Minion 后，Master 可通过 Minion 远程安装 Nginx、修改配置文件。
• Proxy Minion：特殊类型的 Minion，用于管理无法直接安装 Minion 的设备（如网络设备、存储设备、虚拟机 hypervisor 等）。
  • 作用：作为 Master 与非标准设备之间的 “代理”，将 Salt 的管理能力扩展到网络交换机、路由器、防火墙、打印机等异构设备。
  • 工作原理：
    • Proxy Minion 运行在可访问目标设备的服务器上，模拟 Minion 的身份与 Master 通信；
    • 通过设备专属的驱动（如 SNMP、SSH、API）与目标设备交互，将 Salt 指令转换为设备可识别的命令。
  • 示例：管理 Cisco 交换机时，Proxy Minion 通过 SSH 连接交换机，执行salt "cisco-switch-proxy" net.arp获取 ARP 表。
• Salt Syndic：大型分布式环境中的 “中间代理”，连接上层 Master 和下层 Minion 或子 Master。
  • 作用：解决大规模部署时的 Master 负载问题，实现层级化管理（如区域级 Syndic 连接总部 Master，管理本地 Minion）。
  • 适用场景：跨数据中心、跨区域的大型基础设施管理。

通信与认证组件

• ZeroMQ/TCP：Salt 默认的通信协议（ZeroMQ），也支持 TCP 协议，用于 Master 与 Minion 之间的数据传输。
  • 作用：提供高效、异步的消息队列通信，确保指令和数据的低延迟传输（支持加密通信）。
  • 特点：ZeroMQ 基于消息模式（如发布-订阅、请求-响应），适合高并发场景。
• Salt Key：Master 与 Minion 之间的认证机制，基于公钥 / 私钥对。
  • 作用：确保 Minion 与 Master 的身份合法性，防止未授权节点接入。
  • 流程：
    • Minion 启动时生成密钥对，将公钥发送给 Master 请求认证；
    • Master 通过salt-key -a <minion-id>接受公钥（或拒绝），认证通过后 Minion 可与 Master 通信。
• Minion ID：每个 Minion 的唯一标识符，通常为 hostname 或自定义名称（配置在/etc/salt/minion的id字段）。
  • 作用：Master 通过 Minion ID 识别和定位具体的被控节点，用于指令下发和结果筛选。
  • 示例：通过salt "web-server-01" test.ping指令，Master 仅向 ID 为web-server-01的 Minion 发送 ping 请求。

架构图

• 主从模式：详见《主从模式》

• 分布式模式：详见《分布式模式》

入门必备

特殊或专有名词

• Salt Master：Salt 架构中的控制节点，负责向 Minion 发送命令、管理配置和分发资源。
• Salt Minion：被管理节点上运行的代理程序，接收 Master 指令并执行相应操作。
• Grains：Minion 启动时收集的静态系统信息（如操作系统、硬件配置），用于目标匹配和状态定制。
• Pillar：存储在 Master 的加密动态数据（如密钥、配置参数），仅指定 Minion 可访问，用于敏感信息管理。
• State：描述系统期望状态的配置文件（.sls 格式），通过state.apply执行以实现系统标准化。
• Formula：预定义的 State 模块集合，用于快速部署常见服务（如 Nginx、MySQL）的标准化配置。
• Highstate：一次性应用所有关联 State 配置的操作，实现系统整体状态的统一管理。
• Execution Module：Master 调用的实时操作模块（如cmd.run、pkg.install），用于执行临时命令。
• Returner：将 Minion 执行结果发送到外部存储（如数据库、Elasticsearch）的模块，用于结果持久化。
• Outputter：控制命令执行结果展示格式的模块，支持 JSON、表格、文本等多种输出形式，方便结果查看和解析。
• Targeting：Master 指定目标 Minion 的方式（如 ID、Grains、分组），实现精准命令分发。
• Beacon：Minion 上监控系统事件（如文件变化、服务状态）的组件，可触发自动响应。
• Reactor：Master 上接收事件并执行预设动作（如 State、命令）的机制，实现事件驱动自动化。
• Salt Cloud：管理云主机生命周期（创建、配置、销毁）的模块，支持多云平台集成。
• Salt SSH：无需安装 Minion，通过 SSH 协议管理节点的模式，适用于临时或轻量场景。
• SLS 文件：用 YAML 或 Jinja 编写的 State 配置文件，定义系统组件的期望状态和依赖关系。
• Proxy Minion：特殊的 Minion 代理，用于管理无法直接安装 Minion 的设备（如网络设备、IoT 设备），通过代理实现间接管控。
• Nodegroups：在 Master 配置中预定义的 Minion 分组（如按环境、角色划分），简化批量操作时的目标指定。
• Syndic：大规模部署时的层级代理节点，连接上层与下层 Master，实现集群负载分担和分级管理。
• Top File：命名为 top.sls 的特殊文件，定义哪些 Minion 应用哪些 State 配置，是状态管理的入口映射文件。
• Schedule（Minion 定时任务）：Minion 本地的定时任务配置机制，允许在 Minion 上按计划自动执行指定操作（如周期性运行命令、应用状态），无需 Master 持续触发，适用于本地化定时任务需求。

核心目录和配置文件

• /etc/salt/：Salt 的主配置目录，包含所有核心配置文件和子目录。
• /etc/salt/master：Master 节点的主配置文件，定义 Master 的监听端口、密钥路径、文件服务器根目录等核心参数。
• /etc/salt/minion：Minion 节点的主配置文件，设置 Master 地址、Minion ID、日志级别等基础配置。
• /etc/salt/pillar/：存储 Pillar 数据的目录，包含敏感信息（如密码、密钥）的 SLS 文件，需在pillar_roots中配置路径。
• /etc/salt/states/（或自定义的 State 根目录）：存放状态配置（SLS 文件）的目录，定义系统期望状态，路径需在file_roots中指定。
• /etc/salt/top.sls：状态管理的入口文件，定义哪些 Minion（通过匹配规则）应用哪些 State 配置。
• /etc/salt/minion.d/和/etc/salt/master.d/：配置文件扩展目录，可存放拆分的配置片段（.conf 后缀），自动被主配置文件加载，便于模块化管理。
• /var/cache/salt/`：缓存目录，存储 Minion 下载的文件、State 执行缓存、Grains 数据等，可通过配置调整缓存策略。
• /var/log/salt/：日志目录，包含 Master、Minion、Syndic 等组件的运行日志，用于问题排查和审计。
• /etc/salt/keys/：密钥存储目录，保存 Master 和 Minion 的公钥 / 私钥，以及已认证、待认证的 Minion 密钥信息。
• /srv/salt/（默认）：官方推荐的 State 文件根目录，可在file_roots中修改，用于存放 SLS 配置文件和相关资源。
• /srv/pillar/（默认）：官方推荐的 Pillar 文件根目录，存放敏感配置数据，需在pillar_roots中配置生效。

主要运行方式

主从模式

也称为“Master-Minion 模式”，这是 Salt 最经典、最常用的运行方式，采用 C/S（客户端-服务器）架构，通过主节点（Master）集中控制多个从节点（Minion）。

核心架构

• Master 节点 ：作为控制中心，负责发送指令（如远程命令、配置文件）、管理 Minion 认证、存储节点信息等。
• Minion 节点：部署在被管理的服务器 / 设备上，主动向 Master 注册并保持长连接（基于 ZeroMQ 或 TCP），接收并执行 Master 的指令，然后返回结果。
• 认证机制：Minion 首次启动时会生成密钥对，向 Master 发送认证请求；Master 通过后，双方建立加密通信（AES 加密），确保指令传输安全。

运行流程

1. Minion 启动后自动连接 Master 并请求认证；
2. 管理员在 Master 上通过 salt-key 命令接受 Minion 认证；
3. Master 通过 salt 命令向指定 Minion（或分组）发送指令（如salt '*' cmd.run 'ls'）；
4. Minion 执行指令并返回结果给 Master，Master 汇总后展示。

适用场景

• 大规模服务器集群管理（数十到数千节点）；
• 需要集中化控制和统一配置的场景（如批量部署软件、更新配置）；
• 对实时性要求较高的操作（如远程命令执行、状态监控）。

举例说明

某公司有 200 台 Web 服务器，需要批量部署 Nginx 并统一配置反向代理。

1. 部署架构：
   • 1 台 Master 节点（192.168.1.100）
   • 200 台 Minion 节点（已安装 Minion 并完成 Master 认证）
2. 在 Master 上编写 Nginx 部署的SLS状态文件（/srv/salt/nginx/init.sls）：

nginx:
  pkg.installed: []
  service.running:
    - enable: True
    - require:
      - pkg: nginx

/etc/nginx/nginx.conf:
  file.managed:
    - source: salt://nginx/nginx.conf
    - user: root
    - group: root
    - mode: 644
    - require:
      - pkg: nginx
    - watch_in:
      - service: nginx

3. Master 上执行命令批量应用配置：

# 对所有 Minion 部署 Nginx
salt '*' state.apply nginx

# 仅对 web 分组的 Minion 执行（需提前在`/etc/salt/master`配置分组）
salt 'web*' state.apply nginx

4. 结果：200 台服务器自动安装 Nginx、同步配置文件并启动服务，Master 终端输出每台节点的执行结果。

无主模式（Masterless 模式）

又称 “本地模式”，无需部署 Master 节点，Minion 直接在本地读取配置文件并执行操作，适用于小规模或临时场景。

核心原理

• Minion 不与任何 Master 通信，而是通过本地文件系统加载配置（如/etc/salt/minion）和状态文件（Salt States）；
• 使用salt-call命令在本地执行操作，无需网络连接 Master，结果直接输出到本地终端。

常用命令

• 执行远程命令：salt-call --local cmd.run 'echo hello'
• 应用状态配置：salt-call --local state.apply（需提前编写 SLS 状态文件）

适用场景

• 单节点管理或小规模设备（如几台服务器、边缘设备）；
• 离线环境或临时运维任务（无网络连接 Master 时）；
• 开发或测试环境中快速验证状态配置（无需搭建 Master 架构）。

特点

• 架构简单，无需维护 Master 节点，降低部署成本；
• 依赖本地文件，配置分发需手动操作（如通过 Ansible、SCP 同步文件），不适合大规模集群；
• 安全性高，无网络传输指令，减少攻击面。

举例说明

开发者在本地测试环境（单台服务器）验证 Salt 状态配置，无需搭建 Master。

1. 准备工作
   • 在本地服务器安装 Minion（无需启动 Master）
   • 配置 Minion 本地模式（/etc/salt/minion 中设置 file_client: local）
   • 本地创建并编写测试 SLS 状态文件（/srv/salt/test.sls）

test_file:
  file.managed:
    - name: /tmp/test.txt
    - contents: "Hello from Masterless mode"

2. 本地执行

# 本地应用状态配置
salt-call --local state.apply test

# 本地执行命令（如查看磁盘占用）
salt-call --local cmd.run 'df -h'

3. 结果：本地服务器生成 /tmp/test.txt 文件，命令输出直接显示在当前终端，无需网络连接其他节点。

分布式模式

也称为“Syndic 分布式模式”，当节点规模极大（数千到数万个节点）时，单一 Master 可能面临性能瓶颈（如网络负载、处理压力），此时可通过 Syndic 节点 实现分布式扩展，形成 “多级 Master” 架构。

核心架构

• Top Master：顶层控制节点，负责管理 Syndic 节点，不直接与 Minion 通信；
• Syndic 节点：中间层代理，连接 Top Master 和区域 Master，转发指令和结果；
• Syndic Master：区域 Master，负责管理 Minion节点，直接与Minion 通信；
• Minion 节点：被管理节点，与所在区域的 Master 通信。

运行流程

1. Top Master 向 Syndic 发送指令（如批量操作）；
2. Syndic 将指令转发给其管理的区域 Master；
3. 区域 Master 执行指令后，将命令转发给 Minion 并将结果回传给 Syndic；
4. Syndic回传给 Top Master，Top Master 汇总所有 Syndic 返回的结果并展示。

优势

• 分担 Master 负载，通过 Syndic 实现区域化管理（如按机房、业务线划分区域）；
• 减少跨区域网络流量，提升大规模集群的响应速度；
• 支持分级权限控制（Top Master 管理全局，Syndic 管理区域内节点）。

适用场景

• 超大规模集群（数万节点）或跨地域部署（如多机房、跨国集群）；
• 对高可用性和扩展性要求极高的场景（避免单一 Master 故障影响全局）。

Salt SSH 模式

无需在被管理节点部署 Minion 客户端，通过 SSH 协议远程执行命令或应用配置，适用于临时管理未安装 Minion 的节点。

核心原理

• 基于 SSH 协议通信，依赖目标节点的 SSH 服务（需提前配置 SSH 密钥免密登录）；
• Master 通过 salt-ssh 命令直接连接目标节点，无需 Minion 进程，本质是 “无代理远程执行”。

常用命令

• 执行远程命令：salt-ssh '*' cmd.run 'df -h'（需在 Master 的/etc/salt/roster中配置目标节点的 SSH 信息）
• 应用状态配置：salt-ssh '*' state.apply

适用场景

• 临时管理未安装 Minion 的节点（如新增服务器、第三方设备）；
• 对节点侵入性要求低的场景（无需部署客户端软件）；
• 混合环境管理（同时管理有 Minion 和无 Minion 的节点）。

特点

• 无需部署 Minion，降低前期准备成本，但依赖 SSH 配置（密钥、端口等）；
• 性能低于 Minion 模式（SSH 协议开销较大），不适合高频操作；
• 可作为 Master-Minion 模式的补充，应对临时节点管理需求。

总结

运行方式	核心架构	适用规模	优势	劣势
主从模式	Master + Minion	中大规模集群	集中化控制、实时性高	依赖 Master 可用性，部署复杂
无主模式	仅 Minion 本地运行	单节点/小规模	架构简单、离线可用	配置分发困难，不适合集群
Syndic 分布式	多级 Master 代理	超大规模集群	负载分担、区域化管理	架构复杂，维护成本高
Salt SSH 模式	基于 SSH 无代理	临时/混合节点	无需部署 Minion，侵入性低	性能较差，依赖 SSH 配置

安装与部署

服务安装

以 CentOS 7+ 为例

# Master节点
yum install -y epel-release
yum install -y salt-master
systemctl start salt-master
systemctl enable salt-master

# Minion节点
yum install -y epel-release
yum install -y salt-minion

基础配置

Master配置

Master 的配置文件为/etc/salt/master，主要配置项：

• interface：监听的 IP（默认 0.0.0.0，即所有网卡）
• publish_port：发布命令的端口（默认 4505，用于 Master 向 Minion 发送命令）
• ret_port：接收结果的端口（默认 4506，用于 Minion 向 Master 返回结果）
• default_include：用于包含其他配置文件（支持通配符），方便拆分配置，默认包含/etc/salt/master.d/*.conf
• worker_threads:处理 Minion 请求的线程数，默认 5，高负载场景可增加
• cachedir：缓存目录（默认/var/cache/salt/master），存储临时文件、Job 缓存等
• keep_jobs：Job 结果在 Master 上的保留时间（默认 24 小时），超时自动清理
• file_roots：定义状态文件（如 SLS 文件）的存储路径，支持多环境（base/prod/dev 等）
• pillar_roots：定义 Pillar 数据的存储路径，用于存储敏感配置（需指定环境）
• log_file:Master 日志文件路径（默认/var/log/salt/master），记录运行日志
• key_logfile:密钥相关操作日志路径（默认/var/log/salt/key），记录密钥认证过程

配置文件示例：

• /etc/salt/master

# 省略Master自带的配置及内容

# 文件内部配置了nodegroups.conf
default_include: master.d/*.conf
interface: 0.0.0.0
worker_threads: 20
cachedir: /srv/cache/salt/master
keep_jobs: 6
file_roots:
  base:
    - /srv/salt
  dev:
    - /srv/salt/dev
    - /srv/salt/dev/services
  online:
    - /srv/salt
    - /srv/salt/online
    - /srv/salt/online/file_root
  test:
    - /srv/salt/test
    - /srv/salt/test/file_root
pillar_roots:
  base:
    - /srv/pillar
  test:
    - /srv/pillar
log_file: /data1/salt/master
key_logfile: /data1/salt/key

• /etc/salt/master.d/nodegroups.conf

nodegroups:
  #es_builder: 'L@db9.safe.shbt.xxx.xxx,db10.safe.shbt.xxx.xxx,db11.safe.shbt.xxx.xxx'
  #sample_download: 'E@db1[2-6]\.safe\.shbt\.xxx\.xxx'
  PkgAssemble: 'L@scandb19.safe.lycc.xxx.xxx,scandb20.safe.lycc.xxx.xxx,scandb21.safe.lycc.xxx.xxx,scandb22.safe.lycc.xxx.xxx,scandb23.safe.lycc.xxx.xxx,scandb24.safe.lycc.xxx.xxx,scandb25.safe.lycc.xxx.xxx,scandb26.safe.lycc.xxx.xxx'
  kafka: 'L@scandb51.safe.lycc.xxx.xxx,scandb52.safe.lycc.xxx.xxx,scandb53.safe.lycc.xxx.xxx,scandb37.safe.lycc.xxx.xxx,scandb38.safe.lycc.xxx.xxx,scandb62.safe.lycc.xxx.xxx,scandb63.safe.lycc.xxx.xxx,scandb64.safe.lycc.xxx.xxx,scandb65.safe.lycc.xxx.xxx,scandb66.safe.lycc.xxx.xxx,scandb67.safe.lycc.xxx.xxx,scandb68.safe.lycc.xxx.xxx,scandb69.safe.lycc.xxx.xxx,scandb70.safe.lycc.xxx.xxx,scandb71.safe.lycc.xxx.xxx,scandb72.safe.lycc.xxx.xxx,scandb73.safe.lycc.xxx.xxx,scandb74.safe.lycc.xxx.xxx,scandb75.safe.lycc.xxx.xxx,scandb80.safe.lycc.xxx.xxx,scandb27.safe.lycc.xxx.xxx,scandb28.safe.lycc.xxx.xxx,scandb98.safe.lycc.xxx.xxx,scandb99.safe.lycc.xxx.xxx'
  scandb-shcdt: 'E@scandb.*\.safe\.shcdt\.xxx\.xxx'
  CloudSafeLine-1: 'E@scandb(0[3-9]|1[0-4])\.safe\.shcdt\.xxx\.xxx'

Minion配置

Minion 的配置文件为/etc/salt/minion，关键配置：

• master：指定 Master 的 IP 或主机名（必须配置，例如master: 192.168.1.100）
• id：自定义 Minion ID（可选，默认使用主机名，建议设置为唯一标识，如服务器名）

配置文件示例：

• /etc/salt/minion:

# 省略Master自带的配置及内容
master: scandb01.safe.shcdt.xxx.xxx

• /etc/salt/minion.d/_schedule.conf

schedule用于在 Minion 上配置定时任务，无需 Master 干预即可自动执行指定函数（如状态更新、数据采集等）。配置格式为字典，键为任务名称，值为任务参数。

schedule:
  # 任务1：定时更新mine数据
  __mine_interval: 
    enabled: true               # 启用任务（默认true）
    function: mine.update       # 执行的Salt函数（更新mine数据）
    jid_include: true           # 任务结果包含JID（任务ID）
    maxrunning: 2               # 最大并发数（防止任务堆积）
    minutes: 60                 # 执行间隔（每60分钟）
    return_job: false           # 不向Master返回结果
    run_on_start: true          # Minion启动时立即执行一次

  # 任务2：定时执行highstate
  highstate: 
    function: state.highstate   # 执行的Salt函数（应用所有状态）
    seconds: 60                 # 执行间隔（每60秒）

注意：schedule配置完成后，重启 Minion 服务后，配置文件会自动变成如下格式（很有意思）

schedule:
  __mine_interval: {enabled: true, function: mine.update, jid_include: true, maxrunning: 2,
    minutes: 60, return_job: false, run_on_start: true}
  highstate: {function: state.highstate, seconds: 60}

建立链接

1. 密钥生成与认证请求
   • Minion 启动后，会自动生成一对非对称密钥（公钥 + 私钥），存储在/etc/salt/pki/minion/（minion.pem私钥，minion.pub公钥）。
   • Minion 会向配置的 Master 发送公钥和认证请求（通过 Master 的 4506 端口），请求加入 Master 的管理集群。
2. Master 接收并认证 Minion
   • Master 接收到 Minion 的公钥后，会将其暂存在 “未认证列表” 中，等待管理员确认。
   • 管理员通过salt-key命令管理 Minion 密钥，命令详见下文。
   • 当 Master 接受 Minion 的公钥后，会将 Minion 的公钥存储在/etc/salt/pki/master/minions/目录下，完成认证。

# 查看所有Minion的密钥状态（Accepted/Unaccepted/Rejected）
salt-key -L

############ 标准输出 ##############
#Accepted Keys:
#scandb03.safe.shcdt.xxx.xxx
#scandb17.safe.shbt.xxx.xxx
#Denied Keys:
#Unaccepted Keys:
#scandb01.safe.shcdt.xxx.xxx
#Rejected Keys:

# 接受指定Minion的密钥（允许通信）
salt-key -a 【minion_id】  # 例如salt-key -a scandb01.safe.shcdt.xxx.xxx

# 接受所有未认证的Minion密钥
salt-key -A

# 拒绝/删除Minion密钥（禁止通信）
salt-key -r 【minion_id】  # 拒绝
salt-key -d 【minion_id】  # 删除

3. 建立加密通信通道

   • 认证通过后，Master 与 Minion 之间通过加密通道通信：
   • Master 向 Minion 发送命令时，会用 Minion 的公钥加密命令，确保只有对应的 Minion 能解密（私钥在 Minion 本地）。
   • Minion 执行命令后，用 Master 的公钥加密结果，返回给 Master（Master 用自己的私钥解密）。
   • 通信端口：默认使用 4505（Master 发布命令）和 4506（Minion 返回结果），均为 TCP 协议。

4. 验证通信

# 测试所有Minion的连通性
salt '*' test.ping

############ 标准输出 ##############
#scandb03.safe.shcdt.xxx.xxx:
#    True
#scandb17.safe.shbt.xxx.xxx:
#    True

# 查看指定Minion的信息
salt 【minion_id】 grains.items

后记

本文记录了Salt的基础概念、服务安装部署等内容，如何在实战中熟练的使用它，可以参考《自动化运维工具——Salt（saltstack）实践及应用》