In this recipe, we will learn how to synchronize minions with the master and apply the states to minions that are configured on the master.
We will perform both the push and the pull mechanisms for applying states to minions.
Check if the minion has got automatically signed by the master:
[root@salt-master ~]# salt-key -l accepted Accepted Keys: salt-minion
If all the previous recipes were followed correctly, then the preceding output will be found and here
salt-minionis the minion name whose key has been accepted.The communication between the master and the minion can be checked with a couple of Salt commands:
[root@salt-master ~]# salt 'salt-minion' test.ping salt-minion: True [root@salt-master ~]# salt 'salt-minion' grains.items salt-minion: biosreleasedate: 07/31/2013 biosversion: 6.00 . . zmqversion: 3.2.2
The
userstate that we configured can now be applied to the minion.
States can be applied from master to minion as follows:
[root@salt-master ~]# salt 'salt-minion' state.sls user \ saltenv=development salt-minion: ---------- ID: generic_user Function: user.present Name: thomas Result: True Comment: New user thomas created Changes: ---------- fullname: gid: 1001 groups: - thomas home: /home/thomas homephone: name: thomas passwd: x password: $1$PG1inys0$kB2I83KzEVzVs9G7xLHjA1 roomnumber: shell: /bin/bash uid: 1001 workphone: Summary ------------ Succeeded: 1 Failed: 0 ------------ Total: 1
There is a second option of applying the state from master to minion, as follows:
[root@salt-master ~]# salt 'salt-minion' state.highstate \ saltenv=development
If fewer lines of output are needed, then the following command can be used:
[root@salt-master]# salt 'salt-minion' state.highstate \ saltenv=development --state-output=terse salt-minion: Name: thomas - Function: user.present - Result: Changed Summary ------------ Succeeded: 1 Failed: 0 ------------ Total: 1
States can be fetched by minion from master, as follows:
root@salt-minion:~# salt-call state.highstate [INFO ] Loading fresh modules for state activity [INFO ] Fetching file from saltenv 'development', ** skipped ** latest already in cache 'salt://top.sls' [INFO ] Creating module dir '/var/cache/salt/minion/extmods/modules' [INFO ] Syncing modules for environment 'development' [INFO ] Loading cache from salt://_modules, for development) [INFO ] Caching directory '_modules/' for environment 'development' [INFO ] Creating module dir '/var/cache/salt/minion/extmods/states' [INFO ] Syncing states for environment 'development' [INFO ] Loading cache from salt://_states, for development) [INFO ] Caching directory '_states/' for environment 'development' [INFO ] Creating module dir '/var/cache/salt/minion/extmods/grains' [INFO ] Syncing grains for environment 'development' [INFO ] Loading cache from salt://_grains, for development) [INFO ] Caching directory '_grains/' for environment 'development' [INFO ] Creating module dir '/var/cache/salt/minion/extmods/renderers' [INFO ] Syncing renderers for environment 'development' [INFO ] Loading cache from salt://_renderers, for development) [INFO ] Caching directory '_renderers/' for environment 'development' [INFO ] Creating module dir '/var/cache/salt/minion/extmods/returners' [INFO ] Syncing returners for environment 'development' [INFO ] Loading cache from salt://_returners, for development) [INFO ] Caching directory '_returners/' for environment 'development' [INFO ] Creating module dir '/var/cache/salt/minion/extmods/outputters' [INFO ] Syncing outputters for environment 'development' [INFO ] Loading cache from salt://_outputters, for development) [INFO ] Caching directory '_outputters/' for environment 'development' [INFO ] Loading fresh modules for state activity [INFO ] Fetching file from saltenv 'development', ** skipped ** latest already in cache 'salt://user/init.sls' [INFO ] Running state [thomas] at time 19:04:47.080222 [INFO ] Executing state user.present for thomas [INFO ] Executing command 'useradd -s /bin/bash -u 1001 -m -d /home/thomas thomas' in directory '/root' [INFO ] {'shell': '/bin/bash', 'workphone': '', 'uid': 1001, 'passwd': 'x', 'roomnumber': '', 'groups': ['thomas'], 'home': '/home/thomas', 'password': '$1$PG1inys0$kB2I83KzEVzVs9G7xLHjA1', 'name': 'thomas', 'gid': 1001, 'fullname': '', 'homephone': ''} [INFO ] Completed state [thomas] at time 19:04:47.209616 local: ---------- ID: generic_user Function: user.present Name: thomas Result: True Comment: New user thomas created Changes: ---------- fullname: gid: 1001 groups: - thomas home: /home/thomas homephone: name: thomas passwd: x password: $1$PG1inys0$kB2I83KzEVzVs9G7xLHjA1 roomnumber: shell: /bin/bash uid: 1001 workphone: Summary ------------ Succeeded: 1 Failed: 0 ------------ Total: 1
The same task can also be done by using the following command:
root@salt-minion:~# salt-call state.sls user saltenv=development
In this recipe, we have seen how to apply Salt states to minions. Let's now look at the steps in details.
First, we tested if the certificate request for the minion had been accepted and signed by the master because we had configured it to accept all minions by defining the wildcard in the /etc/salt/autosign.conf file.
Next, we tested communication between the master and the minion with the salt binary and using what we call built-in execution modules in Salt. The test.ping module checks if the minion is available and is responding to the master and grains.items returns all the built-in and custom grains on the minion. Here, test.ping and grains.items are the execution modules and are just a couple of the numerous modules available in Salt.
Next, we look at how to actually apply the configured states to minions.
First, we see the push mechanism from the master to the minion:
[root@salt-master ~]# salt 'salt-minion' state.sls user \ saltenv=development
Here, we see the salt binary being used along with the name (minion id) of the minion, followed by another execution module state.sls, and then the name of the state that we had configured. Finally, the name of the environment is specified without which Salt will look for the base environment and fail. Any configured state can be used in this format to apply to minions, and this method is independent of the top.sls file that we configured in the base directory of the development environment.
Next, we see an alternate method to apply states to minions:
[root@salt-master ~]# salt 'salt-minion' state.highstate \ saltenv=development
Here we see the same command, without the state name and a new execution module called state.highstate. When state.highstate is mentioned, it applies all the states that have been configured for the minion in the top.sls file of that environment. Only the user state gets applied to the minion because that is the only state we have configured in top.sls so far.
The third command produces a slightly different output:
[root@salt-master]# salt 'salt-minion' state.highstate \ saltenv=development --state-output=terse
This command has a new option and its value is --state-output=terse. This option is specified if we do not want a detailed output as the first and second commands. However, it does the same task as the first and second commands
Next, we look at the method of doing the same task by fetching the states on the minion from the master by using the pull mechanism:
root@salt-minion:~# salt-call state.highstate
Here, we used the salt-call binary, which is available only on Salt minions along with the state.highstate execution module. This command will automatically take the environment from the minion configuration file, that is, /etc/salt/minion and look for the minion states in the development environment and apply all the states configured for this minion in the top.sls file. Note the output, we see the minion caching all required data in the system from the master before applying the states. This caching process will take place each time the data in the master changes and the salt-call command is run.
The other method (not used very often) to apply specific states to the minion and from the minion is shown next. These states can also be part of highstate, if added to the top file:
root@salt-minion:~# salt-call state.sls user saltenv=development
Here, we see the minion using the salt-call binary, but mentioning the state.sls execution module to specify a particular state instead of all the states, that is, the user state. However, do note that, for this to be successful, the Salt environment must be mentioned as shown, without which it will look for the base environment and fail.
Now let's see, how to apply Salt states on masterless minions.
In the Installing and configuring the Salt minion recipe, you learned how to configure a Salt minion to be its own master. Here, we will see how to apply states to a Salt minion that acts as its own master.
The following command applies the states of a minion by fetching the state configurations from itself:
root@salt-minion:~# salt-call --local state.highstate
Here, we see that the same salt-call command that was used in fetching the Salt states from a separate Salt master is used to do this task, but the --local option has been added to let Salt know that it needs to look for the state files in itself rather than in a separate Salt master.
The Installing and configuring the Salt master and Installing and configuring Salt minion recipes, to learn how to configure the master and minions
The Targeting minions recipe in Chapter 2, Writing Advanced Salt Configurations, to learn about how to target minions from the master