The documentation you're currently reading is for version 3.5.0. Click here to view documentation for the latest stable version.
Overview: Single-box Reference Deployment¶
This page describes a “reference deployment” of all StackStorm components installed on a single system. It explains what the main components are, their role, and how they are wired together.
If you use the one line quick install script, it will set up your system as shown below:
1. StackStorm services¶
“st2” services provide the main StackStorm functionality. They are located at
share a dedicated Python virtualenv, and are configured via
st2sensorcontainer runs sensors from
/opt/stackstorm/packs. It manages the sensors to be run on a node. It will start, stop and restart based on policy the sensors running on a node.
st2rulesengine evaluates rules when it sees TriggerInstances and decides if an ActionExecution is to be requested. It needs access to MongoDB to locate rules and RabbitMQ to listen for TriggerInstances and request ActionExecutions. The auxiliary purpose of this process is to run all the defined timers.
st2timersengine is used for scheduling all user specified timers aka StackStorm cron.
st2scheduler is responsible for scheduling action executions which are then run by
st2actionrunnerservice. It takes care of things such as delaying executions and applying user-defined pre-run policies.
st2actionrunners run actions from packs under
/opt/stackstorm/packsvia a variety of Action Runners. Runners may require some runner-specific configurations, e.g. SSH needs to be configured for running remote actions based on
st2.core.notifytriggerTriggerInstances on the completion of an ActionExecution. The auxiliary purpose is to act as a backup scheduler for actions that may not have been scheduled.
st2garbagecollector is an optional service to periodically delete old execution history data from the database, per settings in
st2auth is an authentication service with a REST endpoint. A variety of authentication backends are available; see Authentication for more details. The reference deployment uses flat file auth backend.
st2api is REST API web service endpoint, used by CLI and WebUI. It also serves webhooks for webhook triggers.
st2stream is an event stream consumption HTTP endpoint where various useful events are posted. These events are consumed by WebUI and hubot i.e. ChatOps to update with results etc.
st2workflowengine is responsible for running Orquesta workflows.
Some services follow active/active model and can scale horizontally (
st2workflowengine). Multiple instances of those services can run to increase the overall system
Other services (
st2sensorcontainer) require only
a single instance to be running for the system to function correctly.
st2client is the CLI and Python bindings for the StackStorm API. To configure the CLI to point to
the right API, authentication options, suppress insecure warnings for self-signed certificates and
other conveniences see the CLI Reference.
st2client is packaged with
st2, or can be
3. NGINX for WebUI and SSL termination¶
nginx provides SSL termination, redirects HTTP to HTTPS, serves WebUI static components, and reverse-proxies REST API endpoints to st2* web services.
StackStorm WebUI (st2web, including Workflow Designer) are installed at
/opt/stackstorm/static/webuiand configured via
st2webcomes in its own
rpmpackage. In StackStorm versions earlier than 3.3 Workflow Designer was deployed as part of the
bwc-enterprisepackage. They are HTML5 applications, served as static HTML, and call StackStorm st2auth and st2api REST API endpoints. NGINX proxies inbound requests to
/authto the st2api and st2auth services respectively. With StackStorm version 3.4 and later, the workflow designer is entirely integrated into st2web, and the
bwc-enterprisepackage is no longer distributed.
4. st2chatops - ChatOps components¶
StackStorm Chatops components are Hubot, |st2|’s Hubot adapter, and plugins for connecting to different Chat
services. They are packaged as
/opt/stackstorm/chatops/ and configured in
ChatOps can be also enabled by installing hubot-stackstorm plugin on your existing Hubot instance.
The required dependencies are RabbitMQ, MongoDB, and Redis (or Zookeeper).
The coordination service is required for workflows that has multiple branches and tasks with items. Previously, the coordination service is optional to support concurrency policies. The backend for the coordination service can be configured to use Redis, Zookeeper, or other. Since v3.5, redis server is installed as part of the single node installation script. The python redis client is also installed into the StackStorm virtualenv. If using Zookeeper, the kazoo module needs to be manually installed into the StackStorm virtualenv.
The optional dependencies are:
nginx for SSL termination, reverse-proxying API endpoints and serving static HTML.