salt的cp模块；及其他如：state,modules,grains,pilla,runners,syndic简介；

http://quenlang.blog.51cto.com/4813803/1576271

之前写过一片博文介绍了saltstack的安装配置，由于最近忙着办理离职，就没有更新了，对不起自己，说好的要坚持下去的。这篇博文准备记录一下saltstack作为文件服务器，从master向minions分发文件的功能。我们知道，类似于hadoop、hbase、zookeeper这些与分布式系统相关的组件在安装配置的时候，往往是一个节点上修改好配置文件后，然后用scp远程拷贝到其他节点上去，如果你有10个节点的话，那么同一条远程拷贝的命令需要执行多次，显然不是一个好办法。那么问题来了，自动化运维之远程分发文件到底哪家强？哈哈，自然是神器saltstack啦！我们需要借助saltstack来实现从master端向minions推送文件的需求。

    Saltstack内置了一个简单的文件服务器用于master分发文件给minions，这个文件服务器是基于zeroMQ消息队列实现的，客户端对文件服务器的操作全部封装在了cp这个模块中。

    首先看环境：

        hadoop0.updb.com    192.168.0.100    OS:CentOS 6.5        Role:master

        uadoop2.updb.com    192.168.0.202    OS:CentOS 6.5        Role:minion

        uadoop3.updb.com    192.168.0.203    OS:CentOS 6.5        Role:minion

    在开始saltstack的配置管理之前，要首先指定saltstack所有状态文件的根目录，在master上做如下操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
## 首先修改master的配置文件，指定根目录，注意缩进全部使用两个空格来代替Tab（python规范）
[root@hadoop0 ~]# vi /etc/salt/master 
file_roots:
  base:
    - /srv/salt
  dev:
    - /srv/salt/dev     
## 确定指定的目录是否存在，如果不存在，需要手动来创建目录
[root@hadoop0 ~]# ls /srv/salt/ -ld
drwxr-xr-x 2 root root 4096 Nov  6 23:54 /srv/salt/
[root@hadoop0 ~]# ls /srv/salt/dev/ -ld
drwxr-xr-x 2 root root 4096 Nov  7 00:36 /srv/salt/dev/
## 重启master服务
[root@hadoop0 ~]# /etc/init.d/salt-master  restart 
Stopping salt-master daemon:                               [  OK  ]
Starting salt-master daemon:                               [  OK  ]

    首先介绍cp.get_file，用来从master端下载文件到minion的指定目录下，如下

1
2
3
4
5
6
7
8
9
10
11
## 在master上创建测试用的文件
[root@hadoop0 ~]# echo 'this is test file with module of cp.get_file!' > /opt/getfile.txt
## 拷贝测试文件到master配置的根目录下
[root@hadoop0 ~]# cp /opt/getfile.txt /srv/salt/
## 在master执行文件的分发
[root@hadoop0 ~]# salt 'uadoop2' cp.get_file salt://getfile.txt /opt/getfile.txt 
uadoop2:
    /opt/getfile.txt
## 分发成功，在minion上查看文件是否已经发送到uadoop2上了
[root@uadoop2 ~]# cat  /opt/getfile.txt 
this is test file with module of cp.get_file!

    使用cp.get_file进行文件的分发时时也可以指定是否对分发的文件进行压缩，如下

1
2
3
4
5
6
7
## 使用gzip的方式进行压缩，数字越大，压缩率就越高，9代表最大的压缩率
[root@hadoop0 ~]# salt 'uadoop2' cp.get_file salt://getfile.txt /opt/getfile.txt gzip=9
uadoop2:
    /opt/getfile.txt
## 分发成功，在minion上查看文件是否已经发送到uadoop2上了    
[root@uadoop2 ~]# cat  /opt/getfile.txt 
this is test file with module of cp.get_file!

    当minion上的目标目录不存在时，可以使用makedirs参数来创建目标目录，如下

1
2
3
4
5
6
[root@hadoop0 ~]# salt 'uadoop2' cp.get_file salt://getfile.txt /opt/test/getfile.txt makedirs=True
uadoop2:
    /opt/test/getfile.txt
## 分发成功，在minion上查看文件是否已经发送到uadoop2上了  
[root@uadoop2 ~]# cat /opt/test/getfile.txt 
this is test file with module of cp.get_file!

    在开始下一个示例之前，先介绍一下grains，这个接口的作用是在minion端的minion服务启动时，调用这个接口，收集minion端的信息，这些信息数据可以在salt的其他模块中直接使用，需要注意的是，这个接口只在minion端的minion服务启动时被调用一次，所以收集的数据是静态的，不会改变的，除非你重启了minion端的服务，关于这点，官方文档是这样说明的：

1
2
3
4
5
6
    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 information
is static. This means that the information in grains is unchanging, therefore the nature of the data is static. So grains
information are things like the running kernel, or the operating system.

    grains的基本用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
## 使用grains.ls列出可以在其他模块中直接使用的grains
[root@hadoop0 ~]# salt 'uadoop2' grains.ls
uadoop2:
    - biosreleasedate
    - biosversion
    - cpu_flags
    - cpu_model
    - cpuarch
    - defaultencoding
    - defaultlanguage
    - domain
    - fqdn
    - fqdn_ip4
    - fqdn_ip6
    - gpus
    - host
    - hwaddr_interfaces
    ..............
 
## 使用grains.items模块列出所有可用grains的具体数据
[root@hadoop0 ~]# salt 'uadoop2' grains.items
uadoop2:
  biosreleasedate: 07/31/2013
  biosversion: 6.00
  cpu_flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm ida arat epb xsaveopt pln pts dts
  cpu_model: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
  cpuarch: x86_64
  defaultencoding: UTF8
  defaultlanguage: en_US
  domain: prolexic.com
  fqdn: unknown.prolexic.com
  fqdn_ip4:
      72.52.4.120
  fqdn_ip6:
  gpus:
      {'model': 'SVGA II Adapter', 'vendor': 'unknown'}
  host: unknown
  hwaddr_interfaces: {'lo': '00:00:00:00:00:00', 'eth0': '00:0c:29:b7:1d:85'}
  id: uadoop2
  ip_interfaces: {'lo': ['127.0.0.1'], 'eth0': ['192.168.0.202']}
  ipv4:
      127.0.0.1
      192.168.0.202
  ipv6:
      ::1
      fe80::20c:29ff:feb7:1d85
  kernel: Linux
  kernelrelease: 2.6.32-431.el6.x86_64
  ..............  
 
## ping测试grains中os的值为CentOS的主机通信是否正常
[root@hadoop0 ~]# salt -G 'os:CentOS' test.ping
uadoop2:
    True        
 
## 查看uadoop2主机的ip地址，注意这里不是items噢，而是item
[root@hadoop0 ~]# salt 'uadoop2' grains.item ipv4
uadoop2:
  ipv4:
      127.0.0.1
      192.168.0.202

    好了，在介绍了grains接口之后，接下来看下在cp模块中如何简单的使用grains的数据呢

1
2
3
4
5
6
7
8
## 首先在状态配置文件的根目录下创建一个CentOS目录，然后将位于根目录下的getfile.txt测试文件
mv到CentOS目录下
[root@hadoop0 ~]# mkdir  /srv/salt/CentOS/
[root@hadoop0 ~]# mv  /srv/salt/getfile.txt /srv/salt/CentOS/
## 然后执行文件分发的命令，注意这里要使用salt内置模版jinja才能分发成功
[root@hadoop0 ~]# salt 'uadoop2' cp.get_file "salt://{{grains.os}}/getfile.txt" /opt/getfile.txt template=jinja
uadoop2:
    /opt/getfile.txt

    

    接着介绍cp.get_dir，get_dir与get_file的用法十分相似，用来将整个目录分发到minions

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
## 创建测试目录
[root@hadoop0 ~]# mkdir /srv/salt/test_dir
## 创建测试文件
[root@hadoop0 ~]# echo 'hello a !' > /srv/salt/test_dir/a.txt
[root@hadoop0 ~]# echo 'hello b !' > /srv/salt/test_dir/b.txt 
## 执行目录文件的分发，并使用压缩传输
[root@hadoop0 ~]# salt 'uadoop2' cp.get_dir salt://test_dir /opt/ gzip=9 
uadoop2:
    - /opt//test_dir/a.txt
    - /opt//test_dir/b.txt
 
