SaltStack(四)配置管理之程序员视角

搞定了当前需求并不是终点,匆匆茫茫出来的往往是半成品,努努力就可能做的更好.毕竟你我不是linus那类的天才.而且当看到一份sls文件,各种高级的魔法固然让人印象深刻,但如果没有可读性,可移植性只有奇葩愿意费力去啃.本文记录下个人使用salt的一点经验.

1. 关于可读性

sls文件最好使用yaml格式,理由就是yaml的可读性非常好.

2. 关于模块化

• include include一个common的sls,类似c的#include ...
• extend 用于做扩展,将一个基础的规则做扩展,而不用重新写一个功能

include和extend将编写salt通用库或者common instances变成可能.

任务进行逻辑分解, 例如安装一个软件或服务,往往可以抽象成一下部分:

• 准备工作 prepare stage. 做一些前置准备工作,比如要安装一些网络软件,但是需要先配置内核的网络转发功能.
• 安装软件包 install pkgs stage.
• 配置拷贝 config stage 用指定的配置文件覆盖默认配置,这一步一定要在install stage之后
• watch config stage 这个阶段主要是watch config files,告诉salt,哪些配置文件改变会需要服务重启
• post stage 这个阶段常常做一些现场清理.比如删除无用的文件等.我常常在这个阶段将各个服务重启一下

很多时候不需要这么复杂的,可能只需要install && config.但是再复杂的任务也能分解成以上步骤.这样心里就有个架子,编写的sls文件会很清晰.

任务逻辑理清楚后,有个重要问题就是如何保证执行顺序?看一下规则:

• 如果没有特殊指定,写在前面的先执行
• require指定依赖. 如果A require B,自然B先于A
• 可是手动指定order.
  • 如果order被指定了,那么执行顺序高于没有指定的(也就是需要系统自己判定顺序的).这个非常不推荐,原因是人为参与太多,累,而且局面会失控
  • 如果order为last, 那么执行顺序为最后.post stage的任务倒是可以直接指定order: last

3. 关于可移植性

写一次部署,不是完成当前任务就ok了,最好能再进一步,考虑的再全一些,让配置灵活一些,例如可以指定变量,而不是每次都需要修改配置模板.salt在这方面提供的基石:

• 渲染器,就是配置模板,支持jinjia语言.可编程啊!
• 灵活的数据获取方式. jinjia提供的是逻辑控制,但是你没有数据,啥都白扯
  • pillar pillar是master定义的数据.master可以控制下发到哪些minion.实现了选择式数据可见.这样能保护数据安全
  • grains grains是minion的数据.什么系统版本信息,ip地址,主机名等.更多的时候grains用于环境区分.这样就可以写出非常灵活的模板
  • salt moudle 在jinjia内可以直接调用salt moudle,这样就可以为所欲为了.

任务开始的时候,不要考虑得过于完美,这样进度就会很慢,甚至停滞不前."跑起来,看看他怎么样?是否能完成任务?"然后在一步一步的去改善.软件世界的好处就是我们可以让我们的孩子轻松的重生,直到满意.工程师需要实效主义,把东西做出来,实实在在的跑起来,这是工程师.在那哇啦哇啦的吹,结果什么也看不到,专家到处都是.但是东西做出来之后就需要完美主义,一个很小的功能,可能最后催生出一个巨大的项目来.

变更记录