Slide 1
Slide 1 text
古参ヲタが語る、
StackStorm を今推すべき理由とアレとの違い
2016/09/13
StackStorm 勉強会
@w4yh
Slide 2
Slide 2 text
自己紹介
@w4yh
SIer 系データセンター
運用系インフラエンジニア / 技術企画
今の持ちネタ :StackStorm, yadifa,
Rancher, holocm, Zoho API
コードはほとんど書かないです ..
Slide 3
Slide 3 text
今日の内容
- st2 概要
- 使用例
- 歴史のおさらい
- アレとの比較
- 本質的でない Tips
- 今後に期待すること
- まとめ
Slide 4
Slide 4 text
StackStorm の概要
Slide 5
Slide 5 text
StackStorm の概要
・「 Web 界の ifttt を運用に持ってきた」
・「自動化＋自動復旧 (auto re-mediation) 」
「 Day0 ～ Day2 Operation 」
・フリーミアムな提供形態
https://github.com/StackStorm/st2
Apache License Version 2.0
・最新は 8/31 リリースの Ver. 2.0.0
Slide 6
Slide 6 text
StackStorm の概要 ( 構成 )
インテグレーションパック
トリガー
センサー
ルール (YAML)
ワークフロー (YAML)
アクション (X,YAML)
公式サイトより
https://docs.stackstorm.com/overview.html
“ トリガーベースの IT 運用向け自動化ワークフロープラットフォーム”
Slide 7
Slide 7 text
StackStorm の概要 (Pack) IaaS
監視 / 運用
CM
データソース 通知
CI/CD
一覧は以下サイトにて
https://github.com/StackStorm/st2contrib
Slide 8
Slide 8 text
StackStorm の概要
標準の WebUI
Action, Rule などの
参照＆編集ができる
ちょっと物足りない？
Slide 9
Slide 9 text
StackStorm 使用例
Slide 10
Slide 10 text
StackStorm 使用例
私 ( データセンター運用 ) の動機 , 課題
1) 複数のホストをまたぐスクリプト処理が
秘伝のタレ化していて整理したかった
2) 開発部門はフレームワークやコーディング規
則がある ( はず ) が、運用部門のスクリプトは方
式 , 品質ともバラバラだった
Slide 11
Slide 11 text
StackStorm 使用例
今回の環境
CentOS7.2 + StackStorm 1.6.0
KAGOYA Japan さんカゴヤクラウド /VPS
HDD モデル タイプ B (Mem 2G/4G)
CentOS7 最小インストール
-yum install sudo が事前に必要な以外は
手順通りでインストール OK
- タイプ A(Mem 1G/2G) ではインストールが完了できず
Slide 12
Slide 12 text
StackStorm 使用例
• まずは Hello World
Slide 13
Slide 13 text
StackStorm 使用例
• 監視検知時に実行
Web サーバーのエラー検知
テストケース実施
LB を操作して再接続
LB を操作して切り離し
restart などサーバー一時対応
Slide 14
Slide 14 text
StackStorm 使用例
• 監視検知時に実行
---
version: '2.0'
e_nagios.remediate_web_workflow:
type: direct
input:
- hostname
- res_code
tasks:
lets_work:
# [466, 27]
action: chatops.post_message
input:
channel: <% $.channel %>
message: "trying
to take care of the web server status issue on <% $.hostname %>"
on-success:
- check_web
check_web:
# [289, 149]
action: e_nagios.check_web
input:
hosts: <% $.hostname %>
res_code: <% $.res_code %>
on-success:
- hubot_error
on-error:
- remediate
remediate:
# [489, 233]
action: e_nagios.web_remediate
input:
hosts: <% $.hostname %>
on-success:
- check_web_full
on-error:
- hubot_mes_fail
Slide 15
Slide 15 text
StackStorm 使用例
( 参考 )
“Stackstorm: from Nagios integration
to Openstack automation”
https://stackstorm.com/2016/01/06/
stackstorm-nagios-integration-openstack-automation/
Slide 16
Slide 16 text
StackStorm 使用例
• ジョブ連動
Web,AP 停止
rsync 開始
DB 停止
DB dump 開始
DB 起動
テスト
AP,Web 起動
Slide 17
Slide 17 text
StackStorm の歴史 ( おさらい )
Slide 18
Slide 18 text
StackStorm の歴史 ( おさらい )
Co-founder
-CEO: Evan Powell 氏
-Dmitri Zimine 氏
元 Opalis の Chief Architect
-MS に買収されて SystemCenter
に統合されている
Slide 19
Slide 19 text
StackStorm の歴史 ( おさらい )
2014/11 v0.5 公開
2015/03 v0.8.0 公開
2015/09 Cassandra Summit で 1.0 公開
Netflix の事例、 Enterprise 版
2016/03 Brocade による買収
2016/08 v2.0.0 公開
Slide 20
Slide 20 text
StackStorm の歴史 ( おさらい )
ドキュメントの急速な整備！
v1.2 の頃まではちょいちょい
「工事中」ページがあった
( 左図は v1.2 の Install using Chef の項 )
→v1.5 頃から工事中ページはなくなり、
手順などの内容のバグもほぼ無くなった
Slide 21
Slide 21 text
StackStorm の歴史 ( おさらい )
インストーラーがようやく安定した！
Scripted Installer st2_deploy.sh
→”All-In-One Installer” install.shの登場＆推奨
(v0.13でbeta, 1.0で正式)
→AOIよく止まるよね テヘッ
→st2bootstrap-deb.sh
→AOI廃止 (v1.4) パッケージへ
Slide 22
Slide 22 text
StackStorm の歴史 ( おさらい )
インストール方法も安定した！
ドキュメントも整備された！
→始めるなら今がチャンス！！
Slide 23
Slide 23 text
アレと StackStorm の比較
Slide 24
Slide 24 text
アレと StackStorm の比較
StackStorm を導入しよう！といった場合
にありがちなリアクション
「また”なんとかスタック”？」
「既存のアレでできないの？」
Slide 25
Slide 25 text
アレと StackStorm の比較
•
入力 処理 出力
古典的なソフトウェアの構成
st2 のコアエンジンは
この”処理”部分に該当
UI/UX
データストア
Slide 26
Slide 26 text
アレと StackStorm の比較
•
入力 処理 出力
そういえば今日は【 IoT× クラウド】だった
フィルタリング
ビジネスロジック
バックエンド選択
IoT
デバイス、センサー
IoT
API 、コントロール
クラウド
メトリクス、メッセージ
クラウド
API 、コントロール
Ansible や
マクロ的自動化ツール
Slide 27
Slide 27 text
アレと StackStorm の比較
•
処理
フィルタリング
ビジネスロジック
バックエンド選択
・運用のジョブマネージャー
・クラウドのイベントドリブン
・ビッグデータのワークフロー
求められているものは近い？
他ノード化、分散処理化で
繋ぎ役、繋ぎ方が重要？
Slide 28
Slide 28 text
アレと StackStorm の比較
(参考) StackStorm のワークフロー形式
・ActionChain
単純直列なものはこれで。速い
・ Mistral
OpenStack のアレ
分岐/合流とかある場合はこれ
・CloudSlang by HPE(?)
最近追加された。今も experimental
YAML ベースだが複雑なものも書ける
CloudSlang の公開WFが使える
Slide 29
Slide 29 text
以下、様々な比較を
( ここで時間調整 ..)
Slide 30
Slide 30 text
ファイル監視と StackStorm の比較
例 : tripwire
IMAP(sgi_fam, gamin, inotify)
・ローカル限定
・スクリプト呼び出し ( ワンライナー )
Slide 31
Slide 31 text
SNMPtrap と StackStorm の比較
SNMPTrap Handler で特定の trap 受信時に
コマンドやスクリプトを実行
・基本的に MIB OID による指定
・ワンライナー
・ ( 肝心な時に trap が来ない )
Slide 32
Slide 32 text
それ Pla! と StackStorm の比較
例 : Plagger, Y! Pipes
・ RSS の更新をトリガーにして起動
・” RSS マーケティング”と言われた時代も
・技術的エッセンスはほぼ同じ
st2 はトリガーソースが多様
個人的には Plagger 大好きです。 Publish::TAKAHASHI!
Slide 33
Slide 33 text
Zabbix と StackStorm の比較
例 : Action Script 、 Custom Alert Script
・監視エラー時や閾値超過時に実行
・監視の初動対応 (Day2 Ops) としては同じ
・変数の埋め込みもできるので便利
・ st2 とは連携対象、の関係
Slide 34
Slide 34 text
ジョブマネージャと StackStorm の比較
例 : JP1/OV 、 Tivoli 、 SystemWalker etc..
・無理に入れ替える理由は無いです
・経緯的にややバッチ向け
規定時間内のジョブの完了 , 途中再開
・ st2 の強みはトリガーベースや拡張性？
Slide 35
Slide 35 text
CI と StackStorm の比較
例: Jenkins
・”Continuous Integration And Delivery, The StackStorm Way”
https://stackstorm.com/2015/01/20/continuous-integration-and-delivery-
the-stackstorm-way/
・既存のJenkinsがうまく動いていればそれでOK
・Dev: Jenkins 、Ops: StackStorm 、 DevOps: ?
・Packがあるので連携可能
・詰め込みすぎたり無理させていたら検討しては
例 : ダミーファイルのコミットで運用ジョブを起動
参考: http://rebuild.fm/152/
Slide 36
Slide 36 text
Bigdata WF と StackStorm の比較
例 : Digdag
・分散処理の管理には簡単に書ける Digdag Good!
・ Digdag もプラットフォーム志向なので連携拡張できそう
・ループ処理やトリガーの種類が棲み分けポイント？
Workflow Hacks! アンケート「何でワークフローを書きたいか？」に
私は st2 Enterprise を念頭に「 GUI 」に手を挙げました
Slide 37
Slide 37 text
FaaS と StackStorm の比較
例: AWS Lambda, Google Cloud Functions, OpenWhisk, Azure Functions
・”StackStorm vs. AWS Lambda: Event-Driven Computing vs. Event-
Driven Operations”
https://stackstorm.com/2014/11/20/stackstorm-vs-aws-lambda-event-driven-
computing-vs-event-driven-operations/
・AWS Lambda 良いですよね
・特定のクラウドに閉じているシステムならそのサービスを活用すべき
・敢えてあげるなら
クラウドしかない、対応言語などの制約、コミュニティノイズ
Slide 38
Slide 38 text
ifttt と StackStorm の比較
例 : ifttt 、 Zapier
・利用シーンの違い (st2 は運用向け )
・特に Zapier はメール連携もできるので
拡張性も高い
・上記サービスはクラウドのみ
・ Webhook がもっと広まればいいのに
・ st2 と連携も可能
Slide 39
Slide 39 text
RBA と StackStorm の比較
例 : Rundeck
・一番かぶってるのはここかも
・” How StackStorm “Stacks” Against The Competiton”
https://stackstorm.com/2014/11/03/stackstorm-vs-other-
software/#more-1333
・ st2 は Sensor によって対応できるトリガーが
広くなっている、と主張している (2014/11)
・プラグイン数は 201608 時点では st2 が多い
Slide 40
Slide 40 text
XXX と StackStorm の比較
注 ) 銀の弾丸は無い
優越ではなく機能や利用シーンの違い
手に合うツールを選べば OK
st2 は繋ぎ役なので、共存もできるはず
Slide 41
Slide 41 text
StackStorm 運用時の
( 本質的でない )Tips
Slide 42
Slide 42 text
StackStorm 運用時の Tips
(1) メールの処理を外に出す
eMail Pack(IMAP,SMTP) があるが
日本語メール処理問題
件名の JIS とかを UTF8 の YAML に
マッチ条件を書くとかツラい
Slide 43
Slide 43 text
StackStorm 運用時の Tips
st2 サーバー上に Sylpheed を
EPEL からインストールして、
仕分け設定アクションで
コマンドを指定
Human readable な設定
分かりやすい
reboot 時の stanley ユーザーの
Sylpheed 起動のスマートな方法が
まだ定まっていない
Slide 44
Slide 44 text
StackStorm 運用時の Tips
(2)MQ….
動いてるけど追加 / 書き込みできない
→ほぼ RabbitMQ の障害
お約束の rabbitmq-server -detached
ダメな場合は rabbitmqctl reset とか stop_app とか
Slide 45
Slide 45 text
StackStorm 運用時の Tips
(3)StackStorm を監視する
( できるとは言ってない )
内部監視 : プロセス、ポート
外部監視 : WebUI 、ダミージョブのログ
Slide 46
Slide 46 text
st2ctl status の出力例
その他の関係プロセス：
rabbitmq
mongod
postgres
gunicorn
nginx
真面目に監視すると項目がかなり多い
…外部監視に集約する手もあるかも
…冗長時の health check も考慮が必要
Slide 47
Slide 47 text
( 参考 : 公式サイトの HA Deploy ガイド )
nginx(proxy) で
振り分けを行い、
action runner など
個別処理を振り分ける
fork のような形で
action runner 側を
stateless っぽく
構成している
Slide 48
Slide 48 text
StackStorm 運用時の Tips
雑に作ると中央集権な SPOF になりやすい
stanley の ssh 鍵を ssh-copy-id して
ansible や serverspec もキックするとか
(st2 run core.remote も
stanley(st2.conf 内の system_user) で実行される )
itamae local 等の (chef-solo 的な ) コマンドで S3 のようなレ
ポジトリから落としたレシピを実行する自立的な構成も検討
Slide 49
Slide 49 text
StackStorm 運用時の Tips
SPOF な構成 自立型
Slide 50
Slide 50 text
StackStorm 運用時の Tips
参考 : Netflix の Winston
http://techblog.netflix.com
/2016/08/introducing-winston
-event-driven.html
Slide 51
Slide 51 text
今後に期待すること
Slide 52
Slide 52 text
Brocade さんに期待すること
このまま順調な開発を！
2016/03/29 買収発表
2016/04/20 v1.4 リリース
2016/06/27 v1.5 リリース
2016/08/10 v1.6 リリース
2016/08/31 v2.0 リリース
買収発表後に Powell さんが Community Slack に降臨した時に
無言で VyOS のロゴを貼ったのはほんとすまんかった
Slide 53
Slide 53 text
Brocade さんに期待すること
• 興味深い FAQ
https://stackstorm.com/2016/04/11/broc
ade-acquisition-faq/
Q: Did you consider open-sourcing Flow,
or other proprietary StackStorm components?
A: We are considering doing so as part of broader decision of
what is included in commercial offering,
but a decision haven’t been made yet, so we don’t know.
Slide 54
Slide 54 text
Brocade さんに期待すること
敷居を下げる
・サンプルユースケースの追加
CloudSlang のサンプルとか良さそう
・ Automation Happy Hour(Webinar) の再開
・デプロイ方法の簡略化
AMI などのイメージ提供 (v0.12.2 まで有った )
・いっそ SaaS 化？
Slide 55
Slide 55 text
Community に期待すること
日本でハネるには足りない Pack が
・ Zabbix ( 内部変数多すぎて大変？ )
・ Serverspec ( 実質 rake コマンドだから難しい？ )
・ itamae
何よりまずは使ってみましょう！
Slide 56
Slide 56 text
まとめ
Slide 57
Slide 57 text
課題は解決したのか
1) 複数のホストをまたぐスクリプト処理が
秘伝のタレ化していて整理したかった
→ワークフローによる制御で YAML 化され
読みやすさ、書式の統一感も達成できそう
処理やノードを跨いで変数を渡せるのも大きい
• 2) 開発部門はフレームワークやコーディング規則があるが、
運用部門のスクリプトは方式 , 品質ともバラバラだった
→ Pack があるものは Pack の機能で対応できる
スクリプト呼び出しや run では自作スクリプトが残るので、
さらなる Pack 化でフレームワークとして定着させたい
Slide 58
Slide 58 text
さらなるバリュー
気付き : 自動化を行うと「よく気がつく人」
という属人依存をあぶりだしてテストの精度
向上が進んだりする
検討中 : 障害時の対応を自動化できるのであ
れば”頻繁に小さく対応する”ように閾値を安
定値近傍で設定しても良いのでは？
Slide 59
Slide 59 text
さらなるバリュー
テスト重要
grep 先ファイルが無く
メッセージが出ているが
status:succeeded
failed: false
Slide 60
Slide 60 text
情報源 (Slack)
・ Invite フォーム
https://stackstorm.typeform.com/to/K76GRP
・ Stackstorm-Community
https://stackstorm-community.slack.com/
・アーカイブ
https://stackstorm-community.slack.com/archives/community/
Slide 61
Slide 61 text
情報源 ( 直近のイベント NFD12)
https://stackstorm.com/2016/08/2
3/summary-brocade-workflow-
composer-nfd-12/
Dmitri さんが説明している動画も
Slide 62
Slide 62 text
情報源 ( 直近のイベント NFD12)
Slide 63
Slide 63 text
今日の差し入れ
圓 ( 六調子酒造 )
長期貯蔵の米焼酎 (40 度 )