In the Salt system there are grains and pillars. I understand how I can assign custom grains, but when would it be better to consider using pillars?
The fundamental difference here is that you can set a custom grain as an innate property of a minion, versus pillar which needs to be assigned to a minion at some point.
For example, there are two practical ways to assign a role to a minion: the minion id or using custom grains. You can then match against the minion id or custom grains inside your top.sls file like so:
# 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
You CANNOT do this with pillar. While you can indeed target with pillar, you first need a way to assign pillar to to your minions (this must be minion id, or grains as stated above). Think about how you would assign pillar in the pillar top file, you need to assign this pillar data using an innate attribute of the minion.
# pillar/top.sls
base:
'G@env:dev':
- match: compound
- dev_settings
'G@env:prod':
- match: compound
- prod_settings
The pattern here is that you use grains (or minion id) as a minimal way to set type/role/environment of your minion. After that, you use pillar data to feed it all the appropriate detailed settings.
In Salt, grains are used for immutable aspects of your minion, such as the cpu, memory, location, time zone, etc.
A pillar is a list of data on the master (in SLS format) that you need to distribute to your minions. Pillar allows you to set variables that the minions can access, for example a database configuration option.
In short, custom static Grains is likely worse alternative than 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) |
| | | |
Pillar is also useful for ensuring that only certain minions get a particular bit of information.
There are some great docs here:
http://docs.saltstack.com/topics/pillar/index.html
and here:
http://docs.saltstack.com/topics/tutorials/pillar.html
You can also use an External Pillar to allow an arbitrary database or config file to set your Pillar data for you. This allows for very powerful integration with other aspects of your infrastructure. There are several built in external pillars listed here:
http://docs.saltstack.com/ref/pillar/all/index.html
And it's pretty straightforward to build a custom external pillar:
http://docs.saltstack.com/topics/development/external_pillars.html
来源:https://stackoverflow.com/questions/13115700/salt-stack-grains-vs-pillars