写在前面的话
上一节谈及了 Saltstack 的安装和初始化配置，本节将谈谈 Saltstack 中两个重要的东西，Grains 和 Pillar。
数据系统 Grains 入门
Grains 是静态数据，其数据来源于 Minion 启动的时候收集的有关客户端本地的相关信息。
包括操作系统，内核，CPU，内存，硬盘，设备型号等等。这就意味着我们可以使用 Saltstack 做资产管理。
这些静态数据除非是 Minion 重启或者 Master 端主动同步更新，否则不会改变。
1. 查看 grains 默认支持的 Key：
salt 'saltstack-node-01' grains.ls
结果如下：
我们可以看到超级多的 Key。我这里只截图了一小部分。grains.ls 这其实就是 python 里面引用 grains 模块中的 ls 方法。
2. 查看所有 Key 的值：
salt 'saltstack-node-01' grains.items
结果如图：
返回的结果其实就是 YAML 格式，后面会单独的提到 YAML 语法特点。这里我们只需要知道其实就是 K/V 结构就行。
3. 查看单独某个 Key 的值：
salt 'saltstack-node-01' grains.item os
结果如图：
这里区别查看所有，item 采用单数的形式，如果该 Key 不存在或者没值，那么就不会有下面绿色部分的显示。
4. 我们就可以根据这里的 KV 来就行选择特定的机器，类似 K8S 中的标签选择器（Label Selector）：
salt -G 'os:CentOS' cmd.run 'uptime'
结果如图：
注意，如果我们用 KV 选择需要使用 -G 参数。且这里的冒号后面没空格。
5. 当然，默认的 grains 可能无法满足我们的需求，我们可以自定义，一共有两种方法：
方法 1：在 /etc/salt/minion 配置文件的 129 行 有关于 grains 的配置（不同版本可能不一样）
可以添加一下配置进行测试：
grains:
roles: app-server
注意 roles 前面空格 2 个，roles 后面 : 后面空格 1 个，这是 YAML 语法要求。
然后我们重启 minion 测试一下：
systemctl restart salt-minion
在 Master 查看：
salt '*' grains.item roles
结果如图：
可以发现刚刚添加的 node3 节点已经能够看到我们新添加的 KV 配置了。
方法 2：通过方法 1 我们发现，如果都写到 minion 配置文件，不便于我们管理，所有我们可以抽离出来：
我们可以新建 /etc/salt/grains 文件，该文件能够自动被 salt 识别，直接在内部写 KV：
server_env: product
server_name: mall-server
注意冒号后面有个空格。我们也可以不重启 minion，直接在 Master 端同步，然后再度查看：
# 不重启直接同步 salt '*' saltutil.sync_grains # 查看多个 salt '*' grains.item server_env server_name
结果如下：
6. 或者某个 Key 的值我们还可以使用如下方法：
salt '*' grains.get os
对比 grains.item 查看结果：
我们发现使用 item 相对于使用 get 多显示了 Key。
7. 自己用 Python 开发一个 grains： 方法就是写个脚本，返回一个字典即可。
首先我们需要修改 master 的配置文件：/etc/salt/master 在当前版本的 658 行有关于 file_roots 的配置，我们把配置放开。
file_roots:
base:
- /srv/salt
该目录同时也用于我们之后写 YAML 文件使用。当然这个目录不存在，还需要我们在 Master 节点手动建立。
# 重启 Master systemctl restart salt-master # 创建目录 mkdir /srv/salt
我们存放 Python 脚本的目录为：_grains
cd /srv/salt/ && mkdir _grains
我们在下面新建一个获取时间的 Python 脚本：get_time.py
#!/usr/bin/env python #-*- coding:utf-8 -*- import time def get_time(): grains = {} grains['year'] = time.localtime().tm_year grains['month'] = time.localtime().tm_mon grains['day'] = time.localtime().tm_mday return grains
然后同步到所有 Minion 节点：
salt '*' saltutil.sync_grains
结果如图：
我们可以查看同步之后的脚本在 Minion 节点放到了什么位置：
tree /var/cache/salt/
结果如图：
我们需要知道的是 /var/cache/salt 目录相当重要，从 Master 端同步的都会放到该目录下，其中红色部分就是能够执行的代码。
可以直接查看刚刚我们定义的那些 Key：
salt '*' grains.item year
结果如图：
如果这过程中出现问题，我们都可以查看日志：/var/log/salt/minion
当然，在我们定义 grains 的时候，可能会和系统的名称出现一样的情况，这就牵扯到一个优先级：
系统自带 > grains 文件中 > minion 中写的 > 自己写的
数据系统 Pillar 入门
Pillar 相比于 Grains，首先 Pillar 是动态的数据。其次 Pillar 定义在 Master 上面，只有特定的节点能看到，所以安全。
我们可以查看当前系统中的 Pillar 数据：
salt '*' pillar.items
可以看到目前是没数据的，但是其实系统是有一部分数据的，只是被隐藏了而已，如果你确实想看，可以通过修改 Master 配置实现查看，配置在 /etc/salt/master 的 878 行（我当前的版本），修改配置为如下配置，再度重启 Master 即可：
pillar_opts: True
其最终查看的结果其实际是一个叫做 master 的字典，但是并不推荐开启，因为不便于管理 pillar 配置。
我们从前面知道了 Grains 是可以直接在 minion 配置文件中定义的，那么 Pillar 需要这么定义呢？此时就可以看出 Grains 和 Pillar 的明显不同，Grains 配置在 Minion 端，Pillar 配置在 Master 端，且 Pillar 使用我们后面会经常用到的 sls 文件进行管理。至于 sls 的具体使用方法，后面会单独详讲。
1. 我们需要通过修改 master 配置文件，放开 Pillar 配置，在 /etc/salt/master 我当前版本的 828 行：
pillar_roots:
base:
- /srv/pillar
重启 Master 新建目录：
# 重启 systemctl restart salt-master # 新建目录 /srv/pillar # 查看目录结构 tree /srv/
结果如图：
2. 为了更好的进行管理，可以对 sls 文件进行归类，我们这里在 pillar 下面新建一个 test 目录，用于存放测试 sls 文件：
cd /srv/pillar/ && mkdir test # 创建配置 vim server_role.sls
内容如下：
{% if grains['fqdn'] == 'demo-node1' %}
salt_role: master
{% else %}
salt_role: minion
{% endif %}
在该配置中我们加入了 Grains 判断。至于这个文件的语法，如果你学过 Python 并且使用过 Django 你就会发现特别熟悉，没错，Jinja2 语法。后面也会详讲，这里先简单应用。该配置大致意思就是根据主机名给不同的 Minion 设置不同的角色属性。
3. 新建 top.sls，在 Saltstack 中 sls 配置有一个统一的入口，那就是 top.sls 文件，我们这里也是简单的应用，后面讲到配置的时候单独详讲，先有这么个概念和印象就行。
vim top.sls
内容如下：
base: '*': - test.server_role
简单做个说明：* 指代所有主机，你也可以写特定的主机或者通配符，因为我们新建了 test 目录，所有我们得像 Python 调用模块一样，使用 test.server_role 来调用配置文件。此时可以查看下目录结构：
4. 同步配置，可以像 grains 一样不用重启直接同步：
salt '*' saltutil.refresh_pillar
结果如下：
再度查看：
salt '*' pillar.item salt_role
结构如图：
5. 使用选择器执行想要的：
salt -I 'salt_role:master' cmd.run 'w'
查看结果：
注意：这里 Pillar 的规则需要使用 -I （大写 i）参数，就行 Grains 需要使用 -G 参数一样。同时可能会遇到这样的情况，如下：
对于 Minion did not return. [No response] 这种问题，一般重启 minion 端就能解决。
小结
通过对比 Grains 和 Pillar，我们会发现其最大的特点有以下几个：
1. Grains 主要配置在 Monion，而 Pillar 主要配置在 Master。
2. Grains 可以自己用 Python 写方法，返回一个字典就行。Pillar 则是用 Salt 最为主要的 sls 配置。
3. Grains 一般是静态数据，虽然自定义的可以使用方法动态获取，而 Pillar 则是可以利用 Jinja2 模板进行逻辑判断。
4. Grains 和 Pillar 都能很好的支持数据查询，配置管理，Pillar 还能够进行敏感数据管理。
5. 两者都能很好的协助我们通过类似标签选择器（Label Selector）的方式对服务器进行批量选择。
注意：这里所说的所谓保护敏感数据其实是因为我们在 Master 端做的定义，这样即使黑客攻陷了某台 Minion 他也无法拿到敏感数据而已。