SaltStack Master 节点关于Pillar配置选项的使用说明

最新推荐文章于 2022-12-27 17:20:39 发布

运维个西瓜

最新推荐文章于 2022-12-27 17:20:39 发布

阅读量1.2k

点赞数

分类专栏： SaltStack

SaltStack 专栏收录该内容

110 篇文章 5 订阅

订阅专栏

pillar是Saltstack最重要的组件之一，其作用是在Master本地定义与被控主机相关的任何数据，定义好的数据可以用于在其他组件中使用，如模板、state、API等。

pillar安全性很高，适用于一些比较敏感的数据，这也是区别于grains最关键的一点，如定义不同业务组主机的用户id、组id、读写权限、程序包等信息，定义的规范是采用Python字典形式，即键/值，最上层的键一般为主机的id或组的名称。

以下为在Master配置文件中，与pillar相关的配置选项的使用说明。相同内容也可以选择参考官网英文原文，或者github翻译类项目中的中文译文。

PILLAR CONFIGURATION

PILLAR_ROOTS

Default:

base:
  - /srv/pillar

设置用于保存pillar sls数据的环境和目录。此配置与file_roots使用方法相同：

pillar_roots:
  base:
    - /srv/pillar
  dev:
    - /srv/pillar/dev
  prod:
    - /srv/pillar/prod

ON_DEMAND_EXT_PILLAR

New in version 2016.3.6,2016.11.3,2017.7.0.

Default: [‘libvirt’, ‘virtkey’]

允许使用pillar.ext获取外部pillar数据。

on_demand_ext_pillar:
  - libvirt
  - virtkey
  - git

Warning:
这将允许minions通过pillar.ext请求特定的pillar数据，这可能被视为一种安全风险。但是，以这种方式生成的pillar数据不会影响内存中的pillar数据，因此这种风险仅限于states/modules等的情况。

DECRYPT_PILLAR

New in version 2017.7.0.

Default: []

在pillar数据编译期间需要进行递归解密的路径列表。

decrypt_pillar:
  - 'foo:bar': gpg
  - 'lorem:ipsum:dolor'

此列表中的条目可以格式化为简单字符串，也可以格式化为键/值对，其中键是pillar位置，值是用于pillar解密的渲染器。如果使用前者，则将使用decrypt_pillar_default选项所指定的渲染器。

DECRYPT_PILLAR_DELIMITER

New in version 2017.7.0.

Default: :

分隔符,用于区分decrypt_pillar选项中的嵌套数据结构。

decrypt_pillar_delimiter: '|'
decrypt_pillar:
  - 'foo|bar': gpg
  - 'lorem|ipsum|dolor'

DECRYPT_PILLAR_DEFAULT

New in version 2017.7.0.

Default: gpg

如果没有为decrypt_pillar中的给定pillar key指定一个，则使用默认渲染器用于解密。

decrypt_pillar_default: my_custom_renderer

DECRYPT_PILLAR_RENDERERS

New in version 2017.7.0.

Default: [‘gpg’]

允许用于支柱解密的渲染器列表。

decrypt_pillar_renderers:
  - gpg
  - my_custom_renderer

PILLAR_OPTS

Default: False

pillar_opts选项会将master的配置文件数据添加到名为master的pillar dict中。这可以用于在master配置文件中设置简单配置，然后可以在所有minions上使用。

请注意，将此选项设置为True后意味着master配置文件将会被包含在所有minion的pillar中。虽然这使得服务和系统的全局配置变得容易，但是如果敏感数据存储在master配置中，则可能不希望这样。

pillar_opts: False

PILLAR_SAFE_RENDER_ERROR

Default: True

