salt分组

http://www.centoscn.com/image-text/config/2015/0426/5282.html

一、SaltStack简介

SaltStack是一种全新的基础设置管理方式，部署轻松，在几分钟内可运作起来，扩展性好，很容易管理上万台服务器，速度够快，服务器之间秒级通讯。通过部署SaltStack环境，我们可以在成千上万台服务器上做到批量执行命令，根据不同业务特性进行配置集中化管理、分发文件、采集服务器数据、操作系统基础及软件包管理等，SaltStack是运维人员提高工作效率、规范业务配置与操作的利器。

 

二、实验环境    

1、版本

系统版本：CentOS 6.4 64bit
Python版本：原生版2.6.6
Salt版本：2014.7.1

2、实验架构

 

Salt-master： 192.168.1.225   soft：salt-master
Salt-minion01：192.168.1.226  soft：salt-minion
Salt-minion02：192.168.1.228  soft：salt-minion

三、开始安装Salt

此次安装SaltStack采用yum安装方式，所以需要借助第三方yum源(epel和rpmforge)

1、安装epel源

# rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# sed -i 's@^#@@' /etc/yum.repos.d/epel.repo
# sed -i 's@mirrorlist@#mirrorlist@' /etc/yum.repos.d/epel.repo

2、安装rpmforge源

 
# rpm -Uvh http://apt.sw.be/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

3、安装依赖包

 
# yum -y install python-jinja2

4、安装SaltStack包

服务器安装salt-master包
# yum -y install salt-master 
 
其余被控端安装salt-minion包
# yum -y install salt-minion

四、着手配置SaltStack

1、master主控端关键项配置

# vim /etc/salt/master
interface: 0.0.0.0    //绑定Master通信IP
auto_accept: True     //自动认证，避免手动运行salt-key来确认证书信任
file_roots:           //指定saltstack文件根目录位置
  base:
    - /srv/salt

2、更新被控端配置

# vim /etc/salt/minion
master: 192.168.0.106     //指定Master主机IP地址
id: SaltStack_minion_01   //修改被控端主机识别id，建议使用操作系统主机名来设置

五、启动SaltStack服务

1、服务端启动salt-master服务
# /etc/init.d/salt-master start
# chkconfig salt-master on
 
2、被控端启动salt-minion服务
# /etc/init.d/salt-minion start
# chkconfig salt-minion on

 

六、使用SaltStack

 

1、在master端查看公钥列表

[root@localhost ~]# salt-key -L
Accepted Keys:            
SaltStack_minion_01       
SaltStack_minion_02        
Unaccepted Keys:          
Rejected Keys:

2、测试被控主机的连通性、硬盘的使用率、网络接口地址

# salt '*' test.ping
# salt '*' disk.usage
# salt '*' network.interfaces

3、远程执行命令测试

  • cmd模块包含的shell的输出在被控端,比如cmd.run and cmd.run_all

# salt '*' cmd.run date
# salt '*' cmd.run uptime
# salt '*' cmd.run 'df -h'
# salt '*' cmd.run 'ls -l /etc'

  • pkg函数自动映射本地系统的包管理到salt函数

 
# salt '*' pkg.install vim

七、salt-key参数

1、salt-key常用选项

  • -L, --list-all

 
#显示已经或未认证的被控端id，Accepted Keys为已认证清单；Unaccepted Keys为未认证清单

  • -a ACCEPT, --accept=ACCEPT

 
#接受单个id证书请求

  • -A, --accept-all

 
#接受所有id证书请求

  • -r REJECT, --reject=REJECT

#拒绝指定的公钥

  • -R, --reject-all

 
#拒绝所有正在请求的公钥

  • -d DELETE, --delete=DELETE

 
#删除指定的公钥

  • -D, --delete-all

 
#删除所有的公钥

2、salt-key返回信息

  • Accepted Keys：接受的公钥列表或者是被控主机

  • Unaccepted Keys：未被接受的公钥列表

  • Rejected Keys：被拒绝的公钥列表

 

 

http://shanks.blog.51cto.com/3899909/1306954

一直在想要是salt能够分组的使用自定义的脚本来完成批量部署就好了，最近在这方面做了比较深入的研究，终于实现了。

一、在master上配置nodegroup

1、在/etc/salt/master的最下面加上default_include: include/group.conf

2、vim include/group.conf

172331289.jpg

二、配置state

通过配置nodegroup，我们已经能够实现按组来分发命令。但是当我们需要做一系列操作的时候，这种依靠一条条命令的方式显然很慢，切容易出现操作上的失误。那好，我们怎么办？

对了，通过state来批量的执行脚本。

