SaltStack系列（五）之各种组件
一、Return组件
1.1 Return介绍
Return组件可以理解为saltstack系统对执行Minion返回的数据进行存储如返回到文件，或者保存到数据库或者返回给其他程序，它支持多种存储方式，比如用Mysql、MongoDB、Redis、Memcache等，目前官方已经支持30种Return数据存储与接口，当然也支持自定义的Return。
这样可以通过返回的数据库，平台日志，或者通过返回的结果进行实时监控，把数据返回给页面前端，就像foreman那样。
# salt '*' sys.list_returners #查看所有Return列表，这里显示的不是很全。所有的Return列表可以去官网查看。
shidc_agent_192.168.1.111:
- carbon
- couchdb
- etcd
- hipchat
- local
- local_cache
- multi_returner
- slack
- smtp
- sqlite3
- syslog
1.2 Return流程
return是在master端触发任务，然后minion接受处理任务后直接与return存储服务器建立连接，然后把数据return存到存储服务器。这个过程都是minion端操作存储服务器，所以要确保minion端的配置跟依赖包是正确的
不可能让每台minion都跟存储服务器连接然后发送返回数据，可以通过event事件实现master端直接return到存储服务器。参考地址：http://pengyao.org/saltstack_master_retuner_over_event_system.html
二、Job管理
1.1 job介绍
在SaltStack里面执行任何一个操作都会在master上产生一个jid号。minion段会在cache目录下的proc目录创建一个以jid为名称的文件，这个文件里面的内容就是此次操作的记录，当操作处理完成后该文件会自动删除。而Master端会记录每次操作的详细信息，这个记录会存到master端cache目录下jobs下。
/var/cache/salt/minion/proc/ #这是minion端下存放job的目录不过运行完毕后就删除掉了。
/var/cache/salt/master/jobs/ #这是master端存放job的目录。
# grep "keep_jobs" /etc/salt/master #master端的jobs，默认保存时间为24小时
#keep_jobs: 24
1.2 通过salt-run来管理job
# salt-run -d|grep jobs #查看对jobs的一些管理办法
#salt-run jobs.active #查看当前正在运行的Jobs
#salt-run jobs.list_jobs #查看所有jobs信息
# salt-run jobs.list_job 20170517224315709946 #指定jid查看jobs详细信息。20170517224315709946就是我们选的的jid号。
# salt-run jobs.lookup_jid 20170517224315709946 #指定jid查看jobs结果。
# salt-run jobs.print_job 20170517224315709946 #指定jid查询jobs详细信息。
1.3 通过saltstack自带的module管理job
salt-run还不支持kill某个job，可以使用saltstack自带的module来管理job。
# salt \* sys.doc saltutil|grep job #查看使用方法
# salt '*' saltutil.find_cached_job <job id> #查询job cache信息
# salt '*' saltutil.find_job <job id> #查看job信息
# salt '*' saltutil.kill_job <job id> #杀掉job（发送SIGTERM 9信号方式）
# salt '*' saltutil.signal_job <job id> 15 #发送指定信号
# salt '*' saltutil.term_job <job id> #发送终止信号到指定的job
三、Event
Event是SaltStack里面的对每个事件的一个记录，它相比job更加底层，Event能记录更加详细的SaltStack事件，比如Minion服务启动后请求Master签发证书或者证书检验的过程，都能通过Event事件来查看整个过程。Event也为扩展SaltStack提供了更加友好的接口。
3.1 查看Event事件
# salt-run state.event pretty=True #查看Event事件，下面操作了一个client端向master端发送认证，然后master端认证通过的示例
salt/auth { #minion向master端请求证书认证
"_stamp": "2017-05-18T07:53:11.059240",
"act": "pend", #这是新minion端是这种状态，要是已经验证过的minion端再向master端发起请求就是"act": "accept",这种状态了。
"id": "shidc_192.168.1.106",
"pub": "-----BEGIN RSA PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvm/p5S2b+hORuYKZ3Uvl\nnG/wDtvuneMxY4wP0ztki0P27L5eXX1IEfbd2kjD3fwik5aafMwry4BJw3tnTi+u\nEFsfBb/vnInj0+2K9EM/Eu/dpi4dec3W8qxahCjEfvlMWyIb7O12qg7f87HH+A1T\nFx/fwUkWYX+79lqoeeYPYvKPRIAGv+Wacx4kx5SbQdJVKU0sAJFDQZk2gSi+Hqch\nkxhvTWi1PIPAkVt5zkO+cPy3FSJlM8xoRVhaiZhDioHsSbHdIDD2VAvYc4s5v7Wi\nhuYqCP66kgpmilP/f5+AAAKiFdrU9JF9EvXWBuUVePN+opQhcUxyhCHVvfG3D5PM\nQwIDAQAB\n-----END RSA PUBLIC KEY-----",
"result": true
}
salt/event/new_client { #master做了操作会有一个新的事件
"_stamp": "2017-05-18T07:53:13.382882"
}
salt/key { #master端同意了认证
"_stamp": "2017-05-18T07:53:13.390370",
"act": "accept",
"id": "shidc_192.168.1.106",
"result": true
}下面是让某个minion执行ip addr命令的操作事件：
salt/event/new_client { #master又有一个新的event
"_stamp": "2017-05-18T08:04:04.062492"
}
20170518160404084807 { #job号是多少
"_stamp": "2017-05-18T08:04:04.085367", #时间
"minions": [ #minion客户端是谁，多主机的话会显示多主机
"agent1.salt"
]
}
salt/job/20170518160404084807/new {
"_stamp": "2017-05-18T08:04:04.085663",
"arg": [
"ip addr" #里面要执行的命令
],
"fun": "cmd.run", #调用的方法函数
"jid": "20170518160404084807",
"minions": [
"agent1.salt"
],
"tgt": "agent1.salt",
"tgt_type": "glob",
"user": "root"
}
salt/job/20170518160404084807/ret/agent1.salt { #如果有多主机的话，这一块会有多条，除了id号是对应的主机的key名称以外，和return里面是minion返回的执行信息外，其他是一致的。
"_stamp": "2017-05-18T08:04:04.228387", #时间这里也是有些小差别的如果是多minion端去执行一个操作。
"cmd": "_return",
"fun": "cmd.run",
"fun_args": [
"ip addr"
],
"id": "agent1.salt",
"jid": "20170518160404084807",
"retcode": 0, #返回码，0代表执行的命令是成功的，这里是执行操作的返回码。类似于#echo $?
"return": inet 192.168.1.102/24 brd 192.168.1.255 #这里是ip addr的信息太长了我就截取了部分信息
"success": true #这里是执行结果成功还是失败
}博文来自：www.51niux.com
四、Reactor
Reactor一般是跟Event结合着使用的，Event就像日志一样，Reactor基于Event的每个事件来做相应的操作（states）。Reactor系统一直监听着Event,然后出发一些States操作。
4.1 master端证书自动认证
master端在配置里面是可以自动开启证书自动认证的，但是是允许所有都可以认证，那么我们是不是可以通过监听事件来做minion端证书的认证呢，上面已经介绍了证书发起认证的json格式。
# vim /etc/salt/master
reactor: # salt master配置区块"reactor"
- 'salt/auth': #监听证书认证的event，请看Event事件记录的最上面那一行。
- /srv/reactor/auth.sls #如果监听到上面的那个'salt/auth'事件，就执行此条states sls文件。
# mkdir /srv/reactor/ #默认没有此目录
# cat /srv/reactor/auth.sls #我这里就写了一个让minion的末尾是_公司标识的minion证书请求通过验证
{% if 'act' in data and data['act'] == 'pend' and data['id'].endswith('_youshi') %}#这句话就是如果事件内容里面有act（"act": "pend",这是那个证书请求嘛），并且data['act']的值是pend，并且data['id']的末尾是跟'_youshi'匹配.
minion_add:
wheel.key.accept: #如果上面的if条件都匹配到了，调用内置函数进行证书通过操作
- match: {{ data['id'] }} #这里就是match匹配，data['id']正好将minion端的id号取出来，那么就是认证这个id证书
{% endif %} #当然还可以在上面继续写，如果不匹配怎么办等。# service salt-master restart
# cat /etc/salt/minion|grep id: #找一台minion机器，id:号设置成以'_youshi'结尾的，然后重启minion服务测试一下。
id: zwidc_kvm_192.168.1.104_youshi
下面是截取的部分内容：
salt/auth {
"_stamp": "2017-05-18T09:15:54.322478",
"act": "accept",
"id": "zwidc_kvm_192.168.1.104_youshi",
"pub": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxq2vWrPIunfTOt8YlhjS\nERsup9Ka97QgqmGjDfCYfRso2Ei4u6WHp43KQQamMhotgumrLfuaszNJy3nD4zTt\nFKN3q8kpLoU+3cmkLyEh5pTmMfNCPcY3q8nRlAcEPkS0axfsWx0lKzEJOCVdYley\nIEcQcEiT16ZUbCJpM5coOl+TxMTAmZL1Fwkt6xZs3vnAf1fbb7EnGiSLTK6gGrGM\nxPL4k8qDB98LwzUSt3ixgGJprpfkXjcZKO+32J3IFUXggfwGtMQn3J1+Bi+m4xM2\nlfpqB/YR4ifW/iRn7LIvqESVAWkte0n30XWnhwWgX/ufbzq8rHX/4gHpEEDOsdpX\nvwIDAQAB\n-----END PUBLIC KEY-----\n",
"result": true
}
minion_start {
"_stamp": "2017-05-18T09:15:54.368410",
"cmd": "_minion_event",
"data": "Minion zwidc_kvm_192.168.1.104_youshi started at Thu May 18 17:15:54 2017",
"id": "zwidc_kvm_192.168.1.104_youshi",
"pretag": null,
"tag": "minion_start"
}
salt/minion/zwidc_kvm_192.168.1.104_youshi/start { #注意salt/minion/zwidc_kvm_192.168.1.104_youshi/start这里，我们将对这个监听继续做下一步的reactor操作,证书验证成功之后会有一个这个时间，当然minion已经验证通过后重启也会有这个事件
"_stamp": "2017-05-18T09:15:54.376514",
"cmd": "_minion_event",
"data": "Minion zwidc_kvm_192.168.1.104_youshi started at Thu May 18 17:15:54 2017",
"id": "zwidc_kvm_192.168.1.104_youshi",
"pretag": null,
"tag": "salt/minion/zwidc_kvm_192.168.1.104_youshi/start"
}
salt/job/20170518171556451859/ret/zwidc_kvm_192.168.1.104_youshi {
"_stamp": "2017-05-18T09:15:56.454118",
"arg": [],
"cmd": "_return",
"fun": "mine.update",
"id": "zwidc_kvm_192.168.1.104_youshi",
"jid": "20170518171556451859",
"pid": 17249,
"return": true,
"schedule": "__mine_interval",
"tgt": "zwidc_kvm_192.168.1.104_youshi",
"tgt_type": "glob"
}4.2 初始化安装
一般一个新的逻辑才会发起证书认证，如果证书认证之后，是不是让minion自己去master同步去执行一些必要的操作呢，而非去手工执行，做到一些操作的自动安装与部署。
# vim /etc/salt/master
reactor:
- 'salt/auth':
- /srv/reactor/auth.sls
- 'salt/minion/*/start': # 匹配 "salt/minion/*/start"
- /srv/reactor/start.sls #如果匹配到了就执行这个sls文件
# cat /srv/reactor/start.sls #这个sls文件写了一个很简单的，让minion本地执行state.highstate操作，主动去向master端发起同步，下拉top.sls里面的内容本地执行。不过这么简单是存在一个问题的，就是minion端的重启操作也会触发这个同步操作，不过一般minion端很少重启，而且初始化如果做过之后，也不会进行什么更改。
highstate_run:
local.state.highstate:
- tgt: {{ data['id'] }}
# cat /srv/salt/base/top.sls #我们top.sls里面引用了init目录下面的env_init，env_init里面include了一些初始优化的操作
base:
'*':
- init.env_init
#这样当证书认证之后就有会有start事件，然后又被捕捉到，然后就又运行state.highstate操作，然后我们top.sls下发到此minion端然后执行初始优化。
博文来自：www.51niux.com
五、Mine
Mine是SaltStack收集Minion数据存储到Master的一个组件，它的功能与Grains有些类似，Mine可以指定任何Minion模块去采集数据。
Mine配置目前支持两种方式，第一种通过在Minion配置文件中定义，另一种是通过模块的方式去下发Mine采集任务。
5.1 第一种通过修改minion配置文件的方式
# vim /etc/salt/minion
mine_functions: #引用mine模块收集
network.ip_addrs: #network模块的方法
interface: eth0 #采集的是eth0网口的信息
# salt 'zwidc_kvm_192.168.1.104' mine.get 'zwidc_kvm_192.168.1.104' network.ip_addrs #通过mine.get来收集数据
5.2 第二种下发采集任务的方式
# salt '*' mine.send network.ip_addrs interface=eth0 #下发一个采集eth0网卡IP的任务
# salt 'zwidc_kvm_192.168.1.104' mine.get '*' network.ip_addrs #前面随便指定一个主机就可以了，不然要重复好多遍，后面要是查看所有主机的就加*，要是特定的条件再自行修改。
六、Peer
Peer组件是Saltstack中Minion向Master发布任务的一个组件，使用Peer可以直接在Minion上向Master发布一些任务，跟我们在Master上执行一样的效果。默认Peer是没有配置的，配置Peer只需要修改Master文件即可。
这个组件还是有点意思的，我们应该尽量少的登录master端，如有的操作，test.ping看看哪些主机跟master端的连接有问题啊，或者一些信息查看的工作啊，都可以交给一台特定的minion机器来执行。
# vim /etc/salt/master #修改配置文件添加下面一句话。
peer:
zwidc_kvm_192.168.1.104:
- test.ping
- cmd.run
shidc.*:
- network.*
#这个就是在peer：下面引入允许哪个minion主机的ID：可以执行什么权限，minion的ID可以使用正则表达式，模块函数也可以。至少minion主机哪里别用正则表达式，就指定某一个minion端可以执行一些查看的操作就可以了，也是将操作上交给master端，然后master端来执行。
# salt-call publish.publish '*' cmd.run 'hostname' #salt-call publish.publish 后面跟主机范围 然后要执行的命令就可以了。下面是一个成功的截图：
下面是一个失败的截图（因为我们这台机器没有network模块的权限）：
七、好多厉害的内容做个记录（这里可忽略）
7.1 saltstack组件的扩展
saltstack的Grains、Module、state都是可扩展的，这就需要些python文件了，因为saltstack本身就是用Python写的嘛。
7.2 第三方调用saltstack
API：开发人员的最爱，给我一个接口我按照我喜欢的方式来。可以通过PythonAPI和RESTfulAPI调用。
7.3 SaltStack架构扩展
无master架构：就是minion配置文件修改，断开与master端的连接，自己本地玩自己的。
多Master架构：salt在0.16.0版本加入了multi-master的特性，所有的minion将连接到所有配置的master上去，这样当其中一个master出现故障，minion端可以使用另外的master继续提供服务。需要自己来做多master端间的数据同步。minion端比较简单配置文件里面指定多master就可以了。
Syndic架构：多Master可以避免单点故障问题，但是提高性能的话就需要用到Syndic了。salt在0.9.0版本中加入了Salt Syndic。Syndic建立在中心master和minions之间，并允许多层风机Syndic。syndic要运行在master上面，但是没有自己的配置由高级master控制。通过syndic将操作命令传输到受控master，受控master来完成对自己旗下minion的管理，并将结果传回高级master,从而实现高级master对所有minion的间接管理。
Salt SSH : salt在版本0.17.0当中，引入了新的传输系统，它支持通过SSH通道来实现salt的通信，就像ansible一样，可以不需要在远程主机上运行minion服务，同时又能支持saltstack的大部分功能，而且salt master也不需要运行，从而实现免客户端方式的部署和实施。使用salt ssh，控制服务器需要使用Rosters来管理这些数据，Roster系统为可插拔设计，用于Salt SSH获取需要连接的服务器信息。
另外saltstack 可以实现web页面的开发，可以为监控提供数据，可以通过event的上报像foreman那样进行报告的展示，可以跟CMDB结合等等很强大。
