SaltStack;以及与AnsibleWorks,Chef-solo,puppet等等等的比较!

2017-11-01 16:06:18来源:oschina作者:carocy人点击

分享
SaltStack;以及与AnsibleWorks,Chef-solo,puppet等等等的比较!

...


      http://www.vpsee.com/2013/08/a-system-configuration-management-and-orchestration-tool-saltstack/


系统自动化配置和管理工具 SaltStack

2013年08月22日 | 标签:devops,puppet,salt,saltstack| 作者:vpsee

我们的服务器由 Puppet 配置管理工具来管理,服务器上线后由 puppet 完成初始化和配置等一系列工作(比如,静态 IP 配置,DNS 设置,NFS/SAN 挂载,LDAP/Kerberos 登录,安全加固配置,内核参数优化,防火墙规则配置等等),等初始化完成后开始运行,运行一段时间后有一些需要自动和手动操作的任务(比如升级、重启、备份等),这时候我们使用 Fabric 来批量执行这些临时任务。


所以从这里可以看到 Puppet 和 Fabric 其实是两个不同性质的工具,看下面的归类可能会更清楚一些。Puppet 和 Fabric 两个的工作其实可以由一个工具 SaltStack(或 AnsibleWorks)完成,减少一个工具的使用会减轻一点负担(学习工具的人力成本、安装和配置工具的时间成本等等)。



操作系统和软件的安装、配置、初始化等; (Puppet, Chef, CFEngine, AnsibleWorks, SaltStack, …)


自动执行任务,比如定期备份、清除日志等; (Fabric, AnsibleWorks, SaltStack, …)


手动执行任务,比如部署应用、升级、重启、检查和校验文件系统、增加用户等。 (Fabric, Rake, Func, Rundeck, AnsibleWorks, SaltStack, …)



SaltStack采用 zeromq 消息队列进行通信,和 Puppet/Chef 比起来,SaltStack 速度快得多。还有一点我们喜欢 SaltStack 的地方是它是 Python 写的,比 Puppet/Chef 这些 Ruby 工具更接近我们的能力圈。


安装主控服务器(salt master)

和大多数类似工具一样,SaltStack 需要在一台机器(主控)上安装服务器端软件(SaltStack 称之为 salt master),在多台机器(受控)上安装客户端软件(SaltStack 称之为 salt minion)。在主控机器上给下属(受控)发命令,在受控机器上接受和执行上级(主控)的命令。


在 Ubuntu 上安装 salt master:


$ sudo add-apt-repository ppa:saltstack/salt
$ sudo apt-get update
$ sudo apt-get install salt-master

在 CentOS 6.x 上安装 salt master:


# rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
# yum update
# yum install salt-master
安装受控客户端(salt minion)

在 Ubuntu 上安装 salt minion:


$ sudo add-apt-repository ppa:saltstack/salt
$ sudo apt-get update
$ sudo apt-get install salt-minion

在 CentOS 6.x 上安装 salt minion:


# rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# yum update
# yum install salt-minion

安装完 salt minion 后记得修改配置文件,让 salt minion 指向 salt master 服务器地址:


$ sudo vi /etc/salt/minion
...
# Set the location of the salt master server, if the master server cannot be
# resolved, then the minion will fail to start.
master: saltmaster.vpsee.com
...
$ sudo restart salt-minion

在 master 上执行 salt-key list 就会看到有个 minion1.vpsee.com 请求加入受控,执行 -a 接受请求后,主控和受控之间的信任关系就建立起来了,主控就可以任意 “摆布” 受控了:


# salt-key list
Accepted Keys:
Unaccepted Keys:
minion1.vpsee.com
Rejected Keys:
# salt-key -a minion1.vpsee.com
The following keys are going to be accepted:
Unaccepted Keys:
minion1.vpsee.com
Proceed? [n/Y]
执行命令的例子

在主控机器上执行一个命令,让所有受控机器执行 hostname 命令:


