Predefined Routine Packages

Dealing with StackStorm is simplified by using the packs already mentioned. You can think of them as deployment units for integrating and automating established services and applications. Thanks to this approach, it is easy to integrate AWS, Docker, GitHub, or similar systems into the management environment. Actions, workflows, rules, sensors, and aliases are bundled in such a pack. Different packs capture automation patterns  – the developers also refer to automation packages.

Predefined integration packages are available, in particular, through the StackStorm Exchange platform but can also be created independently. The

st2 pack <package name>

command manages StackStorm packages. The default installation already has some pre-installed packages that you retrieve with the list command. By default, they are located in the /opt/stackstorm/packs directory. StackStorm Exchange doesn't inform you at first glance that it has well over a hundred StackStorm packages. You can conveniently browse the inventory from within the CLI. To do so, use the commands:

st2 pack search
st2 pack show

Once you have identified one or more packages of interest, install them from the CLI on the basis of the Exchange designation:

st2 pack install <package1> <package2>

Various packages are dependent on the existence of others. Corresponding information is stored in the dependencies section of the pack.yaml file. You do not have to deal with these dependencies any further because StackStorm automatically installs the relevant packages.

However, just installing is not usually enough: You need to adapt the setup to your framework conditions. If a package supports sending notification email, for example, you will need to configure the SMTP server. Another typical requirement is specifying access credentials for a service. Mostly, the package configuration is interactive – for example, by typing

st2 pack config cloudflare

when setting up the Cloudflare package.

In this example, the CLI presents you with an interactive dialog with default values, suggestions, and input fields for your own settings. The package configuration is stored in the file /opt/ stackstorm/configs/<package name>.yaml.

Dealing with Actions

Actions are one of the core concepts of the StackStorm environment. These code snippets can be written in any programming language and basically perform any automation or correction tasks in your environment. Actions can implement a wide variety of management tasks. For example, you can restart services on a server, set up a new cloud server, verify a Nagios alert, use email or SMS notification, start a Docker container, take a snapshot of a virtual machine, or initiate a Nagios check. Actions start running when a rule with matching criteria triggers them. Execution can be from the CLI or with an API.

To perform an action manually, use the commands:

st2 run <action with parameter>
st2 action execute <action with parameter>

To create your own action, you again need to create a YAML-based metafile with the relevant information and a script that implements the action logic. Getting started is simplified with the use of predefined actions that are part of the core package. You can use the core.local action to execute arbitrary shell commands. A simple example is:

st2 run core.local cmd='ls -l'

The core.remote action supports the execution of commands on remote systems and core.http lets you execute an HTTP request, as in:

st2 run core.remote cmd='ls -l' hosts='host1,host2' username='user1'
st2 run core.http url ="http://www.server.de/get" method="GET"

The following action is similar to curl and allows authentication on a remote system with credentials:

st2 run core.http url="http://www. server.com/get" method="GET" username=user1 password=pass1

These actions not only cover the standard tasks but are also great for finding your way around the StackStorm environment. For the full list of core packages, use the command:

st2 action list --pack=core

StackStorm has another special feature to offer: If you already have scripts in any programming or scripting language, StackStorm can convert them into actions. First, you need to make sure that the script conforms to the conventions laid down by the StackStorm developers. In particular, it is important that it returns a status code of zero after execution is complete and that it terminates on a non-zero error. The tool uses the exit codes to determine whether the script completed successfully. You also need to generate a metadata file that lists the script name, a description, the entry point, the runner to use, and the script parameters.

Sensors and Triggers

The purpose of sensors is to integrate external systems and events into a StackStorm environment. These sensors either query external systems for specific system and environment variables or wait until they register a conspicuous or critical event that, if detected on a sensor configuration, causes StackStorm to fire a trigger, with possible actions executed according to a set of rules. The tool has a sensor interface that queries or collects the data. In most cases, sensors and triggers interact, but some triggers do not require sensors, such as the webhook trigger (Figure 2).

Figure 2: The automation environment has a clear-cut web interface; however, the developers recommend using the CLI.

Out of the box, StackStorm comes with several internal triggers that you can apply to your ruleset when you configure a new installation. These can be distinguished from non-system triggers by their st2 prefix:

• core.st2.generic.actiontrigger is a generic trigger for action execution.
• core.st2.generic.notifytrigger triggers a notification.
• core.st2.action.file_written writes to files on the target system.
• core.st2.generic.inquiry executes a new status query after being assigned the pending state.

You will find several sensor-specific triggers in a StackStorm installation. For example, the core.st2.sensor.process_spawn trigger indicates that a sensor process has been activated. The core.st2.sensor.process_exit trigger tells you that a sensor process has been stopped. Sensors run as separate processes and can execute different operations. Before these can be executed, registration with strctl is necessary. After successful registration, the sensor starts automatically.