saltstack 使用

salt '*' cmd.run 'sed -i 's/SELINUX\=enforcing/SELINUX\=disabled/g' /etc/sysconfig/selinux'

===================================================

http://zhengbin.blog.51cto.com/2989505/1229891

检查master与minion的连接状态：salt '*' test.ping

远程执行命令：salt ‘*’ cmd.run 'ls /home'

从master上传文件至minion：

salt-cp nodeid source_file target_file

例子：salt-cp '*' /home/abc /home

master同步命令：

salt '*' state.highstate

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

http://www.geedoo.info/salt-use-notes.html

Grains使用

节点信息(grains)

# 查看grains分类
salt ‘*’ grains.ls

# 查看grains所有信息
salt ‘*’ grains.items

# 查看grains某个信息
salt ‘*’ grains.item osrelease

自定义Grains

自定义grains 就是想客户端汇报你想要的数据到服务器，这个可以通过2个方法实现第一个是在服务器端往客户端推（可以过滤指定客户端）第二个就是直接在客户端配置文件里面编辑。下面说第二种方法：

新建grains配置文件：

vim /etc/salt/minion.d/grains_test.conf 填写一些数据;

grains:
  Wen: 1
  Liu: 2
  List:
    - a
    - b
    - c

好了重启miinon服务，在master上查看
salt "Master.Hadoop" grains.items

[root@Master ~]# salt "Master.Hadoop" grains.items 
Master.Hadoop:
  List:
      a
      b
      c
  Liu: 2
  Wen: 1

想法：利用这个特性，做个数据收集系统。通过程序去修改客户端配置文件的属性。缺点：要重启minion

Pillar使用

pillar 是在master服务器上定义的默认安装没有这个文件夹自己新建一个就行，目录要和/etc/salt/master中的pillar_roots一致

mkdir /srv/pillar/ && touch /srv/pillar/top.sls

base:
  '*':
    - sc

不多说，这里配置和含义和state差不多

新建sc.sls，填入相应的数据：

[root@Master pillar]# cat sc.sls 
a: 1
b: 2
c: )))))))))))))))))

OK 配置完后我们查看下吧有没有生效

在服务器端运行 salt ‘*′ pillar.data

从结果中可以看到相应的值。

总结：其实pillar和state很类似，不同的是state描述的是状态，pillar描述的是kv的变量。

参考：http://www.shencan.net/index.php/2013/05/24/saltstack-%E4%BA%8C-grains%E5%92%8Cpillar/

Salt cp命令使用

大集群下文件分发如果使用scp来做的话，呵呵，累死不偿命啊！

今天教大家尝试使用salt-cp功能来实现文件分发。

我想做的事情：由于我的hadoop集群有很多项目，都是安装cdh4的rpm包，因此有很多项目的配置文件是分开的，但是又集中在/etc下。我想每次修改完配置可以使用一个命令直接分发修改的目录（或文件）到个节点。以前是使用scp，但是集群大了，没法干了。

解决方法:

让salt文件服务器管理/etc目录，修改配置/etc/salt/master：

file_roots:
   base:
     - /srv/salt/
     - /etc
   dev:
     - /srv/salt/dev/services
     - /srv/salt/dev/states

只是在base下添加了/etc目录作为salt文件服务器的另一个文件目录。

重启salt-master。

参看目录是否存在，存在则说明配置成功：
salt '*' cp.list_master_dirs

查看master上的文件：
salt '*' cp.list_master

分发文件：
salt '*' cp.get_file salt://path/to/file /minion/dest

分发目录：
salt '*' cp.get_dir salt://path/to/dir/ /minion/dest

例子：
salt '*' cp.get_dir salt://impala/ /etc/

总结：好了，是不是很方便啊？如果可以的话直接配置成根目录，那就可以管理系统所有文件 / 目录了

参考：salt.modules.cp

定时任务（cron）

查看某用户的定时任务，如 root用户：
salt '*' cron.list_tab root
同上，查看的是文本形式
salt '*' cron.raw_cron root
移除某用户的定时任务：
salt '*' cron.rm_job root /usr/local/weekly
设置某用户的定时任务：
salt '*' cron.set_job root '*' '*' '*' '*' 1 /usr/local/weekly
例如：

salt "*" cron.set_job root 0 1 '*' '*' '*' '/usr/sbin/ntpdate cn.pool.ntp.org'
注意： * 要加引号，最后一个参数也要加引号，不然会当成两个参数

http://www.ituring.com.cn/article/41632

参考链接：原文Salt File Server, 官网文档cp模块

在配置管理系统中，从中心服务器想客户端推送文件是很基本的需求。SaltStack使用内建的ZeroMQ服务器做为文件服务器。文件服务器主要用来在state系统中推送文件到客户端，也可以用于其他文件的传输。

cp模块

客户端对文件服务器的操作都在cp模块中。Salt State系统，Salt-cp都用到了cp模块。

环境

因为文件服务器是为Salt state系统服务，所以也支持环境的概念。master的配置文件中定义各环境的路径，文件的路径基于指定环境的根目录（参见下面的例子）。

常见用法

get_file

cp.get_file用来从master下载文件到客户端，语法如下：

# salt '*' cp.get_file salt://vimrc /etc/vimrc

其中vimrc在master上的实际路径要看环境中定义的根目录，假设在master中有如下定义：

file_roots:base:-/srv/salt/

那么vimrc的实际路径就是/srv/salt/vimrc，这样做的好处是，可以满足state系统中环境的概念。

源路径和目标路径中都可以使用模板，如下：

# salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja

这个例子中，将下载与客户端操作系统名字相同的目录下的文件。

对于大文件，cp.get_file支持gzip压缩，在参数中指定gzip的压缩级别，如下:

# salt '*' cp.get_file salt://vimrc /etc/vimrc gzip=5

其中，1代表作小压缩，9代表最大压缩。

cp.get_file默认不在客户端上建立目录，如果客户端上没有这个目录了，文件拷贝将失败，可以指定makedirs=True来创建目录：

# salt '*' cp.get_file salt://vimrc /etc/vim/vimrc makedirs=True

在这个例子中，如果``/etc/vim不存在，将会建立此目录。

get_dir

cp.get_dir可以从master下载整个目录，语法如下：

# salt '*' cp.get_dir salt://etc/apache2 /etc

cp.get_dir也支持模板和压缩：

# salt '*' cp.get_dir salt://etc/{{pillar.webserver}} /etc gzip=5 template=jinja

get_url

cp.get_url可以从一个URL地址下载文件，URL可以是msater上的路径（salt://），也可以是http网址。

salt '*' cp.get_url salt://my/file /tmp/mine
salt '*' cp.get_url http://www.slashdot.org /tmp/index.html

get_template

