StackStorm勉強会 第2回に行ってきました
※発表内のカット部分が判明したり資料が公開されたりした場合は後ほど修正します
3月23日に行われたStackStorm勉強会 第2回に行ってきました。第1回から約半年、他のイベントでもStackStormの名前を見る機会が出てきたので広まりを感じられるかな...と楽しみにしていました。
"Event-driven automation, DevOps way" by Dmitri Zimine氏
ついにご本人に会えました。背も高くて足も長い方でした。
発表内容は、過去のこちらのプレゼンから技術的に細かい部分を省いた感じだったかなと思います。
www.slideshare.net
(4/1追記。資料公開されました)
(まさかDmitriさんから「日本でStackStormを検索すると芸能的な情報が出てくる」ネタを聞くとは..
cf. http://w4yh.hatenablog.com/entry/2016/09/22/104100 )
他のツールとの違いについての話もあり、「DevOpsに最適である」ことが強調されていました。過去のツールやプロプライエタリなソフトウェアと比較して、コードベースのスピーディーな運用を可能とするインターフェースと拡張性で勝る、という説明はなるほどと感じました。
最後にGitHub Starつけろよ、という念押しもありましたので参加されたみなさまはお忘れなく。
Q&A
Q.ST2と一緒に使われることが多いソフトウェアは？
A.モニタリングソフトが代表(Zabbix, Sensu, Nagios, NewRelic)
OSSに限らず、商用ソフトやクラウドサービスも多い(IaaS系に限らず、PagerDutyとか)
補足.でもZabbixのPackはまだ無いですけどね
Q.ワークフローの例がたくさんあると良いのだがそんなサイトはあるか
A.まとまったものは無いが、公式Docのチュートリアルの中でも紹介している。最近はNetworkの例を2つ公開した
Q.商用のBWC(brocade Workflow Conmposer)の売りは？
A.サポートが付くこと、ビジュアル的なワークフロー作成画面が付くことなど
if 自動化するなら then StackStormを使おう！ by 小島さん
200機種、30000台を超える規模の社内ネットワーク運用をどう効率化していくか、というチャレンジの中でStackStormを使うようになったというお話でした。
www.slideshare.net
ネットワークを対象とした、監視検知時の初動対応の自動化を実装してみたら数日でできた、とのことでしたがそこまでに至る
- 業務のコード化
- コード化の際に行われたであろう、業務のフローチャート的な整理
- Puppet/Ansibleといった個別作業のツール実装
が行われていたことも大きく寄与していたんだろうなと思います。
最後に「思うこと」として挙げられた点はまったく同意でした。
- 自動化を前提としたワークフローを再定義する必要がある
- syslogベースの場合はベンダー間の差を吸収するべくある程度の標準化や自動化対象の明確化が必要
- 自動化に適した構成管理も必要
運用作業の手順書を見直すと「ログを見て問題無いことを確認する」というゆるふわなものがあって自動化に落とし込みにくい、とかは私も経験しました。私は単体テスト/サービス可用テストが通ればOK、に切り替えましたがネットワークが大規模で切り分けが難しい場合はログをきちんと拾っていく方が明確かもですね。
構成管理についても、ohai的なものをどこまで詳細にどう取得するかは課題になりがちですね。自動収集に変えるためにndp/cdpを有効にしてみたり、それがVxLANを超えられなくて困ったり、とか。OpenStackのPandamanプロジェクトも動き止まってそうですし、アセットマネジメントはさらなるツールが求められる分野なのかもしれません。(逆に、作っては壊す時代だからアセット管理にこだわるなということかもしれません)
自動化/StackStorm取組み事例 by 杉本さん
本家Slackでも発言をお見かけする杉本さんによる、IXでStackStormを導入したお話でした。
www.slideshare.net
主にユーザー加入時の開通作業の自動化が紹介され、ExcelからDBへ、手打ちコマンドからexpectスクリプトへ、といった取り組みを進めていくなかで、各ステップの自動化ツール化はできるがそれをつなぐものが無い、というところへStackStormがうまくはまった、という流れでした。現在はcurlを用いたWebhook送信で開始する仕組みになっているとのこと。
導入した利点として挙げられたのは以下。
- アーキテクチャ全体の見通しが良くなった
- 開発効率が向上した
- 将来的な機能拡張が考えやすくなった
さらに感想やTipsとして
- 学習コストは高め。特にPackを自作する場合
- バージョンアップは早いが対応はしやすい
- コミュニティがオープンで活発
を挙げられました。0.12あたりで失敗して以降いつも作り直していたのでバージョンアップはやってなかったのですが、Upgrade Guide通りで行けるとのことでしたので次はやってみようと思います。
今後の取り組みとして
- アラート対応の自動化
- ネットワーク機器に対する操作のAction化
- StackStorm自体の運用
を考えているとのお話でした。ST2自体も大きな仕組みなので運用は持ち寄りでベストプラクティス考えていきたいですね。
Q&Aで同時実行の制御について確認がありましたが、こちらのPolicy action.concurrencyを使っているとのことでした。
https://docs.stackstorm.com/reference/policies.html
StackStormを用いたネットワーク機器の制御 by 北川さん(社会人一年目!)
納品時の初期設定作業の自動化について、デモを交えてお話いただきました。
www.slideshare.net
Excel Packを用いてパラメータを読み込んで、設定テンプレート/Jinja2とAnsible PackでNW機器への設定投入を行うという流れで、ほぼ標準モジュールを採用されていたので理解しやすいユースケースでした。
Excelから読み込む、という所がsfunaiさんのOpenPIE(https://github.com/oss-laboratries/OpenPIE)を彷彿とさせました。デモでは割とシンプルなシートでしたが、実際に使われているシートがどういうものなのか興味ありました。
....その、なんというか....人はなぜパラメーターシートに勝手に列を追加したりパラメータ欄に日本語コメントをつけたりするのだろうか(過去にExcelをパースする仕組みで破綻した人)。
最後に触れられていましたが、Webフォームなど制約をかけやすい形でinputデータを得たほうが入力加工はしやすい気がします。
懇親会でのトーク
- 冗長化/可用性をどうするか。
私は可用性はハイパーバイザーに任せると割り切ったチキンです。来週のohtamaさんのお話で詳しく訊けるのかな..
- 踏み台を経由する環境
~stanley/.ssh/configがすごいことになるのは避けたいですよね....
- Workflow途中での失敗時や再実行
JP1のようなジョブマネージャーが活躍する領域ですね。私はWorkflowを小さめに分けるのが好きですが、retry-continueの紹介がありました
Mistral + YAQL — StackStorm 2.2.1 documentation
- スーツの人が多いですね
確かに。日本で知られるようになったのはBrocadeさんに買収されてからなので代理店さん含めた商流での広まりに現場技術者の間での広まりが追いついてないんですかね....もしくは商材としての魅力が大きくてそちら側の人が多く集まるのか
- もっとテッキーな話したいですね
ユーザー会ができるかも？公式ドキュメントと公式ブログがかなり充実しているので、個人的にはそれらの読み解き会とか有益ではないかと思います。
- いただいたロゴのステッカーはもうちょっと小さくて良いと思うのです
所感
使ってる人増えたなー、と感じられたのが何より良かったです。一年前は全然知られてなかったからなぁ
StackStormはあくまでつなぎ役なので、単体でポンと入れれば何かが解決する類のものではありません。どの発表にも共通していましたが、そこに持っていく前段階としてのワークフローの整理や各作業(Action)のツール化がST2を使う使わないに関わらず大事だな、ということも再確認できました。テスト系の話も訊きたかったかな。
あとActionChainがかなり賢いのでActionChainで済ませている人が多い印象でした。Mistralはもちろん、CloudSlangも運用フローチャートから焼きなおしやすくて楽しいですよ。
開催にご尽力された皆様やスポンサー各社など、みなさま大変有益な機会をありがとうございました！
最後に、最近のDmitriさんの発表スライドへのリンクをご紹介しておきます。
www.slideshare.net
www.slideshare.net
