Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20160913-IrecommendStackStormtoyou-w4yh
Search
w4yh
September 13, 2016
Technology
3
2.9k
20160913-IrecommendStackStormtoyou-w4yh
2016/9/13に行われた、【IoT x クラウド】自動化・IoTプラットフォーム StackStorm勉強会の発表資料 「古参ヲタが語る、StackStormを今推すべき理由とアレとの違い」です
w4yh
September 13, 2016
Tweet
Share
More Decks by w4yh
See All by w4yh
中(小)規模事業者のNTP運用担当としての悩みと成功体験 / 20230407 NTP Meeting LT2
w4yh
0
270
20200319-ssmjp_ResilienceEngineering
w4yh
5
1.2k
StackStormによるCloudSlang対応とはなにだったのか
w4yh
0
600
JKD18.12-2T2_Pharosでk8s環境を楽して割り切って作る / JKD1812_2T2_Pharos
w4yh
0
960
StackStorm
w4yh
1
490
StackStorm-qpstudy201604
w4yh
0
110
ChangeManagement
w4yh
0
110
Zohoを褒めたり叱ったり.pdf
w4yh
0
72
Other Decks in Technology
See All in Technology
自動テストの世界に、この5年間で起きたこと
autifyhq
10
8.6k
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
0
740
レビューを増やしつつ 高評価維持するテクニック
tsuzuki817
1
730
リアルタイム分析データベースで実現する SQLベースのオブザーバビリティ
mikimatsumoto
0
1.4k
Building Products in the LLM Era
ymatsuwitter
10
5.5k
N=1から解き明かすAWS ソリューションアーキテクトの魅力
kiiwami
0
130
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 -
kzkmaeda
2
2.1k
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
3k
データの品質が低いと何が困るのか
kzykmyzw
6
1.1k
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
220
表現を育てる
kiyou77
1
210
ハッキングの世界に迫る~攻撃者の思考で考えるセキュリティ~
nomizone
13
5.2k
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Bootstrapping a Software Product
garrettdimon
PRO
306
110k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
410
Adopting Sorbet at Scale
ufuk
74
9.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Designing for Performance
lara
604
68k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
RailsConf 2023
tenderlove
29
1k
Transcript
古参ヲタが語る、 StackStorm を今推すべき理由とアレとの違い 2016/09/13 StackStorm 勉強会 @w4yh
自己紹介 @w4yh SIer 系データセンター 運用系インフラエンジニア / 技術企画 今の持ちネタ :StackStorm, yadifa,
Rancher, holocm, Zoho API コードはほとんど書かないです ..
今日の内容 - st2 概要 - 使用例 - 歴史のおさらい - アレとの比較
- 本質的でない Tips - 今後に期待すること - まとめ
StackStorm の概要
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
StackStorm の概要 ( 構成 ) インテグレーションパック トリガー センサー ルール (YAML)
ワークフロー (YAML) アクション (X,YAML) 公式サイトより https://docs.stackstorm.com/overview.html “ トリガーベースの IT 運用向け自動化ワークフロープラットフォーム”
StackStorm の概要 (Pack) IaaS 監視 / 運用 CM データソース 通知
CI/CD 一覧は以下サイトにて https://github.com/StackStorm/st2contrib
StackStorm の概要 標準の WebUI Action, Rule などの 参照&編集ができる ちょっと物足りない?
StackStorm 使用例
StackStorm 使用例 私 ( データセンター運用 ) の動機 , 課題 1)
複数のホストをまたぐスクリプト処理が 秘伝のタレ化していて整理したかった 2) 開発部門はフレームワークやコーディング規 則がある ( はず ) が、運用部門のスクリプトは方 式 , 品質ともバラバラだった
StackStorm 使用例 今回の環境 CentOS7.2 + StackStorm 1.6.0 KAGOYA Japan さんカゴヤクラウド
/VPS HDD モデル タイプ B (Mem 2G/4G) CentOS7 最小インストール -yum install sudo が事前に必要な以外は 手順通りでインストール OK - タイプ A(Mem 1G/2G) ではインストールが完了できず
StackStorm 使用例 • まずは Hello World
StackStorm 使用例 • 監視検知時に実行 Web サーバーのエラー検知 テストケース実施 LB を操作して再接続 LB
を操作して切り離し restart などサーバー一時対応
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
StackStorm 使用例 ( 参考 ) “Stackstorm: from Nagios integration to
Openstack automation” https://stackstorm.com/2016/01/06/ stackstorm-nagios-integration-openstack-automation/
StackStorm 使用例 • ジョブ連動 Web,AP 停止 rsync 開始 DB 停止
DB dump 開始 DB 起動 テスト AP,Web 起動
StackStorm の歴史 ( おさらい )
StackStorm の歴史 ( おさらい ) Co-founder -CEO: Evan Powell 氏
-Dmitri Zimine 氏 元 Opalis の Chief Architect -MS に買収されて SystemCenter に統合されている
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 公開
StackStorm の歴史 ( おさらい ) ドキュメントの急速な整備! v1.2 の頃まではちょいちょい 「工事中」ページがあった (
左図は v1.2 の Install using Chef の項 ) →v1.5 頃から工事中ページはなくなり、 手順などの内容のバグもほぼ無くなった
StackStorm の歴史 ( おさらい ) インストーラーがようやく安定した! Scripted Installer st2_deploy.sh →”All-In-One
Installer” install.shの登場&推奨 (v0.13でbeta, 1.0で正式) →AOIよく止まるよね テヘッ →st2bootstrap-deb.sh →AOI廃止 (v1.4) パッケージへ
StackStorm の歴史 ( おさらい ) インストール方法も安定した! ドキュメントも整備された! →始めるなら今がチャンス!!
アレと StackStorm の比較
アレと StackStorm の比較 StackStorm を導入しよう!といった場合 にありがちなリアクション 「また”なんとかスタック”?」 「既存のアレでできないの?」
アレと StackStorm の比較 • 入力 処理 出力 古典的なソフトウェアの構成 st2 のコアエンジンは
この”処理”部分に該当 UI/UX データストア
アレと StackStorm の比較 • 入力 処理 出力 そういえば今日は【 IoT× クラウド】だった
フィルタリング ビジネスロジック バックエンド選択 IoT デバイス、センサー IoT API 、コントロール クラウド メトリクス、メッセージ クラウド API 、コントロール Ansible や マクロ的自動化ツール
アレと StackStorm の比較 • 処理 フィルタリング ビジネスロジック バックエンド選択 ・運用のジョブマネージャー ・クラウドのイベントドリブン
・ビッグデータのワークフロー 求められているものは近い? 他ノード化、分散処理化で 繋ぎ役、繋ぎ方が重要?
アレと StackStorm の比較 (参考) StackStorm のワークフロー形式 ・ActionChain 単純直列なものはこれで。速い ・ Mistral
OpenStack のアレ 分岐/合流とかある場合はこれ ・CloudSlang by HPE(?) 最近追加された。今も experimental YAML ベースだが複雑なものも書ける CloudSlang の公開WFが使える
以下、様々な比較を ( ここで時間調整 ..)
ファイル監視と StackStorm の比較 例 : tripwire IMAP(sgi_fam, gamin, inotify)
・ローカル限定 ・スクリプト呼び出し ( ワンライナー )
SNMPtrap と StackStorm の比較 SNMPTrap Handler で特定の trap 受信時に コマンドやスクリプトを実行
・基本的に MIB OID による指定 ・ワンライナー ・ ( 肝心な時に trap が来ない )
それ Pla! と StackStorm の比較 例 : Plagger, Y! Pipes
・ RSS の更新をトリガーにして起動 ・” RSS マーケティング”と言われた時代も ・技術的エッセンスはほぼ同じ st2 はトリガーソースが多様 個人的には Plagger 大好きです。 Publish::TAKAHASHI!
Zabbix と StackStorm の比較 例 : Action Script 、 Custom
Alert Script ・監視エラー時や閾値超過時に実行 ・監視の初動対応 (Day2 Ops) としては同じ ・変数の埋め込みもできるので便利 ・ st2 とは連携対象、の関係
ジョブマネージャと StackStorm の比較 例 : JP1/OV 、 Tivoli 、 SystemWalker
etc.. ・無理に入れ替える理由は無いです ・経緯的にややバッチ向け 規定時間内のジョブの完了 , 途中再開 ・ st2 の強みはトリガーベースや拡張性?
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/
Bigdata WF と StackStorm の比較 例 : Digdag ・分散処理の管理には簡単に書ける Digdag
Good! ・ Digdag もプラットフォーム志向なので連携拡張できそう ・ループ処理やトリガーの種類が棲み分けポイント? Workflow Hacks! アンケート「何でワークフローを書きたいか?」に 私は st2 Enterprise を念頭に「 GUI 」に手を挙げました
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 良いですよね ・特定のクラウドに閉じているシステムならそのサービスを活用すべき ・敢えてあげるなら クラウドしかない、対応言語などの制約、コミュニティノイズ
ifttt と StackStorm の比較 例 : ifttt 、 Zapier ・利用シーンの違い
(st2 は運用向け ) ・特に Zapier はメール連携もできるので 拡張性も高い ・上記サービスはクラウドのみ ・ Webhook がもっと広まればいいのに ・ st2 と連携も可能
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 が多い
XXX と StackStorm の比較 注 ) 銀の弾丸は無い 優越ではなく機能や利用シーンの違い 手に合うツールを選べば OK
st2 は繋ぎ役なので、共存もできるはず
StackStorm 運用時の ( 本質的でない )Tips
StackStorm 運用時の Tips (1) メールの処理を外に出す eMail Pack(IMAP,SMTP) があるが 日本語メール処理問題 件名の
JIS とかを UTF8 の YAML に マッチ条件を書くとかツラい
StackStorm 運用時の Tips st2 サーバー上に Sylpheed を EPEL からインストールして、 仕分け設定アクションで
コマンドを指定 Human readable な設定 分かりやすい reboot 時の stanley ユーザーの Sylpheed 起動のスマートな方法が まだ定まっていない
StackStorm 運用時の Tips (2)MQ…. 動いてるけど追加 / 書き込みできない →ほぼ RabbitMQ の障害
お約束の rabbitmq-server -detached ダメな場合は rabbitmqctl reset とか stop_app とか
StackStorm 運用時の Tips (3)StackStorm を監視する ( できるとは言ってない ) 内部監視 :
プロセス、ポート 外部監視 : WebUI 、ダミージョブのログ
st2ctl status の出力例 その他の関係プロセス: rabbitmq mongod postgres gunicorn nginx 真面目に監視すると項目がかなり多い
…外部監視に集約する手もあるかも …冗長時の health check も考慮が必要
( 参考 : 公式サイトの HA Deploy ガイド ) nginx(proxy) で
振り分けを行い、 action runner など 個別処理を振り分ける fork のような形で action runner 側を stateless っぽく 構成している
StackStorm 運用時の Tips 雑に作ると中央集権な SPOF になりやすい stanley の ssh
鍵を ssh-copy-id して ansible や serverspec もキックするとか (st2 run core.remote も stanley(st2.conf 内の system_user) で実行される ) itamae local 等の (chef-solo 的な ) コマンドで S3 のようなレ ポジトリから落としたレシピを実行する自立的な構成も検討
StackStorm 運用時の Tips SPOF な構成 自立型
StackStorm 運用時の Tips 参考 : Netflix の Winston http://techblog.netflix.com /2016/08/introducing-winston
-event-driven.html
今後に期待すること
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 のロゴを貼ったのはほんとすまんかった
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.
Brocade さんに期待すること 敷居を下げる ・サンプルユースケースの追加 CloudSlang のサンプルとか良さそう ・ Automation Happy
Hour(Webinar) の再開 ・デプロイ方法の簡略化 AMI などのイメージ提供 (v0.12.2 まで有った ) ・いっそ SaaS 化?
Community に期待すること 日本でハネるには足りない Pack が ・ Zabbix ( 内部変数多すぎて大変? )
・ Serverspec ( 実質 rake コマンドだから難しい? ) ・ itamae 何よりまずは使ってみましょう!
まとめ
課題は解決したのか 1) 複数のホストをまたぐスクリプト処理が 秘伝のタレ化していて整理したかった →ワークフローによる制御で YAML 化され 読みやすさ、書式の統一感も達成できそう 処理やノードを跨いで変数を渡せるのも大きい •
2) 開発部門はフレームワークやコーディング規則があるが、 運用部門のスクリプトは方式 , 品質ともバラバラだった → Pack があるものは Pack の機能で対応できる スクリプト呼び出しや run では自作スクリプトが残るので、 さらなる Pack 化でフレームワークとして定着させたい
さらなるバリュー 気付き : 自動化を行うと「よく気がつく人」 という属人依存をあぶりだしてテストの精度 向上が進んだりする 検討中 : 障害時の対応を自動化できるのであ れば”頻繁に小さく対応する”ように閾値を安
定値近傍で設定しても良いのでは?
さらなるバリュー テスト重要 grep 先ファイルが無く メッセージが出ているが status:succeeded failed: false
情報源 (Slack) ・ Invite フォーム https://stackstorm.typeform.com/to/K76GRP ・ Stackstorm-Community
https://stackstorm-community.slack.com/ ・アーカイブ https://stackstorm-community.slack.com/archives/community/
情報源 ( 直近のイベント NFD12) https://stackstorm.com/2016/08/2 3/summary-brocade-workflow- composer-nfd-12/ Dmitri さんが説明している動画も
情報源 ( 直近のイベント NFD12)
今日の差し入れ 圓 ( 六調子酒造 ) 長期貯蔵の米焼酎 (40 度 )