## 分发成功，验证
[root@uadoop2 ~]# ls /opt/test_dir/   
a.txt  b.txt
[root@uadoop2 ~]# cat /opt/test_dir/a.txt 
hello a !
[root@uadoop2 ~]# cat /opt/test_dir/b.txt  
hello b !

    在往下介绍之前，首先介绍一下salt的pillar接口，pillar是salt中比较重要的组件，跟grains有些相似，但是pillar相比于grains更加灵活，而且是动态的，数据可以随时更新，只要你愿意的话。而grains只在minion启动时采集一次数据，关于pillar官网描述如下，简单翻译一下，但不保证翻译的到位，意思是说pillar是salt实现部署功能的最重要的组件，能够为minions生成非常灵活的数据，这些数据可以被salt的其他的组件所使用。

1
2
3
    The pillar interface inside of Salt is one of the most important components of a Salt 
deployment. Pillar is the interface used to generate arbitrary data for specific minions. 
The data generated in pillar is made available to almost every component of Salt.

    pillar的基本用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
## 使用pillar之前要在master中配置pillar的工作目录，将下面三行的注释打开
[root@hadoop0 ~]# vi /etc/salt/master
pillar_roots:
  base:
    - /srv/pillar
## 重启master服务 
[root@hadoop0 ~]# /etc/init.d/salt-master restart 
Stopping salt-master daemon:                               [  OK  ]
Starting salt-master daemon:                               [  OK  ]
## 创建所需目录
[root@hadoop0 ~]# mkdir  /srv/pillar/
## 该目录用来测试使用
[root@hadoop0 ~]# mkdir  /srv/pillar/user
## 首先在/srv/pillar目录中要有一个入口文件top.sls
[root@hadoop0 pillar]# vi top.sls 
base:
  'uadoop2':
    - data         ## 为uadoop2定义了一个属性数据，引用了跟top.sls同目录下的data.sls
   
  'uadoop3':
    - webserver    ## 为uadoop3定义了一个属性数据，引用了跟top.sls同目录下的web.sls
 
  '*':
    - user         ## 为所有节点定义了一个属性数据，引用了/srv/pillar/user/init.sls
                   ## 这里指定的是一个目录，salt会自动在top.sls文件中的引用目录中寻找状态文件
                   ## 因此会找到位于user目录中的init.sls文件
               
## 编写在top.sls文件中引用的状态文件
[root@hadoop0 pillar]# vi data.sls
data: some data
[root@hadoop0 pillar]# vi webserver.sls 
webserver: test_dir
[root@hadoop0 pillar]# vi user/init.sls 
users:
  kora: 1000
  kadefor: 1100
  foway: 1200
 
## 接着将master上定义的属性同步到对应的minion上去
[root@hadoop0 pillar]# salt '*' pillar.items
uadoop3:
    ----------
    master:
        ----------
        auth_mode:
            1
        auto_accept:
            False
    .............省略N行..............
        worker_threads:
            5
    webserver:
        test_dir
    users:
        ----------
        foway:
            1200
        kadefor:
            1100
        kora:
            1000
uadoop2:
    ----------
    data:
        some data
    master:
        ----------
        auth_mode:
            1
    .............省略N行..............       
        worker_threads:
            5
    users:
        ----------
        foway:
            1200
        kadefor:
            1100
        kora:
            1000
 
## 在master上远程获取刚刚定义的属性
[root@hadoop0 pillar]# salt 'uadoop2' pillar.item data
uadoop2:
    ----------
    data:
        some data
[root@hadoop0 pillar]# salt 'uadoop3' pillar.item webserver
uadoop3:
    ----------
    webserver:
        test_dir  
[root@hadoop0 pillar]# salt '*' pillar.item users
uadoop2:
    ----------
    users:
        ----------
        foway:
            1200
        kadefor:
            1100
        kora:
            1000
uadoop3:
    ----------
    users:
        ----------
        foway:
            1200
        kadefor:
            1100
        kora:
            1000
## 可以看到刚刚为不同的minion定义的属性已经同步到了各个minion上，从这个测试可以看出，使用pillar
## 我们可以为不同的minion或者不同的minion组定义不同的属性，极其灵活。

    好了，在介绍了pillar接口之后，接下来看下在cp模块中如何简单的使用pillar定义的属性数据呢

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
## 我们可以利用之前定义的属性来匹配不同的minion
[root@hadoop0 pillar]# salt -I 'users:kora:1000' test.ping
uadoop2:
    True
uadoop3:
    True
[root@hadoop0 pillar]# salt -I 'data:*some*' test.ping      
uadoop2:
    True
[root@hadoop0 pillar]# salt -I 'webserver:test_dir' test.ping     
uadoop3:
    True
 
## 匹配uadoop3，然后在master上远程分发文件到uadoop3上去
[root@hadoop0 pillar]# salt -I 'webserver:test_dir' cp.get_dir "salt://{{pillar.webserver}}" /opt/ gzip=9 template=jinja    
uadoop3:
    - /opt//test_dir/a.txt
    - /opt//test_dir/b.txt

    从远程执行的结果来看文件已经分发成功，上面的例子就演示了pillar接口定义的属性在cp模块中的简单使用，我们可以通过pillar为不同minion指定的属性及其值来匹配对应的minion，非常的灵活。        

    好了，关于salt文件服务器就介绍到这里。虽然我也只是简单的体验了一下，但是依旧被salt作为文件服务器的强大功能所震精。有了salt的文件分发功能后，真的是鸟枪换炮。当然不需要使用好多条scp命令，只需要写好配置文件，分好组，一条命令过去，完成所有节点的文件分发。

 

 

 

http://m.oschina.net/blog/156610

saltstack知识点

China_OS 发布于 2年前，共有 0 条评论

  上一节对saltstack有了初步的了解，看似salt简单，其实这里面还是有很多东西需要详细了解的，今天主要了解一些salt的细节，其实我也是看官方文档的..

1 file server configuration

  salt有一个用ZeroMQ编写的高性能文件服务，它可以用很小的负载快速管理大量的文件。salt的文件服务是一个感知环境(environment aware)的文件服务，什么是环境感知？就是文件可以被分配在多个根目录下，可以在访问时指定文件路径和搜索路径。独特的环境可以跨越多个根目录覆盖，并以灵活的方式来组织文件。
  salt默认的文件服务强制使用base环境，这个base环境必须被定义，当没有写明环境定义的时候，就是从这个base环境下载文件的，环境允许文件和sls数据在逻辑上分离，但彼此都不是孤立的环境。
  环境设置了一系列目录来发布文件，在这些目录中进行文件查找，并返回第一个找到的文件。这意味着文件查找是按照设定的目录顺序进行查找的。eg：

file_roots:
  base:
    - /srv/salt/base
    - /srv/salt/failover

  假如在查找salt://httpd/httpd.conf文件时，第一个搜索的目录是/srv/salt/base/httpd/httpd.conf。如果在这里找到了这个文件，则返回该文件，如果没有该文件，则继续查找/srv/salt/failover/httpd/httpd.conf。 

2 salt file server

  salt使用文件服务分发文件到minions上，文件服务是一个内嵌在master里面的无状态ZeroMQ服务构成的。salt的文件服务目前用在salt的state system中，因此，文件服务可以用于任何文件传输。cp模块被用于salt的state system，salt-cp可以让salt的文件服务来分发文件。

  cp.get_file可以用来在minion端下载master上的文件。
  
  salt '*' cp.get_file salt://vimrc /etc/vimrc 
    这个会通知所有的minion客户端来下载vimrc文件到/etc/vimrc

  salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja  
    也可以用模版,表示只在OS系统名称一样的机器上下载文件
	
  salt '*' cp.get_file salt://vimrc /etc/vimrc gzip=5
    salt在传输大文件时还支持压缩：压缩比率是1-9

  salt '*' cp.get_file salt://vimrc /etc/vim/vimrc makedirs=True
    cp.get_file默认是不会创建目的端的目录的，如果该目录不存在的时候。要改变这种情况可以使用mkaedirs参数

  salt '*' cp.get_dir salt://etc/apache2 /etc
  salt '*' cp.get_dir salt://etc/{{pillar.webserver}} /etc gzip=5 template=jinja
    cp.get_dir和cp.get_file一样，不过get_dir是用来下载整个目录的，也支持模版和压缩

3 file server backends  

  salt在master上引进了一种能力，就是在整合不同的文件服务后端，文件服务后端允许salt的文件服务作为一个传输桥梁连接到外部资源。最好的例子就是git后端，它允许所有的salt文件保存在远程的git仓库中。

  文件服务后端系统可以承担不同的后端类型，这样就可以在file_roots中配置不同的后端类型。文件后端这个功能是被master中的fileserver_backend参数管理的，它列出在后端系统中搜索的优先级顺序。例如：

fileserver_backend:
  - roots
  - git

  根据以上的配置，file_roots配置中定义的先被搜索，如果在file_roots没有搜索到，则git后端才会被搜索。 

  内建的fileserver模块：http://docs.saltstack.com/ref/file_server/all/index.html

  其他两个没用过，主要使用fileserver.roots模块。

