Getting Started With StackStorm and SaltStack

Guest post by Jurnell Cockhren, CTO and Founder of SophicWare

Our Journey

The task at hand is to connect Stackstorm to your pre-existing Saltstack infrastructure. Why? Well, by doing this you can turn all of your existing Salt actions into StackStorm actions, allowing you to use StackStorm for your overall event driven automation while Salt remains focused on remote execution and other use cases. This is a pattern we are increasingly seeing – so let’s try it out!

This blog covers both proper configuration of Saltstack NetAPI allowing for Stackstorm usage as well as how to install and configure the salt pack within StackStorm. This tutorial covers Scenario 2 listed on the Salt pack README.

Minimum Requirements

  • Saltstack (2014.7+)
  • a Stackstorm ready Vagrant (or VPS, if you’re courageous)

Step 1. Setup NetAPI

Saltstack’s NetAPI allows for remote execution of salt module functions. This feature proved most beneficial when developing deep integration between Stackstorm and Saltstack.

On your salt master, install the salt-api package using your typical means for updating or install Saltstack for your organization.

On Ubuntu, you could run:

apt-get install salt-api

Create a file named: /etc/salt/master.d/salt-api.conf filled with the following:

port: 8000
debug: True
ssl_crt: /etc/nginx/certs/server.crt
ssl_key: /etc/nginx/certs/server.key

Let’s examine what’s what:

  • port: What port to have cherrypy listen on.
  • host: The IP address of your interface to listen on. In production environments I like to not expose cherrypy directly to the world. Instead use nginx as the frontend allowing you to have more controls over the SSL ciphers and protocols.

  • debug: Setting this to True is generally a good idea.
  • ssl_crt and ssl_key: For this post, let’s allow cheerypy to handle SSL communications. Remember, use nginx for your frontend in production.

Step 2: Setup Access Control List

It makes good sense to be deliberate while choosing which users can authenticate with Saltstack and which modules they’re authorized to use. ACLs and external_auth are outside the scope of this post, but it pays off to know what is what during initial setup.

Suppose you have a non-root user called stackstorm that will be making the NetAPI on the behalf of stackstorm. Feel free to use any supported external authenticaion backend. In this example, we’re going with plain ol’ PAM.

Somewhere in your Saltstack master config add:

- '@runner'
- test.*
- service.*
- pkg.*
- state.sls

The above configuration allows your stackstorm user to execute:
1. All runner functions.
2. All functions in the test, service, pkg execution modules and the state.sls function on any minion.

Restart the salt-api and salt-master daemons to put your new settings into effect.


Step 3: Installing Stackstorm

You can install Stackstorm with the following commands:

curl -s latest

sudo bash stable

Ensure Stackstorm is running with

sudo st2ctl status

and it should look like the following:

Check Status

If any of the components aren’t running, executing sudo st2ctl restart will quickly get Stackstorm is a usable state.

Step 4: Readying the Saltstack Pack

Given the salt pack requires some configuration, it’s wise to avoid the packs.install action.

From the docs, you should:

st2 run packs=salt

st2 run packs.setup_virtualenv packs=salt

Assuming the default base_path, the salt pack will be installed at /opt/stackstorm/packs/salt. Fill the empty config.yaml file with the credentials of the stackstorm user from Step 2:

username: stackstorm
password: _some_password_
eauth: pam

Register all actions contained in the pack:

st2 run packs.load register=all

Note: Ideally, you’d execute the above commands as part of a salt state. It’s best practice to generate config.yaml from a template and retrieve your stackstorm user credentials from an encrypted pillar.

Let’s take a look at the available actions:

st2 action list --pack=salt

view action list

There are a lot of actions! Don’t fret, just remember that Stackstorm actions map to Saltstack module functions along the following rules:

  1. Actions prefixed with runner_ map to runner module functions (i.e. commands ran with salt-run).
  2. Actions prefixed with local_ map to execution module functions (i.e. commands ran with salt).

Those aren’t the only module functions you can execute. Using the salt.runner and salt.local generic actions, you can execute any runner or execution functions, respectively!

Given we’ve authorized the stackstorm user to execute any runner function in Step 2, executing the following will return your living Saltstack minions:

st2 run salt.runner_manage.up

Done Done.

You’ve successully configured Stackstorm to use the Saltstack pack. Stay tuned for another post on how to add ChatOps to the mix. Leveraging Stackstorm, we can add easily add ChatOps to your Saltstack Infrastructure!