Master Salt with Our New SaltStack (SSCE) Prep Course

With this month’s content releases of over 150 new hands-on training, we’re expanding our Salt offerings by helping you prepare for the SaltStack Certified Engineer Certification!

Learn the basics of Salt by diving in and getting your hands on the installation process, performing some remote execution, and exploring states. Once you get the hang of Salt’s core systems, we will delve into all the other ways we can use and build upon Salt’s remote execution and state platforms, especially in combination with the event system as we begin to examine the benefits and possibilities of event-driven infrastructure.

Ready for a Taste?

If your interest has been piqued but you’re still not sure if the course is right for you, here’s a peek at something we’ll learn. Don’t worry, there is no Linux Academy cloud server or Salt knowledge required; you can do this little exercise from your own workstation using Vagrant. In this preview, we’re going to add some self-healing features to a Salt infrastructure by making sure any unofficial changes made to a file are reverted automatically.

Before we get started, however, let’s pull down a Vagrant environment. If you’re not familiar with Vagrant, check out this blog post to get started. We’ll be using the VirtualBox provider, and guest tools should be downloaded.

Once you’re ready, clone Salt’s demo environment (provided by SaltStack employee, David Boucha) from here:

$ git clone https://github.com/UtahDave/salt-vagrant-demo.git

Then move into the new directory and start up the Vagrant environment:

$ cd salt-vagrant-demo
$ vagrant up

We now have three Ubuntu 16.04 servers waiting for us: A Salt Master (“master”), and two guests (“minion1” and “minion2”).

We can now log in to the master server:

$ vagrant ssh master

From here, we’re going to complete three tasks: First, we’re going to create an end-state configuration that will add a default nanorc file; then we’re going to add a beacon that will monitor this nanorc file on the minions for any changes; finally, we’ll set up a reactor that will remove those changes when they are not caused by Salt itself.

Create a Salt State

Salt states are end-state descriptions. In other words, we need to spell out what we want our minion to look like once we’re done with it. Here, we want our minions to use a certain nanorc file. Let’s pull this file down first:

$ curl -o /srv/salt/nanorc https://raw.githubusercontent.com/linuxacademy/content-ssce-files/master/nanorc

Next, we’re going to create a state in /srv/salt/ that will take this file and upload it to both our minions. To do this we use a function called file.managed.

$ $EDITOR nano.sls

set_nanorc:
  file.managed:
    - name: /etc/nanorc
    - source: salt://nanorc

Let’s go ahead and break this down line-by-line:

• set_nanorc is the name declaration. Basically, it’s the human-friendly name we gave our state
• file.managed is a function that copies files from our nanorc to our minions
• name is the location of the minion where we want the file to end up
• source is the location on the Salt master of our file; salt:// references the /srv/salt directory

Save and exit the file. We can now apply this to our minions:

$ sudo salt '*' state.sls nano

Monitor File Changes with a Beacon

We now want to create a configuration file that will monitor any changes made to the nanorc file. This is called a beacon, and we’re going to store it at /srv/pillar/beacons.sls.

While /srv/salt is the default location for our end-state configurations, /srv/pillar works as a data store that we can also place many of our minion configurations in, such as beacons.

$ $EDITOR /srv/pillar/beacons.sls

From here, we’re going to use the inotify beacon module to track any changes to our file:

beacons:
  inotify:
    - files:
        /etc/nanorc:
          mask:
            - modify
    - disable_during_state_run: True

This file syntax is fairly self-explanatory. We first define that we’re setting our beacons, define the beacon type, then supply a list of files to monitor. The mask setting denotes what we’re tracking. In this case, it’s looking for any modifications to our file. Finally, disable_during_state_run prevents this beacon from triggering when Salt is making the change to the file.

Save and exit when finished. Before we can see if this works, we need to install the python-pyinotify package in order for inotify to function. We’re going to do this via a Salt execution module, which lets us run commands across multiple minions at once:

$ sudo salt '*' pkg.install python-pyinotify

We also need to map our beacons configuration to our minions. We do this via something called a top file, like so:

$ $EDITOR /srv/pillar/top.sls

base:
  'minion*':
    - beacons