4 dynamic module distribution

  salt的python模块可以通过salt的文件服务自动的分发。在master通过任何一个file_roots定义的根目录下的模块都可以被使用。
  模块同步：自动的从master到minions传输加载、grains、renderers、returners、states模块信息等等。以下目录被优先考虑：

_modules
_grains
_renderers
_returners
_states
  在python模块被创建到这些目录后，这些目录下的内容需要被同步到minions上，有好几种办法同步模块： 
  1 通过states传输，在minion的配置文件中，有一个autoload_dynamic_modules选项，默认是True，当state运行的时候，它使用state system更新所有的动态模块，当动态模块通过states自动加载的时候，modules only pertinent to the environments matched in the master's top file are downloaded。这很重要，因为模块可以被手动的加载，在指定特定的环境特定的模块。 
   
  2 通过saltutil模块分发，saltutil模块有一些函数可以同步所有的或者指定的动态模块。saltutil.sync_all可以同步所有的模块到minion。

  关于saltutil查看：http://docs.saltstack.com/ref/modules/all/salt.modules.saltutil.html#module-salt.modules.saltutil

5 client acl system

  salt的client acl system意思是允许系统账户(非root)可以在master上访问、执行salt命令到minions。
  client acl system是在master上的client_acl参数配置的，在client_acl下可以设置用户可以使用的命令，也可以通过正则匹配设置一系列命令。例如：

client_acl:
  thatch:
    - .*
  fred:
    - ping.*
    - pkg.*
  允许thatch执行任何命令，允许fred使用ping和pkg命令。当然必须要让用户可读相关目录。 

  chmod 755 /var/cache/salt /var/cache/salt/jobs /var/run/salt 

6 state testing

  在执行salt state run的时候，可能潜在的改变系统，他可能是令人满意的，但也可能识不满意的。salt提供了一个test接口，报告哪些东西将被改变，这个接口可以被使用在任何state运行的func上面。

salt '*' state.highstate test=True
salt '*' state.sls test=True

7 the top file

  top file用来映射什么sls模块会通过state system被安装到minions。top file创建了一些通用的抽象。首先，它把节点映射到某个环境，接下来他定义匹配系统应答从哪个节点拉取。   

  First it maps what nodes should pull from which environments, next it defines which matches systems should draw from.

  top file的环境和设置的file_roots是一致的，在一个简单的，单一环境中，你只设置了base环境，因此你只有一个state tree，例子如下：

 

file_roots:
  base:
    - /srv/salt

  以上例子意味着，你的top file只有一个环境可以映射。例子如下：

base:
  '*':
    - core
    - edit
     这也意味着/srv/salt有一个state tree，如果你想使用多个环境，或者分隔file server到多个state tree，file_roots可以如下设置： 
file_roots:
  base:
    - /srv/salt/base
  dev:
    - /srv/salt/dev
  qa:
    - /srv/salt/qa
  prod:
    - /srv/salt/prod
  这时我们的top file可以如下引用多个环境： 
dev:
  'webserver*dev*':
    - webserver
  'db*dev*':
    - db
qa:
  'webserver*qa*':
    - webserver
  'db*qa*':
    - db
prod:
  'webserver*prod*':
    - webserver
  'db*prod*':
    - db
  在上面的设置中，我们设置了三个state tree，并没有设置在base环境中的state tree。 

  Remember, that since everything is a file in Salt, the environments are primarily file server environments, this means that environments that have nothing to do with states can be defined and used to distribute other files.

  关于top file可以参考：http://docs.saltstack.com/ref/states/top.html

8 state modules

  State Modules are the components that map to actual enforcement and management of Salt states

  state模块很容易编写，传入到sls数据结构的信息会被直接映射到states modules。
怎样使用定制的states模块？把你编写的state模块，放到_states目录下，该目录的具体路径是由file_roots指定的，这些定制的模块可以通过多种方法分发，当state.highstate运行时、执行saltutil.sync_states时、执行salr
tutil.sync_all函数时都会分发定制的模块。注意：state模块的名称模式就是state模块python脚本的名称。模块必须返回字典类型的数据。

  内建模块：http://docs.saltstack.com/ref/states/all/index.html

9 salt runners

  salt runners是一个便利的应用，方便使用salt-run的命令。就像salt模块发送到minions执行一样。salt runners在master上执行。一个salt runner可以是一个简单的客户端调用也可以是一个复杂的应用。
  The use for a Salt runner is to build a frontend hook for running sets of commands via Salt or creating special formatted output.
  很容易编写salt runners，它工作起来就和salt模块一样，不同之处在于salt runners在master上运行。一个runner是一个python模块，每个python模块中的共有函数都是一个runner，他可以通过salt-run命令执行。
  如果一个python模块是test.py，存放在runners的目录下，test.py有一个函数是foo，则可以通过一下方法使用：
salt-run test.foo

  系统自带了一些runner模块
     http://docs.saltstack.com/ref/runners/all/index.html
     https://github.com/saltstack/salt/tree/develop/salt/runners

10 startup states

  有时候希望minion启动的时候就执行state，这个减轻了master发起在新的minion上执行state的压力，因为新的minion客户端启动后会自动执行state，就不需要master发起该操作了。在salt的minion配置文件中有一些参数可以定义该功能。
  startup_states 可以传递一个或者多个参数，定义执行哪些states，可用参数如下：
     highstate  执行state.highstate
     sls  读取sls_list选项，然后执行sls文件
     top  读取top_file选项，然后基于master上的top文件执行states
  sls_list
  top_file
  例子：

startup_states: sls
sls_list:
  - edit.vim
  - hyper

11 salt syndic

  一个master控制多个master,同时被控制的master又可以控制很多的minion
    1 首先在中心节点的master上启动order_masters
    2 在次级mastert上启动syndic_master，指定为中心master，启动salt-syndic

    比如总的master为master,syndic节点为syndic1,将minion1的master制定为syndic,启动minion服务,然后在syndic1节点就可以看到未接受的key,接受后,syndic就可以管理minion1了,同时master也可以管理minion1了。

    参考：http://docs.saltstack.com/ref/syndic.html

12 grains

   salt用一个接口收集系统的信息，这个接口称为grains，grains收集到的信息是在minion第一次启动的时候获取的信息，所以必须认识到grains收集到的信息是静态的，是minion第一次启动的时候获取的，这些信息不会变化。grains收集的是客户端的信息，不同的客户端可以有不同的grains，grains.ls则可以列出目标机器上可用的grains的名称。
   你可以在minion配置文件总静态的设置grains。如果不想把grains配置在minion文件中，也可以把grains配置在/etc/salt/grains文件中，如果在两边都设置了grains，则minion配置文件中的优先级高。

#匹配系统是ubuntu的 进行ping测试
salt -G 'os:Ubuntu' test.ping

#获取有效可用的grains
salt '*' grains.ls

#获取grains的数据，所有的。
salt '*' grains.items

#要获取单个的数据，如下：
salt '*' grains.item shell
salt '*' grains.item osfullname osrelease

  上文说过，可以自己设置grains，既可以设置在minion中也可以设置在grains文件中，先看在minion中的格式：

 

grains:
  roles:
    - webserver
    - memcache
  deployment: datacenter4
  cabinet: 13
  cab_u: 14-15
  接着看在/etc/salt/grains文件中的格式：

 

roles:
  - webserver
  - memcache
deployment: datacenter4
cabinet: 13
cab_u: 14-15

  切记：重启minion后才会生效

  不过每次都修改客户端配置文件中的grains很麻烦，我们可以用python编写一些动态的grains来执行。minion启动时会自动执行grains包所带的模块和自定义grains中的函数，不过grains模块中的函数必须返回字典类型的值。这些动态的grains很显然是在master上设置的，放置在file_roots设置下的_grains目录中，然后需要执行 state.highstate或者altutil.sync_grains或者saltutil.sync_all，把_grains中的模块分发到minion上。

  动态grains例子：https://github.com/saltstack/salt/blob/develop/salt/grains/core.py

  参考：http://docs.saltstack.com/topics/targeting/grains.html

13 pillar

   所有通过pillar传输的信息能够保证被提交给目标主机，pillar传输的数据是与特定的minion关联的，每个minion只能看到自己的数据，这使得Pillar引擎在Salt中被用来管理安全的信息。pillar能够包含任意基本的数据结构，如:列表数据，或者k/v数据。可以让数据容易在SLS文档中使用。默认情况下，Pillar已经运行在了Salt系统中。
   默认情况下，主服务器的配置文件内容装载在pillar中，对所用的从服务器来说，通过配置主服务器的配置文件来使全局的从服务器生效。Pillar的数据创建在Salt主服务器上并且安全的分发到从服务器上。Salt当定义pillar的时候 并不局限于pillar sls文件，可以从其他额外的源取得数据。对于那些把基础结构信息存储在其他地方的会很有用。如果想禁止该功能，则可以设置master中的pillar_opts参数。

   pillar使用和state相似的配置，pillar文件子啊地址是在master配置文件中通过pillar_roots参数定义的：

 

