salt常用命令、模块、执行

zoukankan html css js c++ java

salt常用命令、模块、执行
一、salt常用命令
1. salt 该命令执行salt的执行模块，通常在master端运行，也是我们最常用到的命令
  
  salt [options] '<target>' <function> [arguments] 如: salt '*' test.ping
2. salt-run 该命令执行runner(salt带的或者自定义的，runner以后会讲)，通常在master端执行，比如经常用到的manage
  
  salt-run [options] [runner.func] salt-run manage.status ##查看所有minion状态 salt-run manage.down ##查看所有没在线minion salt-run manged.up ##查看所有在线minion
3. salt-key 密钥管理，通常在master端执行
  
  salt-key [options] salt-key -L ##查看所有minion-key salt-key -a <key-name> ##接受某个minion-key salt-key -d <key-name> ##删除某个minion-key salt-key -A ##接受所有的minion-key salt-key -D ##删除所有的minion-key
4. salt-call 该命令通常在minion上执行，minion自己执行可执行模块，不是通过master下发job
  
  salt-call [options] <function> [arguments] salt-call test.ping ##自己执行test.ping命令 salt-call cmd.run 'ifconfig' ##自己执行cmd.run函数
5. salt-cp 分发文件到minion上,不支持目录分发，通常在master运行
  
  salt-cp [options] '<target>' SOURCE DEST salt-cp '*' testfile.html /tmp salt-cp 'test*' index.html /tmp/a.html
6. salt-ssh 0.17.1版本加入的salt-ssh
7. salt-master master运行命令
  
  salt-master [options] salt-master ##前台运行master salt-master -d ##后台运行master salt-master -l debug ##前台debug输出
8. salt-minion minion运行命令
  
  salt-minion [options] salt-minion ##前台运行 salt-minion -d ##后台运行 salt-minion -l debug ##前台debug输出
9. salt-syndic syndic是salt的代理，以后会说到
二、普通用户执行salt

普通用户执行salt两种方案:1,salt ACL 2.salt external_auth

1.ACL

1) 设置master配置文件
```
    client_acl:
    monitor:
     - test*:
    - test.*
    dev:
     - service.*
    sa:
     - .*
```
2) 重启Master
```
service salt-master restart
```
3) 目录和文件权限
```
chmod +r /etc/salt/master
chmod +x /var/run/salt
chmod +x /var/cache/salt
```
4) 测试
```
# su - monitor
# salt 'test*' test.ping
# exit; su - sa
# salt '*' test.ping
# salt '*' cmd.run 'uptime'
# exit;
```
2.external_auth

1) 修改master配置文件
```
 external_auth:
```
pam: monitor: – ‘test‘: – test. sa: – .* – 2) 3)与ACL相同

4) 测试
```
 # salt -a pam 'test*' test.ping    ##会提示输入账号密码，所以external_auth与当前用户无关
   username: monitor
       password:
 # su - monitor
 # salt -a pam '*' cmd.run 'uptime'
username: sa
password:
```
5) 使用Token不必每次都输入账号密码，使用external_auth每次都是需要密码的，这样多麻烦，这里引入了Token，它会保存一串字符到在当前用户家目录下.salt_token中，在有效时间内使用external_auth是不需要输入密码的，默认时间12hour，可以通过master配置文件修改
```
 # salt -T -a pam '*' test.ping
```
username: sa

password:
```
#salt -a pam '*' test.ping #不会提示输入密码了
```
三、target

指定你的命令或者模块应用哪写Minion上

1.globbing 默认
```
salt 'test*' test.ping
```
2.RE 正则
```
salt -E 'web1-(pro|devel)' test.ping
```
3.List 列表
```
salt -L '127.0.0.1, test*' test.ping
```
4.grains
```
salt -G 'os:CentOS' test.ping

#查看所有grains键/值
salt 'test*' grains.items
#查看所有grains项
salt 'test*' grains.ls
查看某个grains的值
salt 'test*' grains.item num_cpus
```
在top file中匹配grains
```
'node_type:web':
  - match: grain         #没有s
  - webserver
```
top file中使用jinja模板
```
{% set self = grains['node_type'] %}
    - match: grain
- {{ self }}
```
5.nodegroups 其实就是对Minion分组

首先在master的配置文件中对其分组,推荐写到/etc/salt/master.d/中一个独立的配置文件中，比如nodegroup.conf
```
vim /etc/salt/master.d/nodegroup.conf 
#写到master中也是这个格式，master.d中*.conf是默认动态加载的
nodegroups:
 test1: 'L@test1,test2 or test3*'
 test2: ‘G@os:CenOS or test2'

salt -N test1 test.ping                #-N指定groupname

在top file中使用nodegroups

'test1':
 - match: nodegroup                   ##意没s
 - webserver
```
6.混合指定,就是将以上的混合起来用
```
 G Grains glob G@os:Ubuntu
 E PCRE Minion ID E@webd+.(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

 salt -C 'G@os:CentOS and L@127.0.0.1,192.168.1.12' test.ping
```
top file 指定:
```
'webserver* and G:CentOS or L@127.0.0.1,test1':
   - match: compound
- webserver
```
7.一次在n个minion上执行
```
-b n
--batch-size n
示例：
salt '*' -b 5 test.ping 5个5个的ping
```
四、远程批量执行