cp.get_template可以在文件下载之前用模板引擎处理。

salt '*' cp.get_template salt://path/to/template /minion/dest

push

cp.push可以从客户端传文件到master上，处于很明显的安全考虑，默认没有启用此功能，如果你需要的话可以参考文档，很方便的开启。

http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cp.html

21.16.28. salt.modules.cp

Minion side functions for salt-cp

salt.modules.cp.cache_dir(path, saltenv='base', include_empty=False, include_pat=None,exclude_pat=None, env=None)

Download and cache everything under a directory from the master

include_pat : None: Glob or regex to narrow down the files cached from the given path. If matching with a regex, the regex must be prefixed with E@, otherwise the expression will be interpreted as a glob.

New in version Helium.
exclude_pat : None: Glob or regex to exclude certain files from being cached from the given path. If matching with a regex, the regex must be prefixed with E@, otherwise the expression will be interpreted as a glob.

Note

If used with include_pat, files matching this pattern will be excluded from the subset of files defined byinclude_pat.

New in version Helium.

CLI Examples:

salt '*' cp.cache_dir salt://path/to/dir
salt '*' cp.cache_dir salt://path/to/dir include_pat='E@*.py$'

salt.modules.cp.cache_file(path, saltenv='base', env=None)

Used to cache a single file in the local salt-master file cache.

CLI Example:

salt '*' cp.cache_file salt://path/to/file

salt.modules.cp.cache_files(paths, saltenv='base', env=None)

Used to gather many files from the master, the gathered files will be saved in the minion cachedir reflective to the paths retrieved from the master.

CLI Example:

salt '*' cp.cache_files salt://pathto/file1,salt://pathto/file1

salt.modules.cp.cache_local_file(path)

Cache a local file on the minion in the localfiles cache

CLI Example:

salt '*' cp.cache_local_file /etc/hosts

salt.modules.cp.cache_master(saltenv='base', env=None)

Retrieve all of the files on the master and cache them locally

CLI Example:

salt '*' cp.cache_master

salt.modules.cp.get_dir(path, dest, saltenv='base', template=None, gzip=None, env=None)

Used to recursively copy a directory from the salt master

CLI Example:

salt '*' cp.get_dir salt://path/to/dir/ /minion/dest

get_dir supports the same template and gzip arguments as get_file.

salt.modules.cp.get_file(path, dest, saltenv='base', makedirs=False, template=None, gzip=None,env=None)

Used to get a single file from the salt master

CLI Example:

salt '*' cp.get_file salt://path/to/file /minion/dest

Template rendering can be enabled on both the source and destination file names like so:

salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja

This example would instruct all Salt minions to download the vimrc from a directory with the same name as their os grain and copy it to /etc/vimrc

For larger files, the cp.get_file module also supports gzip compression. Because gzip is CPU-intensive, this should only be used in scenarios where the compression ratio is very high (e.g. pretty-printed JSON or YAML files).

Use the gzip named argument to enable it. Valid values are 1..9, where 1 is the lightest compression and 9 the heaviest. 1 uses the least CPU on the master (and minion), 9 uses the most.

salt.modules.cp.get_file_str(path, saltenv='base', env=None)

Return the contents of a file from a URL

CLI Example:

salt '*' cp.get_file_str salt://my/file

salt.modules.cp.get_template(path, dest, template='jinja', saltenv='base', env=None,makedirs=False, **kwargs)

Render a file as a template before setting it down. Warning, order is not the same as in fileclient.cp for non breaking old API.

CLI Example:

salt '*' cp.get_template salt://path/to/template /minion/dest

salt.modules.cp.get_url(path, dest, saltenv='base', env=None)

Used to get a single file from a URL.

CLI Example:

salt '*' cp.get_url salt://my/file /tmp/mine
salt '*' cp.get_url http://www.slashdot.org /tmp/index.html

salt.modules.cp.hash_file(path, saltenv='base', env=None)

Return the hash of a file, to get the hash of a file on the salt master file server prepend the path with salt://<file on server> otherwise, prepend the file with / for a local file.

CLI Example:

salt '*' cp.hash_file salt://path/to/file

salt.modules.cp.is_cached(path, saltenv='base', env=None)

Return a boolean if the given path on the master has been cached on the minion

CLI Example:

salt '*' cp.is_cached salt://path/to/file

salt.modules.cp.list_master(saltenv='base', prefix='', env=None)

List all of the files stored on the master

CLI Example:

salt '*' cp.list_master

salt.modules.cp.list_master_dirs(saltenv='base', prefix='', env=None)

List all of the directories stored on the master

CLI Example:

salt '*' cp.list_master_dirs

salt.modules.cp.list_master_symlinks(saltenv='base', prefix='', env=None)

List all of the symlinks stored on the master

CLI Example:

salt '*' cp.list_master_symlinks

salt.modules.cp.list_minion(saltenv='base', env=None)

List all of the files cached on the minion

CLI Example:

salt '*' cp.list_minion

salt.modules.cp.list_states(saltenv='base', env=None)

List all of the available state modules in an environment

CLI Example:

salt '*' cp.list_states

salt.modules.cp.push(path)

Push a file from the minion up to the master, the file will be saved to the salt master in the master's minion files cachedir (defaults to /var/cache/salt/master/minions/minion-id/files)

Since this feature allows a minion to push a file up to the master server it is disabled by default for security purposes. To enable, set file_recv to True in the master configuration file, and restart the master.

CLI Example:

salt '*' cp.push /etc/fstab

salt.modules.cp.push_dir(path, glob=None)

Push a directory from the minion up to the master, the files will be saved to the salt master in the master's minion files cachedir (defaults to /var/cache/salt/master/minions/minion-id/files). It also has a glob for matching specific files using globbing.

New in version Helium.

Since this feature allows a minion to push files up to the master server it is disabled by default for security purposes. To enable, set file_recv to True in the master configuration file, and restart the master.

CLI Example:

salt '*' cp.push /usr/lib/mysql
salt '*' cp.push_dir /etc/modprobe.d/ glob='*.conf'

salt.modules.cp.recv(files, dest)

Used with salt-cp, pass the files dict, and the destination.

This function receives small fast copy files from the master via salt-cp. It does not work via the CLI.

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

http://www.shencan.net/index.php/2013/08/29/saltstack%E5%8D%81%E4%B8%80-%E5%88%A9%E7%94%A8salt-api%E7%BC%96%E5%86%99%E5%91%BD%E4%BB%A4%E6%89%A7%E8%A1%8C%E6%A8%A1%E5%9D%97%EF%BC%88%E5%B8%A6%E6%97%A5%E5%BF%97%E8%AE%B0%E5%BD%95%EF%BC%89/

