Separating Master and Minion functionality

It's easy to think of Salt in terms of the following: the Master sends commands to the Minions, the Minions do the work, and then the Minions send the results back to the Master. However, the Master and the Minion are two distinct components that work together in harmony to complete their respective tasks.

It is important to keep in mind that when the Minion is running in a Masterless mode (using salt-call --local), it behaves as its own Master, and outside of a few specific features (such as salt-key and runners that make use of local_client), any feature that is available on the Master is also available on the Minion, using the same configuration options that would appear in the master file, but in the minion file instead.

But when running with a Master and one or more Minions, they are two distinct entities. Some module types are available to either the Master or the Minion; there are many more that are only available for that specific service.

Let us have a look at a diagrammatic representation of the Salt Master topology:

And now follows the diagrammatic representation of the Salt Minion topology:

Like the Master and the Minion, each module type is specific and distinct. However, like the Master and the Minion, modules connect to each other and work in concert to accomplish larger workflows. Regardless of module type, the Master and the Minion will always communicate directly (using transport modules, which are beyond the scope of this book). Beyond that, different modules are able to communicate with each other to varying degrees.

The Master generally uses its own modules directly. Some of those modules may be used to provide Minions with resources (such as file server modules), but a number of them are used entirely for providing resources to the Master itself. Master returners are functionally identical to returners that execute on the Minion, with the exception of how they get their data.

Minion modules communicate with each other extensively. Execution modules can pull data from grain and SDB modules (and from pillars, through the Master) and cross-call each other. State modules are themselves called from an execution module, but also have access to cross-callback to execution modules. Renderers are used by a number of different module types, and when all is said and done, returners transport return data to the correct destination.

Salt Cloud is the odd man out, because while it can be accessed via either a runner or an execution module, it can also be accessed directly, and even used independently of the rest of Salt. In fact, it can be used to manage nodes without even installing Salt on them.