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

Using the event bus

The event bus does not appear in the topology drawings because it is available anywhere inside of Salt, just by importing the salt.event library. It also has the ability to call out to other module types, using the reactor system. Reactors have access to execution, state, and runner modules.


You may be wondering why we didn't cover reactor modules in this book. In truth, there is no such thing as a reactor module. Reactors are written using standard SLS files, which can include extra functionality using the renderer system. For more thorough discussions on writing and using reactors, be sure to check out Mastering SaltStack, Joseph Hall, Packt Publishing.

Because the event bus is so ubiquitous, it can be a very powerful tool for tying together the other module types into a cohesive workflow.

For example, let's take a look at Salt Cloud. It can be operated independently from the rest of Salt, but when using a Master + Minions setup, it will fire events to the Master during the creation and deletion process that can be picked up by reactors.

Salt Cloud events use tags that are namespaced in a way that can be easily determined by reactors:


Available events vary depending on the cloud provider, and the work that provider has been configured to do, but a properly written cloud driver will always fire at least these two events when creating a node:


It will also fire these two events when deleting a node:


Operations that perform maintenance on Minions and their resources can be kicked off using these events. For instance, if you want to sync a Minion's resources as soon as it's created, you can use a reactor that looks like:

    - tgt: data['id']

Because a Minion will be available by the time Salt Cloud sends the salt/cloud/<minion_id>/created tag, you can set a reactor to ensure that the Minion is synced as soon as it comes online, without having to configure any startup_states.