好久没写博客了，最近没事也很少看salt了今天没事看了下 salt的模块因为我很少用到salt自带的模块（cmd.run除外）今天没事过了几个模块发现很多模块都引用了 salt.utils logging这2个模块第一个模块是salt自带的第2个模块就不讲了大家都知道就是记录日志的，

下面说下我的需求吧我们因为做了 saltstack UI 以后执行命令都在web界面上，我们想做一个记录查询系统（就是什么用户什么时候执行了什么命令返回的结果是什么）。其实这个功能我们完全可以在后台执行命令的时候加一个return 把东西都丢到数据库里面去（其实这个已经实现了）。今天想利用logging模块跟salt.utils重新写个。哎。。。。其实我python MD 太菜了很多源码都看不懂很多东西都不会操蛋呀。。

我这里自定义了一个模块

直接贴代码吧 cpis.py

这个模块是干啥的呢我简单介绍了下

salt.utils 这个模块很关键其实他就是 __salt__ 这个东西我这里用了他的cmd.run

logging 这个是python 的日志记录的东东

我这个脚本的功能是实现salt 的cmd.run 的功能就是执行命令的但是我这里我加了一个把执行的过程都记录到一个日志文件了（以后要对这个日志文件进行分析）

看演示吧大家就明白了记得同步哟

这个跟cmd.run 没区别你懂的

你再看看那个日志文件

知道了吧多了一个日志记录功能

哎。。其实也没啥先写这么多吧 python 不好真的md 是硬伤呀很多东西看不懂。。没事还是去补补python吧

先写这么多吧下面补点吧这个内容是不是有点少了

=================================
http://my.oschina.net/u/877567/blog/182923

saltstack

简述

Salt 和 Puppet Chef 一样可以让你同时在多台服务器上执行命令也包括安装和配置软件。Salt 有两个主要的功能：配置管理和远程执行。

源码: https://pypi.python.org/pypi/salt
文档: http://docs.saltstack.com/

安装

debian/ubuntu

设置debian更新源

1
wget -q -O- "http://debian.saltstack.com/debian-salt-team-joehealy.gpg.key" | apt-key add -

2
echo "deb http://debian.saltstack.com/debian wheezy-saltstack main" /etc/apt/sources.list

设置ubuntu更新源

1
add-apt-repository ppa:saltstack/salt 或

2
echo deb http://ppa.launchpad.net/saltstack/salt/ubuntu `lsb_release -sc` main | tee /etc/apt/sources.list.d/saltstack.list

3
wget -q -O- "http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x4759FA960E27C0A6" | apt-key add -

安装软件包

apt-get update
apt-get install salt-master      # On the salt-master
apt-get install salt-minion      # On each salt-minion
apt-get install salt-syndic

RHEL6/CentOS6

设置RHEL/CentOS更新源

rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm或

rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm/

[epel]
name=Extra Packages for Enterprise Linux 6
baseurl=http://download.fedoraproject.org/pub/epel/6/x86_64
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

安装软件包

yum update
yum install salt-master # On the salt-master
yum install salt-minion # On each salt-minion

基本配置

saltstack 的配置文件格式

