Pillar components of Saltstack series 5:Saltstack

Pillar component

Pillar is also one of the most important components of Saltstack, its function is to define any data related to the controlled host, and the defined data can be used by other components, such as template, state, API and so on.

The data defined in pillar is associated with controlled hosts with different business characteristics, so different controlled hosts can only see their own matching data, so pillar has high security and is suitable for some sensitive data, which is the most important point different from grains, such as defining user id, group id, read and write permissions, packages and other information of hosts in different business groups. The defined specification is in the form of Python dictionary, that is, keys / values. The uppermost key is usually the name of the host's id or group.

Definition of pillar main profile definition

Saltstack defines all the data in the master configuration file into pillar by default, and it is open to all controlled hosts. You can define whether to turn this function on or off by modifying the / etc/salt/master configuration.

[/ etc/salt/master]

Pillar_opts: True/False

Execute the command after modification to observe the effect:

Salt'* 'pillar.dataSLS file definition

Pillar supports the definition of data in the sls file, and the format must comply with the YAML specification, which is very similar to the state component of Saltstack. It is easy for newcomers to confuse the two. The configuration format of the two files and the entry file top.sls are the same.

Define the home directory of pillar

[/ etc/salt/master]

Pillar_roots: base:-/ srv/pillar

At the same time, create the pillar directory and execute the command:

Install-d / srv/pillar

Define the entry file top.sls

The entry file is generally used to define the valid range of pillar data covering the controlled host.'* 'represents any host, including a data.sls file as follows:

[/ srv/pillar/top.sls]

Base:'*':-data # refers to the data.sls file

[/ srv/pillar/data.sls]

Appname: websiteflow: maxconn: 3000 maxmem: 6G check pillar

Refresh the pillar information of the controlled host

Salt'* 'saltutil.refresh_pillar

View the data.sls data items defined above

The use of salt 'wx' pillar.data appname flowpillar

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

Example:

{{pillar ['appname']}} (level 1 dictionary) {{pillar [' flow'] ['maxconn']}} (level 2 dictionary) or {{salt [' pillar.get'] ('flow:maxconn', {})}} # Python API format is as follows: pillar [' flow'] ['maxconn'] pillar.get (' flow:appname', {}) operate target host salt-I 'appname:website' test.ping

Results:

Wx: True

The difference of data processing combined with grains

First, the value of maxcpu of different id is distinguished by combining the id information of grains. Secondly, the data.sls is modified to the following form by referencing and observing the matching information:

Wx:-flow:-maxconn: 3000 maxcpu: 8 maxmem: 6G

Reference:

According to Liu Tiansi's "Python Automation Operation and maintenance Technology and Best practices"