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

Loading modules with Python

Python is well suited to building a loader system. Despite being classified as a very high-level language (and not a mid-level language like C), Python has a lot of control over how it manages its own internals. The existence of robust module introspection built into Python was very useful for Salt, as it made the arbitrary loading of virtual modules at runtime a very smooth operation.

Each Salt module can support a function called __virtual__(). This is the function that detects whether or not a module will be made available to Salt on that system.

When the salt-minion service loads, it will go through each module, looking for a __virtual__() function. If none is found, then the module is assumed to have all of its requirements already met, and it can be made available. If that function is found, then it will be used to detect whether the requirements for that module are met.

If a module type uses the lazy loader, then modules that can be loaded will be set aside to be loaded when needed. Modules that do not meet the requirements will be discarded.

Detecting grains

On a Minion, the most important things to load are probably the grains. Although grain modules are important (and are discussed in Chapter 3, Extending Salt Configuration), there are in fact a number of core grains that are loaded by Salt itself.

A number of these grains describe the hardware on the system. Others describe the operating system that Salt is running on. Grains such as os and os _family are set, and used later to determine which of the core modules will be loaded.

For example, if the os_family grain is set to redhat, then the execution module located at salt/modules/ will be loaded as the pkg module. If the os_family grain is set to debian, then salt/modules/ will be loaded as the pkg module.

Using other detection methods

Grains aren't the only mechanism used for determining whether a module should be loaded. Salt also ships with a number of utilities that can be used. The salt.utils library contains a number of functions that are often faster than grains, or have more functionality than a simple name=value (also known as a key-value pair) configuration can provide.

One example is the salt.utils.is_windows() function that, as the name implies, reports whether Salt is being run inside of Windows. If Windows is detected, then salt/modules/ will be loaded as the file module. Otherwise, salt/modules/ will be loaded as the file module.

Another very common example is the salt.utils.which() function, which reports whether a necessary shell command is available. For instance, this is used by salt/modules/ to detect whether the nginx command is available to Salt. If so, then the nginx module will be made available.

There are a number of other examples that we could get into, but there is not nearly enough room in this book for all of them. As it is, the most common ones are best demonstrated by example. Starting with Chapter 2, Writing Execution Modules, we will begin writing Salt modules that make use of the examples that we've already gone over, plus a wealth of others.