SaltStack Pillar Walkthrough - practical exercise

Pillar Walkthrough - Pillar combat exercise

• Setting Up Pillar- set Pillar
  • More Complex Data- use more complex data
• Pillar Parameterizing States With Pillar- used to parameterize the configuration States
• Pillar Makes Simple States Grow Easily-Pillar allow easy States to become more flexible, powerful
• Setting Pillar Data on the Command Line- Pillar data provided on the command line
• More knowledge More On Pillar-Pillar of
• Minion Config in Pillar- using Pillar profiles defined Minion

Note: This walkthrough assumes that the reader has completed the initial Salt exercise .
About Pillar exercise, we can also refer to this technical information: Pillar Walkthrough - Pillar combat exercise

Pillar tree data structure is defined on Salt Master, and passed to minions used. They allow sending confidential or targeted data securely to the relevant minions.

Note: Grains and Pillar sometimes confused, just remember this, Grains information about a minion is responsible for storing a minion or by the generated data. That's why you can find the cause of the OS and CPU type and other information in the Grains. Pillar in Salt Master is stored or generated information about the many minions or minion of.

Pillar typical usage scenarios are:

• Highly sensitive data: The transmission of information pillar guarantee provided only to the target object, the Pillar for managing security information, such as encryption keys and passwords.
• Minion configuration: Minion module, for example, may generally be performed to configure the module, and a state like returners by the data stored in the pillar.
• Use variables: the need to be assigned to a particular variable or minions minions groups can be defined in the pillar, and then visit sls formula and template files.
• Arbitrary data: Pillar basic data structures can comprise any form dictionary, it is possible to define a set of key / value store, then it is easy sls iteration formula.

Therefore, Pillar is one of the most important use of Salt systems. This walkthrough aims to Pillar up and running in minutes, and then in-depth understanding of the function and the Pillar of available data storage location.

SETTING UP PILLAR

By default, pillar already running in Salt. Check pillar data minion of the method are:

salt '*' pillar.items

NOTE: Prior to version 0.16.2, this function is called pillar.data. This function name is still supported for backward compatibility.

By default, the contents of master configuration file will not be loaded into the pillar minions in. This can be pillar_optsset as the default option False.

Content Master configuration file can be used to configure the minion of pillar file. This makes the overall service and system configuration becomes very easy, but please note that if you store sensitive data in the master configuration file, it may not be appropriate to do so. To make the master configuration file for the content of the pillar minion file, the configuration file in the minion pillar_optsset True.

And the state tree of similar status, pillar by the sls files, and has a top file file. The default storage location Pillar file is / srv / pillar.

Note: You can master configuration file pillar_rootsconfiguration file location pillar of options. But it can not be in state or state tree file_rootsof subdirectories. If the pillar is located file_rootsbelow, any pillar target will be skipped minions.

Now begin configuring pillar, we confirm that /srv/pillarthe directory has been created:

mkdir /srv/pillar

Create a simple top file file, the same file format as the top file use state status:

/srv/pillar/top.sls:

base:
  '*':
    - data

data.sls files were associated with this top.sls all minions in the file.

Now we need to fill /srv/pillar/data.slsfile:

/srv/pillar/data.sls:

info: some data

In order to ensure minions have a new pillar data, issue commands to them, ask them to get there from the master data and refresh their pillar:

salt '*' saltutil.refresh_pillar

Now, it has been minions side pillar of the updated data can be accessed via the following method:

salt '*' pillar.items

We define the key infoshould now appear in the data returned by the pillar.

MORE COMPLEX DATA

The difference is that with the state status, pillar documents do not need to define a formula. The following example uses the UID to set the user data:

/srv/pillar/users/init.sls:

users:
  thatch: 1000
  shouse: 1001
  utahdave: 1002
  redbeard: 1003

NOTE: In the presence of the same state and the state in the pillar configuration directory, the file can be used in the top file usersreferenced users/init.slsfile.

Top file needs to be updated to include this file sls file:

/srv/pillar/top.sls:

base:
  '*':
    - data
    - users

These data are now supplied minions use. To reference the data in the state pillar state, you can use Jinja templates and variables:

/srv/salt/users/init.sls:

{% for user, uid in pillar.get('users', {}).items() %}
{{user}}:
  user.present:
    - uid: {{uid}}
{% endfor %}

This is a recommended security of user data defined in the pillar, and then the user data using the method applied sls file.

PARAMETERIZING STATES WITH PILLAR

You can access the data in the state pillar state file to customize the behavior of each minion. Each minion suitable for all pillar (and grain) data, before running through the template is replaced with the final executable file state status. It includes typical uses for minion configuration directory and skip states applicable state.

A simple example is to set the mapping pillar names for different Linux distributions:

/srv/pillar/pkg/init.sls:

