Salt状态管理

Salt状态管理

 

前言

上一篇文章概括性的介绍了Salt的用途和它的基本组成和实现原理，也深入的的介绍了Salt的命令编排和批量执行，但是对于状态管理只是简单的介绍了一下，因为状态管理是一个比较重要且常用的功能，单独的介绍状态管理会比较适合。本文将会首先介绍Salt状态管理的一些概念，然后会通过实例来演示Salt状态管理的使用，实例的演示基于Vagrant和Vagrant的Salt插件。

Salt状态管理的关键概念

状态树

在Salt中，所有的状态都是通过状态描述文件来定义的，而它们都存储在master节点（masterless情况除外）。Salt通过状态树定义了不同'环境'下状态描述文件的层次结构。如下图：

如上图所示，状态树由的根节点是master的配置文件/etc/salt/master，它通过'file_roots'配置项定义了不同环境下配置文件所存在的目录。‘环境’这个概念的主要是用于分门别类的存放不同用途的状态描述文件。例如，一个公司的服务器集群通常有不同的用途，大部分机器是用于线上环境，但是也还有一部分机器用于开发和测试。因为机器的用途不同，所以他们除了一些基础配置相同外，大部分配置是大相径庭的。Salt考虑到了这一点，他通过’环境‘将不同用途的状态描述文件隔离在不同的目录，然后通过base环境下的'top.sls'文件描述该环境下哪些minion应该处于哪种状态。base环境是默认的基础环境，它可以用于存放一些基础的状态描述文件，如每个机器都需要的ldap、ntp、监控等。其它环境的定义是可以按自己的需要自定义的，如上图，通常可以定义dev，qa和prod环境分别代表开发、测试和生产环境。

salt-master配置文件中的file_roots定义了环境，如下：

1 2 3 4 5 6 7 8 9 10

# Master file_roots configuration: file_roots:   base:     - /srv/salt/base   dev:     - /srv/salt/dev   qa:     - /srv/salt/qa   prod:     - /srv/salt/prod

base环境下的'top.sls'文件描述该环境下哪些minion应该处于哪种状态，如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

base:   '*':     - global dev:   'webserver*dev*':     - webserver   'db*dev*':     - db qa:   'webserver*qa*':     - webserver   'db*qa*':     - db prod:   'webserver*prod*':     - webserver   'db*prod*':     - db

如上，集群中所有的minions都会使用/srv/salt/base/global.sls定义的状态；fqdn匹配'webserver*dev*'的minions的会使用/srv/salt/dev/webserver.sls所定义的状态，其它类似。Salt仍然是使用Targeting的功能来选取节点，所以选取的方式有很多种。

Salt中状态树拓扑结构的定义由salt-master配置文件中的'file_roots'和base环境下的top.sls文件组成。状态的具体定义是由存储在这些目录下的sls文件描述。

关于状态树的更多信息，请阅读：http://salt.readthedocs.org/en/latest/ref/states/top.html

状态描述文件

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

<Include Declaration>:   - <Module Reference>   - <Module Reference>   <Extend Declaration>:   <ID Declaration>:     [<overrides>]     # standard declaration   <ID Declaration>:   <State Declaration>:     - <Function>     - <Function Arg>     - <Function Arg>     - <Function Arg>     - <Name>: <name>     - <Requisite Declaration>:       - <Requisite Reference>       - <Requisite Reference>     # inline function and names   <ID Declaration>:   <State Declaration>.<Function>:     - <Function Arg>     - <Function Arg>     - <Function Arg>     - <Names>:       - <name>       - <name>       - <name>     - <Requisite Declaration>:       - <Requisite Reference>       - <Requisite Reference>     # multiple states for single id   <ID Declaration>:   <State Declaration>:     - <Function>     - <Function Arg>     - <Name>: <name>     - <Requisite Declaration>:       - <Requisite Reference>   <State Declaration>:     - <Function>     - <Function Arg>     - <Names>:       - <name>       - <name>     - <Requisite Declaration>:       - <Requisite Reference>

上表给出了一个比较完整的状态描述文件的结构，这是用yaml格式来描述的。Yaml格式和jinja2模板是Salt默认提供的状态文件描述格式，同时Salt也支持不同类型的描述文件，他们通过Render模块支持，例如xml等。在此，我们以默认的yaml格式进行介绍。

我们先看一个实际的例子，example.sls：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

