Guest post by Jurnell Cockhren, CTO and Founder of SophicWare
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.
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:
rest_cherrypy:
port: 8000
host:
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.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:
external_auth:
pam:
stackstorm:
- '@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.
{WOULD SOME SORT OF DRAWING SHOWING THE INTEGRATION BE POSSIBLE?}
You can install Stackstorm with the following commands:
curl -s https://downloads.stackstorm.net/releases/st2/scripts/st2_deploy.sh latest
sudo bash st2_deploy.sh stable
Ensure Stackstorm is running with
sudo st2ctl status
and it should look like the following:
If any of the components aren’t running, executing sudo st2ctl restart will quickly get Stackstorm is a usable state.
Given the salt pack requires some configuration, it’s wise to avoid the packs.install action.
From the docs, you should:
st2 run packs.download 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:
api_url: https://salt.example.com:8080
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
There are a lot of actions! Don’t fret, just remember that Stackstorm actions map to Saltstack module functions along the following rules:
runner_ map to runner module functions (i.e. commands ran with salt-run).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
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!