Grains 与 Pillars

Grains介绍

Grains接口是salt用来采集底层系统信息的，包含了操作系统信息、域名、IP地址、内核、内存等一些底层信息。就是因为grains采集了这些信息，在salt中就可以利用这些信息，进行minion选择，选择符合条件的minion，来执行操作。

Grains数据是一个相对静态的数据，只是在minion启动的时候进行采集，在下一次minion重启之前，不会主动去更新，也就是说在这段时间，信息发生了变化，grains是不会主动更新的，但是有一些系统参数或者用户自定义参数发生了变化，grains还是会去进行更新的。

Grains数据可以用于信息查询类，比如资产管理，获取指定的参数值，都是字典形式的，可以用于目标选择，通过特定的item值，来选择相同类型的主机。

1.信息查询

[root@master ~]# salt '192.168.64.132' grains.ls    
[root@master ~]# salt '192.168.64.132' grains.items
[root@master ~]# salt '192.168.64.132' grains.item os

Grains是以字典的形式，存放这些数据信息的，所有对grains的操作，和对字典的操作类似，其中grains.ls是列出所有的key，grains.items是列出所有的键值对key-value的形式，而grains.item是指定key，获取该key对应的值。

由于可以通过grains进行查询，这里就可以对目标minion进行区别，假如现在的minion中有CenOS和RedHat两种不同的操作系统，只想对CentOS的系统进行操作，就可以通过grains来进行选择。

[root@master ~]# salt -G 'os:CentOS' test.ping
192.168.64.132:
    True
192.168.64.131:
    True

-G表示通过grains进行匹配，后面需要填写grains的键值对，没有空格，后面就是需要进行的操作了。

除了系统自带的grains意外，还可以对于不同的minion自定义grains，grains是根据minion的配置文件静态指定的，只需要在配置文件中使用grains，然后按照YAML规则，填写相关的值即可。填写完成之后，必须要重启minion，或者同步grains才能生效。

# Custom static grains for this minion can be specified here and used in SLS
# files just like all other grains. This example sets 4 custom grains, with
# the 'roles' grain having two values that can be matched against.
#grains:
#  roles:
#    - webserver
#    - memcache
#  deployment: datacenter4
#  cabinet: 13
#  cab_u: 14-15

在这里，我们可以在132上指定一个grains，roles:webserver。然后通过master去查询所有。

[root@master ~]# salt  '*' grains.item roles
192.168.64.132:
    ----------
    roles:
        - webserver
192.168.64.131:
    ----------
    roles:
[root@master ~]# salt -G 'roles:webserver' test.ping
192.168.64.132:
    True

只有132有返回值，这样就可以通过用户自定义的grains，来选择minion了。

还有一种方式可以自定义grains，就是直接在/etc/salt/grains文件中，以YAML的格式，编写文件，然后重启minion后，就可以查询到自定义的grains了。

[root@localhost ~]# cat /etc/salt/grains
place:
  dc01:
    rack13:
      10-13U

在132上编写grains文件，然后在master上执行刷新操作，然后进行查询。

[root@master ~]# salt '*' saltutil.sync_grains
192.168.64.131:
192.168.64.132:
[root@master ~]# salt '*' grains.item place
192.168.64.132:
    ----------
    place:
        ----------
        dc01:
            ----------
            rack13:
                10-13U
192.168.64.131:
    ----------
    place:

2. 状态管理（目标选择）

有了grains获取信息之后，在编写top.sls的时候，就可以根据minion的特征grains，来有针对性的安装或执行命令。比如现在需要在roles为webserver的主机上，安装httpd，安装文件已经写成了状态文件web.apache了。

base:
  'place:dc01:rack13:10-13u'
    - match: grain
    - web.apache

在top.sls文件中，以YAML的格式编写，其中第一行是键值对，匹配跪着是grian，描述的状态是web.apache。然后通过topfile进行执行。

[root@master salt]# salt '*' state.highstate
192.168.64.131:
----------
          ID: states
    Function: no.None
      Result: False
     Comment: No Top file or master_tops data matches found. Please see master log for details.
     Changes:   

