It is said in saltstack documentation that adding :
{% set node_type = salt['grains.get']('node_type', '') %}
{% if node_type %}
'node_type:{{ self }}':
- match: grain
- {{ self }}
{% endif %}
to
/srv/salt/top.sls
will create a grain called node_type
I added the code below to the top file, and I would like to know why I can't see node_type
in my minion :
myHost ~ # service salt-master restart; service salt-minion restart;
myHost ~ # salt '*' grains.get "node*"
The last command returns nothing. And I think it is normal because I haven't defined node_type
in /etc/salt/grains
This makes me ask a question : what is the difference between :
top.sls
file and
/etc/salt/grains
) or to minion file ( /etc/salt/minion
)Salt comes with an interface to derive information about the underlying system. This is called the grains interface, because it presents salt with grains of information. Grains are collected for the operating system, domain name, IP address, kernel, OS type, memory, and many other system properties.
"salt-key -L" will list all minions that whose public keys you've accepted on your master.
In Salt, the file which contains a mapping between groups of machines on a network and the configuration roles that should be applied to them is called a top file . Top files are named top. sls by default and they are so-named because they always exist in the "top" of a directory hierarchy that contains state files.
Salt minions are your servers that actually run your applications and services. Each minion has an ID assigned to it (which can be automatically generated from the minion's hostname), and the Salt master can refer to this ID to target commands to specific minions.
You can't create a grain in the top file. Can you point me to the documentation that's telling you that? All a top file does is define which Salt states (sls files) should be applied to which servers.
You can use grains to match in your top file. You don't declare grains in your top file.
You can create a Salt state that will add a grain to your minion for you and reference that in your top file. Docs here: http://docs.saltstack.com/en/latest/ref/states/all/salt.states.grains.html#salt.states.grains.present
Here's an example
$ cat /srv/salt/top.sls
base:
'server01':
- rolegrain
$ cat /srv/salt/rolegrain.sls
role:
grains.present:
- value: application_server
When running a highstate, this would cause your server with the Salt id of server01
to have a grain with the key role
and value application_server
.
That would look like this:
salt server01 state.highstate
or
salt server01 state.sls rolegrain
Then you'd get this output
salt server01 grains.item role
server01:
----------
role:
application_server
For completeness, here's some docs.
The top file: http://docs.saltstack.com/en/latest/ref/states/top.html
Grains: http://docs.saltstack.com/en/latest/topics/targeting/grains.html
You can create a top file where you do advanced minion targeting. The targeting can be done based on the matched type seen in https://docs.saltstack.com/en/latest/ref/states/top.html#advanced-minion-targeting
What I have in my top.sls file is:
'site:private':
- match: grain
- path.to.state1
- path.to.state2
Assuming that your target minion has a grain with key 'site' and value 'private', you can do:
salt -v 'minion_id' state.highstate test=True
This will pickup all the state assigned in the top.sls file above.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With