vim:　　　　　　　　　　<ID Declaration>   pkg:　　　　　　　　　<State Declaration>     - installed　　　　<Function>   salt:　　　　　　　　　　<ID Declaration>   pkg:　　　　　　　　　　<State Declaration>     - latest　　　　　　　<Function>   service.running:　　　　<State Declaration>.<Function>     - require:　　　　　　　　　　　　<Requisite Declaration>       - file: /etc/salt/minion　　　<Requisite Reference>       - pkg: salt　　　　　　　　　　　<Requisite Reference>     - names:　　　　　　　　　　　　　　<Names>       - salt-master　　　　　　　　　　　　<Name>       - salt-minion　　　　　　　　　　　　<Name>     - watch:　　　　　　　　　　　　　　<Requisite Declaration>       - file: /etc/salt/minion　　　 <Requisite Reference>   /etc/salt/minion:　　　　　　　　　　　　<ID Declaration>   file.managed:　　　　　　　　　　　　　　<State Declaration>.<Function>     - source: salt://salt/minion　　　　<Function Arg>     - user: root　　　　　　　　　　　　　<Function Arg>     - group: root　　　　　　　　　　　　<Function Arg>     - mode: 644　　　　　　　　　　　　　　<Function Arg>     - require:　　　　　　　　　　　　　　　<Requisite Declaration>       - pkg: salt　　　　　　　　　　　　　　<Requisite Reference>

<ID Declaration>ID声明

在这个例子中首先通过<ID Declaration>定义了三个状态描述模块，他们分别是vim，salt和/etc/salt/minion。在<ID Declaration>下包含了<State Declaration><Function>等定义，这些定义具体描述了vim, salt和/etc/salt/minion这三个模块具体是由哪些状态组件组成，使用了状态组件的哪些功能和具体的参数，它们之间的依赖关系是什么。同时，如果<State Declaration>下没有定义<Name Declaration>或<Names Declaration>那么<ID Declaration>将会默认成为<State Declaration>下的Name参数。就如同下面两个状态描述是等价的，他们都定义了使用pkg这个状态组件将vim这个包处于安装状态。

1 2 3

vim:   pkg:     -installed

和

1 2 3 4

editor:   pkg:     - installed     - name: vim

<ID Declaration>在整个状态树中必须是单一的，它是其它状态描述模块引用它的Key。如果在状态树中出现两个同名的<ID Declaration>，Salt只会识别第一个被加载的状态定义模块。

<Name Declaration>和<Names Declaration>声明

<Name Declaration>和<Names Declaration>都定义在<State Declaration>下，可以把它们看作是State下某个Function的参数，其中<Names Declaration>就是一个参数数组。如在salt中的service状态模块的描述中，就使用salt-mastre和salt-minion作为<Names Declaration>，定义了这两个服务处于安装状态。

这两个声明的使用可以解决一些实际中的问题，如避免ID冲突，缩短ID声明等，可参考：

http://salt.readthedocs.org/en/latest/ref/states/highstate.html#name-declaration

http://salt.readthedocs.org/en/latest/ref/states/highstate.html#names-declaration

<State Declaration>状态声明

状态声明下包含了功能<Function>、功能参数<Function Arg>、Name、Names和表示状态之间的关系的声明<Requisite Declaration>（状态之间的关系在后面一节介绍）。

其实从状态声明的数据结构，并结合上一篇文章说讲到的命令编排来看，我们可以隐约的察觉出salt的状态管理其实也是使用了由minions所提供的不同状态组件，就如同命令编排中不同的module。在状态描述文件中，通过使用<State Declaration>和<Function>指定了使用状态组件的某个函数，并将Function Arg, Name和Names传递到该函数执行。所以这也验证了Salt本质上是一个可批量执行的远程命令编排系统，它的其它扩展功能，包括状态管理也是基于这样一个系统构建。

Salt提供了这丰富的状态组件用于实现状态管理，如常见的包管理、服务管理、文件管理等，参考:http://docs.saltstack.com/ref/states/all/index.html

如本例中salt和vim模块都使用了pkg组件，并分别使用了latest和installed函数，这些我们都可以在该组件的文档中找到：

http://docs.saltstack.com/ref/states/all/salt.states.pkg.html#salt.states.pkg.installed

http://docs.saltstack.com/ref/states/all/salt.states.pkg.html#salt.states.pkg.latest

从文档的描述，我们可以知道installed函数保证了包处于安装状态，latest函数确保了包处于安装状态并且是最新的。

在知晓工作原理的前提下，我们可以很轻松的通过文档学习状态管理的使用，并且能自定义的扩展状态组件。

状态之间的关系

在Salt中，<Include Declaration>可以用于应用引用位于其它.sls文件下的<ID Declaration>，就如同c语言的inlcude语句一样。例如位于base环境中的一个sls文件：

1 2 3 4 5 6 7 8 9 10 11 12

include:   - apache　　　　# include /srv/salt/base/apache.sls   extend:   apache:　　　　　# extend the descrpition of apache     service:       - watch:         - file: mywebsite   mywebsite:   file:     - managed

这个文件首先用<Include Declaration>引用了apache这个状态文件，因为是位于base环境，所以实际引用的是/srv/salt/base/apache.sls文件。如果apache.sls文件位于/sav/salt/base/web/apache.sls，那么在include时应该指明是web.apache.

extend语句对apache的定义进行了扩展（apache.sls中已经对apache进行了定义），这个功能相当于c++中子类对父类进行扩展。

在这只要明确如果需要引用位于其它sls文件中的<ID Declaration>就必须先用include文件引用该sls文件。

除此之外，Salt还提供了7种<Requisite Declaration>，用于实现状态之间的依赖，它们分别是require, require_in, watch, watch_in, prereq, prereq_in, use。