# salt '*' cmd.run "hostname"
minion1.vpsee.com:
minion1.vpsee.com

在主控机器上执行一个命令,让所有受控机器上执行内建 test.ping 命令:


# salt '*' test.ping
minion1.vpsee.com:
True

还有一些内建命令可以尝试:


# salt '*' disk.usage
# salt '*' network.interfaces
执行状态的例子

开头的时候我们说了 SaltStack = Fabric + Puppet,上面 “执行命令的例子” 演示了 Fabric 类似的功能,这里要演示的是 Puppet 类似的功能,在主控上定义好系统配置应该有的状态,然后受控自动完成相应的操作和配置。


首先确定状态定义的文件应该放在什么地方,以下操作都在主控(salt master)上执行。检查 /etc/salt/master 文件的 file_roots 条目,默认是在 /srv/salt 下,如果没有这个目录还需要手动创建一个:


# vi /etc/salt/master
...
#file_roots:
#base:
#- /srv/salt
...
# mkdir /srv/salt

比如我们想在所有受控机器上安装 vim 软件包,并使用自己定义的 vimrc 文件:


# vi /srv/salt/vim.sls
vim:
pkg.installed
/etc/vimrc:
file.managed:
- source: salt://vimrc
- mode: 644
- user: root
- group: root
# vi /srv/salt/vimrc
syntax enable
set textwidth=79
set shiftwidth=4
set tabstop=4
set expandtab
set softtabstop=4
set shiftround
set fileencodings=utf-8
set encoding=utf8
set tenc=utf8

强制执行这个状态:


# salt '*' state.sls vim

再来一个例子,参考 “安装和使用系统监控工具 Glances” 一文,我们想在所有受控机器上安装 Glances,如何实现呢?


# vi /srv/salt/glances.sls
python-pip:
pkg.installed
build-essential:
pkg.installed
python-dev:
pkg.installed
glances:
pip.installed:
- require:
- pkg: python-pip

强制执行这个状态:


# salt '*' state.sls glances
...
minion1.vpsee.com:
----------
State: - pip
Name:glances
Function:installed
Result:True
Comment: Package was successfully installed
Changes: Glances==1.7.1: Installed
...

YC- August 24th, 2013 3:11 pm

前一段时间调研过saltstack,ansible,chef-solo三个自动化部署工具,最后决定用ansible。看来有空要试试saltOwnLinux- August 28th, 2013 1:34 pm有个地方需要更正一下。


默认是在 /srv/salt 下,如果没有这个目录还需要手动创建一个:# vi /etc/salt/master ... #file_roots: # base: # - /srv/salt ...

# mkdir /srt/salt

应该是 mkdir /srv/salt,后还有几个笔误的地方。


#########################################################################################################


http://blog.halfss.com/blog/2013/09/06/ge-ren-dui-yun-wei-ji-yun-wei-zi-dong-hua-de-li-jie/


个人对运维及运维自动化的理解

以下内容为个人理解,如有不对,请及时指出,谢谢


对于运维来说,基于状态的配置管理已经向自动化迈进了一大步,以状态为核心的运维,让状态本身有了可管理性;在运维过程中我们会发现,同样的一个配置,我们会在不同的时间,不同的地点一次在一次的配置,这个时候,配置管理就有了重复性;有的甚至是原封不动的重复,而另外一些则是按照一定的规律在发展,这些按照一定规律发展的配置,就是可预测的.综上我认识的,我们运维工作的本身是可管理,可重复,可预测的.基于这样的理念,我们就可以更进一步的推进我们的运维自动化,甚至到智能化. 看到这里,我理想中的运维自动化的配置管理平台应该有如下功能:


1:对状态的配置及管理(最基本的)
2:可以及时的对系统状态进行调整并能看到结果(实时性和反馈性)
3:可以对其本身做方便的第三方管理(方便的将运维与其他管理做整合)

加分项:


1:开发语言单一
2:架构简单,灵活
3:有不错的安全性 4:没有商业版(个人偏见)