格式：
```
salt '<target>' <function> [argument]
```
注： function是salt带的或自己写的可执行模块里面的function，自带的所有列表http://docs.saltstack.com/ref/modules/all/index.html?highlight=full%20list%20builtin 实例：
```
salt '*' at.at 10.10am 'uptime'
salt '*' test.ping
```
五、多Master

1.在另一台机器上安装salt-master
```
yum -y install salt-master
```
2.将原来master上的master密钥拷贝到新的master是一份
```
scp /etc/salt/pki/master/master* newmaster:/etc/salt/pki/master/
```
3.启动新的Master
```
service salt-master start
```
4.修改minion配置文件/etc/salt/minion设置两个master
```
 master:
   - master1
- master2
```
5.重启minion
```
service salt-minion restart
```
6.在新的master上接受所有key
```
salt-key -L
salt-key -A
```
注意:

1.2个master并不会共享Minion keys，一个master删除了一个key不会影响另一个

2.不会自动同步File_roots,所以需要手动去维护，如果用git就没问题了

3.不会自动同步Pillar_Roots，所以需要手工去维护，也可以用git

4.Master的配置文件也是独立的

六、pillar

Pillar在salt中是非常重要的组成部分，利用它可以完成很强大的功能，它可以指定一些信息到指定的minion上，不像grains一样是分发到所有Minion上的，它保存的数据可以是动态的,Pillar以sls来写的，格式是键值对

适用情景：

1.比较敏感的数据，比如密码，key等

2.特殊数据到特定Minion上

3.动态的内容

4.其他数据类型

查看Minion的Pillar信息
```
salt '*' pillar.items
```
查看某个Pillar值
```
salt '*' pillar.item <key>      #只能看到顶级的
salt '*' pillar.get <key>:<key> #可以取到更小粒度的
```
编写pillar数据

1.指定pillar_roots，默认是/srv/pillar(可通过修改master配置文件修改),建立目录
```
mkdir /srv/pillar
cd /srv/pillar
```
2.编辑一个pillar数据文件
```
vim test1.sls
name: 'salt'
 users:
   hadoop: 1000
redhat: 2000
ubuntu: 2001
```
3.建立top file指定minion到pillar数据文件
```
 vim top.sls
 base:
   '*':
     - test1
```
4.刷新Pillar数据
```
salt '*' saltutil.refresh_pillar
```
5.测试
```
salt '*' pillar.get name
salt '*' pillar.item name
```
在state中通过jinja使用pillar数据
```
vim /srv/salt/user.sls
 {% for user, uid in pillar.get(’users’, {}).items() %}  ##pillar.get('users',{})可用pillar['users']代替，前者在没有得到值的情况下，赋默认值
 {{user}}:
   user.present:
     - uid: {{uid}}
 {% endfor %}
```
当然也可以不使用jinja模板
```
vim /srv/salt/user2.sls
{{ pillar.get('name','') }}:
 user.present:
   - uid: 2002
```
通过jinja模板配合grains指定pillar数据
```
/srv/pillar/pkg.sls

pkgs:
 {% if grains[’os_family’] == ’RedHat’ %}
 apache: httpd
 vim: vim-enhanced
 {% elif grains[’os_family’] == ’Debian’ %}
 apache: apache2
 vim: vim
 {% elif grains[’os’] == ’Arch’ %}
 apache: apache
 vim: vim
 {% endif %}
```
七、grains

服务器的一些静态信息，这里强调的是静态，就是不会变的东西，比如说os是centos，如果不会变化，除非重新安装系统

定义minion的grains可以写在/etc/salt/minion中格式如下
```
grains:
 roles:
   - webserver
   - memcache
 deployment: datacenter4
 cabinet: 13
 cab_u: 14-15
```
或者写在/etc/salt/grains中，格式如下
```
roles:
 - webserver
 - memcache
deployment: datacenter4
cabinet: 13
cab_u: 14-15
```
也可以在master中编写grains的模块，同步到minion中，用Python来写很简单的

1.在/srv/salt中建立_grains目录
```
mkdir /srv/salt/_grains
```
2.编写grains文件，需要返回一个字典
```
 vim test1.py
 def hello():                      ##函数名字无所谓，应该是所有函数都会运行
   agrain = {}
   agrain['hello'] = 'saltstack'
return agrain                   ##返回这个字典
```
3.同步到各个minion中去
```
salt '*' saltutil.sync_grains
salt '*' saltutil.sync_all
salt '*' state.highstate
```
4.验证
```
salt '*' grains.item hello
```
八、使用 salt state

它的核心是写sls(SaLt State file)文件,sls文件默认格式是YAML格式(以后会支持XML)，并默认使用jinja模板，YAML与XML类似，是一种简单的适合用来传输数据的格式，而jinja是根据django的模板语言发展而来的语言，简单并强大，支持for if 等循环判断。salt state主要用来描述系统，软性，服务，配置文件应该出于的状态，常常被称为配置管理！

通常state，pillar,top file会用sls文件来编写。state文件默认是放在/srv/salt中，它与你的master配置文件中的file_roots设置有关

