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
...
#########################################################################################################
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 有反馈系统
puppet 5 3.5 1 1 0 0 10.5
chef 5 1 -1 -1 1 0 5
salt 4 5 1 1 1 1 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是都是非常优秀的工具.
运维自动化之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:reactor
4: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.doc
3: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/
salt qq群：294953305
author weibo：halfss (http://weibo.com/halfss)
#########################################################################################################
http://linuxtoy.org/archives/saltstack.html
这个 youtube 视频介绍了几个 配置管理工具的特点： T-DOSE 2012 Toshaan Bharvani, Puppet, Chef, CFEngine, Ansible, Salt, different approacheshttp://youtu.be/T56uN6N_hs0
视频简单介绍了它们的特点：
ansible 只有服务端，无须客户端 协义：ssh , ZeroMQ , git 配置文件格式：yaml , json
Salt server client 协义：ssh, ZeroMQ 配置：yaml, json, jinja, mako, python
配置管理，基于 python 的新秀 Ansible，Salt 使用的，还是要看社区和文档 1. salt github 2012 notale 社区参与度高 2. 文档也比较好，入门还好
Parallel execution 和 Configuration Management 是两个不同的领域，很多工具都涵盖两者，比如 Puppet （其 MCollective），Chef （knife 勉强也算但并不是其强项），Ansible （有了 Playbooks 和 Chef Cookbooks 相似）等等。
只论并行执行，Salt 某种程度上和 MCollective 相似，用了 ActiveMQ / RabbitMQ / ZeroMQ 等中间件来保证连接的一致性和稳定性。Ansible 是通过 SSH 直接连接的，并发是直接 -f 暴力用进程实现的...
- swulling 评论 @ 2013-07-18 22:50
用ssh远程执行的，偶尔为之还好，长期运行肯定不行的。。。
- 14swulling 评论 @ 2013-07-18 22:51
所以推荐saltstack用来做自动化，ansible和fabric用来做操作，
- 15Michael 评论 @ 2013-07-31 14:21
又知道了两个Python阵营的工具:Salt 和 Ansible 好文章，评论也有含量
#########################################################################################################
http://ruby-china.org/topics/12249
假如你用的是VPS或者AWS什么的
首选Rex
次选Ansible
恶意满满地介绍Salt
A Taste of Salt: Like Puppet, Except It Doesn’t Suck
http://blog.smartbear.com/devops/a-taste-of-salt-like-puppet-except-it-doesnt-suck/
我用了 Puppet 有一年多. 也是在 Vagrant 里面搭环境用. Puppet 代码 + 配置模板大概上千行. 是从自己对 Puppet 一无所知开始写起. 所以借题扯个蛋吧.
需要强调的是 Chef 我一点都没用过... 所以下面出现的 Chef 信息可能有误.
最开始接触 Puppet 和 Chef 的时候感觉一下子要学好多陌生的概念, 好讨厌. 当时 Puppet 的文档比 Chef 亲切得多, 陌生概念也比 Chef 看上去要少一点, "快使用 Vagrant" 的欲望又十分强烈, 就先从 Puppet 用起来了. 虽然 Puppet 和 Chef 默认的设计都是 Master-Agent 的架构, 但也都可以在单机内使用. 我的使用方式就是 Vagrant 提供的 puppet provisioner, 由 Vagrant 替我 ssh 进虚拟机然后跑puppet apply. Chef 的等价物是 chef-solo.
用到现在, 对 Puppet 比较恼火的有以下两点
-
执行顺序不确定(non-deterministic). 虽然说正确的做法是开发者应该显式声明依赖关系, 但 Puppet 的问题是当我犯了错误没能正确声明依赖关系的时候, 不一定会在测试中出错... Chef 就不存在这个问题. 以及, 当我需要在一个 puppet class (Chef 方面的等价物好像是叫 recipe?)里序列化地部署几个资源时, 本来是一目了然的自上而下的顺序, 却还要手动声明这几项之间的依赖关系. 另一个小问题是后来我需要在部署完成时打印一条成功提示, 由于 Puppet 没有执行顺序这回事, 所以需要用某种不整洁的 hack 才行. 甚至 Puppet 后来又引入 Stages机制用来解决此类问题......
-
Puppet 自己的语法始终觉得不习惯. 而 Chef 完全是 Ruby 语法. 似乎也存在有 Ruby 语法版的 Puppet, 这个没有仔细深究.
如果现在给我再选择一次的话, 估计会坚持把 Chef 啃下来. 不过现在这样说实在是这山望着那山高...
至于说"能在 Vagrant 中使用"这件事, 一方面要看 basebox 里是否预先安装了 Chef / Puppet. 另一方面要看 Vagrant 是否安装了 provisioner 整合支持. 官方文档里列出 Ansible, Chef, Puppet 这几个意味着内置支持. 以及 vagrant-omnibus 这个插件会帮你在虚拟机里安装 / 更新虚拟机里的 Chef. 我用的 basebox 里的 Puppet 至今还没更新过.
Puppet 出道早，用户群体更广泛，但 Puppet Server 存在性能问题。但 Opscode Chef 有后来居上之势，其社区和 Ruby 社区类似非常有激情（大量成熟的工具，比如 knife-solo, Berkshelf,librarian-chef 还有 vagrant 插件，等等，我和我的小伙伴都惊呆了）。
后者对写会写代码的更友好些（前者对 SA 更友好？），即所谓的 Infrastructure as Code 以代码（用 git 进行版本控制）的形式管理基础架构。
如果还没学 Puppet 就直接 Chef 好了，会 Ruby 懂一点 Shell 和 Linux 上手很快，瞬间就可以组装，甚至写出复杂的 cookbook 了。个人没有系统学过 Ruby 只会 Shell scripting 两周速成 Chef 完成了两个还有点复杂的 cookbooks ;-)
有人提到 Ansible 这用来做 ad-hoc 并行执行工具还可以（模块相当多），拿来做 configuration management 就够呛了，其 Playbooks 完全就是模仿 Cookbooks 远不如 Chef ...
BTW: MCollective 被 Puppet 收购了，拿来当 Parallel Execution Framework 这方面 Chef 比较欠缺，光靠 knife / knife solo 可能不行。需要用 MCollective / Ansible / Fabric 之类的工具辅助一下...
#########################################################################################################
#########################################################################################################
http://jjasghar.github.io/blog/2013/06/26/ansible-vs-chef-vs-puppet/
Ansible vs Chef vs Puppet
Intro
First off, I’m going to say I’m a chef zealot, but I’m attempting to put together an intelligent discussion of the battle that has popped up in sysadmin discussion groups now-a-days. Secondly, I’m only focusing on the three systems I have exposure to, ansible the least, puppet the second, and chef the most. I could also probably throw salt, cfengine, and others in there, but that’s superfluous, this is my discussion so I’m going to keep it in my scope.
I’m going focus on the pluses of each, and use the “Overall” section to combine them. In my conclusion my true thoughts will come out, so if you want the tl;dr I’d skip down there.
ansible
Links: homepage, a great tutorial
- Low overhead
- python based
- playbook based
To quote Wikipedia:
Ansible is an open-source software platform for configuring and managing computers. It combines multi-node software deployment, ad-hoc task execution, and configuration management. It manages nodes over SSH and does not require any additional remote software to be installed on them. Modules work over JSON and standard output and can be written in any programming language. The system uses YAML to express reusable descriptions of systems.
Probably the neatest thing about ansible is that it only requires ssh to work. You do the work on a local box, and run the “play book” and it walks through the steps. its designed to be something fast and quick to spin up boxes. The disadvantage of this is that creep can happen; you can make sure the box is what you expect but you don’t have the focused control of something like chef or puppet. If you need just a webserver that is configured one way and is disposable then this is the way to go. If you have to support something for long term though, it seems its out of scope of this product. I could be wrong but that’s how I interperat it.
chef
Links: homepage, a great tutorial
To quote Wikipedia:
chef is a configuration management tool written in Ruby and Erlang. It uses a pure-Ruby, domain-specific language (DSL) for writing system configuration “recipes” or “cookbooks”. chef was written by Opscode and is released as open source under the Apache License 2.0. chef is a DevOps tool used for configuring cloud services or to streamline the task of configuring a company’s internal servers. chef automatically sets up and tweaks the operating systems and programs that run in massive data centers.
As I said in the intro, I love chef. Hell if I could I’d probably work for opscode. As soon as I got my head wrapped around chef (which is chef’s main problem), its quick and efficient, and its slick. I’ve only ever used chef with a chef server, never really touched chef-solo. I also leveraged chef-zero in my testing because I like the idea of uploading the cookbooks and pulling them down. Having cookbooks on a centralized chef server, its a true “system of record” that doesn’t rely on your laptop or workstation, if you do a knife server create 'role[web]' you know what you are going to get.
Something I would like to say though, a huge disadvantage of chef is the way cookbooks are controlled. It requires constant babying, or plugins like knife-sporkto make sure people don’t mess with each others work. I am lucky enough to work in an environment with only 2 others that have any real use for chef, so I am able to be a good gatekeeper. I could only imagine the cluster with larger teams. As of 6/26/13 I know this is a conversation topic and pain point, I’d be interested to see how the workflow matures.
puppet
Links: homepage, a great cheat sheet
To quote Wikipedia:
puppet is a tool designed to manage the configuration of Unix-like and Microsoft Windows systems declaratively. The user describes system resources and their state, either using puppet’s declarative language or a Ruby DSL (domain-specific language). This information is stored in files called “puppet manifests”. puppet discovers the system information via a utility called Facter, and compiles the puppet manifests into a system-specific catalog containing resources and resource dependency, which are applied against the target systems. Any actions taken by puppet are then reported.
Something I’ve always loved about puppet is the trifecta. You can easily create a manifest to control the package/file/service in only a few lines. (check that cheat sheet above for an example) I was able to take over an infrastructure in an extremely short period of time with just that. I didn’t have that long to control every facet of the groupings but the investment to the reward was mind boggling fast.
Overall
Ok, now that my little tl;dr of the pluses are done, I can start my views overall. puppet is a very “eins, zwei, eins, zwei,” type application. With marrying it with something like cobbler you can in theory rack mount a machine, hit the power button and have a machine exactly how you want it to be in “x” about of time. This is great for big companies that always want machines to cookie cutter. It could be that that’s how I saw puppet being used, but comparing them to the two other config management systems; it really fits. Speaking of cobbler, yes, I do understand you can leverage cobbler with each of these tools, but as you can see it just seems that cobbler and puppet are a match made in heaven. chef on the other hand seems like it’s designed for smaller companies with smaller teams. It looks for cooperation, nay, requires cooperation, and its to its strength and its weakness. Unlike puppet, chef doesn’t default to an “active” mode (Ok, that’s not fully true about puppet either, but the better practice is to have puppet in active mode from the get go). puppet runs by default every 30 mins, to make sure its what you want to be, chef on the other hand is a pull based config-management that they even suggest “putting chef-client” in your crontab. This originally bothered me, coming from the puppet world, but as i learned more about chef i realized that isn’t its bread and butter. chef is a way to spin up boxes for an elastic environment like AWS. You have a massive blast of traffic, chef will trigger throw your machines in the load balancer, install apache or whatever, and you have what you expect, and 2-3 hours later you blow it away. This is different than ansible because it is not “automated” per se. Remember the play books site in your local machine, you have interact with the provisioning, which for a startup seems like the correct path. In a startup you have to know exactly what machines are running, not only because of OPEX but because its your baby, you want focus and tweak; you probably don’t have the budget to just blow away the boxes.
Conclusion
So I’ll say this because I believe this: each of these tools are for different “size” infrastructures. You can argue as much as you want; saying that “yes well you can use each in of the different sizes”, but they were all seem to have a natural fit. puppet for the corporate/enterprise space, chef for the the small corporate/budding-enterprise space, and ansible for the start ups.
前一段时间调研过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,后还有几个笔误的地方。