运维的工作主要在2方面:
- 状态的管理
- 系统性能调优
这里主要简介下运维状态的管理:
- 对 于运维来说,基于状态的配置管理已经向自动化迈进了一大步,以状态为核心的运维,让状态本身有了可管理性;在运维过程中我们会发现,同样的一个配置,我们 会在不同的时间,不同的地点一次在一次的配置,这个时候,配置管理就有了重复性;有的甚至是原封不动的重复,而另外一些则是按照一定的规律在发展,这些按 照一定规律发展的配置,就是可预测的.综上我认识的,我们运维工作的本身是可管理,可重复,可预测的.基于这样的理念,我们就可以更高一步的推进我们的运 维自动化,甚至到智能化.
看到这里,我理想中的运维自动化的配置管理平台应该有如下功能:
- 对状态的配置及管理(最基本的)
- 可以及时的对系统状态进行调整并能看到结果(可以方便的实时升级系统状态)
- 可以对其本身做方便的第三方管理(借助其API,直接给状态制定好其发展方向)
加分项:
- 开发语言单一
- 架构简单,灵活
- 有不差的安全性
- 没有商业版
下面是现有比较有代表性的自动化配置管理工具(以下仅基于开源版本进行介绍):
| 名称 | 理念 | 优缺点 |
| 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%。
saltstack的基本介绍
salt是一个新的基础平台管理工具。很短的时间即可运行并使用起来, 扩展性足以支撑管理上万台服务器，数秒钟即可完成数据传递. 经常被描述为 Func加强版+Puppet精简版。
salt的整个架构都是基于消息来实现.所以能够提供横强的拓展性,灵活性,实时性;不夸了,看实际的slat是什么样的
不过salt还是一个很年轻的东西，还有很多地方不够完善，做的不够好，不过我相信这些都只是时间问题。
注：以下文档仅仅为基本内容，相关知识点的深入学习，请看相应文档连接
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 |
服务端
安装
yum install salt-master
配置文件
- 文件名称： /etc/salt/master
- 配置文件字段选项介绍: http://docs.saltstack.com/ref/configuration/master.html
- 最基本字段： interface (服务端监听IP)
运行
- 调试模式：
salt-master -l debug
后台运行：
salt-master -d
作为centos管理员,我选择:
/etc/init.d/salt-master start
master默认监听两个端口， 4505(publish_port)为salt的消息发布系统，4506(ret_port)为salt客户端与服务端通信的端口,所以确保客户端能跟服务端的这2个端口通信
客户端
安装
yum install salt-minion
配置文件
- 配置文件: /etc/salt/minion
- 配置文件选项介绍: http://docs.saltstack.com/ref/configuration/minion.html
- 最基本字段: master: 服务端主机名 id: 客户端主机名(在服务端看到的客户端的名字)
运行
调试模式
salt-minion -l debug
后台运行
salt-minion -d
作为centos管理员,我选择:
/etc/init.d/salt-minion start
注意事项：
- minion 默认和主机名salt的主机通信
- 关于配置文件
- salt的配置文件均为yaml风格
- $key: $value #注意冒号后有一个空格
基础知识
salt minion和master的认证过程：
- minion在第一次启动时，会在/etc/salt/pki/minion/下自动生成minion.pem(private key), minion.pub(public key)，然后将minion.pub发送给master
- 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-master 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
salt的使用
基础知识
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
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
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的变量
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引用方式: {{ pillar['$key'] }}
#复杂:
users:
thatch: 1000
shouse: 1001
utahdave: 1002
redbeard: 1003
#state引用方式:
#{% for user, uid in pillar.get('users', {}).items() %}
# {{user}}:
# user.present:
# - uid: {{uid}}
#{% endfor %}
查看节点的pillar数据：
salt 'client2' pillar.data
同步pillar：
salt '*' saltutil.refresh_pillar
附：这里我们可以看到，pallar中也可以使用jinja（后面会提到）做一些处理
状态管理
state
salt基于minion进行状态的管理
state语法
$ID: #state的名字
$state: #要管理的模块类型
- $State states #该模块的状态
示例：
vim:
pkg:
{% if grains['os_family'] == 'RedHat' %}
- name: vim-enhanced
{% elif grains['os'] == 'Debian' %}
- name: vim-nox
{% elif grains['os'] == 'Ubuntu' %}
- name: vim-nox
{% endif %}
- installed
如果是redhat系列的就安装 vim-enhanced，如果系统是Debian或者Ubuntu就安装vim-nox
附：state默认使用jinja（http://jinja.pocoo.org/ ）的模板语法，文档地址：http://jinja.pocoo.org/docs/templates/
state的逻辑关系
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功能外，还增了关注状态的功能
order：优先级比require和watch低，有order指定的state比没有order指定的优先级高
vim:
pkg.installed:
- order: 1
想让某个state最后一个运行，可以用last
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
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拉去一次配置，进行自我配置
实时管理
有时候我们需要临时的查看一台或多台机器上的某个文件，或者执行某个命令
cmd.run
- 用法: salt ‘$targeting’ cmd.run ‘$cmd’
- 示例：salt ‘*’ cmd.run ‘hostname’
执行下这样的命令，马上就感受到效果了，速度还贼快
module
同时，salt也将一些常用的命令做了集成
这里几乎涵盖了我们所有的常用命令
比如：
#查看所有节点磁盘使用情况 salt '*' disk.usage
无master
主要应该在测试和salt单机管理的时候
peer
提供了一种让某个或者某些minion通过master管理其他minoin的方法。既然minion都可以管理其他minion了,肯定要涉及到权限的问题,否则就乱了;peer的权限设置在master配置文件的peer块,风格如下:
peer:
*: #有管理权限的minion节点
- .* #可以使用的module
例子：
peer:
.*example.com: #ID以example.com结尾的节点
- test.* #可以使用test模块
- ps.* #可以使用ps模块
- pkg.* #可以使用pkg模块
runner
官方的想法是提供了一种灵活的,快捷的调用salt的方式,通过salt-run就可以直接在minion上运行自己的代码,但是我感觉有点多余;我直接在master写也可以啊。在master配置文件中定义runner代码目录:
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
reactor
这个模块讲消息中的部分标签与部分sls绑定起来(绑定通过master的配置文件),sls定义了动作(做什么操作)
1. 定义tag与sls的关系
# vim /etc/salt/master
reactor:
- 'test':
- /srv/reactor/test.sls
2. 定义reactor的sls
# vim /srv/reactor/test.sls
reactor:
- 'test':
- /srv/reactor/test.sls
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、实在的功能
salt开发
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
参考文档
- salt中文wiki：http://wiki.saltstack.cn/
- salt官网http://saltstack.com/