示例： apache.sls文件内容 ##/srv/salt/apahce.sls，以后没有用绝对路径意思就是在/srv/salt下
```
apache:            ##state ID，全文件唯一,如果模块没跟-name默认用的ID作为-name
 pkg:             ##模块
   - installed    ##函数
  #- name: apache ##函数参数，可以省略
 service:         ##模块
   - running      ##函数
  #- name: apache ##函数参数，这个是省略的，也可以写上
   - require:     ##依赖系统
     - pkg: apache  ##表示依赖id为apache的pkg状态
```
下面来解释上面示例的意思：

声明一个叫apache的状态id,该id可以随意，最好能表示一定意思

pkg代表的是pkg模块

installed是pkg模块下的一个函数，描述的是状态，该函数表示apache是否部署，返回值为True或者False，为真时，表示状态OK，否则会去满足该状态(下载安装apache)，如果满足不了会提示error,在该模块上面省略了参数-name: apache,因为ID为apache,这些参数是模块函数需要的（可以去查看源码）

service是指的service模块，这个模块下主要是描述service状态的函数，running状态函数表示apache在运行，省略-name不在表述，-require表示依赖系统，依赖系统是state system的重要组成部分，在该处描述了apache服务的运行需要依赖apache软件的部署，这里就要牵涉到sls文件的执行，sls文件在salt中执行时无序(如果没有指定顺序，后面会讲到order)，假如先执行了service这个状态，它发现依赖pkg包的安装，会去先验证pkg的状态有没有满足，如果没有依赖关系的话，我们可以想象，如果没有安装apache，apache 的service肯定运行会失败的，我们来看看怎么执行这个sls文件:
```
salt '*' state.sls apache   
```
在命令行里这样执行就ok了，.sls不要写，如果在目录下，将目录与文件用’.’隔开，如： httpd/apache.sls –> httpd.apache

或者
```
salt '*' state.highstate 
```
这需要我们配置top file执定哪个minion应用哪个状态文件

top.sls内容
```
base:
 '*':
   - apache
```
下面我们继续看一些比较复杂的:

ssh/init.sls文件内容
```
openssh-client:
 pkg.installed
/etc/ssh/ssh_config:
 file.managed:
   - user: root
- group: root
- mode 644
- source: salt://ssh/ssh_config
- require:
 - pkg: openssh-client
```
ssh/server.sls文件内容
```
include:
 - ssh

openssh-server:
 pkg.installed

sshd:
 service.running:
   - require:
 - pkg: openssh-client
 - pkg: openssh-server
 - file: /etc/ssh/banner
 - file: /etc/ssh/sshd_config

/etc/ssh/sshd_config:
 file.managed:
   - user: root
- group: root
- mode: 644
- source: salt://ssh/sshd_config
- require:
 - pkg: openssh-server

/etc/ssh/banner:
 file:
   - managed
- user: root
- group: root
- mode: 644
- source: salt://ssh/banner
- require:
 - pkg: openssh-server
```
ssh/init.sls,学过Python的都知道目录下面的init文件是特殊文件，它怎么特殊呢，它特殊在当我们应用目录时会应用该文件的内容，如我们执行 salt ‘*’ state.sls ssh时应用的就是init.sls文件，明白了吗？再看里面的内容，前两行我们已经看过了，是描述某个rpm包有没有安装的，第三行是ID，也可以用来表示-name，以省略-name，file.managed是file模块与函数managed的快捷写法，看server.sls下最后就知道了，managed它描述了某个文件的状态，后面跟的是managed的参数，user,group,mode你们一看就知道什么意思了，关于这个source是指从哪下载源文件，salt://ssh/sshd_config是指的从salt的文件服务器里面下载，salt文件服务器其实就是file_roots默认/srv/salt/明白了吗，所以salt://ssh/sshd_config指的就是 /srv/salt/ssh/sshd_config,出来用salt的文件服务器，也可以用http,ftp服务器。- require是依赖系统不表，以后会详细说它的。再往下是server.sls文件，include表示包含意思，就是把ssh/init.sls直接包含进来

这时你会看到/srv/salt的目录树是:
```
ssh/init.sls
ssh/server.sls
ssh/banner
ssh/ssh_config
ssh/sshd_config
```
下面再来看一个官方样例：

ssh/custom-server.sls 文件内容
```
include:
 - ssh.server
extend:
 /etc/ssh/banner:
   file:
 - source: salt://ssh/custom-banner
```
python/mod_python.sls文件内容
```
include:
 - apache

extend:
 apache:
   service:
 - watch:
   - pkg: mod_python
```
首先我们include的别的文件，但是里面的内容并不是全部符合我们的要求，这时我们就需要用extend来重写部分内容，特殊的是依赖关系都是追加。custom-server.sls文件意思是包含ssh/server.sls,扩展/etc/ssh/banner，重新其source而其它的如user,group等不变，与include一致。 mode_python.sls文件意思是把apache.sls包含进来，想apache-service是追加了依赖关系(watch也是依赖系统的函数).

常用状态配置 salt-states-master.zip

九、关于渲染器render system

我们上面也提过salt默认的渲染器是yaml_jinja,salt处理我们的sls文件时，会先把文件用jinja2处理，然后传给ymal处理器在处理，然后生成的是salt需要的python数据类型。除了yaml_jinja还有yaml_mako,yaml_wempy,py,pydsl,我比较感兴趣的就是yaml_jinja,还有py，yaml_jinja是默认的，而py是用纯python来写的。下面来看个样例吧，

