StackStorm Workflowの設計

1. INTERNET MULTIFEED CO.Copyright ©
StackStorm Workflowの設計
Shu Sugimoto
Software Development Manager, JPNAP
2019-04-24(Wed)

2. INTERNET MULTIFEED CO.Copyright ©
今日のサマリー
• StackStormのWorkflowは柔軟でパワフル
• 柔軟であるからこそ、しっかりと設計しておこう
• JPNAP/MFでのこれまでの経験から見えた、st2 Workflowを考え
るときに意識するべきポイントを3つ紹介
• 1. 目的を意識して、Packの振り分けをしよう
• 2. 複数の環境で動かせるように、WorkflowのParameterを
定義しておこう
• 3. Workflowのコア部分と、付帯的な部分を極力分離出来る
ようにしよう
2

3. INTERNET MULTIFEED CO.Copyright ©
おさらい：Packの種類
• Packはその性質から2種類に大別される
• [ ]
•
• [ ]
3

4. INTERNET MULTIFEED CO.Copyright ©
おさらい：Packの種類
• Packはその性質から2種類に大別される
• Integration Pack
• ある特定のアプリケーション・プロダクトに特化した
Action/Workflow/etc.をまとめたもの
• stackstorm-exchangeにあるものは(ほぼ?)全てこれに該当
• Automation Pack
• ある特定の業務フローを自動化するWorkflowを含むもの
• Integration PackのActionを組み合わせてWorkflowを組み立て
るのが典型的なパターン
• https://docs.stackstorm.com/packs.html
• 名前に違いはあるが、st2から見たときはどちらも全く同じよう
に扱われる
4

5. INTERNET MULTIFEED CO.Copyright © 5
🤔
(この業務フローを自動化したい…)
システムX システムY
get A
get P
do B
get Q
do R
とある業務フロー

6. INTERNET MULTIFEED CO.Copyright ©
パズル
6
Pack: [ ] Pack: [ ] Pack: [ ]
Action:
get.A
Action:
do.B
Action:
get.P
Action:
get.Q
Action:
do.R
Workflow:
run_task

7. INTERNET MULTIFEED CO.Copyright ©
パズル
7
Pack: X Pack: Y Pack: hoge
Action:
get.A
Action:
do.B
Action:
get.P
Action:
get.Q
Action:
do.R
Workflow:
run_task
Integration Pack Automation Pack

8. INTERNET MULTIFEED CO.Copyright ©
Packの分離設計
• 実装しているWorkflow/Actionが、特定のシステムを対象として
いるかどうか考える
• もしそうであれば、そのシステムを対象とした
Action/Workflowをまとめて1つのPackにしてあげる
→ Integration Pack
• 実装しているWorkflowが、複数のシステムを連携させてなにか
の業務フローを自動化している
• その業務フローをまとめる単位で、1つのPackにまとめてあ
げる
→ Automation Pack
8

9. INTERNET MULTIFEED CO.Copyright © 9
🤔
(商用環境とステージング環境の両方で使いたい…)
とある業務フローを自動化したWorkflow
Production Staging

10. INTERNET MULTIFEED CO.Copyright ©
Workflow/Actionのパラメータ設計
• 各システムがlab/staging/productionを持つことを考慮して、
Parameterを外部からセット出来るようにする
• 環境毎に異なる値をとり得るものは、全てパラメータ化して
おく
• 例えば、接続先サーバーのホスト名とか
• 関数で言うところの引数
• Action metadataにParameterを定義して、default値にPack
config/st2kvのキーをセットする
10

11. INTERNET MULTIFEED CO.Copyright ©
Pack configとst2kv
• Pack config
• Pack毎に定義する
• スキーマがある
• どんなパラメータがあるか、や、型の定義、そのパラメータの説明
等を含めることが出来る
• DevOps可能
• Packとは切り離してSCM管理/CDが出来る
• Configの値の参照先としてst2kvを指定することも可能
• ただしこの場合、入れられるのは文字列型だけになる
• st2kvに入れる場合は暗号化可能
• Action metadataからはアクセスできるが、Workflow内からは
アクセス出来ない
• Python actionからは直接参照出来る
• Workflow内で使いたい場合、Parameterで渡してあげる必要があ
る
• 厳密に言うとpython-script runner以外はmetadataから
Parameter渡しが必要
• 他のPackのconfigは(簡単には)参照出来ない
11

12. INTERNET MULTIFEED CO.Copyright ©
Pack configとst2kv
• st2kv
• keyは自由に設定可能
• スキーマレス
• ドキュメントがないと、コードを見ないとどこでどういうキー
が使われているか分からなくなる
• valueには文字列しか入らない
• DevOps可能
• Pack configよりは強引な方法だが、可能といえば可能
• APIを直接叩いてどうにかする感じ
• 暗号化可能
• Action metadataからもWorkflow内からも直接アクセス出来
る
12

