柴少的官方网站 技术在学习中进步,水平在分享中升华

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来收集数据

图片.png

5.2 第二种下发采集任务的方式

# salt '*' mine.send network.ip_addrs interface=eth0  #下发一个采集eth0网卡IP的任务

图片.png

# salt 'zwidc_kvm_192.168.1.104' mine.get  '*' network.ip_addrs  #前面随便指定一个主机就可以了,不然要重复好多遍,后面要是查看所有主机的就加*,要是特定的条件再自行修改。

图片.png

六、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 后面跟主机范围 然后要执行的命令就可以了。下面是一个成功的截图:

图片.png

下面是一个失败的截图(因为我们这台机器没有network模块的权限):

图片.png

七、好多厉害的内容做个记录(这里可忽略)

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结合等等很强大。

作者:忙碌的柴少 分类:SaltStack系列 浏览:11746 评论:0
留言列表
发表评论
来宾的头像