Creating Triggers and Actions

When a sensor detects an event, it activates a trigger. Triggers are interfaces that define which actions are to be executed when a certain event occurs, which means triggers can be used for many types of events (e.g., syslog events or SNMP traps). Triggers are available in the web interface, but you can also configure them with the st2 command in the CLI. A trigger might look like:

name: syslog_trigger
pack: default
description: "Triggers on critical syslog errors"
type: "core.syslog"

In contrast, actions are the automation steps that StackStorm executes after a trigger has been initiated, such as restarting a service, sending an email, or executing a script. To define a simple action, you could use a script that restarts a service; for this, you need a YAML file (Listing 2). This action restarts the specified network service when activated by a trigger.

name: restart_service
runner_type: "remote-shell-cmd"
description: "Restarts a network service"
enabled: true
entry_point: ""
parameters:
    cmd:
        type: "string"
        default: "sudo systemctl restart network-service"

The StackStorm package includes various default actions that execute remote commands on Linux or Windows systems by way of an example. You can use these actions and extend them to suit your needs, as described in the documentation [2]. You can list existing actions with the command referred to earlier:

st2 action list --pack=core

They can also be viewed in the Actions section of the web interface (Figure 2). Additionally, large numbers of pre-configured integration packs are available on the StackStorm Exchange platform [3]. You can install them directly from the CLI. The command

st2 pack install

Figure 2: You can control actions in StackStorm either from the CLI or, as shown here, in the web interface.

lets you access numerous packs that support integration with Kubernetes, Ansible, VMware, and more. These packs let you extend actions without having to write your own code.

Coordinating Actions with Workflows

Workflows coordinate several actions and can automate multistage processes, which in turn can detect critical errors, restart services, send notifications, and check network connections. You can also define workflows in a YAML file. In the simple example in Listing 3, StackStorm triggers a workflow when a sensor detects a service error. The workflow then restarts the service and notifies the admin.

name: recover_network_service
description: "Automated recovery of a network service"
type: "direct"
tasks:
        restart_service:
                action: "default.restart_service"
                next:
                        - when: "{{ succeeded() }}"
                                do: send_notification
        send_notification:
                action: "default.send_email"
                input:
                        to: "admin@domain.com"
                        subject: "Service restarted"
                        body: "The network service was successfully restarted."

Once you have configured sensors, triggers, actions, and workflows, you can test your automation setup in the CLI by starting a workflow manually:

st2 rundefault.recover_network_service

The web GUI lets you monitor the status of running workflows and view their results in real time. In the History area, you can view a graph of the individual steps and check whether all the actions are happening the way you intended.

Pre-configured Packs

In StackStorm, packs play a central role in the implementation of automation. A pack contains all the resources you need (e.g., actions, workflows, sensors, and triggers) that join forces to automate certain tasks. Think of packs simply as extensions, much like apps on a smartphone that add additional features.

Packs are also available on StackStorm Exchange with pre-configured automations for a variety of systems and services such as Active Directory, Kubernetes, AWS, VMware, and ServiceNow. These ready-made packs give you a head start in the automation universe without having to develop everything from scratch. Packs generally interact seamlessly with each other.

A workflow can exchange information between different packs and trigger complex, cross-system automation. You can install existing packs and use them immediately or extend them as needed to meet your specific requirements. To install a pack, go to StackStorm Exchange and click the Copy install command button for the appropriate pack; then, paste the command into the StackStorm CLI.

To install the Active Directory package, for example, you would enter

st2 pack install activedirectory

at the command line (Figure 3). The installation takes a few seconds before the actions, rules, sensors, and triggers become available. You can then manage these either in the CLI or the web interface, although the configuration work normally takes place in the CLI.

Figure 3: StackStorm can be expanded at any time with additional packs from the StackStorm Exchange.

Once the pack has been installed, you can configure it by adjusting the connection settings to the domain controller. You need to edit a configuration file in StackStorm to specify the IP address and the domain controller and add the required details to the /opt/stackstorm/configs/activedirectory.yaml configuration file, such as hostname, IP address, and credentials for accessing the controller.

One typical example of monitoring is performing regular LDAP queries to ensure that the domain controller is working properly. You could set up a sensor that monitors certain events in Active Directory, such as creating or deleting user accounts. Besides this, automations can be set up to perform certain actions automatically when certain events occur.

For example, a workflow could trigger a restart of the domain controller in the event of a critical error or notify an administrator if the domain controller is unreachable. Listing 4 is an example of monitoring or automating the dc1.joos.int domain controller, which has IP address 10.0.1.230. Add this configuration to the /opt/stackstorm/configs/activedirectory.yaml file.

hostname: "dc1.joos.int"
ip: "10.0.1.230"
username: "Administrator" # AD user name that has the necessary rights
password: "YourPassword" # Password for the user
base_dn: "DC=joos,DC=int" # Base DN of the Active Directory domain
use_ssl: true # Use SSL for secure LDAP connections
port: 636 # Default port for LDAP via SSL
default_ad_server: "10.0.1.230" # IP address of the domain controller
ad_server: - "10.0.1.230" # A list of AD servers if several are used
timeout: 30 # Timeout for connections (in seconds)