The Art of Packing Part 1

Sub title: Building a StackStorm Pack
DISCLAIMER: You can only trust a mad scientist so much!

TL;DR
Stackstorm uses sensors to monitor just about anything and when an event happens, a Rule is triggered that will launch Actions that do things. Intergration to the rest of the world happens through “packs”. Want to know more? Read on!


Don’t get the wrong impression! I’m not talking about packing your bags, this is a post about building StackStorm integration packs! What? Haven’t heard of StackStorm? It’s one of the coolest automation platforms I have had the “pleasure” of becoming familiar with. Ask not what does it do, rather what can’t it do. One thing I can’t do it educate you in this post, that’s not what its for. You can check them out over here.

A StackStorm integration pack is a predefined set of Actions, Sensors, Rule, python or shell scripts and other miscellaneous stuff. A StackStorm pack has a specific structure that looks like this!

This image is from the StackStorm documentation and if you are a real curious explorer you can look HERE.

I have just started this journey myself and I wanted to share some knowledge that cost about a thousand google searches.

So the good news is, if you have some existing python or shell scripts you are using for automating things, we can recycle them into StackStorm. I am working with python scripts. The first thing to do is pair the script file `myPython.py` with a ‘myPython.yaml” file. When this happens the resulting pair of files represent StackStorm Actions. These are stored in the Action directory. You can manually run an Action by typing st2 run action name on the command line. So lets take a look at an action.

Actions:

Lets start with the yaml file.

It’s fairly straigt forward. Our entry point will be a python script called `get_switches` The runner type is python-script. After that we describe each variable we will be sending to the python script at execution.

StackStorm Datastore

So I am using the Datastore built into StackStorm. st2 key set ipaddress “10.10.10.10” will save a key:value pair to the datastore. To retrieve it at any time, simply reference it by “{{ st2kv.system.ipaddress }}” this must be in DOUBLE quotes or you will not have any fun. So to recap this YAML file tells StackStorm that there is an action that will run a python script and pass three variable, IP Address, Username and Password. Don’t worry, you can encrypt these as well. Start googling!

Next we have the python script.

This was a script that I was already using. I added the import Action and wrapped my script up in a class. In the def() you see the three variable that we are being passed by the Action YAML.
You can also see I am importing pyhpecfm. To make this work, we need to include a requirements.txt file in our pack to tell StackSorm to perform a PIP install of the package automatically.

By creating this action, we can now reference it in workflows.

Workflows are YAML files that can run actions. Orquesta, StackStorm’s new workflow application, allows you to do some fairly complex workflows. Want to know more? Orquesta.

When the workflow runs, it can call our action to get switches. Once it has the python dictionary from whatever we are talking to, it can stash it in the “context” and other Actions can read from that. It was here my cheeese almost slid off my cracker, the “context” was like stashing variables in thin air. Here is an example of an Oquesta workflow.


You can see the get_switches action is called. It in turn runs a python script. The result is stashed in the context by publishing it. Once it has succeeded, It will route to the sendsnow task and another workflow is called and passed the switch information. That workflow uses pre-built StacksStorm integration packs from Service Now which are freely available on the StackStorm Exchange Here. Here is a screen shot of the workflow that calls Service now. I use with items and iterate through the dictionary.


I will be moving on to learning about sensors. These are python files that can watch message buses and kick off triggers.
Stay tuned for more in a later blog post!

Leave a Reply

Your email address will not be published. Required fields are marked *