pillar_safe_render_error选项可防止master将pillar渲染过程中的错误传递给minion。这是默认设置为True的，因为错误k中可能包含模板数据，这将会给minion提供它不应该具有的信息，如密码！设置为True时，错误消息仅显示：
`Rendering SLS ‘my.sls’ failed. Please see master log for details.``

pillar_safe_render_error: True

EXT_PILLAR

ext_pillar选项允许在填充pillar数据时调用任意数量的外部pillar接口。该配置是基于ext_pillar函数工作的。可以在此处找到有哪些可用的ext_pillar函数：

https://github.com/saltstack/salt/blob/develop/salt/pillar

默认地, ext_pillar interface is not configured to run.

Default: []

ext_pillar:
  - hiera: /etc/hiera.yaml
  - cmd_yaml: cat /etc/salt/yaml
  - reclass:
      inventory_base_uri: /etc/reclass

EXT_PILLAR_FIRST

New in version 2015.5.0.

Default: False

此选项允许在pillar_roots之前先评估外部pillar源。外部pillar数据与pillar_roots下的数据分开评估，然后两组pillar数据合并为一个pillar字典，因此该配置选项的值将影响哪个关键字会“获胜”，当在外部pillar数据和pillar_roots下数据中都存在相同的名称。通过将此选项设置为True，ext_pillar键将覆盖pillar_roots，而将其保留为False则效果相反。

ext_pillar_first: False

PILLARENV_FROM_SALTENV

Default: False

设置为True时，pillarenv值将在运行状态时继承自saltenv的值。这基本上使salt-run pillar.show_pillar saltenv=dev相当于salt-run pillar.show_pillar saltenv=dev pillarenv=dev。不过如果在CLI上设置了pillarenv，它将覆盖此选项。

pillarenv_from_saltenv: True

注意对于使用salt远程执行命令时，则应该在Minion配置中设置此选项。

PILLAR_RAISE_ON_MISSING

New in version 2015.5.0.

Default: False

将此选项设置为True可以在尝试从pillar中检索一个指定名称的值失败时强制引发KeyError。如果将此选项设置为False，则失败的尝试将返回空字符串。

GIT EXTERNAL PILLAR (GIT_PILLAR) CONFIGURATION OPTIONS

GIT_PILLAR_PROVIDER

New in version 2015.8.0.

Default: master

指定要用于git_pillar的提供程序。必须是pygit2或gitpython。如果未设置，则将以相同的顺序尝试两者，并且安装了兼容版本的第一个将是使用的提供程序。

git_pillar_provider: gitpython

GIT_PILLAR_BASE

New in version 2015.8.0.

Default: master

如果所需的分支与此值匹配，并且git_pillar配置中省略了环境，则该git_pillar远程的环境将是base。例如，在下面的配置中，foo分支/标记将分配给base环境，而bar将映射到bar环境。

git_pillar_base: foo

ext_pillar:
  - git:
    - foo https://mygitserver/git-pillar.git
    - bar https://mygitserver/git-pillar.git

GIT_PILLAR_BRANCH

New in version 2015.8.0.

Default: master

如果从git_pillar remote中省略了分支，则将使用这里指定的分支。例如，在下面的配置中，前两个remotes将使用pillardata分支/标签，而第三个将使用foo分支/标签。

git_pillar_branch: pillardata

ext_pillar:
  - git:
    - https://mygitserver/pillar1.git
    - https://mygitserver/pillar2.git:
      - root: pillar
    - foo https://mygitserver/pillar3.git

GIT_PILLAR_ENV

New in version 2015.8.0.

Default: ‘’ (unset)

用于git_pillar remote的环境。这通常来自分支/标记（或来自每个remote的env参数），但如果设置了该选项，这将覆盖从分支/标记名称派生env的过程。例如，在下面的配置中，foo分支将被分配给base环境，而bar分支需要明确地将bar配置为其环境，以防止它也被映射到base环境。

git_pillar_env: base

ext_pillar:
  - git:
    - foo https://mygitserver/git-pillar.git
    - bar https://mygitserver/git-pillar.git:
      - env: bar

出于这个原因，建议不要设置此选项，除非用例要求所有（或几乎所有）git_pillar remotes控制器使用相同的环境，而不管使用的分支/标记。

GIT_PILLAR_ROOT

New in version 2015.8.0.

Default: ‘’

相对于git_pillar top文件和SLS文件所在的存储库根目录的路径。在下面的配置中，将在名为pillar的子目录中查找pillar top文件和SLS文件。

git_pillar_root: pillar

ext_pillar:
  - git:
    - master https://mygitserver/pillar1.git
    - master https://mygitserver/pillar2.git

这是一个全局选项。如果只有一个或两个repos需要从子目录中获取文件，那么可以省略git_pillar_root，并且可以在每个remote的基础上指定root，如下所示：

ext_pillar:
  - git:
    - master https://mygitserver/pillar1.git
    - master https://mygitserver/pillar2.git:
      - root: pillar

在此示例中，对于第一个remote文件，将在存储库的根目录中查找top文件和SLS文件，而在第二个remote文件中，将从pillar子目录中检索pillar数据。

GIT_PILLAR_SSL_VERIFY

New in version 2015.8.0.

Changed in version 2016.11.0.

Default: False

指定在联系远程存储库时是否忽略SSL证书错误。如果您使用的是使用自签名证书的git仓库，则False设置非常有用。但是，请记住，将此设置为True以外的其他任何值是一种被认为不安全的操作，与之相比使用基于SSH的传输（如果可用）可能是更好的选择。

在2016.11.0版本中，默认配置值从False更改为True。

pygit2仅支持在版本0.23.2及更高版本中禁用SSL验证。

GIT_PILLAR_GLOBAL_LOCK

New in version 2015.8.9.

Default: True

设置为False时，如果git_pillar远程数据库存在update/checkout锁定且写入的pid未在master服务器上运行，则锁定文件将自动清除并获取新锁定。设置为True时，Salt会在存在锁定时记录警告。

在单master部署中，禁用此选项可以帮助自动处理在git_pillarupdate/checkout期间关闭/重新启动master服务器的实例，并保留锁定。

但是，在通过GlusterFS，nfs或其他网络文件系统共享git_pillar cachedir的多master部署中，强烈建议不要禁用此选项，因为这样做会导致锁定文件是由其他master创建时被删除。

# Disable global lock
git_pillar_global_lock: False

GIT_PILLAR_INCLUDES

New in version 2017.7.0.

Default: True

通常，在处理git_pillar remotes数据库时，如果ext_pillar配置中同一git部分下的多个repo引用相同的pillar环境，则给定环境中的每个repo都可以访问其top file引用的其他repos文件。文件。但是可能需要禁用此行为。如果是这样，请将此值设置为False。

有关如何包含工作的更详细的检查，请参阅git_pillar文档中的此解释。

git_pillar_includes: False

GIT EXTERNAL PILLAR AUTHENTICATION OPTIONS

这些参数目前仅适用于pygit2 git_pillar_provider。如GitFS Walkthrough中所述，身份验证与gitfs中的身份验证相同，但全局配置选项的命名方式不同，以反映它们用于git_pillar而不是gitfs。

GIT_PILLAR_USER

New in version 2015.8.0.

Default: ‘’

与git_pillar_password一起，用于对HTTPS remotes进行身份验证。

git_pillar_user: git

GIT_PILLAR_PASSWORD

New in version 2015.8.0.

Default: ‘’

与git_pillar_user一起，用于对HTTPS remotes进行身份验证。如果存储库不使用身份验证，则不需要此参数。

git_pillar_password: mypassword

GIT_PILLAR_INSECURE_AUTH

New in version 2015.8.0.

Default: False

默认情况下，Salt不会对HTTP（非HTTPS）远程进行身份验证。此参数启用HTTP身份验证的支持。启用此功能需要你自担风险。

git_pillar_insecure_auth: True

GIT_PILLAR_PUBKEY

New in version 2015.8.0.

Default: ‘’

与git_pillar_privkey（以及可选的git_pillar_passphrase）一起，用于对SSH remotes进行身份验证。

git_pillar_pubkey: /path/to/key.pub

GIT_PILLAR_PRIVKEY

New in version 2015.8.0.

Default: ‘’

与git_pillar_pubkey（以及可选的git_pillar_passphrase）一起，用于对SSH remotes进行身份验证。

git_pillar_privkey: /path/to/key

GIT_PILLAR_PASSPHRASE

New in version 2015.8.0.

Default: ‘’

此参数是可选的，仅在用于身份验证的SSH密钥受密码保护时才需要。

git_pillar_passphrase: mypassphrase

GIT_PILLAR_REFSPECS

New in version 2017.7.0.

Default: [’+refs/heads/:refs/remotes/origin/’, ‘+refs/tags/:refs/tags/’]

从远程存储库获取时，默认情况下Salt将获取分支和标记。此参数可用于覆盖默认值并指定要提取的替代refspec。此参数与其GitFS对应项的工作方式类似，既可以全局配置，也可以为单个remote进行配置。

git_pillar_refspecs:
  - '+refs/heads/*:refs/remotes/origin/*'
  - '+refs/tags/*:refs/tags/*'
  - '+refs/pull/*/head:refs/remotes/origin/pr/*'
  - '+refs/pull/*/merge:refs/remotes/origin/merge/*'

GIT_PILLAR_VERIFY_CONFIG

New in version 2017.7.0.

Default: True

默认情况下，当master服务器启动时，它会对配置的git_pillar存储库执行一些健康性检查。如果任何这些健康性检查失败（例如使用无效配置时），则master守护程序也将中止。

要跳过这些健康性检查，请将此选项设置为False。

git_pillar_verify_config: False

PILLAR MERGING OPTIONS

PILLAR_SOURCE_MERGING_STRATEGY

New in version 2014.7.0.

Default: smart

pillar_source_merging_strategy选项允许您配置不同源之间的合并策略。它接受5个值：

none: 它根本不会执行任何合并，只解析传递环境中的pillar数据，如果没有指定环境，则解析“base”环境。New in version 2016.3.4.
recurse: 它将以递归方式合并数据。例如，下面两个来源：

foo: 42
bar:
    element1: True

bar:
    element2: True
baz: quux

将会被合并为:

foo: 42
bar:
    element1: True
    element2: True
baz: quux

aggregate:
指示使用＃!yamlex渲染器的源之间进行元素的聚合。
例如，下面两个配置：

#!yamlex
foo: 42
bar: !aggregate {
  element1: True
}
baz: !aggregate quux

#!yamlex
bar: !aggregate {
  element2: True
}
baz: !aggregate quux2

将会被聚合为:

foo: 42
bar:
  element1: True
  element2: True
baz:
  - quux
  - quux2

overwrite:将使用2014.1分支及更早版本的行为。根据元素的处理顺序覆盖元素。
例如，第一个处理的pillar数据：

A:
  first_key: blah
  second_key: blah

第二个处理的pillar数据：

A:
  third_key: blah
  fourth_key: blah

将会被合并为：

A:
  third_key: blah
  fourth_key: blah

smart (default):根据“渲染器”的设置猜测最佳策略。

为了使基于yamlex的功能（如！aggregate）在使用默认智能合并策略的文档中按预期工作，必须将渲染器配置选项设置为jinja | yamlex或类似。

PILLAR_MERGE_LISTS

New in version 2015.8.0.

Default: False

递归合并列表,通过聚合方式而不是替换它们。

pillar_merge_lists: False

PILLAR_INCLUDES_OVERRIDE_SLS

New in version 2017.7.6,2018.3.1.

Default: False

在2017.7.3版之前，来自pillar includes的键将合并在顶部的pillar SLS。自2017.7.3起，includes的先被合并在一起，然后pillar SLS合并在其上。

将此选项设置为True可返回旧版本时的行为。

pillar_includes_override_sls: True

PILLAR CACHE OPTIONS

PILLAR_CACHE

New in version 2015.8.8.

Default: False

Master服务器可以在本地缓存pillars，以避免在每个请求上为每个minion呈现它们时花费渲染处理成本。只有在已知pillar渲染时间不令人满意的情况下才能启用此功能，并且已解决了有关在master缓存中存储pillars的任何附带安全问题。

启用此功能时，请务必通读其他pillar_cache_*配置选项，以完全了解可调参数及其含义。

pillar_cache: False

设置为pillar_cache: True时并不会对使用targeting minions with pillar有影响。

PILLAR_CACHE_TTL

New in version 2015.8.8.

Default: 3600

当且仅当master服务器设置了pillar_cache：True时，缓存TTL选项会控制master服务器将缓存视为无效（时间量，以秒为单位），并重新编译和存储新的pillars。

PILLAR_CACHE_BACKEND

New in version 2015.8.8.

Default: disk

当且仅当master设备设置了pillar_cache：True选项时，可以选用以下几种存储选项之一：

disk (default):
默认存储后端。这会将渲染的pillars数据缓存到master缓存。渲染的pillars被序列化并反序列化为msgpack结构以提高处理速度。请注意，pillar存储为UNENCRYPTED方式。请确保master缓存具有适当的权限设置（提供了合理的默认值）。
memory [EXPERIMENTAL]:
pillar缓存的一个可选后端，它使用纯Python内存数据结构以获得最佳性能。然而，有几点需要注意。首先，因为每个master工作进程都包含自己的内存缓存，所以不保证minion请求之间的缓存一致性。这种情况在pillar很少发生变化的情况下效果最好。其次，也许更重要的是，这意味着任何可以检查sat-master的进程都可以访问未加密的pillars！这可能代表存在潜在的安全风险。