盐堆：谷物与柱子答案

【问题标题】：salt stack: grains vs pillars盐堆：谷物与柱子
【发布时间】：2017-11-29 04:52:42
【问题描述】：

Salt system 中有颗粒和柱子。我了解如何分配自定义颗粒，但什么时候考虑使用柱子更好？

【问题讨论】：

此外，支柱可以针对特定的奴才，就像您可以将状态定位到特定的奴才一样。

标签： salt-stack configuration-management

【解决方案1】：

在 Salt 中，grains 用于您的 minion 的不可变方面，例如 cpu、内存、位置、时区等。

Pillar 是您需要分发给您的 Minion 的 master 上的数据列表（SLS 格式）。 Pillar 允许您设置 minions 可以访问的变量，例如数据库配置选项。

【讨论】：

重要的是：Pillar 数据存储在 master 上并缓存在匹配的 minions 上。谷物存储在 minions 上并缓存在 master 上。这有点反直觉但很方便。 Pillar 数据只对匹配的 minions 可用，所有 grains 数据对所有 minions 可用。
@DanGarthwaite 你介意解释一下minion如何请求所有grains数据吗？
@brodie31k 你想说一个 minion 不能从另一个 minion grains 中获取数据？

【解决方案2】：

简而言之，自定义 static Grains 可能比 Pillars 更糟糕。

| Differences                  | Grains                        | Pillars                             |
|------------------------------|-------------------------------|-------------------------------------|
| This is info which...        | ... Minion knows about itself | ... Minion asks Master about        |
|                              |                               |                                     |
| Distributed:                 | Yes (different per minion)    | No (single version per master)      |
| Centralized:                 | No                            | Yes                                 |
|                              |                               |                                     |
| Computed automatically:      | Yes (preset/computed value)   | No (only rendered from Jinja/YAML)  |
| Assigned manually:           | No (too elaborate)            | Yes (Jinja/YAML sources)            |
|                              |                               |                                     |
| Conceptually intrinsic to... | ... individual Minion node    | ... entire system managed by Master |
| Data under revision control: | No (computed values)          | Yes (Jinja/YAML sources)            |
|                              |                               |                                     |
| They define rather...        | _provided_ resources          | _required_ resources                |
|                              | (e.g. minion OS version)      | (e.g. packages to install)          |
|                              |                               |                                     |

【讨论】：

【解决方案3】：

这里的根本区别在于，您可以将自定义颗粒设置为小兵的固有属性，而柱子需要在某个时候分配给小兵。

例如，有两种实用的方法可以为 minion 分配角色：minion id 或使用自定义 grain。然后，您可以匹配 top.sls 文件中的 minion id 或自定义颗粒，如下所示：

# salt/top.sls
base:
  # match against custom grain
  'G@role:webserver':
    - match: compound
    - webserver
  'G@role:search':
    - match: compound
    - elasticsearch
  # match against minion id
  'minion_db*':
    - database

你不能用柱子做到这一点。虽然您确实可以使用柱子作为目标，但您首先需要一种将柱子分配给您的奴才的方法（这必须是奴才 id，或如上所述的颗粒）。考虑一下如何在柱子顶部文件中分配柱子，您需要使用 minion 的固有属性分配此柱子数据。

# pillar/top.sls
base:
  'G@env:dev':
    - match: compound
    - dev_settings
  'G@env:prod':
    - match: compound
    - prod_settings

这里的模式是你使用grains（或minion id）作为设置你的minion的类型/角色/环境的最小方法。之后，您使用支柱数据为其提供所有适当的详细设置。

【讨论】：

对上述答案稍作修正。 match: pillar 现在可以按照这个salt doc
请注意，出于安全原因，您不应使用grains来定位敏感的支柱文件（例如包含数据库密码的文件）。 Grains 设置在 Minion 一侧，扎根于 Minion 的人可以更改其 Grain，以便接收其他 Minion 的 Pillar 数据。
既然柱子是主端设置的，那么如果你想根据某种角色分发敏感数据，你不希望这些角色被定义为柱子吗？
肯定存在安全问题，因为这个模型平等地信任所有的奴才。尽管如此，你不能使用柱子来区分你的不同奴才。它必须基于其他东西。即使有match: pillar，那么这些支柱是如何分配给奴才的？它们必须通过 minion name、hostname 或 grains 分配。
我认为按小兵名称/ID 定位是唯一的“安全”路径。主机名和粒度（也可能是 IP 地址，取决于网络安全）可以在受感染的 Minion 上进行操作，但是当主服务器接受密钥时，Minion ID 会被锁定，因此破坏单个 Minion 只会泄露其已知的敏感信息奴才。

【解决方案4】：

Pillar 还有助于确保只有特定的奴才获得特定的信息。

这里有一些很棒的文档：

http://docs.saltstack.com/topics/pillar/index.html

这里：

http://docs.saltstack.com/topics/tutorials/pillar.html

您还可以使用外部支柱来允许任意数据库或配置文件为您设置支柱数据。这允许与基础架构的其他方面进行非常强大的集成。这里列出了几个内置的外部支柱：

http://docs.saltstack.com/ref/pillar/all/index.html

构建自定义外部支柱非常简单：

http://docs.saltstack.com/topics/development/external_pillars.html

【讨论】：

并没有真正回答这个问题。 Jeff Bauer - 考虑将接受的答案改为 akoumjian 的答案。