Salt默认使用PyAMl语法(http://pyyaml.org) 作为它的模板文件的格式，其他很多模板语言在Salt中是可以使用的。
一定要按照正确的格式书写YAML,比如最基本的，它使用到两个空格代替tab，：或 - 后面要有空格。

例一：

interface: 0.0.0.0
log_file: /var/log/salt/master 
key_logfile: /var/log/salt/key

例二：

file_roots:
  base:
    - /srv/salt

服务端配置

主控端基本设置
编辑配置文件 /etc/salt/master,修改如下所示配置项，去掉前面的注释符

interface: 0.0.0.0                  # interface (服务端监听IP),0.0.0.0 是监听所有IP
log_file: /var/log/salt/master      # 记录主控端运行日志
key_logfile: /var/log/salt/key      # 记录认证证书日志

master默认监听两个端口， 4505(publish_port)为salt的消息发布系统，4506(ret_port)为salt客户端与服务端通信的端口,所以确保客户端能跟服务端的这2个端口通信

客户端配置

受控端基本设置
编辑配置文件 /etc/salt/minion,修改如下所示配置项，去掉前面的注释符#

master: 42.121.124.237          # 设置主控端IP
id: ubuntu-server-001           # 设定受控端编号
log_file: /var/log/salt/minion  # 记录受控端服务日志
key_logfile: /var/log/salt/key  # 记录认证证书日志

最基本字段:

master: 服务端，
主机名 id: 客户端主机名(在服务端看到的客户端的名字，可以不设置，默认与hostname相同)

小技巧：查看配置文件信息，过滤注释语句

sed -e '/^#/d;/^$/d' /etc/salt/minion

检查服务

主控端，和受控端启动各自的服务，确保服务启动后没有任何报错信息,如果异常请检查相应日志文件处理

主控端: service salt-master restart
受控端: service salt-minion restart

证书管理

如果一切顺利，请继续！

saltstack 主控端是依靠openssl证书来与受控端主机认证通讯的，受控端启动后会发送给主控端一个公钥证书文件，在主控端用 salt-key 命令来管理证书。

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发送指令了

salt-key -L               # 用来查看证书情况
salt-key -a 

 

 
  
 
  
     # 用来管理接受证书

受控端证书认证后会显示如下情形：

Accepted Keys:
ubuntu-server-001
Unaccepted Keys:
Rejected Keys:

主控端和被控端的证书默认都存放在 /etc/salt/pki/ 中，如果遇到证书不生效的情况下，可在主控端证书存放目录删除受控端证书，重新认证一下。

简单的测试

你可以从master 使用一个内置命令 test.ping 来测试他们之间的连接

salt '*' cmd.run test.ping

它应该有如下输出:

ubuntu-server-001: 
  True

测试与外网的连接

salt '*' cmd.run "ping -c 4 baidu.com"

salt更多命令及手册

salt '*' sys.doc

如果能返回正确结果，salt的基本配置就完成了。

salt的基本使用

salt按照操作模式可以分为实时管理和配置管理：

远程执行，也可以称为实时管理：通过执行命令来完成管理任务，优点就是实时性高，缺点就是无法跟踪，保存配置状态；
配置管理，也可以称为状态管理：通过编写特定的文件用来记录目标系统的配置状态，然后将这些受控主机会定期同步这些配置状态信息；

实时管理

有时候我们需要临时的查看一台或多台机器上的某个文件，或者执行某个命令，最通用的模块是 cmd.run

基本操作命令通用格式

格式: 命令 对象 执行模块 参数
示例：salt '*' cmd.run "ping -c 4 baidu.com"

'*' target,操作对象，可以使用salt命令的扩展模式 -E -G 等
cmd.run func，执行模块，函数
参数 args，传递给执行模块的参数,

salt也将一些常用的命令做了集成,比如,查看所有节点磁盘使用情况:

salt '*' disk.usage

其他命令示例：

salt '*' grains.ls      查看grains分类
salt '*' grains.items   查看grains所有信息
salt '*' grains.item osrelease 查看grains某个信息
salt '*' pillar.items   查看pillar所有信息

更多请参考文档：http://docs.saltstack.com/ref/modules/all/index.html

nodegroup

作用：对minion进行分组

参考文档: http://docs.saltstack.com/topics/targeting/nodegroups.html

编辑 /etc/salt/master 启用分组，最基本分组示例：

nodegroups:
  UBUNTU: 'ubuntu-12.04-*'
  CENTOS: 'centos-6.4-*'

建立分组之后,操作对象使用分组功能才生效，更多示例：

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

请确保这条属性存在

- match: nodegroup

更多请参考文档：http://docs.saltstack.com/topics/targeting/nodegroups.html

targeting

从最基本的测试命令来讲述：

salt '*' test.ping

引号中以实现很强大的minion的过滤与匹配技术

常用命令:

salt 'shell正则' 命令
salt -E 'prel 正则' 命令
salt -N  GroupName  命令
salt -L 'server_id1,server_id2,server_id3' 命令

示例:

salt -C 'webserv* and G@os:Debian or E@web-dc1-srv.*' test.ping

更多请参考官方文档: http://docs.saltstack.com/topics/targeting/compound.html

配置管理，或称状态管理

个人理解，管理一个服务器应用可以从软件包,配置文件,服务管理这个三个最基本角度来出发，要启用配置管理，首先应对受控端进行额外的配置

配置受控端

配置受控端主机,以root用户身份来接受主控端主机的管理

编辑/etc/salt/minion

user: root

配置主控端，开启配置管理功能

Salt的配置管理指令和文件保存在默认在/srv/salt目录下，这里存放着所有的配置文件，和一些你想要拷贝到从服务器的文件。

配置主控端，编辑 /etc/salt/master 文件

file_roots:
  base:
    - /srv/salt

手动创建目录和配置文件 /srv/salt/top.sls

/srv/salt/top.sls 为默认入口配置文件，这个配置项可以自定义，基本配置如下：

base:
  '*':
    - ubuntu.vim

详细解释一下这个本配置文件的参数

base: 默认的的起点配置项：
'*': 这个引号内的是匹配对象，针对所有受控主机
ubuntu.vim 就是指资源文件/srv/salt/ubuntu/vim.sls

一个简单的例子：ubuntu 基本系统默是不安装 vim 我们可以利用配置管理把被托管的ubuntu主机全部安装上vim

编辑 /srv/salt/ubuntu/vim.sls

vim:
  pkg:
    - name: vim
    - installed

执行命令

salt '*' state.highstate

请注意观察返回结果，查看/var/log/salt/下面的日志来调试saltstack配置。

稍微复杂的例子：管理ssh服务

一个更复杂的例子：管理ssh服务，并且使用salt托管配置文件

/srv/salt/top.sls 内容：

base:
  '*':
    - ubuntu.ssh

/srv/salt/ubuntu/ssh.sls

ssh:
  pkg:
    - name: ssh
    - installed
  service:
    - name: ssh
    - running
    - reload: True
    - watch:
      - file: /etc/ssh/ssh_config
/etc/ssh/ssh_config:
  file.managed:
    - source: salt://ubuntu/ssh_config
    - user: root
    - group: root
    - mode: 644

简要解释一下配置文件

pkg, service , file 这些都是salt的管理模块,pkg 是包管理模块; file是文件管理模块; service 是包服务管理模块
模块下一级是各个管理模块配置项的属性，以 service: 模块为例
name: ssh ubuntu下的服务脚本名称是 ssh
running 状态是持续运行，如果受控端配置了自动同步，每格一段时间就会对其状态进行检查
reload: True 是否重载服务
watch: 监视文件
最后两条属性的整体含义是如果配置文件 /etc/ssh/ssh_config 发生变化，服务重启更新
source: salt://ubuntu/ssh_config 托管的配置文件实际存储在 /srv/salt/ubuntu/ssh_config

同样，使用如下命令来验证结果需要

salt '*' state.highstate

参考

二进制软件包

rpm deb 不同包管理体系，不同发行版二进制包拆分命名规则不尽相同,相比之下 deb 拆分的力度要更细些。

RHEL6/CentOS 软件包列表

salt
salt-master
salt-minion
salt-api
salt-cloud

Deian/Ubuntu 软件包列表

salt-master
salt-minion
salt-syndic
salt-doc
salt-common
salt-cloud
salt-cloud-doc
salt-api
salt-ssh

下面按照服务端（主控端）和客户端（受控端）来说明主要功能项。

主控端命令列表

/usr/bin/salt 主控命令
/usr/bin/salt-cp 批量复制文件
/usr/bin/salt-key 证书管理
/usr/bin/salt-master 服务端程序
/usr/bin/salt-run 管理虚拟机
/usr/bin/salt-ssh 管理ssh
/usr/bin/salt-syndic master分布式节点服务程序

受控端命令列表

/usr/bin/salt-call
/usr/bin/salt-minion 客户端程序

启用扩展配置文件目录

主控端 /etc/salt/master
```
default_include: master.d/*.conf
```
受控端 /etc/salt/minion
```
default_include: master.d/*.conf
```

命令示例

salt

测试与受控主机网络是否通畅
```
salt '*' cmd.run test.ping
```
在全部受控主机行执行命令
```
salt '*' cmd.run “uptime”
```
使用 -E 按照正则匹配操作对象
```
salt -E 'ubuntu*' cmd.run “uptime”
```

使用 -N 按照分组匹配操作对象

salt -N 'UBUNTU-GROUPS' cmd.run “uptime”

使用 -G 按照查询信息匹配操作对象选项
```
salt -G 'cpuarch:x86_64' grains.item num_cpus
```
查看受控端模块函数帮助信息
```
salt '*' sys.doc
```
查看受控端模块函数帮助信息
```
salt '*' sys.doc service
```

salt-master

启动服务
```
salt-master -d
```

salt-key

查看证书
```
salt-key -L
```
接受指定的证书
```
salt-key -a KeyName
```
接受所有未认证的证书
```
salt-key -A
```
删除所有证书
```
salt-key -D
```
删除指定的证书
```
salt-key -d KeyName
```

salt-cp

*批量复制文件到受控主机

salt-cp '*' /home/vmdisk.img /var/lib/libvirtsh/vmdisk.img

*拷贝小文件很有效，简单测试，拷贝2.5MB以上的文件就会超时报错

salt-run

salt-run 是用于管理虚拟机的命令

查询虚拟机信息
```
salt-run virt.hyper_info
```
查询虚拟机信息
```
salt-run virt.query
```

基于云镜像创建一个新的虚拟机

salt-run virt.init centos1 2 512 salt://centos.img

salt-ssh

编辑配置文件 /etc/salt/roster

ubuntu-12.04-001:
host: 10.8.0.18
user: root
passwd: root
sudo: True

简单的测试
```
salt-ssh '*' test.ping
```
测试执行命令
```
salt-ssh '*' -r “ifconfig -a”
```

salt-syndic

salt的master和minion的交互很大程度上都和网络有关系,比如在管理多个国家的机器的时候(比如大中华局域网),一个master控制多个master,同时被控制的master又可以控制很多的minion，就好比是在 master 和 minions 之间又加了一层的分布式架构。

salt-minion

启动服务

salt-minion -d

salt-call

内置模块列表

内置的状态模块的完整列表： http://docs.saltstack.com/ref/states/all/index.html
内置的执行模块的完整列表： http://docs.saltstack.com/ref/modules/all/index.html

参考文档

http://netkiller.github.io/linux/management/saltstack/
http://blog.halfss.com/blog/2013/06/15/saltxiang-guan-shi-yong/
http://www.ituring.com.cn/article/42398

唧唧歪歪

saltstack 可能由于比较新的缘故，版本之间支持的模块差异较大，建议最好主控端，受控端使用相同版本的软件包，比如ssh_auth模块从0.17.2版本才开始出现。

问题：

证书管理 ssh_auth salt 模块.优先处理（已完成)
配置仓库，符号链接（已完成）
salt配置仓库能否托管目录？（已完成）
一台机器是否属于多个组？（已完成）
salt 配置仓库致命错误情况能否回滚？（已完成）
是否支持，配置模板（已完成）
怎么支持自定义的模块（部分）
如何输出给程序解析结果？（已完成）
如何针对特例机器进行定义配置？
是否支持 lsattr 如何保证重要配置文件不轻易被更改
主机列表管理功能，查询当前主机列表的托管状态
自动计划任务以及，以及远程执行结果跟踪分析，
细粒度的主机权限认证控制，（LDAP）
salt-call

