runsisi's

technical notes

saltstack学习总结

2018-12-27 runsisi#devops

本文共分五部分: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/,内容很杂、较全,开源项目有文档已经不错了,不过这么乱的也少见。