The documentation you're currently reading is for version 3.1.0. Click here to view documentation for the latest stable version.
Overview: Single-box Reference Deployment¶
This page describes a “reference deployment” of all EWC 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 EWC 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 EWC 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 EWC 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
Mistral is a workflow service component that EWC uses for long-running workflows. It
is packaged as
st2mistral, installed under
/opt/stackstorm/mistral, runs in a dedicated
Python virtualenv, and is configured via
workflow logic and calling actions, reaching out to st2api for action execution requests.
st2mistral is a mistral plugin with stackstorm extensions.
mistral-api is an internal
end-point accessed by
st2notifier. In a single-box deployment it is
restricted to localhost.
4. 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, and Workflow Designer, for Extreme Workflow Composer) are installed at
/opt/stackstorm/static/webuiand configured via
st2webcomes in its own
rpmpackage. Workflow Designer is deployed as part of the
bwc-enterprisepackage. They are HTML5 applications, served as static HTML, and call EWC st2auth and st2api REST API endpoints. NGINX proxies inbound requests to
/authto the st2api and st2auth services respectively.
5. st2chatops - ChatOps components¶
EWC 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 PostgreSQL. The optional dependencies are:
nginx for SSL termination, reverse-proxying API endpoints and serving static HTML.
Redis or Zookeeper for concurrency policies (see Policies).
LDAP for Extreme Workflow Composer LDAP authentication.