Role-based infrastructure

In this chapter, we'll discuss how to setup SaltStack to manage infrastructure using 'roles', instead of matching solely on the id of the minion. This is an intermediate topic, so if you are not familiar with the following concepts inside of Salt, we urge you to check them out in this guide:

  • Grains
  • Matchers
  • Master/Minion setup

The overview

To manage our infrastructure using grains, we'll attach a particular grain as a role inside the architecture. We'll then tell the Master to match defined roles based upon these grains. Finally, we'll separate out these grains such that we can set multiple roles per-host.

Grains

Grains in SaltStack are the interface to derive information about the underlying system. Every machine has a set of immutable grains that won't change. These are loaded when the salt minion starts up so these cannot be modified on the fly. Grains include information like the OS model and version, the number of CPUs a particular machine has, how much memory is available to a machine and more.

SaltStack provides a method for modifying these grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file.

To add grains to the minion config, simply include the grains key, for example:

id: minion-01
grains:
  roles:
    - database
  region: us-east-1

To set custom grains within the /etc/salt/grains file, simply set the grains without prefacing them with grains:, like so:

roles:
  - database
region: us-east-1

This is how we will setup our role-based execution environment. Setting the roles grain and then matching states and pillar information based off of these.

SaltStack also enables you to set roles at the command-line as well. To set roles on the command-line, use the command-line from the master:

salt 'minionId' grains.setval roles [roleA, roleB]

Note, this can also be run on the salt minion with a slightly modified comamnd:

salt-call grains.setval roles [roleA, roleB]

Applying roles

In order to apply our roles to different states, we'll have to target the minions based upon the contents of the roles in their grains. We'll use SaltStack's powerful targeting system to target minions.

Although we'll talk more about the targeting system in-depth in another chapter, we'll run through a basic introduction to the targeting system.

SaltStack provides a mechanism to select minions based upon simple or complex rules. The targeting system gives you the ability to specify which minion or groups of minions should run a command, apply states, have access to certain pillars, etc.

There are multiple ways to target a minion, but the default method is by machine along the minion_id. This is the id of the minion that the minion is configured with in the /etc/salt/minion configuration file.

salt web1 nginx.restart

We can also match minions based on their grains. This is called compound matching. Let's say we want to run a command only on all of our ubuntu instances. We can do this with the following command:

salt -C 'G@os:Ubuntu' test.ping

Or what if we only want to run a command on all of our webservers:

salt -C 'G@roles:web' test.ping

We can use this functionality when we run a highstate across the cluster. We can use the targeting sytnax in the top.sls file. for instance:

base:
  'roles:saltmaster':
    - match: grain
    - salt.master
  'roles:mysql':
    - match: grain
    - database

As you can can see, targeting turns out to be very easy to do from within SaltStack.

This same syntax can be used with the pillar top.sls file.

When salt runs highstate, it will apply the appropriate sls files to the right nodes simply based upon their roles.

Note, that we are using arrays as our roles list. SaltStack will still match multiple roles using this same syntax, so it's possible to start a machine with multiple roles.

Your email is required. Your email is required to be at least 3 characters That is not a valid email. Please input a valid email.

Comments

comments powered by Disqus