Pillar 演练¶

设置Pillar¶

The pillar is already running in Salt by default. To see the minion's pillar data:

salt '*' pillar.items

By default the contents of the master configuration file are loaded into pillar for all minions. This enables the master configuration file to be used for global configuration of minions.

Similar to the state tree, the pillar is comprised of sls files and has a top file. The default location for the pillar is in /srv/pillar.

要开始设置pillar，需要准备/srv/pillar目录：

mkdir /srv/pillar

Now create a simple top file, following the same format as the top file used for states:

/srv/pillar/top.sls:

base:
  '*':
    - data

This top file associates the data.sls file to all minions. Now the /srv/pillar/data.sls file needs to be populated:

/srv/pillar/data.sls:

info: some data

To ensure that the minions have the new pillar data, issue a command to them asking that they fetch their pillars from the master:

salt '*' saltutil.refresh_pillar

Now that the minions have the new pillar, it can be retrieved:

salt '*' pillar.items

The key info should now appear in the returned pillar data.

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

base:
  '*':
    - data
    - users

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

用Pillar参数化States¶

state文件可以使用Pillar数据为每个minion定制动作。适用于各个minion的所有pillar(和grain)数据在被使用前通过templating代入到state文件中。通常的用法包括恰当地为minion设置路径和跳过不应用的states。

一个简单的例子是在pillar中为不同的Linux发行版设定包名字的映射:

/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 %}

新的 pkg sls需要被添加到top文件中:

/srv/pillar/top.sls:

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

现在minion们将会自动映射在pillar中基于各自操作系统的值，这样sls文件就能安全地被参数化了：

/srv/salt/apache/init.sls:

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

亦或者，如果没有pillar可用，一个默认的设置同样可以启用：

/srv/salt/apache/init.sls:

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

在上面的例子中，如果pillar值 pillar['pkgs']['apache'] 在minion的pillar未设置，那么默认值``httpd`` 将被使用。

Pillar使简单States扩展更容易¶

pillar的设计原则的之一是让简单的sls公式不需要重构或复杂化states就能轻松地扩展成更加灵活的公式。

一个简单的公式：

/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

可以轻松的被转化成一个强大的，参数化的公式：

/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

vimrc的源地址现在可以在pillar中修改:

/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 %}

确保正确的vimrc被发送到正确的minions上。

通过命令行设置Pillar数据¶

Pillar数据可以像这样通过命令行设置：

salt '*' state.highstate pillar='{"foo": "bar"}'

state.sls 命令同样可以用命令行的方式来设置pillar值：

salt '*' state.sls my_sls_file pillar='{"hello": "world"}'

Nested pillar values can also be set via the command line:

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

The example below will swap the value for vim with telnet in the previously specified list, notice the nested pillar dict:

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

更多关于Pillar¶

Pillar数据由Salt master生成，安全地分发给minions。Salt在设置pillar时可以检索来自外部资源的数据而并不是局限于pillar sls文件。当一个基础设施的相关信息存放在一个单独的位置时会很有帮助。

pillar和外部pillar接口的参考信息可以在Salt文档中找到:

Pillar

Minion Config in Pillar¶

Minion configuration options can be set on pillars. Any option that you want to modify, should be in the first level of the pillars, in the same way you set the options in the config file. For example, to configure the MySQL root password to be used by MySQL Salt execution module:

mysql.pass: hardtoguesspassword

This is very convenient when you need some dynamic configuration change that you want to be applied on the fly. For example, there is a chicken and the egg problem if you do this:

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

mydb:
  mysql_db.present

The second state will fail, because you changed the root password and the minion didn't notice it. Setting mysql.pass in the pillar, will help to sort out the issue. But always change the root admin password in the first place.

This is very helpful for any module that needs credentials to apply state changes: mysql, keystone, etc.