下面是现有比较有代表性的自动化配置管理工具:


附:以下仅基于开源版本进行介绍基本属性(每项5分)加分项目(每项1分) 总分
状态管理 实时管理架构简单,灵活 开发语言单一 有API有反馈系统
puppet5 3.5 11 0010.5
chef5 1-1 -1 10 5
salt4 511 11 13

附:

1:puppet的实时管理,我给了3.5是因为moc的原因,这个moc,我感觉就是硬生生的加在puppet上的,只不过整合的比较好,所以用起来没那么大的违和感;这就相当于为了给puppet加入一个新的功能完全引入一个新的系统;你喜欢这样吗? 我不喜欢
2:我对chef的架构和开发语言方面基本是怀有敌意,我在用chef的时候,我想改个功能,结果发现有3门语言:ruby,java,erlang而且我一个都不会(你们有谁能自己搞定这3门语言吗?),架构方便更是引入了各种东西;都数不过来;我只能说chef的理念很好(cookbook的管理及编写,节点的管理,role,environment的的设定,这些东西真的很好);但是被他们实现的我感觉很不好;而且chef的安全问题和对安全的态度;chef客户端基本可以获取当前chef环境中的所有信息,基本上意为这一个chef-client被黑了(架构如此复杂被黑的可能性很高),你的所有chef-client+chef-server就悲剧了;chef官方git的代码被微薄上的木人该了2次后(仅仅是我知道的);官方也没什么反应,请问,你敢用吗?
3:salt的状态不比puppet和chef的差多少,所以我给了4分

到这里,如果你现在正要选择一个运维自动化的工具的时候,毋庸置疑,就是salt了