pillar_roots:
  base:
    - /srv/pillar
   这段代码的意思是base环境下的pillar文件存放在/srv/pillar目录下，与state类似，pillar也有top file，使用相同的匹配方式将数据发送到minion上：/srv/pillar/top.sls

 

base:
  '*':
    - data
    - packages

/srv/pillar/data.sls内容是：

 

{% if grains['os'] == 'RedHat' %}
apache: httpd
git: git
{% elif grains['os'] == 'Debian' %}
apache: apache2
git: git-core
{% endif %}
/srv/pillar/packages/init.sls内容是：

 

{% for user, uid in pillar.get('users', {}).items() %}
{{user}}:
  user.present:
    - uid: {{uid}}
{% endfor %}

  上面的代码表示base环境中的而所有minion都具有data和packages中定义的数据，pillar采用与file server相同的文件映射方式，在上例中data映射到文件/srv/pillar/data.sls，packages映射到文件/srv/pillar/packages/init.sls。

  pillar模块有两个函数：pillar.data、pillar.raw，要查看所有的数据，可以如下：

 

salt '*' pillar.items
  在master上修改pillar下的文件后，要刷新一下，minion上的才能更新

 

salt '*' saltutil.refresh_pillar

   在使用pillar.items后，得出的额数据是python字典格式的，可以直接使用字典方法访问其中的数据。

下面展示一个官方提供的例子：

  /srv/pillar/pkg/init.sls

 

pkgs:
  {% if grains['os_family'] == 'RedHat' %}
  apache: httpd
  vim: vim-enhanced
  {% elif grains['os_family'] == 'Debian' %}
  apache: apache2
  vim: vim
  {% elif grains['os'] == 'Arch' %}
  apache: apache
  vim: vim
  {% endif %}
  /srv/pillar/top.sls

 

base:
  '*':
    - data
    - users
    - pkg

   /srv/salt/apache/init.sls

 

apache:
  pkg.installed:
    - name: {{ pillar['pkgs']['apache'] }}

  参考：http://docs.saltstack.com/topics/tutorials/pillar.html

14 Highstate data structure definitions

   top file ：主要的state入口文件，指定minions在state执行期间可以使用那些环境、模块。
   state tree ： 一些sls文件，存放在file_roots指定的目录下，使用sls模块的形式组织state tree。
   incluede 声明 ：定义了一系列modules reference包含在该sls文件中。例如

include:
  - edit.vim
  - http.server
   module reference：sls模块的名称，定义在单独分开的sls文件中。一个模块edit.vim，意思是它的sls文件在salt://edit/vim.sls. 
   id 声明：定义一个独特的highstate元素。经常代表一个字典数据，包含state声明和requisite声明。不过可以被name声明覆盖。如果有重复的id声明，则第一个生效。 
   extend 声明：扩展被引用的sls模块中的name声明，extend的值必须是在被引用的sls模块中定义的id。例如：

 

include:
  - apache

extend:
  apache:
    service:
      - watch:
        - file: mywebsite

   state 声明：是一个列表，值是function声明定义的。

   requisite 声明：是一个列表，其成员是requisite reference。用来生成动作依赖书，salt states被设计成按顺序执行，作为list组件用在state声明的下一级。

   requisite reference：只有一个值，值是被引用的state声明的名字，只能是requisite声明的成员。 

   function 声明：state中要执行的function，一个state声明中只能有一个function声明。例如：

 

#简写
httpd:
  pkg.installed
  
#或者完整写法
httpd:
  pkg:
    - installed
	
#注意下面连续两个简写是不生效的
httpd:
  pkg.installed
  service.running
   function arg 声明：作为参数传递给function声明。用在function声明的下一级。

 

/etc/http/conf/http.conf:
  file.managed:
    - user: root
    - group: root
    - mode: 644
   name 声明：覆盖state声明中的name参数，name参数的默认值是ID声明，例如：

 

mywebsite:
  file.managed:
    - name: /etc/apache2/sites-available/mywebsite.com
    - source: salt://mywebsite.com

   很明显mywebsite这个名词比/etc/apache2/sites-available/mywebsite.com方便。

   参考：http://docs.saltstack.com/ref/states/highstate.html

 

 

 

http://www.bubuko.com/infodetail-617813.html

saltstack 自动化运维神器（二）文件同步

时间：2015-02-04 18:53:56      阅读：45      评论：0      收藏：0      [点我收藏+]

标签：操作系统   配置文件   python   master   根目录   

文件同步：

    其实在做openstack的运维对一些文件的同步其实是很繁琐。有一个配置项或者一行代码的源码文件进行同步。那么现在我们就开始介绍saltstack的文件同步功能

 

环境说明：操作系统版本：rhel6.5x64

 

1、master配置同步根目录

     在开始saltstack的配置管理之前，要首先指定saltstack所有状态文件的根目录，在master上做如下操作

 ## 首先修改master的配置文件，指定根目录，注意缩进全部使用两个空格来代替Tab（python规范）## 确定指定的目录是否存在，如果不存在，需要手动来创建目录

[root@controller1 ~]# vim /etc/salt/master 
file_roots:
  base:
    - /srv/salt
  dev:
    - /srv/salt/dev/

[root@controller1 ~]# mkdir -p /srv/salt/dev
[root@controller1 ~]# ls -ld /srv/salt/dev
drwxr-xr-x 2 root root 4096 Feb  3 21:49 /srv/salt/dev

 重启master服务

[root@controller1 ~]# service salt-master restart
Stopping salt-master daemon:                               [  OK  ]
Starting salt-master daemon:                               [  OK  ]

2、介绍cp.get_file

   

   首先介绍cp.get_file，用来从master端下载文件到minion的指定目录下，如下

## 在master上创建测试用的文件

[root@controller1 ~]# echo ‘This is test file with saltstack module to  cp.get_file‘ >/opt/getfile.txt        
[root@controller1 ~]# cat /opt/getfile.txt 
This is test file with saltstack module to  cp.get_file

将文件拷贝到master的同步根目录下

[root@controller1 ~]# cp /opt/getfile.txt /srv/salt/

在master上执行文件下发

[root@controller1 ~]# salt ‘computer3‘ cp.get_file salt://getfile.txt /tmp/getfile.txt  
computer3:
    /tmp/getfile.txt

登录到computer3上查看同步情况

[root@computer3 ~]# cat /tmp/getfile.txt 
This is test file with saltstack module to  cp.get_file

 

分发文件的一些属性：

（1）压缩  gzip

 使用gzip的方式进行压缩，数字越大，压缩率就越高，9代表最大的压缩率

[root@controller1 ~]# salt ‘computer8‘ cp.get_file salt://getfile.txt /tmp/getfile.txt gzip=9
computer8:
    /tmp/getfile.txt

 

（2）创建目录 makedirs（当分发的位置在目标主机上不存在时，自动创建该目录）

[root@controller1 ~]# salt ‘computer8‘ cp.get_file salt://getfile.txt /tmp/srv/getfile.txt makedirs=True
computer8:
    /tmp/srv/getfile.txt

[root@computer8 opt]# ll /tmp/srv/getfile.txt 
-rw-r--r-- 1 root root 56 Feb  3 22:14 /tmp/srv/getfile.txt

3、grains

   先介绍一下grains，这个接口的作用是在minion端的minion服务启动时，调用这个接口，收集minion端的信息，这些信息数据可以在salt的其他模块中直接使用，需要注意的是，这个接口只在minion端的minion服务启动时被调用一次，所以收集的数据是静态的，不会改变的，除非你重启了minion端的服务

 

grains的基本用法:

[root@controller1 ~]# salt ‘computer3‘ grains.ls
computer3:
    - biosreleasedate
    - biosversion
    - cpu_flags
    - cpu_model
    - cpuarch
    - defaultencoding
    - defaultlanguage
    - domain
    - fqdn
    - fqdn_ip4
    - fqdn_ip6
    - gpus
    - host
    - hwaddr_interfaces
    - id
    - ip_interfaces
    - ipv4
    - ipv6
    - kernel
    - kernelrelease
    - localhost
    - manufacturer
    - master
    - mem_total
    - nodename
    - num_cpus
    - num_gpus
    - os
    - os_family
    - osarch
    - oscodename
    - osfinger
    - osfullname
    - osmajorrelease
    - osrelease
    - path
    - productname
    - ps
    - pythonpath
    - pythonversion
    - saltpath
    - saltversion
    - saltversioninfo
    - serialnumber
    - server_id
    - shell
    - virtual
    - zmqversion

 

