【2】Saltstack handbook：Grains and Pillar

 

 

写在前面的话

 

上一节谈及了 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 他也没法拿到敏感数据而已。