apache/init.sls文件内容
```
apache:
 pkg:installed:
   {% if grains['os'] == 'RedHat' %}
- name: httpd
{% endif %}
 service.running:
   {% if grains['os'] == 'Redhat' %}
- name: httpd
{% endif %}
- watch:
 - pkg: apache
```
这个样例很简单，就是加了个判断，如果Minion的grains的os是RedHat那么apache的包名是httpd，默认是apache,我们知道在别的Linux发行版上，如ubuntu，suse他们的apache的包名就是叫apache，而在redhat系上则叫httpd,所以才有了这个判断写法，下面的service也是如此。我们着重说语法，jinja中判断，循环等标签是放在{% %}中的，通常也会有结束标签{% end** %},而变量是放在 {{ }}中的，salt,grains,pillar是salt中jinja里面的三个特殊字典，salt是包含所有salt函数对象的字典，grains是包含minion上grains的字典，pillar是包含minion上pillar的字典。

示例：for user/init.sls文件内容
```
{% set users = ['jerry','tom','gaga'] %}
{% for user in users %}
{{ user }}:
 user.present:
   - shell: /bin/bash
   - home: /home/{{ user }}
{% endfor %}
```
示例；salt字典 user/init.sls文件内容
```
{% if salt['cmd.run']('uname -i') == 'x86_64' %}
hadoop:
 user.present:
   - shell: /bin/bash
   - home: /home/hadoop
{% elif salt['cmd.run']('uname -i') == 'i386' %}
openstack:
 user.present:
   - shell: /bin/bash
- home: /home/openstack
{% else %}
django:
 user.present:
   - shell: /sbin/nologin
{% endif %}
```
py渲染器说明:py渲染器是用纯python写的sls文件，它返回的数据与yaml_jinja经过jinja处理经过yaml处理后的数据类似，用其他渲染器需要在sls文件头行声明用的渲染器类型，#!py就是声明用的py渲染器,py中可用的变量有salt,grains,pillar,opts,env,sls,前三个分别对应jinja里的salt,grains,pillar,opts是minion的配置文件的字典，env对应的是环境如base,sls对应的是sls的文件名

示例： user/init.sls
```
#!py
import os
def run():
   '''add user hadoop'''
platform = os.popen('uname -a').read().strip()
if platform == 'x86_64':
   return {'hadoop': {'user': ['present',{'shell': '/bin/bash'}, {'home': '/home/hadoop'}]}}
elif platform == 'i386':
       return {'openstack': {'user': ['present', {'shell': '/bin/bash'}, {'home': '/home/openstack'}]}}
else:
   return {'django': {'user': ['present', {'shell': '/sbin/nologin'}]}}
```
说明: 首行声明了使用py作为渲染器，导入了os模块，声明run函数，py渲染sls文件是从run函数开始的，其它的就是python的语法了，注意的是return的数据结构{ID: {module: [func, arg1,arg2,...,]}} 或 {ID: {module.func: [arg1,arg2,..,]}} 。表示的内容与“示例；salt字典”表达的相同

十、state的执行顺序

以前我们说过，state的执行时无序，那个无序是指执行我们写的那个sls是无序的，正是因为那个无序，salt保证每次执行的顺序是一样的，就加入了state order，在说它之前看看High Data(高级数据？)和Low Data(低级数据？)，高级数据我理解的就是我们编写sls文件的数据，低级数据就是经过render和parser编译过的数据。

查看highdata
```
salt '*' state.show_highstate
```
查看lowdata
```
salt '*' state.show_lowstate
```
通过查看lowdata我们发现里面有一个字段order,因为salt默认会自动设置order，从10000开始。可以通过设置master配置文件参数state_auto_order: False来关闭

Order的设定：

1.include 被include的文件Order靠前，先执行

2.手动定义order字段，如
```
  apache:
    pkg:
  - installed
  - order: 1
 order的数字越小越先执行从1开始，-1是最后执行
```
3.依赖关系系统

十一、依赖关系系统requisite system

前面我们已经用过了依赖关系系统，就是定义状态与状态之间的依赖关系的，经常遇到的依赖系统的函数有’require’和’watch’和它们的变种’require_in’,’watch_in’,require和watch有什么区别吗？

1.不是所有的state都支持watch,比较常用的是service

2.watch定义的依赖条件发生变化时会执行一些动作，如当配置文件改变时，service会重启

示例: apache/init.sls文件内容
```
/etc/httpd/httpd.conf:
 file:
   - managed
- source: salt://httpd/httpd.conf
httpd:
 pkg:
   - installed
 service:
   - running
   - require:
     - pkg: httpd
   - watch:
     - file: /etc/httpd/httpd.conf            ##当httpd.conf改变时，重启httpd服务
```
require与require_in, watch与watch_in

require,watch是指依赖，require_in,watch_in是指被依赖

a reuire b 那么就是b require_in a

a watch b 那么就是b watch_in a

示例: apache/init.sls文件内容
```
/etc/httpd/httpd.conf:
 file:
   - managed
- source: salt://httpd/httpd.conf
- watch_in:
 - service: httpd
httpd:
 pkg:
   - installed
- require_in:
 - service: httpd
 service:
   - running
```
十二、salt state环境