使用grains.items模块列出所有可用grains的具体数据

[root@controller1 ~]# salt ‘computer3‘ grains.items
computer3:
  biosreleasedate: 08/28/2013
  biosversion: 2.10.0
  cpu_flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt aes lahf_lm arat dts tpr_shadow vnmi flexpriority ept vpid
  cpu_model: Intel(R) Xeon(R) CPU E7- 4820  @ 2.00GHz
  cpuarch: x86_64
  defaultencoding: UTF8
  defaultlanguage: en_US
  domain: 
  fqdn: computer3
  fqdn_ip4:
      192.168.100.23
  fqdn_ip6:
  gpus:
      {‘model‘: ‘MGA G200eW WPCM450‘, ‘vendor‘: ‘unknown‘}
  host: computer3
  hwaddr_interfaces: {‘lo‘: ‘00:00:00:00:00:00‘, ‘tap002cf093-0c‘: ‘fe:16:3e:cf:43:28‘, ‘em4‘: ‘f0:1f:af:90:38:65‘, ‘eth1.2‘: ‘f0:1f:af:90:37:fd‘, ‘em3‘: ‘f0:1f:af:90:38:63‘, ‘brq8f15ee7f-54‘: ‘f0:1f:af:90:37:fd‘, ‘brqadf94242-74‘: ‘f0:1f:af:90:37:fd‘, ‘eth1.400‘: ‘f0:1f:af:90:37:fd‘, ‘eth1‘: ‘f0:1f:af:90:37:fd‘, ‘eth0‘: ‘f0:1f:af:90:37:fb‘}
  id: computer3
  ip_interfaces: {‘lo‘: [‘127.0.0.1‘], ‘tap002cf093-0c‘: [], ‘em4‘: [], ‘eth1.2‘: [], ‘em3‘: [], ‘brq8f15ee7f-54‘: [], ‘brqadf94242-74‘: [], ‘eth1.400‘: [], ‘eth1‘: [], ‘eth0‘: [‘192.168.100.23‘]}
  ipv4:
      127.0.0.1
      192.168.100.23
  ipv6:
      ::1
      fe80::60f7:96ff:feab:3d44
      fe80::f21f:afff:fe90:37fb
      fe80::f21f:afff:fe90:37fd
      fe80::f8e7:cdff:fe54:7d02
      fe80::fc16:3eff:fecf:4328
  kernel: Linux
  kernelrelease: 2.6.32-431.el6.x86_64
  localhost: computer3
  manufacturer: Dell Inc.
  master: 192.168.100.200
  mem_total: 225995
  nodename: computer3
  num_cpus: 64
  num_gpus: 1
  os: RedHat
  os_family: RedHat
  osarch: x86_64
  oscodename: Santiago
  osfinger: Red Hat Enterprise Linux Server-6
  osfullname: Red Hat Enterprise Linux Server
  osmajorrelease:
      6
      5
  osrelease: 6.5
  path: /sbin:/usr/sbin:/bin:/usr/bin
  productname: PowerEdge M910
  ps: ps -efH
  pythonpath:
      /usr/bin
      /usr/lib64/python26.zip
      /usr/lib64/python2.6
      /usr/lib64/python2.6/plat-linux2
      /usr/lib64/python2.6/lib-tk
      /usr/lib64/python2.6/lib-old
      /usr/lib64/python2.6/lib-dynload
      /usr/lib64/python2.6/site-packages
      /usr/lib64/python2.6/site-packages/gtk-2.0
      /usr/lib/python2.6/site-packages
      /usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info
  pythonversion: 2.6.6.final.0
  saltpath: /usr/lib/python2.6/site-packages/salt
  saltversion: 2014.1.10
  saltversioninfo:
      2014
      1
      10
      0
  serialnumber: XXXXXX
  server_id: 111111111
  shell: /bin/bash
  virtual: physical
  zmqversion: 4.0.5

 

  ping测试grains中os的值为RedHat的主机通信是否正常

[root@controller1 ~]# salt -G ‘os:RedHat‘ test.ping 
computer5:
    True
computer8:
    True
computer6:
    True
computer7:
    True
computer4:
    True
computer3:
    True

 

查看uadoop2主机的ip地址，注意这里不是items噢，而是item

[root@controller1 ~]# salt ‘*‘ grains.item ipv4
computer5:
  ipv4:
      127.0.0.1
      192.168.100.25
computer7:
  ipv4:
      127.0.0.1
      192.168.100.27
computer4:
  ipv4:
      127.0.0.1
      192.168.100.24
computer3:
  ipv4:
      127.0.0.1
      192.168.100.23
computer8:
  ipv4:
      127.0.0.1
      192.168.100.28
computer6:
  ipv4:
      127.0.0.1
      192.168.100.26

 

 好了，在介绍了grains接口之后，接下来看下在cp模块中如何简单的使用grains的数据呢

先确定os是什么版本

[root@controller1 RedHat]# salt ‘computer4‘  grains.item os         
computer4:
  os: RedHat
[root@controller1 ~]# mkdir /srv/salt/RedHat/
[root@controller1 ~]# mv /srv/salt/getfile.txt  /srv/salt/RedHat/
[root@controller1 RedHat]# salt ‘computer4‘ cp.get_file "salt://{{grains.os}}/getfile.txt" /opt/getfile.txt template=jinja
computer4:
    /opt/getfile.txt

4、目录同步

    介绍cp.get_dir，get_dir与get_file的用法十分相似，用来将整个目录分发到minions

创建测试文件

[root@controller1 ~]# mkdir /srv/salt/test_dir
[root@controller1 ~]# echo ‘hello word !!‘ >>/srv/salt/test_dir/hello1.txt
[root@controller1 ~]# echo ‘hello2 word !!‘ >>/srv/salt/test_dir/hello2.txt
[root@controller1 ~]# ll /srv/salt/test_dir/
total 8
-rw-r--r-- 1 root root 14 Feb  4 14:49 hello1.txt
-rw-r--r-- 1 root root 15 Feb  4 14:49 hello2.txt

测试分发： 执行目录文件的分发，并使用压缩传输

[root@controller1 ~]# salt ‘computer4‘ cp.get_dir salt://test_dir /tmp gzip=9 
computer4:
    - /tmp/test_dir/hello1.txt
    - /tmp/test_dir/hello2.txt

 登录到目标节点查看分发状态：
[root@computer4 ~]# ll /tmp/test_dir/
total 8
-rw-r--r-- 1 root root 14 Feb  4 14:52 hello1.txt
-rw-r--r-- 1 root root 15 Feb  4 14:52 hello2.txt

 

5、数据的灵活变更

 

   在往下介绍之前，首先介绍一下salt的pillar接口，pillar是salt中比较重要的组件，跟grains有些相似，但是pillar相比于grains更加灵活，而且是动态的，数据可以随时更新，只要你愿意的话。而grains只在minion启动时采集一次数据，关于pillar官网描述如下，简单翻译一下，但不保证翻译的到位，意思是说pillar是salt实现部署功能的最重要的组件，能够为minions生成非常灵活的数据，这些数据可以被salt的其他的组件所使用。

   The pillar interface inside of Salt is one of the most important components of a Salt deployment. Pillar is the interface used to generate arbitrary data for specific minions. The data generated in pillar is made available to almost every component of Salt.

grains的基本用法

（1）配置master

[root@controller1 ~]# vim /etc/salt/master 
pillar_roots:
  base:
    - /srv/pillar
[root@controller1 ~]# service salt-master restart
Stopping salt-master daemon:                               [  OK  ]
Starting salt-master daemon:                               [  OK  ]
[root@controller1 ~]# mkdir /srv/pillar
[root@controller1 ~]# mkdir /srv/pillar/user   //创建一个user的测试目录

 

（2）创建入口文件

 首先在/srv/pillar目录中要有一个入口文件top.sls

[root@controller1 pillar]# cat top.sls 
base:
  ‘computer3‘:
    - date         ## 为uadoop2定义了一个属性数据，引用了跟top.sls同目录下的data.sls

  ‘computer4‘:
    - webserver    ## 为uadoop3定义了一个属性数据，引用了跟top.sls同目录下的web.sls

  ‘*‘:
    - user         ## 为所有节点定义了一个属性数据，引用了/srv/pillar/user/init.sls
                   ## 这里指定的是一个目录，salt会自动在top.sls文件中的引用目录中寻找状态文件
                   ## 因此会找到位于user目录中的init.sls文件
                   ## 在测试请不要有任何的‘#’
