七天学会SALTSTACK自动化运维 (3)

时间:2023-12-30 20:34:02

七天学会SALTSTACK自动化运维 (3)

  • 导读
  • SLS
  • TOP.SLS
  • MINION选择器
  • SLS文件的编译
  • 总结
  • 参考链接

导读


SLS

SLS (aka SaLt State file) 是 salkstack 中非常基础和重要的一种配置文件. 重要程度仅次于minion和 master 的主配置文件(或者说是一种数据结构,使用yaml编写), 因为 SLS 配置文件决定了我们所定义的命令的执行路径,比如 target到的很多minion, target完成之后就要开始执行命令了,或是真的执行一组命令,或是同步一堆配置文件,都是要确定哪个target ,执行哪个命令或者操作的,寻找对应的环境是sls文件的功能之一,也是第一步要学会的关于SLS的知识,关于环境配置,大多数都写在 top.sls 中, 每个环境都有自己的top.sls,方便多环境配置,其他的sls多用于控制配置文件同步或者执行命令之类的工作。


TOP.SLS

我的 file_roots

/etc/master
file_roots:
base:
- /srv/salt/base
dev:
- /srv/salt/dev
test:
- /srv/salt/test

我的 top.sl

/srv/salt/base/top.sls
base:
'*':
- salt.minion
- base /srv/salt/dev/top.sls
dev:
'dev*':
- development_config
- dev_db /srv/salt/test/top/sls
test:
'env:test':
- match: grain
- test_config
- test_db

我的配置文件中有3个环境,不同的环境对应不同的环境配置目录,目录在 master 的file_roots中配置,意思就是说,每个minion可以读取base的配置文件, dev的可以读取dev的环境, test的可以读取test的环境,这样就可以避免把 settings.py, nginx.conf, my.cnf等等都放到同一个目录中.

现在我的/srv/salt/base/中只放一些通用配置,当执行state.highstate的时候就会执行base.sls中的所有操作到我的minion上,下面参见我的base.sls.

minion_config:
file.managed:
- name: /etc/base/minion.config
- source: salt://minion.config apache:
pkg.installed:
- watch:
- file: minion_config

非常简单,且saltstack自动处理的非常好,只需要告诉minion应该保存文件的位置就可以,source则完全不用配置,因为salt自己知道当前minion对应的哪个环境目录,自动去寻找minion.config文件并且同步到自己的/etc/base/minion.config下,这样就实现了不同环境的分离,不过有一个地方需要注意的是,如果/etc/base目录不存在会同步失败,所以要事先确定目录是否存在


MINION选择器

官方文档中的关于top.sls的一节有完整的使用方法,不过既然要写自己的理解,就一定写最简单最常用的.

其实就把这个东西当做是jquery的选择器来使用就好了,jquery的选择器的出现是因为dom节点非常多,需要通过一中好用的手段去选取自己要控制的节点,而saltstack的选择器也是出于同样的理由而被设计出来,那就是不同minion节点的选择,因为你可能要管理梦幻西游的服务器,梦幻西游的服务器少说也有好几千台吧,有了saltstack选择起来很容易了.

Saltstack的选择器根据文档来看大致分为2种,一中是基于 Compound Matcher,另一种是基于 Node groups的, 其实按笔者的角度来看,其实只有一种,那就是前者,后者只不过是按照前者提供的方法,分了一下组而已,把不同功能的minion分到不同的组,这样就不用每次用很长的正则去匹配 id或者grains了.

compound:

Letter    Match Type        Example
G Grains glob G@os:Ubuntu
E PCRE Minion ID E@web\d+\.(dev|qa|prod)\.loc
P Grains PCRE P@os:(RedHat|Fedora|CentOS)
L List of minions L@minion1.example.com,minion3.domain.com or bl*.domain.com
I Pillar glob I@pdata:foobar
S Subnet/IP address S@192.168.1.0/24 or S@192.168.1.100
R Range cluster R@%foo.bar

上方的表格出自官方文档,有了第一次的使用经验( sudo salt -G 'env:test' test.ping) 理解起来就很容易了,而且这么多匹配方式还支持混用,也支持 and not or 之类的逻辑运算,就像nginx的配置文件一样灵活。

    sudo salt -C 'G@env:dev and G@cpu_nums:8 and E@tokyo* and P@os:(CentOS)'

上面的复杂表达式虽然很长,但是一眼就可以看懂,无需多说,只是对于正则的使用是一个难关.

Node groups:

这个分组配置在 master 的配置文件里,具体的写法可以参考 这里, 简单配置之后就可以使用,没有太多需要注意的地方.


SLS文件的编译

这个结果也是读官方文档之后得出的,而且有一个ISSUE,这里并不解释如何使用jinja2模板引擎来编译sls文件,而是要说明sls文件的定义顺序对环境变量的影响,在前面的配置中已经看到了,在每个环境的目录下都可以配置top.sls文件来定义自己的配置,而且每个环境的top.sls只定义了自己的配置,也就是说base/top.sls只配置了base,没有配置其他的,而当base目录下没有top.sls的时候(或者是没有base的section),那么就按照字母表的顺序去查找其他的其中含有base section的top.sls, 这是一种容错策略,也是加强配置灵活性的方法,这个例子可以见文档,笔者这里只说自己的理解,尽量避免复制代码.

base/top.sls文件比较特殊(其实并不特殊),因为一般情况下base的目标是所有的minion,而且在base/top.sls中也是可以配置其他环境的section的,这里有一点就是说,当在base/top.sls 发现dev的section之后,那么这个环境就会使用base/top.sls中的dev的配置,而不管dev/top.sls中是否有自己的配置,换一种方法说就是base.sls是在第一时间被解析编译的,可以通过读代码去验证,不过这是学会使用之后的事情了.(其实在ISSUE存在的情况下,上面的一段话是错误的,具体可以hack代码)

对于除base/top.sls之外的其他环境的top.sls, 也遵循与base/top.sls相同的策略,自己的top.sls不存在自己section的,按照字母表顺序去查找其他包含自己section的top.sls,找到之后就使用这个section作为自己的环境.

最后关于ISSUE,该ISSUE目前还没有关闭,表明该bug目前仍然存在,不过这里会说一个安全方法,不过安全方法也是有安全前提的,因为安全方法不一定符合你的使用需求.

作者的意思是,他的 base , qa ,dev, master 环境,每一个环境都有自己的一个top.sls,而且这个top.sls是同一个文件,但是这个top.sls的内容不是相同的,为什么呢?因为top.sls是在git中的不同版本,所以是同一个文件,但是内容不同,由于含有重复的配置,所以最后一个配置,覆盖了前面所有的配置,最后一个就是qa, 其实作者还有几句含糊的话让我看不明白,不过大致就是这样,避免的方法就是按照我说的,每个top.sls只做自己分内的事情,不要包含其他的section.

如果谁知道作者为什么使用不同版本的top.sls放在不同的目录中,请联系我


总结

完全基于自己的理解,基本上对SLS说明的比较清楚了,下一步可能会去debug该软件,或者按照实践去研究,不过我认为别人不一定能完全懂得我的意思,痛点几乎都找到了,下面就是看实践了,可能会开发一套基于saltstack的运维组件,毕竟是提供了api的.


参考链接

http://salt.readthedocs.org/en/latest/topics/tutorials/starting_states.html

http://salt.readthedocs.org/en/latest/ref/states/top.html#other-ways-of-targeting-minions

https://github.com/saltstack/salt/issues/12483#issuecomment-64181598

http://www.shencan.net/index.php/2013/08/21/saltstack-ui开发/