针对不用环境，应用不同的state的file，salt支持多环境，比如开发，测试，生产等环境，我们通过修改Master配置文件对不同的环境应用不同的目录！
```
file_roots:
 base:
   - /srv/salt/prod   ##生产环境
 qa:
   - /srv/salt/qa     ##测试环境，如果没发现去prod里面找
- /srv/salt/prod
 dev:
   - /srv/salt/dev    ##开发环境，如果找不到，先去qa里找，如果找不到再去prod里面找
- /srv/salt/qa
- /srv/salt/prod
/srv/salt/prod/top.sls文件内容
base:
 'web*prod*':
   - webserver.foobarcom
qa:
 'web*qa*':
   - webserver.foobarcom
dev:
 'web*dev':
   - webserver.foobarcom
   - 
```
pillar的目录与file_roots无关，所以Pillar的目录默认还是/srv/salt，pillar只是Minion的一些信息，不会对系统有什么改变，所以不需要区分环境，通常base即可。

/srv/pillar/top.sls文件内容
```
base:
 'web*prod*':
   - webserver.prod
 'web*qa*':
   - webserver.qa
 'web*dev*':
   - webserver.dev
```
/srv/pillar/webserver/prod.sls文件内容
```
webserver_role: prod
```
/srv/pillar/webserver/qa.sls文件内容
```
webserver_role: qa
```
/srv/pillar/webserver/dev文件内容
```
webserver_root: dev
```
最后sls文件/srv/salt/prod/webserver/foobarcom.sls(该文件会被所有环境访问到)的内容：
```
{% if pillar.get('webserver_role', '') %}
/var/www/foobarcom:
 file.recurse:
   - source: salt://webserver/src/foobarcom
- env: {{ pillar['webserver_role'] }}
- user: www
- group: www
- dir_mode: 755
- file_mode: 644
{% endif %}
```
开发完成后，应用sls文件

1.现在开发环境

salt -I ‘webserver_role:dev’ state.sls webserver.foobarcom

十三、salt schedule

schedule是salt中的crontab，就是周期性执行一些函数，需要注意的是在minion上执行的函数是salt的可执行模块里的函数，在master上执行的是runner模块的函数，下面看看如何设置: master是修改master配置文件/etc/salt/master:
```
schedule:
 overstate:                    ##这个是ID，可以随意起，全文件唯一
   function: state.over        ##对于master，function就是runner
   seconds: 35                 ##间隔秒数
   minutes: 30                 ##间隔分数
   hours: 3                    ##间隔小时数
```
这时每隔3小时30分35秒，master就会运行一个state.over这个runner

minion的schedule定义有两种方式

1.通过修改minion的配置文件,这种方式需要修改所有Minion的配置文件略麻烦
```
schedule:
 highstate:
   function: state.highstate
seconds: 30
minutes: 5
hours: 1
```
2.为Minion指定pillar

/srv/pillar/schedule.sls文件内容
```
schedule:
 highstate:
   function: state.highstate
seconds: 30
minutes: 5
hours: 1
```
通过top file指定到Minion

/srv/pillar/top.sls文件内容
```
base:
 *:
   - schedule
```
十四、YAML语法风格

1.空格和Tabs

在YAML中不要使用Tab

2.缩进

YAML推荐缩进为2个空格，’:’,’-’后面缩进1个空格再写

3.数字会解析成数字

如mode: 0644会解析成mode: 644,可用’括住防止mode: ’0644′此情况

4.YAML不允许双简写

vim:
```
pkg.installed   ##第一个简写，单一个简写没问题
user.present    ##第二个简写，加上它是不支持的
```
不要偷懒写成下面这样吧。

vim: pkg：
- installed user: – present – 5.YAML只支持ASCII

其它字符集最好不要使用，如果非要使用用以下格式:
- micro: ‘u00b5′
6.下划线_将会被删除
```
date: 2013_05_13  --> date: 20130513
```
通过’括住防止出现该问题
```
date: '2013_05_13'  
```
十五、salt事件系统与反应系统 event and reacter system

我们知道Master与Minion是基于ZMQ通信的，他们通信我们看来是消息队列，对它们来说这些消息就是一些事件，什么事件应该做什么，是salt基本已经预设好了。我们学习它的事件系统来完成一些自定义的行为，后面的反应系统就是基于事件系统的。一条消息其实就是一个事件，事件通常是一个字典数据，这个字典数据通常包含tag,这个tag是用来区分用途过滤消息的，详见绿大-https://groups.google.com/forum/#!topic/saltstack-users-cn/wXVE4ydnnzc ,让我们来看看这些事件。

捕捉事件(listen event)

1.下载官方给的事件捕捉程序eventlisten

https://github.com/saltstack/salt/blob/develop/tests/eventlisten.py 打开网址，复制下载，不要直接wget

2.运行该程序
```
Master: python2.6 eventlisten.py                         ##捕捉master端的event直接运行即可
Minion: python2.6 eventlisten.py -n minion <minion-id>   ##捕捉minion端的需要额外参数，minion-id是该Minion的id
```
发送事件(fire event)

Master发给minion
```
salt '*' event.fire "{'data': 'some message'}" "tag"     ##前面必须是字符串包住的字典，后面是tag,如果你的minion在监听event，你会看到这条event的
```
Minion发给minion
```
salt-call event.fire_master 'some message' 'tag'  ##前面数据类型没有要求，后面是tag,去master那看看收到了没有
```
Minion发给自己
```
salt-call event.fire "{'data': 'some message'}" 'tag' ##前面必须是字符串包住的字典，后面是tag
```
用code来捕捉，并发送event

