How to define any data related to the controlled host through the Saltstack pillar component?

What is pillar?
Pillar is also one of the most important components of Saltstack. Its role is to define any data related to the controlled host. The defined data can be used by other components, such as templates, state, and APIs. The data defined in the pillar is associated with the controlled hosts with different business characteristics, so that different controlled hosts can only see their matching data. Therefore, the pillar is very safe and suitable for some sensitive data, which is also different from The most critical point of grains, such as defining the user id, group id, read and write permissions, program package and other information of different business group hosts. The definition specification is in the form of a Python dictionary, that is, key/value. The uppermost key is generally for the host. id or group name.

Main pillar configuration file definition

Saltstack defines all data in the master configuration file to the pillar by default, and is open to all controlled hosts. You can modify the /etc/salt/master configuration to define whether to enable or disable this function.

[root@saltstack-master _grains]# vim /etc/salt/master
pillar_opts: True
[root@saltstack-master _grains]# /etc/init.d/salt-master restart
Stopping salt-master daemon: [确定]
Starting salt-master daemon: [确定]

Execute the command after modification to observe the effect:

[root@saltstack-master _grains]# salt 'saltstack_web1group_1' pillar.data
saltstack_web1group_1:
----------
master:
----------
__role:
master
auth_mode:
1
auto_accept:
True
cache_sreqs:
True
cachedir:
/var/cache/salt/master
cli_summary:
False
--------------忽略部分内容------------------

SLS file definition

Pillar supports the definition of data in sls files. The format must conform to the YAML specification, which is very similar to the state component of Saltstack. The configuration format of the two files and the entry file top.sls are the same. The following details the configuration process defined by pillar using sls.

1. Define the main directory of the pillar

Modify the pillar_roots parameter of the main configuration file /etc/salt/master to define the main directory of the pillar. The format is as follows:

[root@saltstack-master _grains]# vim /etc/salt/master
pillar_roots:
base:
- /srv/pillar
[root@saltstack-master _grains]# /etc/init.d/salt-master restart
Stopping salt-master daemon: [确定]
Starting salt-master daemon: [确定]

Create a pillar directory at the same time, execute the command: install -d /srv/pillar

[root@saltstack-master _grains]# install -d /srv/pillar

2. Define the entry file top.sls

The function of the entry file is generally to define the effective domain range of the controlled host covered by the data of the pillar, "*" represents any host, including a data.sls file.

[root@saltstack-master _grains]# vim /srv/pillar/top.sls
base:
'*':
- data
[root@saltstack-master _grains]# vim /srv/pillar/data.sls
appname: website
flow:
maxconn:30000
maxmen:6G

3. Validation pillar

　　By viewing the pillar data of the host "saltstack_web1group_1", you can see that there are more data.sls data items, because we used " " to cover all hosts when we defined top.sls . As shown below, if the result is not as expected, you can try to refresh the Pillar data of the controlled host by running salt ' ' saltutil.refresh_pillar.

[root@saltstack-master _grains]# salt 'saltstack_web1group_1' pillar.data appname flow
saltstack_web1group_1:
----------
appname:
website
flow:
maxconn:30000 maxmen:6G

The use of
pillar After completing the pillar configuration, the next step is to introduce how to use it. We can quote in state and template files, the template format is "{{pillar variable}}"

{{ pillar['appname'] }} (一级字典)
{{ pillar['flow']['maxconn'] }} (二级字典)或{{ salt['pillar.get']('flow: 'maxconn',{}) }}

Python API format:

pillar['flow']['maxconn']
pillar.get('flow:appname',{})

1. Operate the target host

Use pillar to match the controlled host with the -I option:

[root@saltstack_master ~]# salt -I 'appname:website' test.ping
saltstack_web1group_1:
True

2. Combining grains to process data differences

首先通过结合grains的ID信息来区分不同id的maxcpu的值，其次进行引用观察匹配的信息。将data.sls修改成如下形式，其中，"if ... else...endfi"为jinja2的模板语法。

appname: website
flow:
maxconn:30000
maxmen:6G
{% if grains['id'] == 'SN100-128' %}
maxcpu: 8
{% else %}
maxcpu: 4
{% endif %}

View the pillar data of the controlled host

salt 'saltstack_web1group_1' pillar.data appname flow

Pillar defines an example in top.sls:

Open pillar_root in the master configuration file

pillar_roots:
base:
- /etc/salt/pillar

mkdir /etc/salt/pillar
mkdir /etc/salt/pillar/init

重启 /etc/init.d/salt-master restart

vim /etc/salt/pillar/top.sls
base:
'*':
- init.rsyslog

vim /etc/salt/pillar/init/rsyslog.sls

{% if grains['osfinger'] == 'CentOS-6' %}

syslog:rsyslog
{% elif grains['osfinger'] == 'CentOS-5' %}

syslog: syslog

{% endif %}

salt '*' saltutil.refresh_pillar //刷新