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
Credits
Foreword
About the Author
About the Reviewer
www.PacktPub.com
Preface
Index

Using SDB modules


There are a number of places where SDB modules can be used. Because SDB retrieval is built into the config.get function in the config execution module, the following locations can be used to set a value for a Minion:

  • Minion configuration file

  • Grains

  • Pillars

  • Master configuration file

SDB is also supported by Salt Cloud, so you can also set SDB URIs in:

  • The main cloud configuration file

  • Cloud profiles

  • Cloud providers

  • Cloud maps

Regardless of where you set an SDB URI, the format is the same:

<setting name>: sdb://<profile name>/<key>

This can be particularly useful with cloud providers, all of which require credentials, but many of which also use more complex configuration blocks that should be checked into revision control.

Take, for example, the openstack Cloud provider:

my-openstack-config:
  identity_url: https://keystone.example.com:35357/v2.0/
  compute_region: intermountain
  compute_name: Compute
  tenant: sdb://openstack_creds/tenant
  user: sdb://openstack_creds...