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.