配置state

1、vim /srv/salt/top.sls

172345386.jpg

2、在/srv/salt下建立目录：（top.sls中的目录就是从这来的）

 

mkdir dnsmasq

mkdir -p myscript/{lvs-server,lvs-realserver}

mkdir -p myscript/lvs-realserver/config/

mkdir -p myscript/lvs-server/{config,install}

 

3、进入dnsmasq目录，编辑init.sls以及创建files目录

mkdir files

之后将你的dnsmasq.conf文件放到files目录下

vim init.sls

 

dnsmasq:

pkg:

– name: dnsmasq

– installed

service:

– running

– enable: True

– reload: True

– watch:

– file: /etc/dnsmasq.conf

 

 

/etc/dnsmasq.conf:

file.managed:

– source: salt://dnsmasq/files/dnsmasq.conf

– user: root

– group: root

– mode: 644

– require:

– pkg: dnsmasq

 

4、接下来就是我们的lvs了，用的都是脚本

先从lvs的install开始

进到刚刚建好的目录：/srv/salt/myscript/lvs-server/install

vim init.sls

 

install_lvs:

cmd.script:

– source: http://172.16.224.23/soft/lvs/install_lvs.sh

– unless: [ -f /tmp/test.passed ]

当你准备好脚本后，lvs的install部署就完成了。config和lvs真实服务的config也是一样，只是目录和脚本不一样。

6、我们命令行怎么用呢？

以lvs的install为例

 

salt -N 'lvs-server' state.sls myscript.lvs-server.install

 

done

 

 

 

http://segmentfault.com/a/1190000000506668

在使用 SaltStack 对主机进行批量管理的时候，因为不同的服务器组所做的业务功能不同，因此为了更加方便的管理，势必要对主机进行分组管理。

因此就自己在分组使用的过程中有以下一点记录下。

参考 SaltStack 的官方文档 4.4 Compound matchers 和 4.3. Node groups 知道，对目标服务器分组有以下七种方式，这七种方式的标示符分别为：

  1. G -- 针对 Grains 做单个匹配，例如：G@os:Ubuntu
  2. E -- 针对 minion 针对正则表达式做匹配，例如：E@web\d+.(dev|qa|prod).loc
  3. P -- 针对 Grains 做正则表达式匹配，例如：P@os:(RedHat|Fedora|CentOS)
  4. L -- 针对 minion 做列表匹配，例如：L@minion1.example.com,minion3.domain.com or bl*.domain.com
  5. I -- 针对 Pillar 做单个匹配，例如：I@pdata:foobar
  6. S -- 针对子网或是 IP 做匹配，例如：S@192.168.1.0/24 or S@192.168.1.100
  7. R -- 针对客户端范围做匹配，例如： R@%foo.bar

然后我自己在做分组的时候，尝试了下 L 是否可以使用正则表达式

尝试一：

   nodegroups:
    #  group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com and bl*.domain.com'
    #  group2: 'G@os:Debian and foo.domain.com'
       TEST1: 'L@JF1-TEST1-001,JF1-TEST1-002,JF-TEST1-0[0-9][0-9]'

执行命令 sudo salt -N TEST1 test.ping结果为：

JF1-TEST1-002:
    True
JF1-TEST1-001:
    True

只会出现两台服务器，后面的不能匹配。

尝试二：

nodegroups:
    #  group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com and bl*.domain.com'
    #  group2: 'G@os:Debian and foo.domain.com'
       TEST1: 'L@JF1-TEST1-001,JF1-TEST1-002 or JF-TEST1-0[0-9][0-9]'

执行命令 sudo salt -N TEST1 test.ping结果为：

JF1-TEST1-002:
    True
JF1-TEST1-001:
    True
JF1-TEST1-003:
    True
JF1-TEST1-004:
    True
JF1-TEST1-006:
    True
JF1-TEST1-005:
    True

结果是所有的都匹配成功了

尝试三

nodegroups:
    #  group1: 'L@foo.domain.com,bar.domain.com,baz.domain.com and bl*.domain.com'
    #  group2: 'G@os:Debian and foo.domain.com'
       TEST1: 'L@JF-TEST1-0[0-9][0-9]'

执行结果为：

No minions matched the target. No command was sent, no jid was assigned.

表示没有匹配到任何一个

结论

使用 L 列表的方式，必须把 minion 列出来，或者是列出几台后，在后面接 or 或者 and 表达式， or 或者 and 后面接的表达式后面可以使用正则表达式。

注：想使用正则表达式，最好的方式就是使用 E

 

 

 

 http://bubuko.com/infodetail-757414.html