require, require_in

require声明了本状态依赖于指定的状态，require_in声明了本状态被指定状态依赖。A require B <=> B require_in A。通过require指令，我们就可以指定一个状态收敛的顺序，如先安装vim再配置vim的配置文件。

1 2 3 4 5 6 7 8

vim:   pkg.installed   /etc/vimrc:   file.managed:     - source: salt://edit/vimrc　　# get from master's file server:/srv/salt/[env]/edit/vimrc     - require:       - pkg: vim

等价于

1 2 3 4 5 6 7 8

vim:   pkg.installed:     - require_in:       - file: /etc/vimrc   /etc/vimrc:   file.managed:     - source: salt://edit/vimrc

watch, watch_in

watch和watch_in是require和require_in的扩展，唯一的区别是watch和watch_in会额外的调用状态组件中的mod_watch函数，如果状态组件没有提供该函数，那么它和require, require_in的行为完全一样。

如本节的第一个例子，通过include apache并扩展了对apache的定义，将service.runing的watch设置成了mywebsite。那么，mywebsite状态的改变将触发调用service的mod_watch函数，重启apache服务。

prereq, prereq_in

prereq, prereq_in同样是指明了本状态的执行依赖于指定的状态。但是与require不同的地方是，当A require B，那么状态的收敛顺序是，先B后A，如果B失败，A不会执行；当A prereq B时，系统先会用（test＝True）去测试B状态是否会改变（B过程并未实际执行），如果B状态会改变，那么先执行A状态，再执行B状态，如果A执行失败，那么B就不执行了。prereq就是pre request的意思。

这两个声明通常用于分布式服务中，部署升级时先将服务从负载均衡中摘除，在进行代码升级。例如：

1 2 3 4 5 6 7 8 9 10

graceful-down:   cmd.run:     - name: service apache graceful     - prereq:       - file: site-code   site-code:   file.recurse:     - name: /opt/site_code     - source: salt://site/code

当通过salt master代用更新了/opt/site_code下的代码文件时，salt-minion上的file组件会先对比本地的代码文件是否与master上的不一致，如果不一致说明site-code这个状态会变化，那么先执行graceful-down这个状态，apache在服务完当前的请求后会shutdown，如果前端的负载均衡器有心跳包检查机制，会自动将请求分发到其它的节点。这时在实际执行更新代码的操作，从master上的file server下载最新的site-code文件。

use

use声明可以简化配置，复用指定状态的配置。例如：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/etc/foo.conf:   file.managed:     - source: salt://foo.conf     - template: jinja     - mkdirs: True     - user: apache     - group: apache     - mode: 755   /etc/bar.conf   file.managed:     - source: salt://bar.conf     - use:       - file: /etc/foo.conf

等价于

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

/etc/foo.conf:   file.managed:     - source: salt://foo.conf     - template: jinja     - mkdirs: True     - user: apache     - group: apache     - mode: 755   /etc/bar.conf   file.managed:     - source: salt://bar.conf     - template: jinja     - mkdirs: True     - user: apache     - group: apache     - mode: 755

用模板动态生成的状态文件

Salt除了可以静态地描述状态文件，同时还支持动态生成的状态文件，使用者可以通过Jinja2模板并结合Grains或Pillar等功能，对状态文件进行编程，动态生成状态文件。

1 2 3 4 5 6 7

apache:   pkg.installed:     {% if grains['os'] == 'RedHat' %}     - name: httpd     {% elif grains['os'] == 'Ubuntu' %}     - name: apache2     {% endif %}

通过Grains提供的操作系统信息动态的指定pkg组件使用apache2或httpd安装包。

更详细内容请参考：

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

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

状态收敛的运行过程

Salt的状态管理由state模块完成，一个命令'salt '*' state.highstate'就会触发所有的minions进行状态收敛。整个过程大致如下：

1. master通过命令'salt [Targeting] state.highstate'调用指定的minions的state模块的highstate函数；
2. minion的state模块访问master的file server，通过top.sls的定义，file server会将minion所属环境下的状态文件和静态文件传输给minion;
3. minion对状态文件进行编译，从highdata到lowdata，生成了具体的状态收敛顺序；
4. minion中的state模块根据状态收敛的顺序执行该状态说指定的状态组件，如pkg, service, file等；
5. minion中的state将执行结果返回给master；

实例：使用Vagrant和Salt配置开发环境

需求

• 单节点
• 安装vim并从git仓库中拉取配置文件
• 使用ubuntu 12.04 64位操作系统
• 整个过程全部自动化

实现步骤

1. 安装virtualbox和vagrant；
2. 安装vagrant-salt插件，'$vagrant plugin install vagrant-salt'；
3. 参考salty-vagrant的手册，编写Vagrant配置文件；
4. 参考本文内容编写Salt的配置文件；
5. 运行'$vagrant up'构建开发环境；

全部文件：https://github.com/AlexYangYu/example-vagrant-salt

 

 

分类: 运维和自动化