13. INTERNET MULTIFEED CO.Copyright ©
Pack configとst2kv、どう使うべき？
• 戦略1: すべてst2kvでやる
• 最もシンプル
• README.mdでパラメータ一覧を別に管理する必要あり
• 更新忘れを機械的に防ぐ手法がない
• 戦略2: すべてPack configでやる
• 暗号化が使えない
• config更新がちょっと面倒
• st2kvの場合、st2 keyコマンドで簡単にできるが、configはファイ
ル作らないといけない
• CDでしか変えないなら問題にはならないが…
• 戦略3: Pack configでパラメータを定義し、値はすべてst2kvに入れ
るハイブリッド
• パラメータはconfig schemaで管理出来る
• 初期configの登録だけちょっと面倒
• Pack単体のCDでは完結させることが出来ない
• 新しいパラメータを追加したときのデプロイフロー未確立
13

14. INTERNET MULTIFEED CO.Copyright ©
Pack configとst2kv、どう使うべき？
• いろいろな戦略があるが、どれも一長一短なので自分にあったや
つを選びましょう
• st2kvの使い方について留意しておくべきこと
• Workflow内で直接st2kvを参照するときは、一時的に保管す
るデータ、TTL付きのデータのみにとどめておく
• もしそうでない場合、それは恐らく高確率でParameter化し
てAction metadataから渡してあげたほうが良いもの
14

15. INTERNET MULTIFEED CO.Copyright © 15
🤔
(このWorkflowの開始・終了時にSlackに通知を送りたい…)
とある業務フローを自動化したWorkflow

16. INTERNET MULTIFEED CO.Copyright ©
Workflowの開始・終了を通知する方法
• 1. Workflowの一番最初と最後に slack.chat.postMessage を
突っ込む
• 一番最初に思いつく、最も簡単かつシンプルな方法
• しかしこれは後々で確実につらくなる
16

17. INTERNET MULTIFEED CO.Copyright ©
Workflowの開始・終了を通知する方法
• 「1. Workflowの一番最初と最後に slack.chat.postMessage を
突っ込む」の、ダメなところ
• ビジネスロジックとは関係のないActionがWorkflowに混ざり、
見通しが悪くなる
• 同じく、関係ないパラメータが混ざり、混乱を招く
• Slackに投稿するために必要なtokenやchannel名等は、本来そ
のワークフローの責務の範疇外の値のはず
• ビジネスロジックの外の影響を、そのワークフローが受けて
しまう
• 「HipChatに変えました」→この全く関係のない変更により、
Workflowを全て書き換える必要がある
17

18. INTERNET MULTIFEED CO.Copyright ©
Workflowの開始・通知を終了する 改善版
• 2. Triggerを使う
• st2 -> IFTTT
• Workflowの開始時/終了時にtriggerを出すことが出来る
• st2.generic.actiontrigger
• st2.confの[action_sensor]のemit_whenに、いつtriggerを発
火させるか指定可能
• ここで`scheduled`を追加指定すると、Action/Workflow
がスケジュールされた際、つまり開始時にtriggerを発火で
きる
• これを使って、通知用のルールからWorkflowをキックしてあげ
る
• ※なぜnotifytriggerじゃないのか？
• →開始時のフックが出来ないから
18

19. INTERNET MULTIFEED CO.Copyright © 19
# 該当workflowを追加する時はこのruleのpatternを変更
name: start_workflow
description: Kick the notification workflow when specific workflow starts.
enabled: true
trigger:
type: core.st2.generic.actiontrigger
criteria:
trigger.action_ref:
type: inside
pattern:
- jpnap_scg.deploy_scdb
- jpnap_scg.register_ml
- jpnap_scg.publish_web
- jpnap_scg.deploy_mac_ip_table
- jpnap_scg.peerwatcher_dataclean
- jpnap_rfeed.add_rfeed_peer
- jpnap_rfeed.remove_rfeed_peer
- jpnap_neko.create_mac_acl
- jpnap_neko.delete_mac_acl
- jpnap_neko.modify_mac_acl_dual
- jpnap_tests.test.ask_to_proceed.example2
- jpnap_tests.finish_workflow_with_snippet.mistral
- jpnap_tests.finish_workflow_with_snippet.orquesta
trigger.status:
type: equals
pattern: scheduled
action:
ref: jpnap_common.start_workflow
parameters:
execution_id: "{{ trigger.execution_id }}"
target_name: "{{ trigger.action_name }}"
# ruleごとに通知先channelを指定する
notify_channel: "{{ st2kv.system.jpnap_common.config.slack.wf_notify.start_finish }}"

20. INTERNET MULTIFEED CO.Copyright ©
今日のサマリー (再掲)
• StackStormのWorkflowは柔軟でパワフル
• 柔軟であるからこそ、しっかりと設計しておこう
• JPNAP/MFでのこれまでの経験から見えた、st2 Workflowを考え
るときに意識するべきポイントを3つ紹介
• 1. 目的を意識して、Packの振り分けをしよう
• 2. 複数の環境で動かせるように、WorkflowのParameterを
定義しておこう
• 3. Workflowのコア部分と、付帯的な部分を極力分離出来る
ようにしよう
20