pkgs:
  {% if grains['os_family'] == 'RedHat' %}
  apache: httpd
  vim: vim-enhanced
  {% elif grains['os_family'] == 'Debian' %}
  apache: apache2
  vim: vim
  {% elif grains['os'] == 'Arch' %}
  apache: apache
  vim: vim
  {% endif %}

We see that when defining pillar, we can define the pillar minions dynamic variable data through grains.

Need to pkgbe added to the top file in sls:

/srv/pillar/top.sls:

base:
  '*':
    - data
    - users
    - pkg

Now, Minions automatically mapped to the correct value, which can be safely pillar reference data parameters within the pillar attribute information in each operating system file sls:

/srv/salt/apache/init.sls:

apache:
  pkg.installed:
    - name: {{ pillar['pkgs']['apache'] }}

Alternatively, if there is no data available pillar can also specify a default value, used like this:

Note: This function used in the example pillar.gethas been added to version 0.14.0 in Salt

/srv/salt/apache/init.sls:

apache:
  pkg.installed:
    - name: {{ salt['pillar.get']('pkgs:apache', 'httpd') }}

In the example above, if the pillar value pillar['pkgs']['apache']and do not disposed in the pillar minion, then you use the default value httpd.

NOTE: In the package under various salt, is really just a Python dictionary Pillar, Python dict method can be used, such as getand items.

PILLAR MAKES SIMPLE STATES GROW EASILY

Pillar One of the design goals is to make a simple formula sls easily become more flexible formula, without the need to reconstruct the state or complicated.

A simple formula:

/srv/salt/edit/vim.sls:

vim:
  pkg.installed: []

/etc/vimrc:
  file.managed:
    - source: salt://edit/vimrc
    - mode: 644
    - user: root
    - group: root
    - require:
      - pkg: vim

You can use this formula pillar changes into a more flexible, parameterized formula:

/srv/salt/edit/vim.sls:

vim:
  pkg.installed:
    - name: {{ pillar['pkgs']['vim'] }}

/etc/vimrc:
  file.managed:
    - source: {{ pillar['vimrc'] }}
    - mode: 644
    - user: root
    - group: root
    - require:
      - pkg: vim

We can now proceed to change the source file vimrc by pillar location:

/srv/pillar/edit/vim.sls:

{% if grains['id'].startswith('dev') %}
vimrc: salt://edit/dev_vimrc
{% elif grains['id'].startswith('qa') %}
vimrc: salt://edit/qa_vimrc
{% else %}
vimrc: salt://edit/vimrc
{% endif %}

Ensure that sends the correct vimrc to correct minions.

Pillar top file in the file must contain a reference to the new sls pillar file:
/srv/pillar/top.sls:

base:
  '*':
    - pkg
    - edit.vim

SETTING PILLAR DATA ON THE COMMAND LINE

Operation state.apply <salt.modules.state.apply_(), the pillar data may be provided on the command line, as follows:

salt '*' state.apply pillar='{"foo": "bar"}'
salt '*' state.apply my_sls_file pillar='{"hello": "world"}'

Nested pillar values ​​may also set the command line:

salt '*' state.sls my_sls_file pillar='{"foo": {"bar": "baz"}}'

Data can be passed through a list of command-line pillar, as follows:

salt '*' state.sls my_sls_file pillar='{"some_list": ["foo", "bar", "baz"]}'

Note: If a key on the existing minion, while passing on the command line of a same key, the key will cover the entire incoming value of the key, rather than merging.

The following example will list the previously specified value vim and telnet exchange, note nested pillar dict:

salt '*' state.apply edit.vim pillar='{"pkgs": {"vim": "telnet"}}'

This will attempt to install telnet on your minion, when you can safely uninstall the test or replace telnet value package with anything else for testing.

Note: When sending sensitive data via the command line pillar, all minions will receive publications containing the data, and does not limit the target minions. In some cases, this may mean a security problem.

MORE ON PILLAR

Pillar Data generated on the Salt master and securely distribute minions. When defining pillar, Salt is not limited to use only pillar sls file, and to retrieve data from an external source. When information is stored about the infrastructure at a separate location, which may be useful.

About the pillar and pillar external interface reference information can be found in the documentation Salt: Pillar

MINION CONFIG IN PILLAR

Minion configuration options can be set through the pillar. But you have to modify any configuration options that should be the same minion located pillar of the first stage, the configuration file options. For example, to configure the MySQL root password MySQL Salt execution module used:

mysql.pass: hardtoguesspassword

When you need to dynamically change the configuration information, which is very convenient. For example, if you do, there is a chicken and egg problem:

mysql-admin-passwd:
  mysql_user.present:
    - name: root
    - password: somepasswd

mydb:
  mysql_db.present

The second state will fail, because you changed the mysql root password and minion did not notice it. At this time, by setting the pillar mysql.passwill help to solve the problem. But always you need to change mysql root administrator password.

Any changes to this module requires credentials to the application state is useful: mysql, keystone and so on.