Summary for 192.168.64.131
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1
Total run time:   0.000 ms
192.168.64.132:
----------
          ID: apache-install
    Function: pkg.installed
        Name: httpd
      Result: True
     Comment: The following packages were installed/updated: httpd
     Started: 16:09:59.537687
    Duration: 4358.622 ms
     Changes:   
              ----------
              httpd:
                  ----------
                  new:
                      2.4.6-67.el7.centos
                  old:
----------
          ID: apache-install
    Function: pkg.installed
        Name: httpd-devel
      Result: True
     Comment: The following packages were installed/updated: httpd-devel
     Started: 16:10:03.977852
    Duration: 4197.869 ms
     Changes:   
              ----------
              httpd-devel:
                  ----------
                  new:
                      2.4.6-67.el7.centos
                  old:
----------
          ID: apache-service
    Function: service.running
        Name: httpd
      Result: True
     Comment: Started Service httpd
     Started: 16:10:09.845850
    Duration: 146.409 ms
     Changes:   
              ----------
              httpd:
                  True

Summary for 192.168.64.132
------------
Succeeded: 3 (changed=3)
Failed:    0
------------
Total states run:     3
Total run time:   8.703 s
ERROR: Minions returned with non-zero exit code

在执行这个topfile的时候，也就会将该top.sls文件传递给对应的minion，位置还是/var/cache/salt/minion/file/base/top.sls。

3. 用户自定义grains

在master上，可以对minion进行自定义grains，然后传递给minion。在master上自定义的grains文件，必须存放在file_roots目录下的grains目录下，默认就是/srv/salt/grains。在执行高级状态的时候，也就是top file的时候，或者是执行saltutil.sync_grains的时候，从master上传递给所有的minion上。

用户自定义grains很好写，只需要返回一个字典就好了。在方法中定义一个空字典，然后可以选择填写多个值，然后返回该字典就好了。

自定义granis的使用场景，当需要向maste中增加新的minion的时候，新minion的有些字段和现在的minion不同，需要在现在的minion上配置该字段，就可以直接在master上配置grains，然后同步给所有的minion，以后就可以通过该字段区分这些minion。

写的时候，文件命名一定要是.py结尾的，因为默认呢会将该文件导入到salt中去执行。

[root@master _grains]# cat mygrains.py 
def my_grains():
    grainsdict = {}
    grainsdict['create_time'] = '20190414'
    return grainsdict
[root@master _grains]# salt '*' saltutil.sync_grains
192.168.64.131:
    - grains.mygrains
192.168.64.132:
    - grains.mygrains
[root@master _grains]#

同步给了minion之后，在minion的/var/cache/salt/minion目录下就能看到，是在extmodus中。

[root@localhost minion]# tree
.
├── accumulator
├── extmods
│   └── grains
│       ├── mygrains.py
│       └── mygrains.pyc
├── files
│   └── base
│       ├── _grains
│       │   └── mygrains.py
│       ├── top.sls
│       └── web
│           └── apache.sls
├── highstate.cache.p
├── module_refresh
├── proc
└── sls.p

8 directories, 8 files

以grains命名的目录，然后多了在master上创建的grains。

然后就可以通过该定义的grains来进行匹配目标了。其实在传递的时候，可以指定minion，这意思就是给指定的minion设置grains了。

[root@master _grains]# salt '*' grains.item create_time
192.168.64.132:
    ----------
    create_time:
        20190414
192.168.64.131:
    ----------
    create_time:
        20190414

4.Pillar

Grains只能预先定义minion的属性，定义完成之后，必须要重启minion或者是刷新grains，master才能通过之前预先定义的grains进行目标选择。如果在定义grains之后，minion上的该属性值发生了变化，grains不会跟着修改，比较麻烦。所以出现了一种可以动态定义的属性，也就是Pillars。

Pillar是一种支持动态数据采集的，然后根据pillar值，动态的匹配minion，也就是target minion。默认情况下，所有的minion是没有pillar的。

[root@master ~]# salt '*' pillar.items
192.168.64.132:
    ----------
192.168.64.131:
    ----------
[root@master ~]# salt '*' pillar.item
192.168.64.131:
    ----------
192.168.64.132:
    ----------
