Book Image

Extending SaltStack

Book Image

Extending SaltStack

Overview of this book

Salt already ships with a very powerful set of tools, but that doesn't mean that they all suit your needs perfectly. By adding your own modules and enhancing existing ones, you can bring the functionality that you need to increase your productivity. Extending SaltStack follows a tutorial-based approach to explain different types of modules, from fundamentals to complete and full-functioning modules. Starting with the Loader system that drives Salt, this book will guide you through the most common types of modules. First you will learn how to write execution modules. Then you will extend the configuration using the grain, pillar, and SDB modules. Next up will be state modules and then the renderers that can be used with them. This will be followed with returner and output modules, which increase your options to manage return data. After that, there will be modules for external file servers, clouds, beacons, and finally external authentication and wheel modules to manage the master. With this guide in hand, you will be prepared to create, troubleshoot, and manage the most common types of Salt modules and take your infrastructure to new heights!
Table of Contents (21 chapters)
Extending SaltStack
About the Author
About the Reviewer

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.