编写其他两个属性：
[root@controller1 pillar]# cat date.sls 
date: some date
[root@controller1 pillar]# cat webserver.sls 
webserver: test_dir

测试：

# salt ‘*‘ pillar.items

computer3:
    ----------
    date:
        some date
    master:
        ----------
        auth_mode:
            1
        auto_accept:
        ....省略N行...........
    user:
        ----------
        foway:
            1200
        kadefor:
            1000
        kora:
            1000
computer4:
    ----------
    master:
        ----------
        auth_mode:
            1
        auto_accept:
            False
        cachedir:
            /var/cache/salt/master
         .........省略N行..........
    user:
        ----------
        foway:
            1200
        kadefor:
            1000
        kora:
            1000
    webserver:
        test_dir
computer5:
    ----------
    master:
        ----------
        auth_mode:
            1
        auto_accept:
            False
        cachedir:
            /var/cache/salt/master
            ......省略N行......
    user:
        ----------
        foway:
            1200
        kadefor:
            1000
        kora:
            1000
            ...............

 在master上远程获取刚刚定义的属性

[root@controller1 pillar]# salt ‘computer3‘ pillar.items
computer3:
    ----------
    date:
        some date
    master:
        ----------
        auth_mode:
            1
        auto_accept:
            False
        cachedir:
        ..........省略N行..........
    user:
        ----------
        foway:
            1200
        kadefor:
            1000
        kora:
            1000
           
[root@controller1 pillar]# salt ‘computer4‘ pillar.items 
computer4:
    ----------
    master:
        ----------
        auth_mode:
            1
        auto_accept:
            False
       ..........省略N行..........
    user:
        ----------
        foway:
            1200
        kadefor:
            1000
        kora:
            1000
    webserver:
        test_dir

## 可以看到刚刚为不同的minion定义的属性已经同步到了各个minion上，从这个测试可以看出，使用pillar

## 我们可以为不同的minion或者不同的minion组定义不同的属性，极其灵活。

 

好了，在介绍了pillar接口之后，接下来看下在cp模块中如何简单的使用pillar定义的属性数据呢

   我们可以利用之前定义的属性来匹配不同的minion

 

 

首先先同步一下pillar到每个节点上

[root@controller1 ~]# salt ‘*‘ saltutil.refresh_pillar
computer8:
    None
computer4:
    None
computer5:
    None
computer6:
    None
computer3:
    None
computer7:
    None

测试一下匹配

[root@controller1 ~]# salt -I -v ‘date:some date‘ test.ping                    
Executing job with jid 20150204164730224160
-------------------------------------------

computer3:
    True
[root@controller1 ~]# salt -I -v ‘webserver:test_dir‘ test.ping
Executing job with jid 20150204165017170702
-------------------------------------------

computer4:
    True
[root@controller1 ~]# salt -I -v ‘users:foway:1200‘ test.ping   
Executing job with jid 20150204165053938046
-------------------------------------------

computer5:
    True
computer6:
    True
computer7:
    True
computer3:
    True
computer8:
    True
computer4:
    True

匹配computer3，然后在master上远程分发文件到computer上去

[root@controller1 salt]# salt -I -v ‘webserver:test_dir‘ cp.get_dir "salt://{{pillar.webserver}}" /opt/ gzip=9 template=jinja
Executing job with jid 20150204165518149257
-------------------------------------------

computer4:
    - /opt//test_dir/hello1.txt
    - /opt//test_dir/hello2.txt

 

感觉saltstack的功能很强大，有没有把你震惊到。继续学习把。。。。。

 

 

 

 

http://www.kerncai.com/page2/

salt的pillar定义以及使用(六)

  • 2014 年 01 月 13 日
  • tech
  • sa

Pillar是Salt非常重要的一个组件，它用于给特定的minion定义任何你需要的数据，这些数据可以被Salt的其他组件使用。这里可以看出Pillar的一个特点，Pillar数据是与特定minion关联的，也就是说每一个minion都只能看到自己的数据，所以Pillar可以用来传递敏感数据（在Salt的设计中，Pillar使用独立的加密session，也是为了保证敏感数据的安全性）。 
另外还可以在Pillar中处理平台差异性，比如针对不同的操作系统设置软件包的名字，然后在State中引用等。

定义pillar数据

默认情况下，master配置文件中的所有数据都添加到Pillar中，且对所有minion可用。默认如下：

#pillar_opts: True

master上配置文件中定义pillar_roots，用来指定pillar的数据存储在哪个目录

pillar_roots:
   base:
    - /srv/salt/pillar

首先，和state系统一样，pillar也是需要一个top.sls文件作为一个入口，用来指定对象。

base:
  '*':
    - pillar #这里指定了一个pillar模块

pillar.sls文件：

############IDC#############
{ % if grains['ip_interfaces'].get('eth0')[0].startswith('10.10') %}
nameservers: ['10.10.9.31','10.10.9.135']
zabbixserver: ['10.10.9.234']
{ % else %}
nameservers: ['10.20.9.75']
zabbixserver: ['10.20.9.234']
{ % endif %}

######## nginx ########
ngx_home_dir: /var/cache/nginx

上文的IDC这块是我自己整理的通过ip来划分不同的nameserver等，这里只是放出来参考，在State文件中将可以引用Pillar数据，比如引用ngx_home_dir:

nginx:
  pkg:
    - installed
  user.present:
    - home: { { pillar['ngx_home_dir'] }}
    - shell: /sbin/nologin
    - require:
      - group: nginx
  group.present:
    - require:
      - pkg: nginx
  service.running:
    - enable: True
    - reload: True
    - require:
      - file: /etc/init.d/nginx
      - file: /data1/logs/nginx
    - watch:
      - file: { { pillar['ngx_conf_dir'] }}/nginx.conf
      - file: { { pillar['ngx_conf_dir'] }}/fastcgi.conf
      - pkg: nginx

······ 后面关于配置就省略了

在pillar内可以提前将不同的部分根据在pillar内定义好，这样统一配置的时候就可以实现根据机器实际情况配置；比如根据机器的硬件情况配置nginx的worker_processes:

user nginx;
{ % if grains['num_cpus'] < 8 %}
worker_processes { { grains['num_cpus'] }};
{ % else %}
worker_processes 8;
{ % endif %}
worker_rlimit_nofile 65535;
``````````具体配置省略

很多定义的时候，都可以使用到pillar来进行自定义相关数据，具体情况可以自行摸索，这里只是个举例。

salt的state.sls配置说明以及使用(五)

  • 2014 年 01 月 12 日
  • tech
  • sa

SLS（代表SaLt State文件）是Salt State系统的核心。SLS描述了系统的目标状态，由格式简单的数据构成。这经常被称作配置管理 
首先，在master上面定义salt的主目录，默认是在/srv/salt/下面，vim /etc/salt/master：

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

然后，在/srv/salt下面创建top.sls文件(如果有的话，就不用创建了，直接编辑好了) 
vim top.sls

base:
  '*':

top.sls 默认从 base 标签开始解析执行,下一级是操作的目标，可以通过正则，grain模块,或分组名,来进行匹配,再下一级是要执行的state文件

base:
  '*':               #通过正则去匹配所有minion
    - nginx          #这里都是我自己写的state.sls模块名 这里可以无视 后面会提到

  my_app:             #通过分组名去进行匹配 必须要定义match:nodegroup
    - match: nodegroup
    - nginx

  'os:Redhat':        #通过grains模块去匹配，必须要定义match:grain
    - match: grain
    - nginx

整个top.sls大概的格式就是这个样子，编写完top.sls后，编写state.sls文件；

cd /srv/salt 
vim nginx.sls

nginx.sls内容：

nginx:
  pkg:               #定义使用（pkg state module）
    - installed      #安装nginx（yum安装）
  service.running:   #保持服务是启动状态
    - enable: True
    - reload: True
    - require:
      - file: /etc/init.d/nginx
    - watch:                 #检测下面两个配置文件，有变动，立马执行上述/etc/init.d/nginx 命令reload操作
      - file: /etc/nginx/nginx.conf
      - file: /etc/nginx/fastcgi.conf
      - pkg: nginx
/etc/nginx/nginx.conf:       #绝对路径
  file.managed:
    - source: salt://files/nginx/nginx.conf  #nginx.conf配置文件在salt上面的位置
    - user: root
    - mode: 644
    - template: jinja   #salt使用jinja模块
    - require:
      - pkg: nginx

/etc/nginx/fastcgi.conf:
  file.managed:
    - source: salt://files/nginx/fastcgi.conf 
    - user: root
    - mode: 644
    - require:
      - pkg: nginx