建议:

主机命名分组避免使用正则表达式

FAQ:

A: Salt配置仓库托管的配置文件是否支持符号链接？
Q: Salt配置仓库支持文件符号链接。
A: salt 配置仓库中配置项存在致命错误情况能否回滚？
Q: 主要保证受控端主机网络通畅，配置仓库结合svn版本控制工具，就可以实现回滚功能。
A: salt 是否支持测试执行？
Q: Salt支持执行测试，需要做的仅仅是将Test设置为True
```
salt 'minion1.example.com' state.highstate -v test=True
```
A: salt 是否支持配置模板?
Q: Salt默认使用yaml_jinja渲染器，还支持其他渲染器，包括：yaml_mako，使用Mako模板引擎；yaml_wempy，使用Wempy模板引擎；py，直接使用Python写SLS文件；pydsl，建立在Python语法基础上的描述语言。
A: 如何输出给程序解析结果？
Q: salt 可以将执行结果是输出为json格式，yaml等格式，见salt PDF文档 756 页！例如:
```
salt '*' test.ping --out json
state.show_highstate --out yaml
state.show_sls edit.vim --out pprint
```

========================================

http://www.cnblogs.com/alexyang8/p/3445333.html

简介

系统管理员（SA）通常需要管理和维护数以百计的服务器，如果没有自动化的配置管理和命令执行工具，那么SA的工作将会变得很繁重。例如，要给集群中的每个服务器添加一个系统用户，那么他必须登陆到每台服务器上去逐一的执行命令。好在有编程能力的SA能通过bash + ssh的方式来自动化自己的工作，于是出现了ClusterShell这一类的工具。但这类工具只是解决了远程命令调用的问题，并没有对一些运维的过程进行抽象，在面对不同的操作系统等环境时，使用会变得复杂和繁琐，对常见的运维操作，如包管理、配置文件分发也没有很好的支持。于是出现了CFEngine，Puppet，Chef，Salt等工具，他们在远程命令执行的基础上对一些常见的运维操作进行了抽象，如节点分组、命令编排、状态管理等。

Salt正是其中年轻一员，它是一个使用Python和ZeroMQ开发的开源项目，使用Apache 2.0 License。Salt的主要功能有两个：1）配置管理，使节点处于所定义的状态，如指定web类节点apache包的状态为安装并运行；2）分布式的命令执行系统，一方面分发命令到节点执行，另一方面从节点收集所需的数据。

特点

（翻译自官方介绍http://salt.readthedocs.org/en/latest/topics/index.html）

1）简单

salt能适用于不同规模的部署，安装和维护都很简单。

2）并行执行

由master向Minion发出的命令是并行执行的，而不是串行；
master与Minion之间的使用加密的协议；
尽可能的使网络负载降低，提高网络传输效率；
提供简单的编程接口；

3）基于成熟的技术

使用ZeroMQ进行网络通信；
使用AES对通讯进行加密；
使用msgpack作为数据序列化的格式；

4）快、灵活、可扩展

架构

Salt主要由三个部分组成：

salt-master：安装有salt-master的节点我们称作Master节点，它负责存储配置信息、对可信的Minion节点进行授权、通过ZeroMQ与Minion节点进行交互。
salt-minion：安装有salt-minion的节点称作Minion节点，salt-minion就是一个agent进程，通过ZeroMQ接收来自master的命令，执行并返回结果；
salt-syndic：在特别庞大的部署环境中才会使用syndic，比如在多数据中心的部署中。syndic相当于一个正向代理节点，它代理了所有Master节点与Minion节点的通信。这样做一方面可以将Master的负载分担给多个syndic承担。另一方面，它也可以降低Master通过广域网访问Minion的成本，提高了安全性，使salt适用于夸数据中心的部署。

快速体验

http://docs.saltstack.com/topics/tutorials/walkthrough.html

体验的步骤如下：

为各个节点配置fqdn，并确定各个节点之间能通过fqdn互相访问，其中master节点的fqdn为salt（因为Minion节点启动后会默认向salt注册信息）；
安装salt，master节点安装salt-master，Minion节点安装salt-Minion；
确保防火墙关闭或打开指定的端口，salt-master主要使用4505和4506端口；
在master节点使用salt-key对Minion进行认证；
尝试运行命令；

核心功能

Targeting（批量操作）

批量操作是指master将选取哪些minion执行命令或同步master指定的状态。salt提供了几种方式来选取执行操作的Minion，它们分别是:

匹配minion_id

这种方式是基于匹配minion_id，minion_id在默认情况下是minion节点的fqdn。匹配的方式支持正则表达式、通配符、列表，如：