saltstack的探索-salt指定目标和分组

一、探讨一下，如何针对指定的minion id来执行
先了解官网文档的targeting这一节的内容：
Targeting

Salt allows for minions to be targeted based on a wide range of criteria. The default targeting system uses globular expressions to match minions, hence if there are minions named larry1, larry2, curly1, and curly2, a glob of larry* will match larry1 and larry2, and a glob of *1 will match larry1 and curly1.

Many other targeting systems can be used other than globs, these systems include:

Regular Expressions
Target using PCRE-compliant regular expressions
Grains
Target based on grains data: Targeting with Grains
Pillar
Target based on pillar data: Targeting with Pillar
IP
Target based on IP address/subnet/range
Compound
Create logic to target based on multiple targets: Targeting with Compound
Nodegroup
Target with nodegroups: Targeting with Nodegroup

二、通配符和正则

5.1 Matching the minion id
5.1.1 Globbing
The default matching that Salt utilizes is shell-style globbing around the minion id. This also works for states in the top file.
Note: You must wrap salt calls that use globbing in single-quotes to prevent the shell from expanding the globs before Salt is invoked.
Match all minions:

salt ’*’ test.ping


Match all minions in the example.net domain or any of the example domains:

salt ’*.example.net’ test.ping
salt ’*.example.*’ test.ping


Match all the webN minions in the example.net domain (web1.example.net, web2.example.net . . . webN.example.net):

salt ’web?.example.net’ test.ping


Match the web1 through web5 minions:

salt ’web[1-5]’ test.ping


Match the web-x, web-y, and web-z minions:

salt ’web-[x-z]’ test.ping


5.1.2 Regular Expressions
Minions can be matched using Perl-compatible regular expressions (which is globbing on steroids and a ton of caf-feine).
Match both web1-prod and web1-devel minions:

salt -E ’web1-(prod|devel)’ test.ping

When using regular expressions in a State’s top file, you must specify the matcher as the first option. The following example executes the contents of webserver.sls on the above-mentioned minions.

base:
  ’web1-(prod|devel)’:
    - match: pcre
    - webserver

5.1.3 Lists
At the most basic level, you can specify a flat list of minion IDs:

salt -L ’web1,web2,web3’ test.ping


三、Grains
我的理解：通过grains能得到系统底层的一些基本信息。是静态的。可以在master和minion的配置中写入key:value，但要注意优先级等区别。
还是翻官网文档先：
5.2 Grains
Salt comes with an interface to derive information about the underlying system. This is called the grains interface, because it presents salt with grains of information.
Grains Static bits of information that a minion collects about the system when the minion first starts.
The grains interface is made available to Salt modules and components so that the right salt minion commands are automatically available on the right systems.
It is important to remember that grains are bits of information loaded when the salt minion starts, so this informationis static. This means that the information in grains is unchanging, therefore the nature of the data is static. So grainsinformation are things like the running kernel, or the operating system.


Match all CentOS minions:

salt -G ’os:CentOS’ test.ping


Match all minions with 64-bit CPUs and return number of available cores:

salt -G ’cpuarch:x86_64’ grains.item num_cpus


Additionally, globs can be used in grain matches, and grains that are nested in a dictionary can be matched by adding a colon for each level that is traversed. For example, the following will match hosts that have a grain called ec2_tags,which itself is a dict with a key named environment, which has a value that contains the word production:

salt -G ’ec2_tags:environment:*production*’


5.2.1 Listing Grains
Available grains can be listed by using the ‘grains.ls’ module:
salt ’*’ grains.ls


Grains data can be listed by using the ‘grains.items’ module:
salt ’*’ grains.items


5.2.2 Grains in the Minion Config
Grains can also be statically assigned within the minion configuration file. Just add the option grains and pass options to it:
grains:
  roles:
    - webserver
    - memcache
  deployment: datacenter4
  cabinet: 13
  cab_u: 14-15

  
Then status data specific to your servers can be retrieved via Salt, or used inside of the State system for matching. It also makes targeting, in the case of the example above, simply based on specific data about your deployment.


5.2.3 Grains in /etc/salt/grains
If you do not want to place your custom static grains in the minion config file, you can also put them in /etc/salt/grains. They are configured in the same way as in the above example, only without a top-level grains: key:
roles:
  - webserver
  - memcache
deployment: datacenter4
cabinet: 13
cab_u: 14-15


Precedence of Custom Static Grains
Be careful when defining grains both in /etc/salt/grains and within the minion config file. If a grain is defined in both places, the value in the minion config file takes precedence, and will always be used over its counterpart in /etc/salt/grains.


