【2】Saltstack handbook：Grains and Pillar

EDITORIAL words

On one talked about Saltstack installation and initial configuration, this section will talk about Saltstack two important things, Grains and Pillar.

Data entry system Grains

Grains are static data , which is activated when the data from the Minion collected about the client's local information.

Including the operating system, the kernel, CPU, memory, hard disk, device model, and so on. This means that we can use Saltstack do asset management.

These static data unless it is restarted or Minion Master side actively updated simultaneously, it would not change.

1. Check the grains supported by default Key:

salt 'saltstack-node-01' grains.ls

The results are as follows:

We can see that the Super Multi Key. I am here only capture a small part. grains.ls fact, this is python inside reference method ls grains module.

2. Check the value of all Key:

salt 'saltstack-node-01' grains.items

The results are shown:

The results returned is actually YAML format, the latter will separate mention YAML syntax features. Here we need to know is actually a K / V structures on the line.

3. Check the individual values of a Key:

salt 'saltstack-node-01' grains.item os

The results are shown:

See all the difference here, item takes the form of the singular, if the Key value does not exist or is not, then there would be a green section below.

4. At this time, we can select a particular machine line according KV herein, similar K8S the tag selector (Label Selector):

salt -G ' them: CentOS ' cmd.run ' uptime '

The results are shown:

Note that if we choose to use KV need to use the -G parameter. And no space after the colon here.

5. Of course, the default grains may not be able to meet our needs, we can customize a total of two ways:

Method 1: In the / etc / Salt / Minion 129 line profile about grains configurations (different versions may be different)

You can add some configuration tested:

grains:
  roles: app-server

Note that the space in front of two roles, behind roles: a rear space, which is YAML syntax.

Then we restart minion test:

systemctl restart salt-minion

In the Master View:

salt '*' grains.item roles

The results are shown:

Node3 node can be found just added have been able to see our newly added KV configured.

方法 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 上面，只有特定的节点能看到，所以安全。

【2】Saltstack handbook：Grains and Pillar

Guess you like