salt ‘*' test.ping                               //选取所有的minion执行test.ping命令
salt -E 'web1-(prod|devel)' test.ping            //选取web1-prod或web1-devel去执行命令
salt -L 'web1,web2' test.ping                    //选取web1和web2
salt ‘web*' test.ping                            //选取所有以web为前缀的节点执行

Grains，基于minion信息的匹配

Grains是指minion节点注册时master节点所收集的信息，比如操作系统、CPU架构等。salt也可以基于grains信息来选取执行命令的minion节点，例如：

salt -G 'os:Ubuntu' test.ping //选取所有操作系统是ubuntu的minion节点执行test.ping命令

节点分组

可以使用salt -N 从配置文件中读取指定的分组执行命令；

复合匹配

可以使用salt -C 来组合使用上面提到的三种匹配策略，例如：

salt -C '* and not G@os:Ubuntu' test.ping //选取所有操作系统不是Ubuntu的节点执行test.ping

批量大小

通过-b参数从已匹配的节点中再次筛选指定数量的节点执行命令，例如:

salt ‘*’ -b 25% test.ping //从所有节点中选取25%执行命令

Remote Execution（命令编排）

按字面意思理解，这个核心功能可以称作远程调用或者远程执行。但是中文的专业术语会翻译成命令编排，这其中的原因我想是因为“编排”这个词能体现在minion端所执行的命令是逻辑有序的。salt提供了很多功能不同的模块实现了日常的运维工作，这些模块编排了常用的运维指令和逻辑，而master能远程调用他们完成相应的功能。例如，test.ping完成了测试minion节点是否存活，bridge.add 会添加网桥设备。

了解完这个核心功能后，salt的命令格式也变得清晰

salt [TARGETING] [COMMAND] [ARGS]

TARGETING指出了谁去执行命令，COMMAND和ARGS指出了执行什么命令以及命令的参数。其实后面讲到的状态管理也是基于这两个核心功能构建。此外用户还可以自己写模块，对salt的功能进行扩展。

States（状态管理）

状态管理也通常被称作软件配置管理(SCM, Software Configuration Management)。状态管理程序会使让的系统保持或到达预先定义的状态，他会依据状态的描述，安装软件包、打开或重启服务或将配置文件分发到指定的位置并监控它的变化。

拥有状态管理，SA可以很轻松的管理数百台或数万台的服务器配置。将状态管理的配置文件放置在版本管理工具（git, svn）下，能很好的管理配置的变更。

Salt States是Salt的配置管理工具。如上文所述，它本质上是Remote Execution的一个模块。master通过命令编排调用minion上的state模块，触发minion从master获取状态描述文件（SLS文件）并按照描述文件的描述执行相应的操作。

SLS文件可以静态的描述minion的状态，也可以通过Grains和Jinja模板动态的生成状态描述，状态描述之间也存在着不同的关系。可以参照下面的文章深入的学校Salt的状态管理。

http://thinkinside.tk/2013/06/25/salt_usage.html

http://salt.readthedocs.org/en/latest/topics/tutorials/states_pt1.html

http://salt.readthedocs.org/en/latest/ref/states/index.html

其它功能

Salt还提供了很多的扩展功能，如Returners提供了不同的存储后端保存minion返回的数据，salt cloud添加了对AWS等公有云的支持等。

小结

本文简单首先介绍了系统运维的需求和运维工具的基本情况，因为我不是专职的运维人员总结的比较笼统；然后介绍了Salt的架构和核心功能。其实只要在宏观上对Salt有一个基本的认识“它是干什么的，怎么干的”，那么以后无论是使用Salt还是基于Salt做开发都会有思路了，遇到问题查阅官方手册基本都能解决。

要熟悉Salt的使用，动手实践是必不可少的。我还会记录一些在Vagrant上使用Salt的过程，也会尝试使用Salt、vagrant去部署一个OpenStack环境。

执行命令的例子

在主控机器上执行一个命令，让所有受控机器执行 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://www.saltstack.cn/projects/cssug-kb/wiki/Dive-into-saltstack

安装

创世之初，满是空白和无序，黑暗笼罩着整个系统……然后神安装了配置管理器，于是阳光普照！唯一的麻烦是，我们还需要安装依赖……然后配置管理器本身还得被配置……并且有时事情会有那么一点丑陋。

Salt在Ubuntu和CentOS上的安装过程异常简单,我相信在有安装指南的别的系统也一样 (Arch Linux, Debian, Fedora, RedHat, CentOS, FreeBSD, Gentoo, Windows, Solaris). YMMV. 典型安装过程隐藏了不必要的细节配置，除非你需要修改他们。首先安装salt master，然后安装salt minions, 将minions指向master，安装完成。如果salt master的主机名是"salt"，都不需要将minions指向master，直接就可以运行。

然而, 如果你不是使用上面提到的发行版或操作系统, 你很可能需要卷起袖子自己手动安装一些依赖。包括Python (>= 2.6 < 3.0), ZeroMQ, pyzmq, PyCrypto, msgpack-python和YAML的Python绑定.

另一方面, Puppet在多数基础安装时只依赖Ruby和Facter, 依赖带来的麻烦显著减少. 然而，Puppet的依赖列表可以进一步增加，包括augeas-libs, dmidecode, hiera, libselinux-ruby, pciutils, ruby-augeas, ruby-irb, ruby-rdoc, rubygem-json, ruby-shadow, rubygems. 这取决于Puppet的版本和你想要使用的功能。

我喜欢Salt包安装的简单明了。For the cases mentioned it is trivial to set up and get going. 如果你想亲自安装和配置的繁过程, 跟着安装指南做即可。

If you are like me though and you prefer your provisioning and configuration all in one gift wrapped package, que Vagrant to the rescue and download this project by elasticdog on github.

配置管理

配置状态

配置管理对Puppet来说是小菜一叠，对Salt又如何呢。让我（高兴的）惊讶的是，这件事简单到令人发指。和Puppet一样，在Salt中可以描述系统的目标状态。. Salt将其称之为一个state, 配置模块是state模块。Salt的State模块文件用YAML写成，以.sls结尾。它们从功能上等同于Puppet模块的manifest文件，后者用Puppet DSL写成，以.pp结尾。

Salt在master的配置文件中指定"file roots", 类似于Puppet的"module path", 但同时包含了模块根目录和环境类型。举例来说，在Salt中我们可以分别指定development和test环境配置文件路径. 注意base环境是必须存在的。

file_roots:
  base:
    - /srv/salt/
  dev:
    - /srv/salt/dev
  prod:
    - /srv/salt/prod

