saltstack实战-8

      为了使系统上线后更块的初始化，我们需要在minion在master上注册完毕后，master感知到有新的minion加入了，就开始自动初始化这台新加入的minion客户端，大致需求就是这样的

saltstack有个reactor系统，reactor系统是一个能够允许event触发动作的逻辑引擎，reactor系统结合sls文件在master端去匹配event tags，为这些sls文件定义匹配到events的具体反应。这样需要在master的配置文件中定义reactor配置，把遇到的tags和sls文件进行关联，这些sls文件使用highdata去定义哪些反应应该执行。reactor系统中使用和state系统同样的数据结构和编译程序，唯一不同的是数据使用的是salt command API和runner系统。command API通俗的说就是在命令行执行的那些东西，在命令行可以执行的都可以写在sls文件中。

我们来看看一个具体的例子：一个处于192.168.*网段的机器要加入集群，需要master自动接收key，并且自动同步grains

master配置文件目录增加reactor配置/etc/salt/master.d/reactor.conf：

reactor:
  - 'salt/auth':
    - /srv/reactor/auth.sls
  - 'salt/minion/*/start':
    - '/srv/reactor/start.sls'
  - 'minion_start':
    - '/srv/reactor/sync_grains.sls'

/srv/reactor/auth.sls

{% if not data['result'] and data['id'].startswith('192.168') %}
minion_remove:
  wheel.key.delete:
    - match: {{ data['id'] }}
minion_rejoin:
  local.cmd.run:
    - tgt: 192.168.1.203
    - arg:
      - ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "{{ data['id'] }}" 'sleep 10 && /etc/init.d/salt-minion restart'
{% endif %}

{% if 'act' in data and data['act'] == 'pend' and data['id'].startswith('192.168') %}
minion_add:
  wheel.key.accept:
    - match: {{ data['id'] }}
{% endif %}

/srv/reactor/start.sls

highstate_run:
  local.state.highstate:
    - tgt: {{ data['id'] }}
    - ret: mysql

/srv/reactor/sync_grains.sls

sync_grains:
  local.saltutil.sync_grains:
    - tgt: {{ data['id'] }}

实战到现在还没有提及过saltstack的job管理功能，比如我想要定时执行某些任务或者定时同步一些配置文件呢？

salt可以在很多系统中运行job，所以salt就需要能管理这些在多个系统中运行的job。在salt的minion中维护了一个proc目录，是通过cachedir配置项设置的，默认是在/var/cache/salt/proc，这个proc目录维护着已经执行过的job id的命名文件，这些文件包含了当前正在minion上运行的job信息。

saltutil增加了几个用于管理任务的方法，这些方法是：

1  running 返回在proc目录下找到的正在运行的job
2  find_job 返回指定job id的信息
3  signal_jon 给指定的job id发送一个信号
4  term_job 发送term信号给指定的job
5  kill_job 发送kill信号给指定的job

runner可以在前端方便的管理job，runner可以方便的查看数据，通过runner管理job方法如下：

jobs.active 返回当前系统正在运行的job
lookup_jid 执行后的结果返回给master，并在本地缓存24小时，时间可配置，可以通过指定job id来查看当job当时执行完毕后的返回结果
list_job 返回当前本地所缓存的所有job数据

Scheduling job

job调度系统通过在master或者minion的配置文件中设置schedule配置项来进行配置，或者通过指定pillar数据来实现，如果要通过pillar数据来实施，则只需要刷新minion的pillar数据，不论是在master还是在minion上配置，都需要重启应用使配置生效。调度器在master和minion上执行不同的函数，在master上函数调用runner函数，在minion上时函数指定要运行的函数。调度在minion上运行的时候没有输出结果，除非你在配置文件中进行日志信息配置。设置maxrunning参数来设置，某个任务最多执行的次数限制，默认为1。

在minion上执行sates，和其他所有的states一样，也是采用yaml格式来定义的，下面来看看几个例子：

1

schedule:
  job1:
    function: state.sls
    seconds: 3600
    args:
      - httpd
    kwargs:
      test: True
    splay:
      start: 10
      end: 15

2

schedule:
  job1:
    function: state.sls
    args:
      - httpd
    kwargs:
      test: True
    when:
        - Monday 5:00pm
        - Tuesday 3:00pm
        - Wednesday 5:00pm
        - Thursday 3:00pm
        - Friday 5:00pm

3

schedule:
  job1:
    function: state.sls
    seconds: 3600
    args:
      - httpd
    kwargs:
      test: True
    range:
        start: 8:00am
        end: 5:00pm

4    states

schedule:
  log-loadavg:
    function: cmd.run
    seconds: 3660
    args:
      - 'logger -t salt < /proc/loadavg'
    kwargs:
      stateful: False
      shell: \bin\sh

5    highstates

schedule:
  highstate:
    function: state.highstate
    minutes: 60

6    runners

schedule:
  overstate:
    function: state.over
    seconds: 35
    minutes: 30
    hours: 3

7    returnner

schedule:
  uptime:
    function: status.uptime
    seconds: 60
    returner: mysql
  meminfo:
    function: status.meminfo
    minutes: 5
    returner: mysql