1 StackStorm介绍
StackStorm是一个强大的自动化平台，结合DevOps和ChatOps，提供可扩展、灵活和健壮的工具链用于应用、服务和工作流的自动化能力。
StackStorm核心概念
StackStorm的工作步骤大体如下：
StackStorm Sensor感应并触发事件。
Rules Engine对事件进行规则匹配，如果匹配产生任务。
StackStorm Worker执行任务，一般是调用到外部系统。
StackStorm记录审计任务执行的细节。
5.任务执行结果返回给Rules Engine进行进一步处理。
可以看出StackStorm是个以事件驱动的系统，为此抽象出一系列概念来分解事件从产生、触发、规则匹配到执行的整个生命周期事件，具体包含核心概论如下：
Sensor感应器
Sensor是一系列的感应器用于接受或者监测事件，当事件发生的时候，Sensor将会通知Trigger提交事件到StackStorm。
Sensor是Python插件实现，只要实现StackStorm定义的接口，然后配置元数据YAML注册到StackStorm:
class_name: "SampleSensor"
entry_point: "sample_sensor.py"
description: "Sample sensor that emits triggers."
trigger_types:
name: "event"
description: "An example trigger."
payload_schema:
type: "object"
properties:
executed_at:
type: "string"
format: "date-time"
default: "2014-07-30 05:04:24.578325"
Trigger触发器
Trigger代表事件，一般事件是由外部系统产生，比如监控告警，JIRA问题更新等等，另外也有通用的事件触发器，比如定时器或者WebHook。
在StackStorm系统中，Trigger只是String类型的对象，由Sensor注册，用户可以在Sensor插件自定义新的Trigger。
Action 动作/任务
Action是事件触发后的处理方式，一般是由外部系统执行，包括：
重启服务
创建云服务
发生邮件
启动Docker容器
制作VM快照
Action可以是通用的执行方式，比如SSH，REST API调用，也能够集成Openstack、Docker/Kubernetes等系统实现。Action Runner是Action的执行环境，StackStorm的内置Action Runner：
Action Runner Description
local-shell-cmd This is the local runner. This runner executes a Linux command on the same host where StackStorm components are running.
local-shell-script This is the local runner. Actions are implemented as scripts. They are executed on the same hosts where StackStorm components are running.
remote-shell-cmd This is a remote runner. This runner executes a Linux command on one or more remote hosts provided by the user.
remote-shell-script This is a remote runner. Actions are implemented as scripts. They run on one or more remote hosts provided by the user.
python-script This is a Python runner. Actions are implemented as Python classes with arun method. They run locally on the same machine where StackStorm components are running.
http-request HTTP client which performs HTTP requests for running HTTP actions.
action-chain This runner supports executing simple linear work-flows.
mistral-v2 Those runners are built on top of the Mistral OpenStack project and support executing complex work-flows.
cloudslang This runner is built on top of the CloudSlang project and supports executing complex workflows.
通过Action Runner用户可以自定义Action的实现，以下是一个python-script类型的Action用于发送SMS:
name: "send_sms"
runner_type: "python-script"
description: "This sends an SMS using twilio."
enabled: true
entry_point: "send_sms.py"
parameters:
from_number:
type: "string"
description: "Your twilio 'from' number in E.164 format. Example +14151234567."
required: true
position: 0
to_number:
type: "string"
description: "Recipient number in E.164 format. Example +14151234567."
required: true
position: 1
secret: true
body:
type: "string"
description: "Body of the message."
required: true
position: 2
default: "Hello {% if system.user %} {{ system.user }} {% else %} dude {% endif %}!"
Workflow 工作流
Workflow是Action集合，Workflow能够定义Action的执行顺序和条件，组合一系列Action完成复杂的任务。Workflow可以认为是广义意义上的Action。
StackStorm支持2种类型的Workflow:
ActionChain:通过简单的语法定义Action链
--------------------------------------------------------------------------------
chain:
- name: "c1"
ref: "core.local"
parameters:
cmd: "echo c1"
on-success: "c2"
on-failure: "c4"
- name: "c2"
ref: "core.local"
parameters:
cmd: "echo "c2: parent exec is {{action_context.parent.execution_id}}.""
on-success: "c3"
on-failure: "c4"
- name: "c3"
ref: "core.local"
parameters:
cmd: "echo c3"
on-failure: "c4"
- name: "c4"
ref: "core.local"
parameters:
cmd: "echo fail c4"
default: "c1"
Mistral ：Openstack的工作流组件,可以同Stackstorm集成，支持复杂的工作流配置。
version: '2.0'
examples.mistral-join:
description: >
A sample workflow that demonstrates how to join parallel branches.
type: direct
tasks:
a:
action: core.local
input:
cmd: "echo 'a'"
on-success:
- b
- c
- d
b:
action: core.local
input:
cmd: "echo 'b'"
on-success:
- e
c:
action: core.local
input:
cmd: "echo 'c'"
on-success:
- e
d:
action: core.local
input:
cmd: "echo 'd'"
on-success:
- e
e:
join: all
action: core.local
input:
cmd: "echo 'e'"
Rule 规则
Rule是映射Trigger到Action（或者Workflow），即当事件触发后，通过Rule定义的标准（Criteria）进行匹配，当匹配成功将执行Action（或者Workflow）。
Rule的定义格式：
name: "rule_name" # required
pack: "examples" # optional
description: "Rule description." # optional
enabled: true # required
trigger: # required
type: "trigger_type_ref"
criteria: # optional
trigger.payload_parameter_name1:
type: "regex"
pattern : "^value$"
trigger.payload_parameter_name2:
type: "iequals"
pattern : "watchevent"
action: # required
ref: "action_ref"
parameters: # optional
foo: "bar"
baz: "{{trigger.payload_parameter_1}}"
Audit 审计
Audit是用来跟踪和记录Action的执行细节，用于查询定位：
{
"status": "succeeded",
"start_timestamp": "2014-10-31T02:00:46.679000Z",
"parameters": {
"cmd": "ifconfig"
},
"callback": {},
"result": {
...
},
"context": {
"user": "stanley"
},
"action": "core.local",
"id": "5452ed4e0640fd6b59e75908"
}
ChatOps
ChatOps是一种新的DevOps方法，ChatOps是诞生于GitHub的一种基于会话驱动的协作开发方法，过去团队之间的通讯和开发操作是两层皮，导致各种不透明和低效率。ChatOps将开发工具带入开发者聊天室，通过定制的插件和脚本，一个聊天机器人能够执行聊天中输入的各种命令，实现在聊天平台上的团队协作开发自动化，把团队沟通和执行统一整合到一个可视化更高的聊天环境中，“聊着天就把事情办了”。
目前流行的ChatOps聊天机器人主要有Hubot（GitHub的bot，用CoffeeScript和Node.js开发）、Lita（用Ruby开发）和Err（用Python开发）三种，都是开源软件，而且可以整合到开发团队在工作中经常会使用一些聊天工具例如HipChat、Slack、Flowdock和Campfire等。