base环境必须包含Salt的入口top文件(叫做top.sls).base定义了一个或多个环境，用正则来匹配节点，然后引用相应的Salt states. top文件与Puppet的nodes文件相似。(Puppet入口点是site文件,在Salt中不需要).

假设有一个Salt master和两个minions (由Elasticdog github提供)，我想要在两个minions上安装mongodb。如果在默认的软件仓库中有mongodb包，只需要3步即可。

1、在top.sls中指定节点:

dev:
  'minion*.example.com':
    - mongodb

2、在dev/mongodb.sls中描述状态:

mongodb:
  pkg:
    - installed

3、传递状态到salt minions:

salt 'minion*' state.highstate -v

Executing job with jid 20121218102842533621
-------------------------------------------

minion1.example.com:
----------
State: - pkg
Name: mongodb
Function: installed
Result: True
Comment: Package mongodb installed
Changes: libicu: {'new': '3.6-5.16.1', 'old': ''}
mongodb: {'new': '1.6.4-1.el5', 'old': ''}
boost: {'new': '1.33.1-15.el5', 'old': ''}
js: {'new': '1.70-8.el5', 'old': ''}

minion2.example.com:
----------
State: - pkg
Name: mongodb
Function: installed
Result: True
Comment: Package mongodb installed
Changes: libicu: {'new': '3.6-5.16.1', 'old': ''}
mongodb: {'new': '1.6.4-1.el5', 'old': ''}
boost: {'new': '1.33.1-15.el5', 'old': ''}
js: {'new': '1.70-8.el5', 'old': ''}

配置描述文件与Puppet非常相似。但格式差别很大。这是因为Puppet使用自己的ruby-like DSL, 而Salt使用YAML. 正是由于这点不同，造就了Salt state配置文件在视觉上的简洁性。YAML对人类可读也容易被映射到数据结构, 非常适合做配置管理中的资源描述。这不是说Puppet DSL不清晰或不结构化- it is neither - 但很难胜过YAML. YAML可以快速写成，在我的经验看，比Puppet DSL要容易生成.

注意: 配置管理社区关于声明配置的最佳方式一直存在争论。部分人青睐于利用编程语言（比如说Ruby）的灵活性。Chef是其中的代表。Puppet处于中间地段。当使用现成的功能时，Puppet DSL非常强大。但要给配置开发者更大的能力，就必须使用内部的Ruby DSL。在波谱的另一端，Salt的简单YAML状态描述非常结构化。然而，Salt也支持渲染诸如JSON, Mako, Wempy和Jinja来扩展其能力, 在将来还会支持XML,原生Python及其他。

内置的state模块

我知道Salt是比Puppet新（注：原文为“近”字，在转载时觉得不妥、进行了修正）的项目，我完全可以预料到不会有太多可用的内置模块。我错了: Salt有大量的内置模块，包含Puppet中的大部分必要模块比如 cron, exec (Salt是cmd), file, group, host, mount, package (Salt中是pkg), service, ssh_authorized_key (Salt是ssh_auth)和user。

尽管如此, Puppet仍然具有部分优势。比如, 我非常喜欢Puppet的Augeas模块。Augeas把内容当作value树，允许你修改(而不是覆盖)一个已存在的配置文件。

虽然Salt有一个Augeas execution模块，但很不幸貌似没有Augeas的state模块。虽然这样，Salt也有一些自己特有的东西，比如针对git, hg和svn的内置state模块.

模板

Puppet具有开盒即用的模板系统。Puppet有file资源和template资源的概念，这些资源分布在模块目录结构的不同路径下。在Salt中, files和templates在同一个位置。通过为template指令指定type来区分是template还是普通文件资源, type可以是jinja, mako或wempy。好处是可以很容易为file资源增加逻辑。state文件可能看起来像下面这样：

/etc/myapp.conf:
  file.managed:
    - source: salt://files/myapp.conf
    - mode: 644
    - owner: root
    - group: root
    - template: jinja

注意最后一行, 指明被管理的文件是一个jinja模板。

配置文件可以使用jinja的语法来增加逻辑。举例来说, 假设你的应用程序配置文件中用到了主机名。再假设在Ubuntuh 只需要短主机名（hostname），在CentOS需要FQDN。这可以很容易地在模板文件myapp.conf中指定:

{% if grains['os'] == 'Ubuntu' %}
host: {{ grains['host'] }}
{% elif grains['os'] == 'CentOS' %}
host: {{ grains['fqdn'] }}
{% endif %}

在CentOS节点minion1上结果文件/etc/myapp.conf将包含以下内容:

host: minion1.example.com

变量

Salt中的全局变量不能在使用时定义。在对变量的支持方面Puppet更加直观和灵活。在Salt中, 所有的变量保存在单独的位置。这样做不够灵活，但优势是更有秩序。用Salt的话讲，变量叫做"pillars"。pillars的位置在salt master的配置文件中指定:

pillar_roots:
  base:
    - /srv/salt/pillar

和state文件一样, 首先创建一个top文件，在其中可以引用相关的pillar模块。

base:
  '*':
    - packages

这个top文件引用了名为packages.sls的state文件, 其中包含将要安装的软件包的版本号的变量，如下所示:

mongodb: mongodb-1.6.4-1
httpd: httpd-2.2.3-65

声明了两个pillar, mongodb和httpd, 然后可以在state文件中用如下方式引用:

pillar['mongodb']
pillar['httpd']

模拟执行(Dry run)

管理系统有点像驾驶飞机。如果不小心谨慎，将会是高风险的事情。假设我是一个双翼飞机的驾驶员，将做一个危险的aerial manoeuvre, 我多半会希望能够先模拟飞行。除非我像Red Baron一样无所畏惧。无论如何，还好在执行Salt之前可以先做测试。你需要做的仅仅是将Test设置为True。

salt 'minion1.example.com' state.highstate -v test=True

minion1.example.com:
----------
State: - file
Name: /etc/myapp.conf
Function: managed
Result: None
Comment: The following values are set to be changed:
newfile: /etc/myapp.conf

Changes:

总结

在配置管理方面，Salt在Puppet面前还是能够站稳脚跟的。Salt安装非常简单，属于简单主义的开发风格, 功能丰富。总的来说，不需要过多的操作就可以完成事情。我发现的唯一问题是salt-master和minion之间的连接有时会无故断掉。搜索一番后，我发现其他人在Salt 0.10.5这个版本上也遇到了同样的问题。希望这个问题在下一个版本中得到解决。

命令编排和远程执行

MCollective

MCollective是 Puppet的命令编排解决方案。由R.I.Pienaar在PuppetLabs那帮人引起重视之前独立开发完成。MCollective使用message broker (比如ActiveMQ)通过pub-sub总线来传递消息, 可以并行通信，这比用ssh快得多。这是一可以理解特定消息并产生响应的框架。Puppet和MCollective现在可以在同一个框架下工作，同时提供完成配置管理和命令编排的功能。

