运维自动化之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-saltstack2：salt官网http://saltstack.com/官网文档：http://docs.saltstack.com/