在当前目录下面（salt的主目录）创建files/nginx/nginx.conf、files/nginx/fastcgi.conf文件，里面肯定是你自己项配置的nginx配置文件的内容啦；使用salt做自动化，一般nginx都是挺熟悉的，这里不做详细解释了

测试安装：

root@salt salt # salt 'sa10-003' state.sls nginx test=True
··········这里省略输出信息
Summary
------------
Succeeded: 8
Failed:    0
------------
Total:     8

往minion上面进行推送的时候，一般salt ‘sa10-003’ state.sls nginx 这种命令；当然，也可以执行 
salt sa10-003 state.highstate 这种命令会默认匹配所有的state.sls模块。其中test=True 是指测试安装 
，也就是不进行实际操作，只是查看测试效果。

state的逻辑关系列表：

include： 包含某个文件 
比如我新建的一个my_webserver.sls文件内，就可以继承nginx和php相关模块配置，而不必重新编写

root@salt salt # cat my_webserver.sls 
include:
  - nginx
  - php

match: 配模某个模块，比如 之前定义top.sls时候的 match: grain match: nodegroup 
require： 依赖某个state，在运行此state前，先运行依赖的state，依赖可以有多个 
比如文中的nginx模块内，相关的配置必须要先依赖nginx的安装

- require:
  - pkg: nginx

watch： 在某个state变化时运行此模块，文中的配置，相关文件变化后，立即执行相应操作

- watch:
  - file: /etc/nginx/nginx.conf
  - file: /etc/nginx/fastcgi.conf
  - pkg: nginx

order： 优先级比require和watch低，有order指定的state比没有order指定的优先级高，假如一个state模块内安装多个服务，或者其他依赖关系，可以使用

nginx:
  pkg.installed:
    - order:1

想让某个state最后一个运行，可以用last

salt的grains使用以及cmd.run(四)

  • 2014 年 01 月 10 日
  • tech
  • sa

grains.items主要用来收集minion端的信息，方便进行信息采集，后续的piller使用，根据硬件信息自动匹配配置文件等。

基本用法

grains.ls

salt '*' grains.ls 显示所有minion的item

grains.items

salt '*' grains.items 显示所有minion的item值

grains.item

salt '*' grains.item os 显示os的相关信息。如下 ：
root@salt ~ # salt 'sa10-003' grains.item os
sa10-003:
  os: RedHat

如果想同时获取多个item，可以在后面接空格后，直接相关item，如下：

root@salt ~ # salt 'sa10-003' grains.item os osrelease oscodename
sa10-003:
  os: RedHat
  oscodename: Tikanga
  osrelease: 5.8

自定义grains： 
首先，现在salt的根目录下(/srv/salt)建一个目录_grains

mkdir /srv/salt/_grains
cd /srv/salt/_grains

假设我要取minion端内存的信息 事例如下： 
vim mem.py

# -*- coding: utf-8 -*-

'''
Module for squid disk information by python
'''
import commands
import os

def cache():
    '''
    Return the memory usage information for volumes mounted on this minion
    '''
    grains={}
    m = commands.getoutput("free -g|awk '$0~/Mem/ {print$2+1}'")
    grains['mem_test']=int(m)

    return grains

同步到minion端

root@salt _grains # salt 'sa10-003' saltutil.sync_all 
sa10-003:
    ----------
    grains:
        - grains.mem #已经同步过来了
    modules:
    outputters:
    renderers:
    returners:
    states:

如果需要更改模块，更改完成后，可以使用下面命令重载:

salt sa10-003 sys.reload_modules

验证下之前的自定义grains：

root@salt _grains # salt sa10-003 grains.item mem_test
sa10-003:
  mem_test: 2

sa10-003的内存信息：

[root@sa10-003 salt]# free -m
             total       used       free     shared    buffers     cached
Mem:          2012       1766        246          0        286       1207
-/+ buffers/cache:        272       1739
Swap:            0          0          0

在saltmaster上面自定义grains取到的信息和本机是一致的

除了salt自带和我们自定义的items可以取到系统信息之外，我们还可以使用shell命令在来达到目的；当然，这需要salt的另外一个强大的命令，cmd.run 
我要取sa10-003的内存信息，可以使用下面的命令：

root@salt _grains # salt sa10-003 cmd.run 'free -m'
sa10-003:
                 total       used       free     shared    buffers     cached
    Mem:          2012       1769        242          0        286       1207
    -/+ buffers/cache:        275       1736
    Swap:            0          0          0

cmd.run在master端进行操作，后面跟着的是系统相关的shell命令，这种方式，可以实现minion端几乎所有的命令。

salt匹配minion和自定义用户组(nodegroup)(三)

  • 2014 年 01 月 09 日
  • tech
  • sa

前提：操作在master在进行 
minion id minion的唯一标示。默认情况minion id是minion的主机名(FQDN)，你可以通过id来指定minion的名字. 
salt默认使用shell样式，当然也可以在states.sls中定义。本文主要记录的是匹配minion，以为只有正确的匹配，才是你以后批量管理机器的前提。

匹配当前所有的minion：

root@salt ~ # salt '*' test.ping
cdn20-002:
  True
cdn20-001:
    True
app10-104:
    True
cdn20-003:
    True
其中 '*' 是匹配当前saltmaster接收到所有minion客户端；test.ping是salt默认的验证通信命令

匹配以cdn开头的所有机器:

root@salt ~ # salt 'cdn*' test.ping
cdn20-002:
    True
cdn20-005:
    True
cdn20-004:
    True
cdn20-001:
    True
cdn20-003:
    True

匹配cdn20-001/004的机器：

root@salt ~ # salt 'cdn20-00[1-4]' test.ping
cdn20-002:
    True
cdn20-001:
    True
cdn20-003:
    True
cdn20-004:
    True

minion也可以通过Perl-compatible正则表达式进行匹配.匹配cdn和sa的机器

root@salt ~ # salt -E 'cdn|sa' test.ping
cdn20-005:
    True
cdn20-002:
    True
sa10-003:
    True
cdn20-004:
    True
cdn20-001:
    True
cdn20-003:
    True

指定特定的机器进行匹配，比如，我想匹配cdn20-002\cdn20-004：

root@salt ~ # salt -L 'cdn20-002,cdn20-004' test.ping
cdn20-002:
    True
cdn20-004:
    True
 

自定义组进行匹配：

使用组进行匹配的前提，必要要在master里面定于组的相关信息