先不管MCollective的优势，有两个负担能够打击你的激情。第一，MCollective只是和Puppet松散集成，至少对社区版本来讲是这样。MCollective有单独的安装包，独立的配置文件。另外你还需要安装配置broker(比如ActiveMQ)，来与MCollective一起工作. 虽然不难，但很繁琐。最后，你还不得不自己解决生产环境中通信渠道的安全问题。不幸的是，这个就有点困难。

MCollective的第二个问题是相对来讲缺少一些自带的功能。有很多现成的插件可以下载安装(https://github.com/puppetlabs/mcollective-plugins), 用Ruby写自己的插件也不是很复杂－不过想要立即使用的话，障碍比想像得要大。Nevertheless, given that the framework is solid and extensible, dabbling in Ruby plugins soon makes the real power of MCollective apparent.

Salt

另一方面，Salt生来就有命令编排的功能。最先设想的就是远程执行技术，然后才添加的配置管理管理。Salt使用轻量的ZeroMQ来处理消息。结果就是不需要单独的安装。装好Salt后，配置管理和命令编排就可以工作了。毫不惊奇,Salt state模块和execution模块的命令在语法上类似，所以很直观。再看Puppet和MCollective组合,各自使用不同的工具和语法结构，需要额外的时间去学习。

Salt远程执行功能的可用性令人印象深刻。当前的在线文档列出了超过100个不同的内置excution模块－包括augeas！(所以augeas成为state模块只是时间上的问题).

举个简单的例子，看看通用的"cmd.run"模块和指令。这在你知道想要执行的命令却又没有现成的模块可用时非常有用，- 或者你仅仅想要快速地远程执行命令。假设我想在所有节点上检查运行的内核版本号：

salt '*' cmd.run "uname -r"

minion1.example.com: 2.6.18-274.18.1.el5
minion2.example.com: 2.6.18-274.18.1.el5
salt.example.com: 2.6.18-274.18.1.el5

或者我想看看磁盘使用情况:

salt '*' cmd.run "df -h"

顺便说一下, Salt有一个模块用来查看磁盘用量以及其他磁盘相关的查询:

salt '*' disk.usage

使用内置模块而不用cmd.run发送shell命令的好处是，模块通常返回固定结构的数据。能够以编程的方式用在自动化处理上。

有很多现成的execution模块来满足通用的管理任务，比如apt, at, cp, cron, disk, extfs, file, hosts, iptables, mount, network, pam, parted, pkg, ps, selinux, shadow, ssh, and test. 也有大量的模块用于指定的软件包和应用程序，比如apache, cassandra, djangomod, git, mongodb, mysql, nginx, nova, postgres, solr, sqlite3, 和tomcat.

甚至支持执行Puppet程序。

总结

毫无疑问，Salt远程执行比Puppet加MCollective更优雅，附带可用的功能更多。支持动态查询和大规模的服务编排。要查看完整的功能，请参考salt execution模块的文档。

附加功能

Dashboard

puppet使用Puppet dashboard. Salt目前没有图形化的界面。我知道，我们都大爱命令行。不过，有时看到满屏幕的绿色或是点点按钮也是很惬意的。认真的讲，dashboard是获得你所管理的节点网络state概览的好工具。Salt的路线图中没有图形界面，希望最终会出现。

Returners

Returners是minion返回数据到达后被调用的模块。不将返回数据传递给salt master，而是调用Returner模块来将数据发给其他服务，通常是数据库。Salt目前支持的returner，可以连接cassandra, mongo, redis和mysql. 也可以很容易的用Python脚本为其他服务写一个returner。

Salt Syndic

Salt文档将Salt Syndic描述为"一个可以构建Salt命令拓扑的强大工具“。实际意义上，Salt Syndic可以让一个运行Syndic服务的Salt master连接到更高层的master。

假设你有多个不同的Salt环境，每个环境都有一个master。这些环境可能是特的云或是有防火墙的网络。假设你想同时控制这几个环境中的minions。你可以在想要控制的master主机上安装Salt Syndic。Salt Syndic创建了传输接口，在最顶层的master看来，就像是控制了很多的minion,但配置状态实际上是传递给了多个master。可以将其想像为军队的命令传递系统。

集成测试¶

有两个采用现有测试框架的项目给Puppet增加测试功能，名字是cucumber-puppet (使用 Cucumber框架)和rspec-puppet (使用RSpec).

Salt采取的做法是通过一系列的集成类提供对集成测试的支持，roadmap中提到未来会使用Unittest2和pytest做单元测试。

自动化集成测试是持续性交付管道被忽视的领域，能有一些内建的支持是非常好的。这也是以后的博文中将探讨的有趣领域

结论

我的目的是看看Salt Stack是否能做为配置管理和系统命令编排的解决方案。我的方法是与Puppet中最常用的功能作比较，以探索Salt的功能。结论是很耀眼的。Salt Stack不仅自带了很多功能，且易于安装，使用，扩展。很明显，Salt前途一片光明。

有用的链接

Saltstack主页: http://saltstack.org

Salt下载: http://saltstack.org/download/ (转载修正：该链接已失效)

Salt在GitHub: https://github.com/saltstack/salt

Salt开发者博客: http://red45.wordpress.com/

posted @ 2014-05-30 11:59 陳聽溪阅读(3684) 评论(1) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

陳聽溪

saltstack 使用

Grains使用

节点信息(grains)

自定义Grains

Pillar使用

Salt cp命令使用

定时任务（cron）

cp模块

环境

常见用法

get_file

get_dir

get_url

get_template

push

21.16.28. salt.modules.cp

saltstack

简述

安装

debian/ubuntu

RHEL6/CentOS6

基本配置

服务端配置

客户端配置

检查服务

证书管理

简单的测试

salt的基本使用

实时管理

nodegroup

targeting

配置管理，或称状态管理

配置受控端

配置主控端，开启配置管理功能

稍微复杂的例子：管理ssh服务

参考

二进制软件包

主控端命令列表

受控端命令列表

启用扩展配置文件目录

命令示例

salt

salt-master

salt-key

salt-cp

salt-run

salt-ssh

salt-syndic

salt-minion

salt-call

内置模块列表

参考文档

唧唧歪歪

FAQ:

简介

特点

架构

快速体验

核心功能

Targeting（批量操作）

Remote Execution（命令编排）

States（状态管理）

其它功能

小结

相关资源

三、简单配置

四、基本使用

远程执行命令

执行模块命令

直接调用远程shell命令

使用状态文件同步状态

五、实际应用

六、saltstack优点与缺点

参考资料

执行命令的例子

执行状态的例子

安装

配置管理

配置状态