[root@master ~]# salt '*' pillar.ls
192.168.64.131:
192.168.64.132:

Pillar是在master上进行定义的，然后根据目标minion设置值，也就是说只有目标minion知道该pillar的值，其他minion都不知道有该值，这个就是敏感数据的设置。

和file_root类似，pillar也有一个root环境，在master的配置文件中需要设置，pillar_root，推荐存放在/srv/pillar目录下，也有环境的区分，比如base等等。在pillar中也有top.sls的概念。

# Salt Pillars allow for the building of global data that can be made selectively
# available to different minions based on minion grain filtering. The Salt
# Pillar is laid out in the same fashion as the file server, with environments,
# a top file and sls files. However, pillar data does not need to be in the
# highstate format, and is generally just key/value pairs.
pillar_roots:
  base:
    - /srv/pillar

修改完master配置之后，需要重启master环境。pillar的编写，也是基于YAML格式来的。可以在pillar目录下创建目录或直接的sls文件，来定义pillar。

比如现在两个主机上都没有一个对象称为owners，可以创建一个owners.sls定义owner。

[root@master pillar]# cat top.sls 
base:
  '*':
    - owners
[root@master pillar]# cat owners.sls 
owner:
  - administrator
[root@master pillar]# salt '*' pillar.ls
192.168.64.131:
    - owner
192.168.64.132:
    - owner
[root@master pillar]# salt '*' pillar.items
192.168.64.131:
    ----------
    owner:
        - administrator
192.168.64.132:
    ----------
    owner:
        - administrator
[root@master pillar]# salt '*' pillar.item owner
192.168.64.132:
    ----------
    owner:
        - administrator
192.168.64.131:
    ----------
    owner:
        - administrator

在上面的例子中，定义了一个顶层文件top.sls，在顶层文件中，表明，所有的minion，都拥有base环境下的owners.sls这个文件定义的pillar。而base环境就是在master文件中定义的pillar_roots中有定义。

然后重新定义了一个owner.sls的状态文件，描述的是一个Key-Value的形式，表示owner为administrator。

配置完成之后，执行刷新命令，为所有的minion赋予该值。

[root@master pillar]# salt '*' saltutil.refresh_pillar
192.168.64.132:
    True
192.168.64.131:
    True

然后就可以通过pillar的命令来查看刚才定义的pillar，和grains的查看方式是一样的。

这种定义方式，和grains的定义是相同的，都是在master上定义，grains需要将文件同步到minion上，pillar貌似没有将文件传递过去。

pillar的另一种方式，就是可以根据其他信息，来动态定义，比如通过grains来做定义。

[root@master pillar]# cat top.sls 
base:
  '*':
    - owners
    - apache
[root@master pillar]# cat apache.sls 
{% if grains['os'] == 'CentOS' %}
apache: httpd
{% elif grains['os'] == 'Debian' %}
apache: apache2
{% endif %}
[root@master pillar]#

在这个例子中，首先是在top文件中增加了一个字段，有apache文件中定义的的属性，然后定义了一个apache文件，里面定义了一个变量apache，该变量的值，是根据grains的值来动态指定的，如果操作系统os是CentOS，则该变量的值为httpd，如果操作系统os为Debian，则该变量的值为apache2.这个和python里面的简单判断很类似，不过这个语法模板成为jinja模板。

使用pillar，最有效的，就是在状态管理/配置管理中，对目标minion进行选择。比如可以选择apache为httpd的节点，进行连通性测试。

[root@master pillar]# salt -I 'apache:httpd' test.ping
192.168.64.131:
    True
192.168.64.132:
    True
[root@master pillar]# salt '*' pillar.item apache
192.168.64.132:
    ----------
    apache:
        httpd
192.168.64.131:
    ----------
    apache:
        httpd

通过pillar进行minion节点选择，是使用了-I参数。

下面对grains和pillar进行一下对比。

	grains	pillar
数据采集方式	minion启动时采集	master自定义
数据类型	静态	动态生成
应用场景	数据查询目标选择配置管理	数据查询目标选择配置管理敏感数据
定义的位置	minion上定义 master可以传递给minion	master上定义