5.2.4 Writing Grains
Grains are easy to write. The grains interface is derived by executing all of the “public” functions found in the modules located in the grains package or the custom grains directory. The functions in the modules of the grains must return a Python dict, where the keys in the dict are the names of the grains and the values are the values.
Custom grains should be placed in a _grains directory located under the file_roots specified by the mas-ter config file. They will be distributed to the minions when state.highstate is run, or by executing the 
saltutil.sync_grains or saltutil.sync_all functions.
Before adding a grain to Salt, consider what the grain is and remember that grains need to be static data. If the data is something that is likely to change, consider using Pillar instead.
Examples of Grains
The core module in the grains package is where the main grains are loaded by the Salt minion and provides the principal example of how to write grains:
https://github.com/saltstack/salt/blob/develop/salt/grains/core.py
Syncing Grains
Syncing grains can be done a number of ways, they are automatically synced when state.highstate is called, or the grains can be synced and reloaded by calling the saltutil.sync_grains or saltutil.sync_all functions.





四、Nodegroup
在master的配置文件/etc/salt/master 中：

有如下一段：


#####         Node Groups           #####
##########################################
# Node groups allow for logical groupings of minion nodes. A group consists of a group
# name and a compound target.
#nodegroups:
#  group1: ‘L@foo.domain.com,bar.domain.com,baz.domain.com and bl*.domain.com‘
#  group2: ‘G@os:Debian and foo.domain.com‘


咱们继续看文档：
5.3 Node groups
Node group A predefined group of minions declared in the master configuration file nodegroups setting as a compound target.
Nodegroups are declared using a compound target specification. The compound target documentation can be found here:
Compound Matchers（参考下面一段）
For example, in the master config file nodegroups setting:

nodegroups:
group1: ’L@foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com’
group2: ’G@os:Debian and foo.domain.com’


Specify a nodegroup via the -N option at the command-line:

salt -N group1 test.ping


Specify a nodegroup with - match: nodegroup in a top file:
base:
  group1:
    - match: nodegroup
    - webserver


实例：
# vim /etc/salt/master
nodegroups:
  cabinet01: ‘E@test21[1-9].company.com or test23[1-2].company.com‘
  cabinet02: ‘E@test12.company.com or test14[0-6].company.com or test18[3-5].company.com‘
  cabinet03: ‘E@test10[1-5].company.com‘

# salt -N cabinet02 test.ping
test144.company.com:
    True
test183.company.com:
    True
test185.company.com:
    True
test146.company.com:
    True
test140.company.com:
    True
test143.company.com:
    True
test141.company.com:
    True
test145.company.com:
    True
test142.company.com:
    True
test12.company.com:
    True
    

五、混合匹配
5.4 Compound matchers
Compound matcher A combination of many target definitions that can be combined with boolean operators.

Compound matchers allow very granular minion targeting using any of the previously discussed matchers. The default matcher is a glob, as usual. For matching via anything other than glob, preface it with the letter denoting the match type. The currently implemented “letters” are:
Letter              Meaning                             Example
G                   Grains glob match                   G@os:Ubuntu
E                   PCRE Minion id match                E@web\d+\.(dev|qa|prod)\.loc
P                   Grains PCRE match                   P@os:(RedHat|Fedora|CentOS)
L                   List of minions                     L@minion1.example.com,minion3.domain.com or bl*.domain.com
I                   Pillar glob match                   I@pdata:foobar
S                   Subnet/IP addr match                S@192.168.1.0/24 or S@192.168.1.100
R                   Range cluster match                 R@%foo.bar
D                   Minion Data match                   D@key:value

Matchers can be joined using boolean and, or, and not operators.

For example, the following command matches all minions that have a hostname that begins with “webserv” and that are running Debian or it matches any minions that have a hostname that matches the regular expression web-dc1-srv.
* :

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


That same example expressed in a top file looks like the following:
base:
  ’webserv* and G@os:Debian or E@web-dc1-srv.*’:
    - match: compound
    - webserver

    
Note that you cannot have a leading not in a command. Instead you must do something like the following:
salt -C ’* and not G@kernel:Darwin’ test.ping


实例：
[root@test200 ~]# salt -C ‘test12.company.com or test14[0-6].company.com or test18[3-5].company.com‘ test.ping 
test144.company.com:
    True
test183.company.com:
    True
test185.company.com:
    True
test146.company.com:
    True
test140.company.com:
    True
test143.company.com:
    True
test141.company.com:
    True
test145.company.com:
    True
test142.company.com:
    True
test12.company.com:
    True
posted @ 2015-05-07 16:08  陳聽溪  阅读(924)  评论(0)    收藏  举报