stackstorm 0.stackstorm组成,服务与架构

1 StackStorm组成 

StackStorm环境中的插件是通过扩展传感器和动作实现。

1) Sensors

是用于内部或外部集成的Python插件，该插件可以接受到个自的事件。
当一个外部系统的事件发生时，该事件可以被一个sensor处理，一个StackStorm
的trigger触发器将会发射到系统中。

2) Triggers

是StackStorm中外部事件的表现。有通用的triggers(例如:timers, webhooks)
和集成的triggers(例如: Sensu alert, JIRA问题更新)。一个新的trigger类型可以
通过编写一个sensor插件来定义。

3) Actions

是StackStorm外部集成。有一般的actions(ssh, REST调用)，intergrations(
OpenStack, Docker, Puppet)，或者定制化actions。
Actions要么是Python插件，或者是任何脚本，通过添加几行代码到metadata中来被StackStorm
消费。Actions可以被用户通过命令行或者API直接调用，或者作为rules和workflows的一部分被使用。

4) Rules

映射triggers到actions(或者workflows)，应用匹配的criteria和映射
trigger payload到action输入。

5) Workflows

将actions组装到uber-actions,定义顺序，转换条件，
并传递数据。大多数自动化不止一步，因此需要不止一个action。
Workflows,就像原子actions,可以在Action库中获取，可以被手动调用或者
被规则触发。

6) Packs

是内容步数的单元。它们简化了管理并通过分组集成(
triggers和actions
)和自动化(rules和workflows)来共享StackStorm插件化内容。
大量packs可以从
https://exchange.stackstorm.org/
获得。用户可以创建他们自己的packs，在Github上共享它们，
或者提交到StackStorm的Exchange。

7) Audit trail

审计跟踪动作执行，手动或自动化的触发上下文和执行结果被记录和存储。
它也可以在audit日志终被布或到，用于集成到外部日志系统和分析工具:
LogStash, Splunk, statsd, syslog。

2 StackStorm各个服务

2.0 stackstorm架构

架构如下所示

2.1 St2服务

st2服务提供StackStorm主要功能，位于/opt/stackstorm/st2，
共享一个通过/etc/st2/st2.conf进行配置专用的Python虚拟环境。

1 st2 services

- st2sensorcontainer运行/opt/stackstorm/packs目录下的传感器。它管理将在一个节点上运行的传感器，可以对它进行启动、停止和重启操作。

- st2rulesengine在收到TriggerInstance时将对规则评判，并决定是否执行ActionExecution请求。它需要访问MongoDB来定位规则，而RabbitMQ侦听TriggerInstance和ActionExecution请求。此过程的另外用途是执行所有定义的定时器。

- st2actionrunners通过各种Action执行器运行/opt/stackstorm/packs下的包含的action包。执行器可能需要一些针对特定执行器的配置，例如需要配置SSH才能运行基于remote-shell-runner和remote-command-runner的远程action。而对于Windows需要先准备好Windows的执行器。详情见执行器（Runner）。

- st2resultstracker通过调用Mstral API端点，跟踪长时间运行的工作流的执行情况。

- st2notifier在ActionExecution执行完成时TriggerInstances产生st2.core.actiontrigger和st2.core.notifytrigger。另外一个目的是充当action的备份调度器，处理哪些可能未列入计划的action。

- st2garbagecollector是一个可选的服务，可以根据在/etc/st2/st2.conf中设置的参数，周期性地从数据库中删除那些老旧的执行历史数据。

- st2auth是一个支持终端REST的认证服务。后端可用各种的认证方法，有关详细信息，请参阅身份验证（Authentication）。参考部署后端认证是使用平面文件（flat file）。

- st2api 是用于CLI和Web UI的REST API Web服务端点。它还为webhook提供webhook触发器。

- st2stream 是一个HTTP消费端的事件流，发布了各种有用的事件。这些事件由Webui和Hubot消费，如Chatps更新结果等。

 

2.2 st2client

- st2client是CLI和通过StackStorm API绑定的Python。要将CLI配置成能指向正确的API，请使用身份验证选项、禁止对自签名证书的不安全警告以及其他方便方式，请参阅CLI参考（CLI Reference）。st2client与st2一起发行，也可以独立安装。

2.3 st2mistral

- st2mistral Mstral是StackStorm为长时间执行的工作流使用的工作流服务组件。它被打包为st2mistral，安装在/opt/stackstorm/mistral下，在一个专门的Python虚拟环境中运行，并通过/etc/mistral/mistral.conf进行配置。
  mistral-server运行工作流逻辑和调用action，向st2api提供action的执行请求。st2mistral是一个随着stackstorm扩展的mstral插件。
  mistral-api是由st2actionrunner和st2notifier访问的内部端点。在单台部署方式中，它只能限于localhost主机。

2.4 NGINX的WebUI和SSL

 

- nginx提供SSL终结，将HTTP重定向到HTTPS，为WebUI静态组件服务，并为RESTAPI端点到st2*的Web提供反向代理服务。

- StackStorm WebUI包括st2web、Workflow Designer、eXtreme Workflow Composer，安装在/opt/stackstorm/static/webui，通过webui/config.js配置。st2web内置了它自己的deb 和rpm包。Workflow Designer是作为bwc-enterprise软件包的一部分部署的，是HTML 5应用程序，充当静态HTML，并调用StackStorm的st2auth和st2api的RESTAPI端点。Nginx代理st2api和st2auth服务的/api和/auth的入站请求。

2.5 st2chatops 

– ChatOps组件StackStorm的Chatops组件是Hubot、st2的Hubot适配器、连接到不同聊天服务的插件。它们打包为st2chatops，安装在/opt/stackstorm/chatops/，在/opt/stackstorm/chatops/st2chatops.env文件中配置。还可以通过在已有Hubot实例上安装hubot-stackstorm plugin插件来启用ChatOps。

依赖软件必须的依赖软件包括RabbitMQ、MongoDB、PostgreSQL，可选的依赖软件如下：
- nginx用于SSL终结、反向代理API端点和服务- 并发策略（Policies）使用的Redis或者Zookeeper
- Extreme Workflow Composer中LDAP认证的LDAP

参考:
[1] https://docs.stackstorm.com/overview.html
[2] https://www.jianshu.com/p/170cc4e7739a
[3] https://docs.stackstorm.com/install/overview.html