When we’re finished editing the file, force a pillar refresh:

$ sudo salt '*' saltutil.refresh_pillar

Test the Beacon

To test the beacon, connect to the event bus on the master:

$ sudo salt-run state.event pretty=true

Next, we want to open up a new terminal window or pane and SSH into one of the minions:

$ vagrant ssh minion1

On the minion, make a change to the /etc/nanorc file:

$ $EDITOR /etc/nanorc

A WILD CHANGE APPEARS!

set tabsize 2
set tabstospaces

Return to the master. You should see a notification on the event bus informing Salt that a change has been made to the /etc/nanorc file on minion1:

salt/beacon/minion1/inotify//etc/nanorc    {
    "_stamp": "2018-07-03T13:32:25.996221",
    "change": "IN_MODIFY",
    "id": "minion1",
    "path": "/etc/nanorc"
}

Press CTRL+C to exit the event bus.

Since we know our beacon works, we can take this information, and make sure Salt resets any changes we manually make to a file.

Add a Reactor

A reactor does just that — it reacts to an event. In our case, we want it to react to our changing nanorc file by reapplying the nano state we created in the first part of this tutorial. Still on the master, we need to first create a directory to store these reactors:

$ sudo mkdir /srv/reactor/
$ sudo chown vagrant:vagrant /srv/reactor

We now want to create a reactor that reinforces are nano state. We’re also going to call this nanorc.sls:

$ $EDITOR /srv/reactor/nanorc.sls

Creating a reactor sls looks a little like creating a state. We’ll provide a name declaration, a function, then some parameters. We’ll also need to supply the targets, or minions, we want the state to run on:

restore_nanorc:
  local.state.sls:
    - tgt: 'minion*'
    - args:
      - mods: nano

We use minion* as our target so it targets both minions (or anything that begins with minion).

Save and exit the file. We now need to map this reactor to the event that triggers it. In our case, it’s the salt/beacon/minion*/inotify//etc/nanorc event. This is taken from the ID of the event triggered by our beacon; the only difference is that we’re using minion* for any minion, instead of minion1 specifically.

This mapping is saved as part of our master’s configuration, so we’ll store it in /etc/salt/master.d:

$ sudo $EDITOR /set/salt/master.d/reactor.conf:

Now we just need to supply the event ID, followed by the reactor we want to run when it occurs:

reactor:
  - 'salt/beacon/minion*/inotify//etc/nanorc':
    - /srv/reactor/nanorc.sls

Save and exit when done.

Since this was a change to our master config, we need to restart the salt-master daemon:

$ sudo systemctl restart salt-master

Now, let’s see if this reactor works!

Test the Reactor

On the master, connect to the event bus once again:

$ sudo salt-run state.event pretty=true

On the minion, make another change to the /etc/nanorc file:

$ sudo $EDITOR /etc/nanorc

CHANGE IS WEAK TO REACTOR TYPES!
A WILD CHANGE APPEARS!

set tabsize 2
set tabstospaces

Save and exit, then return to the master and watch the event bus. After that initial beacon event, we get a series of job events related to enforcing the nano state. And if we open up the /etc/nanorc file on our minion?

$ sudo $EDITOR /etc/nanorc

set tabsize 2
set tabstospaces

It’s back to how it should be!

Become a SaltStack Certified Engineer

Of course, this is just one thing you’ll learn in this new SaltStack Certified Engineer prep course! Some other concepts included in this hands-on training course:

• Use common execution modules
• Use common state modules
• Build Salt states
• Use pillar
• Use Salt via the command line
• Use Salt key
• Understand Salt security concepts
• Use templating within Salt sls files
• Use the event bus
• Use Salt Cloud and Salt SSH

Are you ready to be a SaltStack Certified Engineer? To learn how to write more advanced states, manage servers through execution modules, and combine the event system with other Salt components, head on over to Linux Academy and start your Salt journey with a 7-day free trial!

Other Salt Resources:

• SaltStack Quick Start Guide
• Using Salt for Configuration Management & Orchestration
• Understanding Event-Driven Infrastructure

The post Master Salt with Our New SaltStack (SSCE) Prep Course appeared first on Linux Academy Blog.