捕捉事件 Master:
```
# python2.6
>>> import salt.utils.event
>>> event = salt.utils.event.SaltEvent('master', '/var/run/salt/master')
##master表明是在master端监听，/var/run/salt/master是你master的sock_dir
>>> data = event.get_event()
>>> print(data)       ##查看内容
>>> data = event.get_event(wait=10, tag='auth') ##wait是指timeout时间，默认5s,用tag来过滤事件，可省略
>>> print(data)                
>>> for data in event.iter_events(tag='auth'):  ##用迭代器一直查看事件
>>>     print(data)
Minion:
#python2.6
>>> import salt.utils.event
>>> event = salt.utils.event.SaltEvent('minion', '/var/run/salt/minion',id='minion_id')
##minion代表是在minion端监听，/var/run/salt/minion是minion端的sock_dir,minion_id是该Minion的id
>>> data = event.get_event()
>>> print(data)
>>> for data in event.iter_events(tag='auth'):  ##用迭代器一直查看事件
>>>     print(data)
```
—————–先这样吧发送事件:
```
Master:
>>> import salt.utils.event
>>> event = salt.utils.event.SaltEvent('master', '/var/run/salt/minion')
>>> event.fire_event({'hello': 'world'}, 'hello')
```
—————–先这样

反应系统(reacter system)

反应系统是基于事件系统的，它的作用是当master收到来自minion的特殊事件后就触发某些动作，比如minion上线后发送一个init事件，master收到后，对其应用init的状态文件，minion没有反应系统，事情就是这样的。

配置reactor

1.修改master配置文件或者在/etc/salt/master.d/中建立reactor.conf,内容
```
reactor:
 - 'testtag':                    ##接收到的tag
   - /srv/reactor/start.sls
- /srv/reactor/monitor.sls
 - 'test1*tag':                  ##接收到的tag，支持通配符
   - /srv/reactor/other.sls
```
- 2.建立reactor响应sls文件
/srv/reacter/start.sls文件内容
```
{% if data['id'] == 'mysql1' %}
delete_file:
 cmd.cmd.run:
   - tgt: 'G@os:CentOS'
- expr_form: compound
- arg:
 - rm -rf /tmp/*
{% endif %}
```
/srv/reactor/other.sls文件内容
```
{% if data['data']['state'] == 'refresh' %}
overstate_run:
 runner.state.over
{% endif %}
```
下面来解释一下这两个文件，reacter的sls文件是支持jinja的，所以第一行是通过jinja来判断，reacter的sls支持两个变量data和tag, data是接受事件的那个字典，tag就是事件的tag，所以第一行的判断就很好理解了，第二行是id，可以随意起，第三行是要运行的执行模块或者runner，如果是执行模块，以cmd.开始，如果是runner则以runner.开始，可执行模块执行需要target，所以- tat:后面跟的就是可执行模块的target,- expr_form指的target的匹配方式，- arg是只执行模块函数的参数，runner一般不需要这些。所以第一个示例相当于执行了salt -C 'G@mysql1' cmd.run 'rm -rf /tmp/*' 第二个相当于执行了 salt-run state.over

十六、salt Mine

