StackStorm represents a sophisticated, event-driven automation platform engineered in Python, designed to function as the "IFTTT for Ops." It serves as a powerful orchestration layer that allows operators to wire together disparate infrastructure components—such as GitHub, Docker, Nagios, NewRelic, and AWS—into complex, intelligent workflows capable of auto-remediation and proactive system management. While StackStorm provides the event-driven "brain" and orchestration logic, Ansible provides the "muscle" for configuration management and endpoint execution. The synergy between these two tools transforms static automation scripts into dynamic, reactive workflows. By leveraging Ansible for the deployment of StackStorm itself, and subsequently using StackStorm to trigger Ansible playbooks in response to real-time events, organizations can achieve a level of operational maturity where the infrastructure can self-heal and reconfigure itself without manual intervention.
Technical Architecture and System Requirements
Deploying StackStorm requires a robust environment capable of supporting its multifaceted architecture. Because StackStorm is not a single application but a suite of integrated services, the underlying hardware and operating system must meet specific criteria to ensure stability and performance.
The platform is shipped with a comprehensive set of dependencies that handle messaging, data storage, and web delivery. These include RabbitMQ for message brokering, MongoDB for database storage, Redis for caching and state management, and nginx as the web server. Due to the resource demands of these services, the minimum hardware specification requires at least 2 GB of system memory and 3.5 GB of available disk space. Failure to meet these requirements will likely result in service instability, particularly during the execution of complex workflows or when handling high volumes of event data.
From an operating system perspective, StackStorm maintains broad compatibility across major Linux distributions. The following platforms are officially supported:
- Ubuntu Focal (20.04)
- Ubuntu Bionic (18.04)
- RHEL 7 and CentOS 7
- RHEL 8, Rocky Linux 8, and CentOS 8
It is important to note that while StackStorm is specifically verified on RHEL and Rocky Linux 8.x distributions, the provided RPMs are designed to be compatible with other RHEL 8.x derivatives, including CentOS 8 Stream. For users employing virtualization via Vagrant, the provided Vagrantfile defaults to Ubuntu Focal.
Automated Deployment via Ansible Playbooks
The most efficient, repeatable, and production-friendly method for installing StackStorm is through the use of Ansible playbooks. This approach ensures idempotency, meaning the installation can be run multiple times without changing the system state unless a configuration change is required, which is critical for disaster recovery and scaling.
The source code for these deployment tools is hosted in the StackStorm/ansible-st2 GitHub repository. This repository provides the necessary roles and playbooks to abstract the installation process, moving away from unsustainable "one-line" manual installs.
The Ansible Role Hierarchy
The stackstorm.yml play is not a monolithic script but is composed of several modular Ansible roles that handle specific layers of the stack:
- epel: This role manages the Extra Packages for Enterprise Linux repository, which is essential for RHEL, Rocky Linux, and CentOS systems to access necessary dependencies.
- mongodb: This role handles the installation and configuration of the main database storage engine.
- rabbitmq: This role deploys the message broker required for event distribution.
- st2repos: This role adds the StackStorm PackageCloud repositories to the system.
- st2: This final role installs and configures the core StackStorm platform.
Execution Workflow for Deployment
To initiate a standard single-node deployment with default settings, the following sequence of commands is utilized:
bash
git clone https://github.com/StackStorm/ansible-st2.git
cd ansible-st2
ansible-playbook stackstorm.yml
For more advanced deployments, the execution method varies based on the target environment:
Local Machine Installation: To install StackStorm on the current local machine, use the following command:
bash ansible-playbook --inventory localhost, --connection local stackstorm.ymlRemote Machine Installation: To target a remote server, such as
stackstorm.example.com, a separate inventory file must be created:
bash echo "stackstorm.example.com" > inventory ansible-playbook --inventory inventory stackstorm.yml
Configuration Variables and Customization
The stackstorm.yml playbook is highly parameterizable, allowing administrators to customize the installation via variables passed in the inventory or as extra variables.
| Variable | Default | Description |
|---|---|---|
| st2repo | The StackStorm PackageCloud repository to install. Options include stable, unstable, staging-stable, and staging-unstable. | |
| st2repo_name | stable | The name associated with the repository. |
| st2 | General st2 variable. | |
| st2_version | latest | The version of StackStorm to install. Use "present" for available packages, "latest" for automatic updates, or pin to a numeric version like 2.2.0. |
| st2_config | {} | A hash containing StackStorm configuration settings to be written to the st2.conf ini file. |
Version Control and Pinning
Using the latest version is beneficial for those who wish to keep StackStorm updated by simply re-running the playbook. However, for production environments where stability is paramount, it is recommended to pin the version and revision numbers to prevent unexpected upgrades. For example, to install a specific version with a pinned revision:
bash
ansible-playbook stackstorm.yml --extra-vars "st2_version=2.2.0 st2_revision=8"
Advanced Customization and Security
Default installations use the credentials testu:testp. It is mandatory to change these to secure settings immediately upon deployment. For complex enterprise deployments, users can incorporate custom roles or pass specific authentication and pack requirements during the playbook execution.
An example of a comprehensive deployment command involving custom GitHub tokens and specific packs is as follows:
bash
sudo ansible-playbook stackstorm.yml -i 'localhost,' --connection=local \
--extra-vars='st2_auth_username=st2admin st2_auth_password=Ch@ngeMe \
github_token=1cd45ac235e54acbf4aabc09801e0b5abc549afb \
st2_packs=["st2","https://dylan-bitovi:{{ github_token }}@github.com/dylan-bitovi/my_st2_pack.git","https://dylan-bitovi:{{ github_token }}@github.com/dylan-bitovi/my_st2_jira.git"]'
Additionally, for environments operating behind a proxy, the playbook supports the use of standard environment variables: http_proxy, https_proxy, and no_proxy.
Integrating Ansible within StackStorm Workflows
Once StackStorm is deployed, it acts as a catalyst for executing Ansible playbooks based on external triggers. While StackStorm is not designed for endpoint configuration itself, it orchestrates the execution of Ansible, which handles the actual communication with target devices.
The Ansible Pack Architecture
The ansible pack in StackStorm allows the platform to run Ansible commands and playbooks on arbitrary servers. A critical technical constraint is that the Ansible Python library must be installed on the server where the StackStorm action runner services are residing. The Ansible library is installed automatically when the StackStorm Ansible pack is deployed.
Regarding the placement of Ansible and StackStorm, it is not currently possible to define a remote StackStorm endpoint for the integration pack; they must reside on the same runner. However, this is a negligible limitation because the Ansible pack can target any remote server in the network for playbook execution.
Real-World Application: AOS-CX Network Automation
A practical application of this integration is seen in the automation of Aruba AOS-CX switches. In this scenario, StackStorm is used to monitor a syslog server for specific patterns. When a specific event occurs—such as an interface link coming up on a switch—StackStorm triggers a corresponding Ansible playbook.
The technical requirements for this workflow include:
- An AOS-CX Switch running the latest release.
- A functioning Ansible Engine.
- A Syslog server installed on a Linux distribution.
- StackStorm with the
aoscxandcorepacks installed.
To ensure the workflow is efficient and does not suffer from noise, it is best practice to route switch syslog messages to a dedicated file. For CentOS 8 machines, this is achieved by modifying the /etc/rsyslog.conf file:
bash
if $fromhost-ip startswith '10.100' then /var/log/switch-log.log
StackStorm monitors this file, matches the text pattern of the "link up" event, and subsequently executes the Ansible playbook using the AOS-CX Collection to perform the necessary configuration or verification tasks on the switch.
Infrastructure Management and Scaling
The transition from manual, one-line installations to Ansible-based deployments is essential for meeting expanding resource growth, advanced development workflows, and disaster recovery requirements. By abstracting setup tasks into repeatable playbooks, organizations can treat their automation platform as code.
Connectivity and Firewall Requirements
For the StackStorm Web UI to be accessible, the network infrastructure must allow traffic on the designated HTTP and HTTPS ports. Failure to configure the firewall correctly will prevent administrative access to the platform, regardless of whether the underlying services are running.
The Role of Integration Packs
The power of StackStorm lies in its "packs." These are sets of actions, sensors, and rules. To verify the installed packs on a system, the following command is used:
bash
st2 pack list
By combining the st2 pack with specialized packs like aoscx, users can bridge the gap between high-level event monitoring and low-level device configuration.
Conclusion
The integration of StackStorm and Ansible creates a formidable automation ecosystem. By using Ansible for the deployment and configuration of StackStorm, users ensure that their orchestration layer is stable, repeatable, and easily updated. Once the platform is active, the relationship flips: StackStorm becomes the intelligent trigger that invokes Ansible's vast library of modules to manage endpoints. This synergy allows for the creation of sophisticated, self-healing infrastructures where a syslog message from a network switch can trigger a complex sequence of remediation steps across a data center, all without human intervention. The move toward modular Ansible roles and the use of pinned versions further ensures that this automation is production-ready and resilient against the volatility of software updates.