七天学会SALTSTACK自动化运维 (3)
七天学会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
我的配置文件中有３个环境，不同的环境对应不同的环境配置目录，目录在 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的选择器根据文档来看大致分为２种，一中是基于 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