salt的用的词都太高明，像Grains,Pillar,Mine真心没一个合适的词去翻译，Mine是做什么的呢？Mine的作用是在静态数据和动态数据建立起一座桥梁(官方文档如是说),Mine从minon收集数据然后发送给Master，并缓存在Master端，所有Minion都可以轻易的共享到，Master通常会维护比较新的数据，如果需要维护长期数据，就要考虑retruner或外部的工作缓存了。 mine的出现是用来解决一定问题的. 在Salt的网络体系中,各个minion是毫无关系,相互独立的. 但是在实际应用中,minion之间其实是有一定关联的,比如一台机器需要获取到另一台机器的一些信息或者执行一些命令. 后来Salt加入了peer系统(http://docs.saltstack.com/ref/peer.html)使其成为可能. 但是peer系统每次使用的时候都会重新执行一遍, 显然很多不常变化的信息重复执行效率较低,性能开销较大. 所以就有了后来的mine(peer和mine的关系是我杜撰出来的,如有雷同,纯属巧合). mine系统存储在master端, minion想获取的时候, 通过mine.get获取下就可以了,简单方便

修改minion配置文件，配置Mine
```
mine_functions:
 network.interfaces: []
 test.ping: []
 mine_interval: 1
```
重启Minion，在master端测试
```
salt '*' mine_get '*' network.interfaces
salt '*' mine_get '*' test.ping
salt 'test1' mine_get '*' test.ping    ##查看test1上能得到mine数据
```
十七、salt ssh

从0.17.0开始salt加入salt ssh，salt ssh不需要在客户端安装salt-minion包了，是通过ssh协议来完成运城命令执行，状态管理等任务的。它是作为master-minion形式的补充出现的，原理是有一个花名册的文件，里面记录了各个minion的信息，ip,账号，密码，等，需要远程执行命令时，直接通过ssh来执行，速度与master-minion形式慢很多。

使用： 1.配置/etc/salt/roster格式如下
```
test1:
 host: 192.168.1.133
 user: salt
 passwd: redhat
 sudo: True
 port: 22
 timeout: 5
test2:
 host: 192.168.1.134
 user: root
 passwd: redhat
test3:
 host: 192.168.1.135
 user: sa
 sudo: True
```
说明: test1我们定义了所有常见的选项，test2我们用了超级用户，使用账号密码，test3我们使用普通用户，没有写密码，就是通过key来认证了，并且以sudo方式执行的，需要注意的是1.key认证用的是/etc/salt/pki/master/ssh/目录下的密钥。2.如果普通用户的话，需要有sudo权限，因为一些功能，包括test.ping都需要sudo权限。

测试:
```
 salt-ssh '*' test.ping
 salt-ssh '*' -r 'ls /'   ##执行shell命令
 salt-ssh '*' cmd.run 'ls /' ##用模块来执行也是可以的
 salt-ssh '*' state.sls   ##执行状态，state.sls在0.71.0中还存在bug,0.72.0中已解决
```
十八、Returners

默认所有minion返回的值都会发送到master端，我们可以看到，returner就是让Minion把返回的值发给其它地方，如redis,MySQL,或者一个文本下面我们来自定义一个returner：

1.建立自定义returner
```
mkdir -p /srv/salt/_returners;
vim mysql.py  ##就用官方给的例子吧，修改其中mysql的Host,user和pass
```
内容见https://github.com/saltstack/salt/blob/develop/salt/returners/mysql.py

2.建立需要的数据库

见https://github.com/saltstack/salt/blob/develop/salt/returners/mysql.py注释里的见表语句

3.授权其他主机用户可写该表
```
>grant all on salt.* to 'user_in_returner'@'%' identified by 'passwd_in_returner';
```
4.同步
```
salt '*' saltutil.sync_all      ##同步到minion上去
```
5.测试
```
salt '*' test.ping --return mysql    ##数据返回到mysql上去，打开mysql查看
```
十九、扩展salt

通过自定义各个模块来扩展salt，常见自定义模块有:

1.可执行模块 Execution Modules

如我们常用的cmd.run , test.ping这样的可执行模块

2.Grains

扩展grains，grains是一些静态信息，可能好多我们需要的没有，我们可以通过编写grains模块自定义grains

3.状态模块 State Module

如我们常用的pkg.install,file.managed

4.Returners

我们可以自定义returner，将返回的数据发送到其他存储，只要符合固定的格式就行了

5.Runner

Runner是在master端快速执行的模块，自定义很方便

二十、自定义可执行模块

所有可执行module见https://github.com/saltstack/salt/tree/develop/salt/modules，或http://docs.saltstack.com/ref/modules/all/index.html?highlight=full%20list%20builtin

1.建立自定义模块目录,通常所有自定义模块放在该目录下
```
mkdir /srv/salt/_modules
```
2.编写模块
```
vim test.py
-*- coding: utf-8 -*-
'''
support for yum of RedHat family!
'''
def __virtual__():
   '''
   Only RedHat family os can use it.
   '''
   if __grains__.get('os_family', 'unkown') == 'RedHat':
       return 'yum'
   else:
       return False


def install(rpm):
   cmd = 'yum -y install {0}'.format(rpm)
   ret = __salt__['cmd.run'](cmd)
   return ret
```
说明：__virtual__函数通常用来匹配是否满足该模块的环境，如果满足return出来的字符串作为该模块的名字而不是文件名，如果return的是False代表的此模块无效，不能使用。在自定义模块中可以中__grains__是一个包含了minion 所有grains的字典，__pillar__是包含了所有Pillar的grains字典,__salt__是所有可执行函数对象的字典，通常最常使用的就是这三个变量了。再往下面是定义了函数install,在salt中一般不用’%s’ % var这种格式化形式，而是使用字符串的format方法，具体使用见百度。下面就是通过__salt__执行了cmd.run这个函数来运行yum命令，很简单吧，最后把结果返回回去。

3.测试
```
salt '*' yum.install ftp  ##查看返回值
```
二十一、自定义grains

自定义的grains也是由Python写成的，通常放在/srv/salt/_grains下，grains需要返回一个字典，__salt__,__grains__,__pillar__也是可以在grains中使用的。前面已经介绍过写简单自定义grains了，复杂就就参照https://github.com/saltstack/salt/blob/develop/salt/grains/core.py官方这个吧

二十二、自定义returner

前面已经看过官方的mysql的returner了，今天来说说自定义returner需要注意的，来个例子吧。 /srv/salt/_returners/file.py内容
```
def __virtual__():
   return 'file'
def returner(ret):
   '''
   Return information to /tmp/returns.txt.
   '''
   # open a file
   result_file = '/tmp/returns.txt'
   f = open(result_file, 'a+')
   f.write(str(ret))
   f.close()

salt '*' saltutil.sync_all         ##同步模块
salt '*' test.ping --return file   ##测试
cat /tmp/returns.txt               ##在minion上查看

{'jid': '20131227153001246117', 'return': True, 'retcode': 0, 'success': True, 'fun': 'test.ping', 'id': 'test1'}
```
说明：通过这个简单的例子我们了解返回的值是个字典，字典包括的项就是上面我们看到的，以后写其它returner时，也就是把这个字典的值写到不同的地方而已。这个returner的意思就是把返回的值写到各个minion的/tmp/returns.txt中。

二十三、file state backup

来例子看看吧。 /srv/salt/test.sls文件内容
```
/tmp/test.txt:
 file.managed:
   - source: salt://test.txt
   - backup: minion
```
其中多了一个参数backup，后面跟的值minion，意思是说这个文件在minion中备份一份，文件名带着时间戳，备份位置在/var/cache/salt/minion/file_backup

执行并测试：
```
salt '*' state.sls test    ##注，多修改几次test.txt，多运行几次该state
salt '*' file.list_backups /tmp/test.txt ##这是会返回备份序号，时间，位置，大小
```
回退当文件改错后，我们可以用备份文件回退
```
salt '*' file.restore_backup /tmp/test.txt 2   ##回退的文件，与想要回退的序列号
```
删除删除不需要的备份文件
```
salt '*' file.delete_backup /tmp/test.txt 3
```
二十四、应用实例

saltstack 远程触发文件备份、回滚

1、创建模块方法文件
```
mkdir /srv/salt/_modules
```
默认没有此文件，自己生成一个

下面的py文件自己定义，下面是我写的两个方法：
```
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys,string,shutil
import os,tarfile
import datetime,time

tn=datetime.datetime.today()
time_now=tn.strftime("%Y-%m-%d")
data_bak='/data/databak'
data_tmp='/data/databak/tmp/%s' % time_now
com_f="%s/%s" % (data_bak,time_now)
if not os.path.exists(com_f):
     os.makedirs(com_f)

def CpFile():
     id = sys.argv[1]
     dir = sys.argv[2]            #传入两个变量，任务自动生成的id与要替换的文件
     filename = '%s/%s.tar' % (com_f, id)
     mode = 'w:tar'
     os.chdir(data_bak)                                                                                                                                                
     w_file=open("/tmp/tmp.list",'w')      
     w_file.write(id+" "+dir)              #记录每次备份的id与相对应的备份目录或文件的路径
     w_file.close()
     file = tarfile.open( filename, mode )
     file.add( '/tmp/tmp.list' )
     file.add( dir )    
     file.close()
     return 'ok'       #测试过程，就先让返回ok吧，之后再做判断


def RollBack():
     id = sys.argv[1]        #想要回滚到的版本id
     if not os.path.exists(data_tmp):
          os.makedirs(data_tmp)
     filename = '%s/%s.tar' % (com_f, id)
     tar = tarfile.open("%s" % filename)
     for b in tar:
          tar.extract(b,path="%s" % data_tmp)
     tar.close()
     for line in open('%s/tmp/tmp.list' % data_tmp):
          id = line.split(" ")[:1][0]
          dir = line.split(" ")[1:][0]       #读取备份时的路径
          backup_dir='%s/%s' % (data_tmp,dir)
          os.system('cp -rp %s %s' % (backup_dir,dir))
          return 'ok'
```
2、测试：

master上同步方法脚本到节点
```
salt '*' saltutil.sync_all
```
然后先测试备份方法
saltstack
salt ‘*’ cp_bakfile.CpFile 1234 /tmp/test #id + 路径

上节点服务器上查看，存在

把/tmp/test下内容删除，测试回滚操作
```
salt '*' cp_bakfile.RollBack 1234
```
使用gitfs做fileserver

用gitfs后，master会从git服务器取回文件缓存，minion不会直接联系git服务器修改master配置文件/etc/salt/master(注:以后说master配置文件就是指该文件)
```
fileserver_backend:
 - git
gitfs_remotes:
 - git://github.com/saltstack/saltstack.git
 - git://github.com/example/test1.git      ##可以多个git
 - file:///root/td                         ##可以使用本地git
```
需要:python的模块GitPython >= 0.3.0

saltstack的目录结构
```
.
|-- bfile
|-- edit
|   `-- vim.sls
`-- top.sls
vim.sls

/tmp/a.txt:
 file.managed:
   - source: salt://bfile
ftp:
 pkg:
   - installed
```
也可以使用git下的子目录作为文件服务器根目录
```
gitfs_root: somefolder/otherfolder
```
也可以混合使用git和本地磁盘作为文件服务器
```
fileserver_backend:
 - roots
 - git
 - 
```
使用ssh协议的GitFS,私钥为~/.ssh/id_rsa
```
gitfs_remotes:
 - git+ssh://git@github.com/example/salt-states.git
```
查看全文

相关阅读:
jvm-类加载
 jvm调优
 jdk8与jdk9的共存
 eclipse的插件开发-启动时间
 斐波那契数列算法逐层优化（C++）
2G.处女座与复读机（C++）
3I.处女座的约会（C++）
3D.处女座的训练（C++）
3E.处女座和小姐姐（C++）
3C.处女座点名（C++）

原文地址：https://www.cnblogs.com/davygeek/p/7754207.html

salt常用命令、模块、执行

一、salt常用命令

二、普通用户执行salt

三、target

四、远程批量执行

五、多Master

六、pillar

七、grains

八、使用 salt state

九、关于渲染器render system

十、state的执行顺序

十一、依赖关系系统requisite system

十二、salt state环境

十三、salt schedule

十四、YAML语法风格

十五、salt事件系统与反应系统 event and reacter system

十六、salt Mine

十七、salt ssh

十八、Returners

十九、扩展salt

二十、自定义可执行模块

二十一、自定义grains

二十二、自定义returner

二十三、file state backup

二十四、应用实例

saltstack 远程触发文件备份、回滚

使用gitfs做fileserver