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定义了环境,如下:

# 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应该处于哪种状态,如下:

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

状态描述文件

<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:

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这个包处于安装状态。

vim:
  pkg:
    -installed

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文件:

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的配置文件。

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

等价于

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的意思。

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

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声明可以简化配置,复用指定状态的配置。例如:

/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

等价于 

/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等功能,对状态文件进行编程,动态生成状态文件。

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

 

posted @ 2013-12-05 00:20 杨雨_AlexYang 阅读(...) 评论(...) 编辑 收藏