root@salt ~ # vim /etc/salt/master.d/nodegroups.conf         
master.d之前的记录已经介绍过，在master里面开启default_include: master.d/*.conf
root@salt ~ # cat /etc/salt/master.d/nodegroups.conf 
nodegroups:
  my_app: 'app10-091'
  squid_20: 'cdn20-*'
  mendian: 'app10-114'
  person: 'L@app10-112,app10-113'

查看squid_20这个组的相关信息：

root@salt ~ # salt -N 'squid_20' test.ping
cdn20-002:
    True
cdn20-005:
    True
cdn20-004:
    True
cdn20-003:
    True
cdn20-001:
    True




http://www.kerncai.com/page3/







http://www.shencan.net/index.php/2014/02/22/ansible%E4%B8%89-%E8%87%AA%E5%AE%9A%E4%B9%89%E6%A8%A1%E5%9D%97/

苦逼的路既然开始啦.日子还得继续过呀,路还很长.. 前几日ansible中国用户组的群主发了一个ansible管理配置手册(英文的)  ,简单看了下 还蛮不错的

虽然我英语不好 看不出啥牛掰的东西,还是大概看了下ansible 自定义模块这块 确实不错(至少比官网的好)

ansible 其实我个人一直很喜欢 ,但是以前先搞的salt  其实salt给我的一个感觉是 灵活性很强, 什么一上来就是 state mudule pillar grains return…等等 而且这些玩意都能自定义 如果你懂点py  真的  你线上的东西再复杂用salt都能搞定…  一开始接触ansible  就想用salt的思路去搞ansible   心里没事想  ansible的setup(salt的grains)  咋去自定义…(目前我也没搞定)   模块怎么去自定义

看到那边管理手册 里面有介绍自定义模块  所以就记录下

下面开始干活吧

ansible 模块大家都知道 是干啥的吧  (就是salt 的state ) 做配置管理的 (什么 file  server shell command的 )

这是目前ansible 所有的模块

http://docs.ansible.com/list_of_all_modules.html

但是这些模块都是官方弄的  可能你们线上有些特殊的应用 官网没有这些模块

官网没有模块 不是说ansible 就搞不定了  只是你得用他办法去弄了  如果有模块的话 你只要传几个参数就行 就ok了

ansible 安装完后 所有的模块默认都在 /usr/share/ansible/ 目录下  (默认哟)

当然你也可以通过更改ansible.cfg 配置文件 library 目录来更改啦

哎  不多说了 开始弄吧

先说下 ansible自定义模块 支持 shell跟python脚本  由于我不会python(真不会啦)  我下面就用shell 来自定义一个ansible模块

我这里一开始比较简单  希望大家理解这个过程更原理   以后等你有其他需求了  按照下面的改改就行

上脚本吧 shell的

1

 

这就是自定义的模块 脚本名称叫cpis  你到时候引用的时候 就应用cpis模块  模块里面有2个参数(当然你也可以写多个呀  到时候记得source进去就行)

ansible 自定义模块就写好了  当然 脚本大小 跟用途 你自己决定(shell 应该问题不大  理解就行)  我这里只是演示

ansible 源码包里面自带一个模块测试工具 可以测试你这个模块 是否有问题  (1.3以上版本就ok)

我测试下吧

1

 

测试没问题了 我们得用到playbook上呀   下面我们就应用到playbook上

下面我简单写个简单playbook调用cpis 模块吧

1

 

ok  playbook就先简单搞个啦  我们测试下

下面简单说下  因为我们都知道ansible 模块都在 /usr/share/ansible/ 下 如果你想用cpis这个自定义的模块 你可以把 脚本放到上面那边目录

或者用ansible-playbook –module-path 指定也行

这里我就直接cp 到上面目录啦

下面我来应用啦

1

 

 

ok  功能实现了  擦 感觉写了好多……

下面我简单  实现个功能吧  实现安装salt吧  很蛋疼的例子 为了大家能明白原理

大家都知道 epel 目前salt 版本的0.17.5  epel-testing salt版本是2014.1.0 如果我去yum install salt的话  就是最新版本

下面我把cpis 改下 实现 安装salt  +  指定版本号

 

#!/bin/bash
set -e
source $1 $2
CHANGED=”False”
if [ ! -z "$name" ] || [ ! -z "$version" ];
then
yum install ${name}-${version} -y && CHANGED=”True”
fi
echo “name=${name} version=$version changed=${CHANGED}”
exit 0

 

改下playbook

[root@CAN-GE-1 shencan]# cat fuck.yaml
—
- hosts: all
gather_facts: no
tasks:
- name: cange module test
cpis: name=salt version=0.17.5

 

ok

就这么多吧

 

 

http://www.chenqing.org/tag/saltstatck

saltstatck

【saltstack】saltstack常见教程索引–不定期更新

Posted on 8 八月, 2013 by admin
 
Category: shares, Unix&Linux
 
 
 
 

在上一篇文章《saltstack,目测这货会火》已经可以预见。saltstack 搭载着python在运维中流行（当然流行的主要原因还是灵活，简单），逐渐变得很流行，非官方数据透露，在国内的大的互联网公司，都已经在推进saltstack的使用，包括腾讯，阿里，人人，趣游等等，当然也有一些小公司，比如CC(自黑，哈哈)，所以学会怎么使用saltstack在运维减轻压力，带来成就，就很重要了。

鄙人关注saltstack也算很久了，也没给saltstack做出点贡献，该有的教程都让大牛们出来了，当然，我也是看着大牛们的教程，到了现在，所以，借花献佛，把一些常见的saltstack的教程罗列至此，贱笑了。。。

首先声明：所有教程仅列出连接，并会注明出处和作者（或译者），哈哈，保护产权嘛，你我有责。其实最好的学习就是看官方文档，最直接的学习方式就看源码，然后DO IT.

一、saltstack 起步

阻碍一个产品推行的第一个绊脚石莫过于软件的安装，相信大家都深有体会，而saltstack的安装真的好简单，另外一篇好的入门文档也可以使之加分不少哦，哈哈，二八原则，下面这篇文章，可能只介绍了20%的salt的知识，但应该可以满足你80%的常见任务了（仅是打比方，勿当真！）

官方文档：http://docs.saltstack.com/topics/tutorials/quickstart.html

《自动化运维之salt》:

原文连接：http://wiki.saltstack.cn/reproduction/om-auto-salt

原作者：halfss

本文中讲解了，软件的安装配置，target，nodegroup,grains,pillar，state等简单概念，还包括实时执行命令的的cmd.run 以及模块的概念等，读过此文，相信你已经能够入门，并且有心思意淫salt的妩媚了。

好了，大概了解了salt，相信你也已经安装好了，能够运行salt \* cmd.run ‘hostname’ 了吧

假如按照上面这个命令的顺序，我们也应该介绍上面命令的那个\*,也就是targeting的概念了，对啊，你要下发任务，要执行命令你得有个对象吧（下次再有人问，puppet与saltstack孰优孰劣时，你就可以说，首先，你得有个对象。。。哈哈）

官方文档: http://docs.saltstack.com/topics/targeting/index.html

Targeting — 在SaltStack中选择目标机器

原文链接：http://www.ituring.com.cn/article/41737

原作者（译者）：yinchuan

本文简单介绍了，targeting的概念和应用，使你在执行任务的时候，有了简单的对象，对象，像。。。。

接下来说点啥呢？ok，先来点简单的，Grains吧，不过Grains和pillar一块讲可能会更好些：

官方文档：http://docs.saltstack.com/topics/targeting/grains.html （grains）

http://docs.saltstack.com/topics/pillar/index.html  (pillar)

saltstack (二) grains和pillar

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

原作者：沈灿

备注：此牛人是我同事，牛逼哄哄的，不过网站真心慢。

上面的文章，语言比较诙谐，偶尔有个错字（哈哈，我不是故意的），不客气的说，灿哥应该可以出书的，

再补充几篇讲解pillar的，公认的这东西难理解啊。

如何使用Salt Pillar

原文链接：http://www.ituring.com.cn/article/42398

原作（译）者：yinchuan 

《在SaltStack中使用Pillar》

原文链接：http://wiki.saltstack.cn/reproduction/using_pillar_data_in_saltstack

原作者：pengyao

saltstack(六) pillar+ grains 实际演练

这个还是灿哥的，我不会跟你们说，这货的截图暴露了我们线上很多东西，请大牛们装作真不知道。

下面应该讲讲state了吧，ok，开整：

官方文档：http://docs.saltstack.com/topics/tutorials/starting_states.html （入门）

http://docs.saltstack.com/ref/states/all/index.html （支持的states列表）

http://docs.saltstack.com/ref/states/index.html  （Salt’s Pillar system）

http://docs.saltstack.com/ref/states/highstate.html （highstate）

http://docs.saltstack.com/ref/states/writing.html      (怎么写states)

Salt States概览

原文链接：http://www.ituring.com.cn/article/42238

原作者（译者）：yinchuan 

再接下来，是不是应该讲讲模块了啊

模块这东西，说的简单点，就是已经写好的一些py脚本，然后你直接远程执行就是了，下面是官方的解释：

Salt modules are the core of remote execution. They provide functionality such as installing packages, restarting a service, running a remote command, transferring files, and infinitely more.

官方文档：http://docs.saltstack.com/ref/modules/all/index.html （模块列表）

http://docs.saltstack.com/ref/modules/index.html       （如何写模块）

不过话说过来，想了解怎么用，还是建议去看看源代码，或者使用sys.doc 看下说明

再分享从youtube上下载的俩视频，还有一个PPT挺好的：

http://pan.baidu.com/share/link?shareid=3609767220&uk=3122407145

常见实例：

刘天斯：基于saltstack实现的配置集中化管理[原创]
链接 :http://blog.liuts.com/post/240

一个很不错的完整的例子，大家可以很好的学习一下。

 

 
标签：saltstatck
 

【saltstack】目测这货会火

Posted on 7 六月, 2013 by admin
 
Category: Others, Unix&Linux
 
 
 
 

以前搞puppet，各种纠结，后来就没有后来了，后来同事推荐了saltstack（我们都叫他“盐”），这东西给我的感觉就像当年CodeIgniter给我的感觉一样（那puppet其实和Zend有的一比了，呵呵），一见钟情。

首先，他速度快，基于消息队列+线程，跑完多台设备，都是毫秒级别的。
其次，真TMD的灵活，你会写点python，你就能自定义模块。
最后，简单，简单的令人发指。

至于怎么用，以及一些具体的介绍，可以参考一下链接：

saltstack官网：http://saltstack.org
官方文档：http://docs.saltstack.com/
朋友的两篇幽默诙谐的教程：
http://www.shencan.net/index.php/2013/05/24/saltstack%EF%BC%88%E4%B8%80%EF%BC%89/
http://www.shencan.net/index.php/2013/05/24/saltstack-%E4%BA%8C-grains%E5%92%8Cpillar/

 

 

 

 

 

posted @ 2015-05-08 14:45  陳聽溪  阅读(539)  评论(0)    收藏  举报