最近也出来一个比较新的运维自动化的工具:ansible(http://www.ansibleworks.com/),对于ansible我研究的不多,简单说下ansible与salt的情况:


1:2者仅仅从大的功能上来说,区别不大
2:ansible:基于ssh(现在也可以基于消息),免安装(部分功能还是需要安装的,不过跟salt比安装,配置方面就方便很多了),快捷方便,但也就限制在里linix/unix平台上;自带完善是Web管理,API,数据存在基于数据库; 整体看起来比较完整; 算是一个商业产品级
3:salt在产品这块的整体布局目前看起来不是很成熟(我感觉salt在产品这块的切入点很不错),是一帮纯粹工程师搞出来的东西;虽然简单,灵活,强大,但是真实在实际使用过程中,自己还会遇到不少的问题; 算是一个社区项目;不够salt的迭代非常快,我相信很快就汇成熟
ansible是从商业目的出发,然后做开源
salt是从技术与应用目的出发,现在也算是在做部分商业产品
所以我跟趋向于salt

这里有一个对比salt和ansible的文章:http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/


我简单的说下文章的内容:
在速度上一般情况下salt比ansible快
在安全性上ansible略好于salt
安装&部署&维护上ansible好于salt
在对状态的管理的时候ansible也比salt优雅
最后作者更倾向于ansible;同时也说:也会使用salt;salt和ansible是都是非常优秀的工具.

Sep 6th, 2013ops


    http://blog.halfss.com/blog/2013/05/22/yun-wei-zi-dong-hua-zhi-saltxue-xi-bi-ji/


运维自动化之salt学习笔记
引言:关于运维
1:saltstack的基本介绍
2:salt的安装
1:服务端
1:安装
2:配置文件
3:运行
4:注意事项
2:客户端
1:安装
2:配置文件
3:运行
4:注意事项3:salt的使用:
1:基础知识
1:targeting
2:nodegroup
3:grains
4:pillar
2:状态管理
1:state
1:state语法
2:state的逻辑关系
2:highstate
3:salt schedule
3:实时管理
1:cmd.run
2:module
4:其他
1:无master
2:peer
3:runner
4:reactor4:salt开发
1:saltclient管理salt
2:salt api引言:关于运维
运维的工作主要在2方面:
1:状态的管理
2:系统性能调优
这里主要简介下运维状态的管理:
对于运维来说,基于状态的配置管理已经向自动化迈进了一大步,以状态为核心的运维,让状态本身有了可管理性;在运维过程中我们会发现,同样的一个配置,我们会在不同的时间,不同的地点一次在一次的配置,这个时候,配置管理就有了重复性;有的甚至是原封不动的重复,而另外一些则是按照一定的规律在发展,这些按照一定规律发展的配置,就是可预测的.综上我认识的,我们运维工作的本身是可管理,可重复,可预测的.基于这样的理念,我们就可以更进一步的推进我们的运维自动化,甚至到智能化.
看到这里,我理想中的运维自动化的配置管理平台应该有如下功能:
1:对状态的配置及管理(最基本的)
2:可以及时的对系统状态进行调整并能看到结果(实时性和反馈性)
3:可以对其本身做方便的第三方管理(方便的将运维与其他管理做整合)
加分项:
1:开发语言单一
2:架构简单,灵活
3:有不错的安全性
4:没有商业版(个人偏见)
下面是现有比较有代表性的自动化配置管理工具:
附:以下仅基于开源版本进行介绍
理念 优缺点
puppet从运维的角度去做配置管理(运维人员做给运维用的) 架构简单,系统比较成熟/不便于第三方管理
chef从研发的角度去做配置管理(研发人员做给运维用的) 较便于第三方管理,对自身(节点,变量,cookbook)的管理较方便,有自己的dashboard,cookbook支持版本管理,自从cookbook的版本管理/架构复杂,开发语言较多,(安全问题)
以上2者都比较侧重于状态的管理,对单个或者多个状态的临时调整或者管理较差
2个都有商业版,让我这个用开源版的很自卑
这里我们也能看到,2个配置功能都没能达到我理想中的状态,那就暂用chef吧,直到有一天,了解到了saltstack看到了这句话:“ 系统配置的自动化不仅可预测,可重复, 还具有可管理性”(http://wiki.saltstack.cn/reproduction/dive-into-saltstack),这尼玛才是运维自动化的未来啊,于是毫无节操的开始学习salt,而且发现越学越喜欢;在我使用puppet及chef的时候都没有使用salt的感觉,太爽了。所以我这里仅仅介绍基本的语法不涉及实际用例,salt的安装非常方便,所以你在看本文档的时候希望你能真正的动手去做一下,然后你就会爱上salt了
附::如果你会python,salt基本是不需要怎么学的,而我正好了解一点py,不过这最多占我选择salt的20%。
最近也出来一个比较新的运维自动化的工具:ansible(http://www.ansibleworks.com/),对于ansible我研究的不多,简单说下ansible与salt的情况:
1:2者仅仅从大的功能上来说,区别不大
2:ansible:基于ssh(现在也可以基于消息),免安装(部分功能还是需要安装的,不过跟salt比安装,配置方面就方便很多了),快捷方便,但也就限制在里linix/unix平台上;自带完善是Web管理,API,数据存在基于数据库; 整体看起来比较完整; 算是一个商业产品级
3:salt在产品这块的整体布局目前看起来不是很成熟(我感觉salt在产品这块的切入点很不错),是一帮纯粹工程师搞出来的东西;虽然简单,灵活,强大,但是真实在实际使用过程中,自己还会遇到不少的问题; 算是一个社区项目;不够salt的迭代非常快,我相信很快就汇成熟
ansible是从商业目的出发,然后做开源
salt是从技术与应用目的出发,现在也算是在做部分商业产品
所以我跟趋向于salt
这里有一个对比salt和ansible的文章:http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/
我简单的说下文章的内容:
在速度上一般情况下salt比ansible快
在安全性上ansible略好于salt
安装&部署&维护上ansible好于salt
在对状态的管理的时候ansible也比salt优雅
最后作者更倾向于ansible;同时也说:也会使用salt;salt和ansible是都是非常优秀的工具.1:saltstack的基本介绍
salt是一个新的基础平台管理工具。很短的时间即可运行并使用起来, 扩展性足以支撑管理上万台服务器,数秒钟即可完成数据传递. 经常被描述为 Func加强版+Puppet精简版。
salt的整个架构都是基于消息来实现.所以能够提供很强的拓展性,灵活性,实时性;
不过salt还是一个很年轻的东西,还有很多地方不够完善,做的不够好,不过我相信这些都只是时间问题。
注:以下文档仅仅为基本内容,相关知识点的深入学习,请看相应文档连接2:salt的安装
安装有很多途径,作为一个CentOS的用户,我选择rpm
首先添加RPM源:
rpm -ivh http://mirrors.sohu.com/fedora-epel/6/x86_64/epel-release-6-8.noarch.rpm
附:实际生产中我是自建源
epel中关于salt的包:
salt-api.noarch : A web api for to access salt the parallel remote execution system
salt-master.noarch : Management component for salt, a parallel remote execution system
salt-minion.noarch : Client component for salt, a parallel remote execution system
salt.noarch : A parallel remote execution system
salt-cloud.noarch : Generic cloud provisioning tool
1:服务端
1:安装
yum install salt-master -y
2:配置文件
/etc/salt/master
配置文件选项介绍:http://docs.saltstack.com/ref/configuration/master.html
最基本字段:
interface: 服务端监听IP
3:运行
调试模式:
salt-master-l debug
后台运行:
salt-master-d
作为CentOS管理员,我选择:
/etc/init.d/salt-master start
4:注意事项:
1:监听端口
4505(publish_port):salt的消息发布系统
4506(ret_port):salt客户端与服务端通信的端口,主要用来接受消息
所以确保客户端能跟服务端的这2个端口通信
2:客户端
1:安装
yum install salt-minion -y
2:配置文件
/etc/salt/minion
配置文件选项介绍: http://docs.saltstack.com/ref/configuration/minion.html
最基本字段:
master: 服务端主机名
id: 客户端主机名(在服务端看到的客户端的名字)
3:运行
调试模式:
salt-minion-l debug
后台运行:
salt-minion-d
作为CentOS管理员,我选择:
/etc/init.d/salt-minion start
4:注意事项:
1:minion默认和主机名为salt的主机通信
2:关于配置文件
salt的配置文件均为yaml风格
$key: $value #注意冒号后有一个空格
3:基础知识
1:salt minion和master的认证过程:
(1) minion在第一次启动时,会在/etc/salt/pki/minion/下自动生成minion.pem(private key), minion.pub(public key),然后将minion.pub发送给master
(2) master在接收到minion的public key后,通过salt-key命令accept minion public key,这样在master的/etc/salt/pki/master/minions下的将会存放以minion id命名的public key, 然后master就能对minion发送指令了
如下:
启动服务端:
/etc/init.d/salt-minion restart
启动客户端:
/etc/init.d/salt-minion restart
服务端查看key:
salt-key
Accepted Keys:
Unaccepted Keys:
minion1
Rejected Keys:
服务端接受key
salt-key -a minion1
测试:
salt 'minion1' test.ping
minion1:
True
附:salt更多命令及手册
salt '*' sys.doc3:salt的使用:
1:基础知识
1:targeting
salt '*' test.ping
引号中以实现很强大的minion的过滤与匹配技术
文档:http://docs.saltstack.com/topics/targeting/compound.html
常用命令:
salt 'shell正则' 命令
salt -E 'prel 正则'
salt -N $group 命令
salt -L 'server_id1,server_id2,server_id3'命令
示例:
salt -C 'webserv* and G@os:Debian or E@web-dc1-srv.*' test.ping
2:nodegroup
对minion进行分组
文档: http://docs.saltstack.com/topics/targeting/nodegroups.html
在master的配置文件中按如下格式定义:
nodegroups:
group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com'
group2: 'G@os:Debian and foo.domain.com'
在state或者pillar中引用的时候如下:
base:
group1:
- match: nodegroup
- webserver
3:grains
minion基本信息的管理
文档:http://docs.saltstack.com/topics/targeting/grains.html
基本使用:
salt '*' grains.ls查看grains分类
salt '*' grains.items 查看grains所有信息
salt '*' grains.item osrelease 查看grains某个信息
示例:
salt '*' grains.item osrelease
minoin1:
osrelease: 6.2
在用salt进行管理客户端的时候或者写state的时候都可以引用grains的变量
4:pillar
salt对敏感信息的管理,只有匹配到的节点才能获取和使用
文档:http://docs.saltstack.com/topics/tutorials/pillar.html
默认:pillar数据定义文件存储路径:/srv/pillar
入口文件:/srv/pillar/top.sls
格式:
base:
"targeting":
- $pillar #名字为pillar.sls的文件来存放对匹配到的minion的变量
$pillar.sls
基本:
$key: $value
state引用方式:
复杂:
users:
thatch: 1000
shouse: 1001
utahdave: 1002
redbeard: 1003
state引用方式: 查看节点的pillar数据:
salt 'client2' pillar.data
同步pillar:
salt '*' saltutil.refresh_pillar
附:这里我们可以看到,pallar中也可以使用jinja(后面会提到)做一些处理
5:minion
即为salt的客户端
2:状态管理
1:state
salt基于minion进行状态的管理
1:state语法
文档:http://docs.saltstack.com/ref/states/all/index.html
结构:
$ID:#state的名字
$state: #要管理的模块类型
- $State states #该模块的状态
示例:
vim:
pkg:
- installed
如果是redhard系列的就安装 vim-enhanced,如果系统是Debian或者Ubuntu就安装vim-nox
附:state默认使用jinja(http://jinja.pocoo.org/)的模板语法,
文档地址:http://jinja.pocoo.org/docs/templates/
2:state的逻辑关系:
文档:http://docs.saltstack.com/ref/states/ordering.html
require:依赖某个state,在运行此state前,先运行依赖的state,依赖可以有多个
httpd:
pkg:
- installed
file.managed:
- name: /etc/httpd/conf/httpd.conf
- source: salt://httpd/httpd.conf
- require:
- pkg: httpd
watch:在某个state变化时运行此模块
redis:
pkg:
- latest
file.managed:
- source: salt://redis/redis.conf
- name: /etc/redis.conf
- require:
- pkg: redis
service.running:
- enable: True
- watch:
- file: /etc/redis.conf
- pkg: redis
附:watch除具备require功能外,还增了关注状态的功能
还有与watch 和 require相反的watch_in,require_in
order:
优先级比require和watch低
有order指定的state比没有order指定的优先级高
vim:
pkg.installed:
- order: 1 #让当前状态第一个运行,如果该状态依赖其他状态,依赖的状态会在这个状态运行前运行
想让某个state最后一个运行,可以用last
3:state与minion
临时给minoin部署个state
salt 'minion1' state.sls 'vim'#给minion1加一个vim的state
执行该命令后可以立即看到输出结果
2:highstate
给minion永久下添加状态
文档: http://docs.saltstack.com/ref/states/highstate.html
默认配置文件:/srv/salt/top.sls
语法:
'*':
- core
- wsproxy
/srv/salt/目录结构:
.
├── core.sls
├── top.sls
└── wsproxy
├── init.sls
├── websocket.py
└── websockify
应用:
salt "minion1" state.highstate
测试模式:
salt "minion1" state.highstate -v test=True
3:salt schedule
默认的state只有在服务端调用的时候才执行,很多时候我们希望minon自觉的去保持在某个状态
文档:http://docs.saltstack.com/topics/jobs/schedule.html
cat /srv/pillar/top.sls
base:
"*":
- schedule
cat /srv/pillar/schedule.sls
schedule:
highstate:
function: state.highstate
minutes: 30
如上配置:
minion会每30分钟从master拉去一次配置,进行自我配置
3:实时管理
有时候我们需要临时的查看一台或多台机器上的某个文件,或者执行某个命令
1:cmd.run
用法 salt '$targeting' cmd.run '$cmd'
示例:salt '*' cmd.run 'hostname'
执行下这样的命令,马上就感受到效果了,速度还贼快
2:module
同时,salt也将一些常用的命令做了集成
文档:http://docs.saltstack.com/ref/modules/all/index.html
这里几乎涵盖了我们所有的常用命令
比如:
查看所有节点磁盘使用情况
salt '*' disk.usage
4:其他
1:无master
文档:http://docs.saltstack.com/topics/tutorials/quickstart.html
主要应该在测试和salt单机管理的时候
2:peer
文档:http://docs.saltstack.com/ref/peer.html
提供了一种让某个或者某些minion通过master管理其他minoin的方法
既然minion都可以管理其他minion了,肯定要涉及到权限的问题,否则就乱了;peer的权限设置在master配置文件的peer块
风格如下:
peer:
.*: #有管理权限的minion节点
- .* #可以使用的module
例子:
peer:
.*example.com: #ID以example.com结尾的节点
- test.* #可以使用test模块
- ps.*#可以使用ps模块
- pkg.* #可以使用pkg模块
3:runner
官方的想法是提供了一种灵活的,快捷的调用salt的方式,通过salt-run就可以直接在minion上运行自己的代码,但是我感觉有点多余;我直接在master写也可以啊
定义runner代码目录:
master配置文件:
runner_dirs: ['/srv/salt/_runner',]
测试:
cat /srv/salt/_runner/foo.py
def test():
print "True"
salt-run foo.test
True
当然这里应该写的是关于salt的调用
官方自带的几个runner:https://github.com/saltstack/salt/tree/develop/salt/runners
4:reactor
官方文档: http://docs.saltstack.com/topics/reactor/index.html
这个模块将消息中的部分标签与部分sls绑定起来(绑定通过master的配置文件),sls定义了动作(做什么操作)
1:定义tag与sls的关系
vim /etc/salt/master
reactor:
- 'test':
- /srv/reactor/test.sls
2:定义reactor的sls
vim /srv/reactor/test.sls
clean_tmp:
cmd.cmd.run:
- tgt: '*'
- arg:
- rm -rf /tmp/*
3: 发送消息
salt-call event.fire_master '' 'test'
这个时候就可以看到 上面的哪个reactor是执行了的,也就是说所有节点的tmp目录都是空的了
这里我们注意到,第三步中执行的命令第一个参数是空的;这2个参数分布是一个data和tag;这个data可以在sls中做处理,tag就是用来触发sls的哪个标志,和master中定义的哪个需要一样
比如这个命令:
salt-call event.fire_master '{"overstate": "refresh"}' 'foo'
首先:foo代表了触发那个tag,然后执行相应的sls;然后在你的sls中可以引用这个data,上面的哪个overstate,在sls中引用的时候就需要这样:data['data']['overstate'];
这个功能就提供了无限的可能性啊,比如一个服务器出现某种问题的时候让另一个服务器做某种操作等,反正我认识这事一个非常NB,实在的功能4:salt开发
1:saltclient管理salt
只有master才可以
salt全部用python,这里也用python
文档:http://docs.saltstack.com/ref/python-api.html
示例:
import salt.client
client = salt.client.LocalClient()
ret = client.cmd('*', 'cmd.run', ['ls -l'])
print ret
2:salt api
salt api我现在还没用,不过我也没搞定,如果你搞定了,我会非常感谢你能分享下的。参考文档:
1:salt中文wiki:http://wiki.saltstack.cn/
很不错的文章:http://wiki.saltstack.cn/reproduction/dive-into-saltstack
2:salt官网http://saltstack.com/
官网文档:http://docs.saltstack.com/

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台