Using the Pillar Roster¶
You can think of the
Pillar Roster
as a Roster that loads the list of devices / inventory dynamically using the
Pillar subsystem. Or, in simpler words, you can use any of these features from
here: https://docs.saltstack.com/en/latest/ref/pillar/all/index.html to load
the list of your devices, including: JSON / YAML HTTP API, load from MySQL
/ Postgres database, LDAP, Redis, MongoDB, etcd, Consul, and many others;
needless to say that this is another pluggable interface and, in case you have
a more specific requirement, you can easily extend Salt in your environment by
providing another Pillar module under the salt://_pillar
directory. For
example, see this old yet still accurate article:
https://medium.com/@Drew_Stokes/saltstack-extending-the-pillar-494d41ee156d.
The core idea is that you are able to use the data pulled via the Pillar modules once you are able to execute the following command and see the list of devices you’re aiming to manage:
$ salt-run pillar.show_pillar
devices:
- id: device1
...
It really doesn’t matter where is Salt pulling this data from.
By default, the Pillar Roster is going to check the Pillar data for *
(any
Minion), and load it from the devices
key. In other words, when executing
salt-sproxy pillar.show_pillar
the output should have at least the
devices
key. To use different settings, have a look at the documentation:
Pillar Roster.
Say we want to pull the list of devices from an HTTP API module providing the data in JSON format. In this case, we can use the http_json module.
If the data is available at http://example.com/devices, and you can verify,
e.g., using curl
:
$ curl http://example.com/devices
{"devices": [{"id": "router1"}, {"id": "router2"}, {"id": "switch1"}]}
That being available, we can configure the http_json
External Pillar:
/etc/salt/master
:
roster: pillar
ext_pillar:
- http_json:
url: http://example.com/devices
Now, let’s verify that the data is pulled properly into the Pillar:
$ salt-run pillar.show_pillar
devices:
- id: router1
- id: router2
- id: switch1
That being validated, salt-sproxy is now aware of all the devices to be managed:
$ salt-sproxy \* --preview-target
- router1
- router2
- switch1
As well as other target types such as list
or PCRE
:
# target a fixed list of devices:
$ salt-sproxy -L router1,router2 --preview-target
- router1
- router2
# target all devices with the Minion ID starting with "router",
# followed by one or more numbers:
$ salt-sproxy -E 'router\d+' --preview-target
- router1
- router2
The same methodology applies to any of the other External Pillar modules.