本文共分五部分：1. 基础；2. standalone 模式；3. C/S 模式；4. ssh模式；5. 总结。

基础

先稍微比较一下 saltstack 和 puppet。

puppet

在我看来 saltstack 是没有 mcollective 的 puppet 的超集，puppet 本身只是一个完整的配置管理工具，并不具有远程执行方面的功能，mcollective 作为 puppet 的一个组件扩展了这方面的能力，但默认只整合在 puppet 的企业版中，社区版本需要自己单独安装、配置，因此当对来说使用比较麻烦。

saltstack

saltstack 天生就具有远程执行的能力，实际上远程执行是它的核心，而配置管理之类的都只算是它的附加功能，而且它也没有企业版和社区版的区别，所有功能模块的安装、配置都超级简单，而且它还具有类似 ansible 的通过 ssh 进行远程执行、部署的能力，因此在不方便安装 saltstack 客户端的情况下也能够方便的进行系统管理操作。

saltstack 使用 python 语言实现，所有代码全部开源，源代码托管在 github 上。

基本工作模式为 C/S 模式，客户端与服务端建立连接，然后在服务端上主动发起动客户端的操作，从而实现远程执行的功能。除了这种常规的模式外，还可以实现不需要服务端直接本地执行、通过 ssh 通道进行远程执行等功能。

三个基本概念

• grain

类似puppet 的 fact，其实就是当前客户端系统的一些基本信息，比如 cpu 数目、网卡地址之类的，这些信息由客户端系统生成，客户端在连接服务端时会携带这些数据给服务端；

• pillar

类似 puppet 的 hiera，其实就是一个数据仓库，这些数据在服务端通过 pillar 文件进行定义，客户端只能获取对应于自身的数据，所有 pillar 文件组成一个 pillar tree，由 top.sls 文件描述客户端所拥有的 pillar 文件；

• state

类似于 puppet 的 resource，定义 state 就是定义系统状态，各种 state 定义文件组成一个 state tree，由 top.sls 文件（注意与 pillar tree 所使用的 top.sls 不是同一个文件，pillar tree 和 state tree 分别定义在不同的目录）描述客户端所拥有的 state 文件，该 top.sls 文件类似于 puppet 的 site.pp 文件；

对于系统状态（state）的描述 saltstack 没有重复发明轮子，使用的是 yaml 语言，pillar 文件的定义也是用的 yaml，当然类似于 puppet 的 ERB（Embedded Ruby），saltstack 也有自己的一套扩展纯 yaml 定义的方式，即 yaml + render，而且有多种 render 可供选择，默认是 yaml + jinja 的组合。

standalone模式

在 standalone 模式下，state tree、pillar tree 都可以直接定义在本地，不需要单独起服务端或客户端的守护进程，执行带 --local 选项的 salt-call 命令即可，有点类似于服务端就是本机，客户端执行一次即退出的意思，也类似于 puppet 的 agent 模式，主要可用于单机部署之类的任务，如安装、配置比较复杂的软件等，当然所有的远程执行模块都可以在本地执行。

当然 standalone 模式也可以将 state tree、pillar tree 定义在服务端，这时候必须起服务端守护进程，但客户端的守护进程还是不需要启动，直接执行不带 --local 选项的 salt-call 命令即可，客户端会主动从服务端下载相应的 state 定义和 pillar 数据，然后就和带 --local 选项的 salt-call 命令一样的工作流程了。

执行 salt-call 命令时不需要指定客户端，因为 standalone 模式本身就是针对本机的操作，在命令行上再指定客户端就是多此一举了。

C/S模式

服务端：salt-master。

客户端：salt-minion。

客户端在上电后会主动发起对服务端的连接，且随时接收服务端发出的远程执行指令并处理，然后将处理结果返回给服务端。这里的实现原理与 puppet 有较大区别，puppet 是建立短连接，一次操作完成即关闭连接，然后客户端定时发起对服务端的连接，因此我认为相比 saltstack，puppet 的主要劣势也就在此：无法实时的动态调整客户机配置，当然我对 puppet 的 mcollective 组件了解不多，是否增加了 mcollective 组件就能实现类似 saltstack 的实时远程执行功能就不得而知了。

与 standalone 模式不同，C/S 模式在服务端发起对客户端的控制操作，显然这就是所谓的远程执行，所使用的命令为 salt 而不是 salt-call，由于服务端与客户端是一对多的关系，因此在执行 salt 命令时需要指定命令所针对的目标，saltstack 支持多种匹配规则，非常灵活，如 *、? 通配符，正则表达式，grain 数据等。

在一般规模的环境下多个客户端通常只对应一个服务端，但如果客户端数量超级大，还可以组建服务器集群。对于数千个客户端规模的集群，根据官方的意思 saltstack 应该是能够应付得了的，但貌似 puppet 就没有这么幸运了，根据网上的资料是在有几十个客户端的情况下 puppet 的处理就有点吃力了。

ssh模式

这种模式与 ansible 这种自动化配置管理工具的原理类似，由于被管理节点的 ssh 服务一般都是启用的，因此能够充分利用了现有的传输通道，而不需要在被管理节点上单独安装客户端，这种非侵入式的管理方式在部署 saltstack 本身（chicken or the egg 的问题）等特定场合下很有用。

与 standalone 模式不同，standalone 模式不需要知道客户端是谁，因为客户端就是本机，也与 C/S 模式不同，此时客户端会主动连接服务端，服务端总会知道当前有哪些被管理的客户端，但是对于 ssh 模式而言，是无从知晓这些信息的，因此需要手工定义一个客户端列表文件，默认路径为：/etc/salt/roster，在 roster 文件里定义了客户端之后就可以对客户端进行管理了，当然相应的命令与前两种模式都不同，这一回使用的是 salt-ssh 命令，命令格式与 salt 一样，但当前的目标匹配规则还很简单，只支持简单的列表、通配符匹配。

总结

总之很好很强大，官方文档可参考：http://docs.saltstack.com/en/latest/，内容很杂、较全，开源项目有文档已经不错了，不过这么乱的也少见。

最后修改于 2018-12-27