僕らはStackStormをどう使うべきか / NTT TechConference #2 StackStorm

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 Copyright© 2017 NTT TechnoCross Corporation アジェンダ 1. どんなもの？ • StackStormとは • StackStormの特徴 2. StackStormがやるべきこと • そもそも自動化したい業務とは • 他製品との機能比較 • StackStormに任せるべきこと 3. ユースケース • 紹介 • 試してみたい人向け • 実例 4. おまけ(時間があれば) • 個人的に興味のある使い方 • NWCI

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright© 2017 NTT TechnoCross Corporation 7 StackStormによるWorkflowの動作イメージ (かなり省略) Rule イベント Workflow Action Action Workflow Action Task Task Task Task Task Task ... イベントに応じた Workflowを起動 Workflow内のTaskとして別のWorkflowを起動できる

Slide 8

Slide 8 text

Copyright© 2017 NTT TechnoCross Corporation 8 StackStormの特徴 (次項から解説) APIフレンドリー大抵の操作はAPIで可能 JSONで返せるので外部連携も楽実行契機を柔軟に設定できる・Webhook ・WebUI ・CLI ・ファイル更新・Polling ・RabbitMQ Workflowの記述が楽 • Metadataによって Actionの引数定義などを把握できる • Workflowの形式の使い分けコードの再利用性が高い Action, Workflowの流用が楽また、Packによって再配布が容易

Slide 9

Slide 9 text

Copyright© 2017 NTT TechnoCross Corporation 9 特徴1: APIフレンドリー大抵の操作はAPIでできる • Action, Workflowの起動 • Rule, Action, Workflowの登録、参照 • Datastore(内部にあるkvs) への登録、参照、削除 • 認証 • etc... → 他のツール、システムとの連携が容易詳しくは以下参照 https://api.stackstorm.com/

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright© 2017 NTT TechnoCross Corporation 11 特徴3: Workflowの記述が楽 metadataという仕組みによって、実コードを読まなくてもActionやWorkflowの概要を把握できる # metadataの例 --- name: “hoge_ssh“ pack: test runner_type: "python-script" description: “sshで何かする" enabled: true entry_point: “ssh.py" parameters: port: type: “integer" description: “ssh port" required: true default: 22 • YAMLで記述する • ActionやWorkflowのコードとセットで作成しなくてはいけない • 見れば「何をするものなのか」「何を与えればいいのか」がおおよそ分かる

Slide 12

Slide 12 text

Copyright© 2017 NTT TechnoCross Corporation 12 特徴3: Workflowの記述が楽実現したい手順によって、異なる記法を使い分けることができる記法メリットデメリット ActionChain • 記法がシンプルで、覚えることが少ない • 成功/失敗による分岐しかサポートしていない • 条件分岐が不可 Mistral • 条件分岐が可能 • タスクの並列実行が可能 (fork, join) • ループ処理が可能 • 有料版(BWC)ではGUIによるWorkflow作成が可能 • ActionChainより覚えることが多い (YAQLなど) • 旧バージョンのst2では ASCII外文字の取り扱いに難あり CloudSlang • Mistralとほぼ同じ • 市中に情報が少ない...

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright© 2017 NTT TechnoCross Corporation 16 そもそも論: 開発、運用で自動化したいユースケース開発&運用業務の中で、自動化したい業務手順(Workflow)は大きく3つだと考えている • 開発: CI/CD → ビルド、テスト、デプロイなど • 開発&運用: 定型処理 → チケットの集計、ログ収集&蓄積、収集データのクリーニングなど • 運用: イベント対応処理 → 稼動中システムの障害対応など

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyright© 2017 NTT TechnoCross Corporation 18 Workflow Engineと呼ばれる製品たち • Apache Airflow (Apache) • Luigi (Spotify) • Digdag (Treasure Data) • Jenkins Pipeline (Jenkins) ... → 比較するには数が多いので、絞る Workflow Engineの定義: • タスクを実行順序に従って実行できること • タスクの実行順序とその結果を一連の処理として管理できること

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyright© 2017 NTT TechnoCross Corporation 20 • いわずと知れた自動化ツールの定番 • 色んな拡張機能が揃っていて、周辺ツールとの連携に強み • Workflow管理機能として、Jenkins Pipelineがある • WorkflowはGroovy DSLで記述比較するのはPipeline周り調査で参考にした情報(2017/08/01): • Jenkins Pipeline: https://Jenkins.io/doc/book/pipeline/ • How to set current build result in Pipeline?: https://support.cloudbees.com/hc/en-us/articles/218554077-How-to-set-current-build-result-in-Pipeline-

Slide 21

Slide 21 text

Copyright© 2017 NTT TechnoCross Corporation 21 • 去年OSS化されたWorkflowエンジン • Treasure Data製品との連携機能が豊富 • サーバとして動作させなくても、ローカル環境で Workflowを実行することが可能 • WorkflowはYAML DSLで記述調査で参考にした情報(2017/08/01): • Digdag: http://docs.digdag.io/ • Digdagによる大規模データ処理の自動化とエラー処理: https://www.slideshare.net/frsyuki/digdag-76749443

Slide 22

Slide 22 text

Copyright© 2017 NTT TechnoCross Corporation 22 StackStormとの機能比較操作 WebUI ○ ○ ○ CLI ○ ○ ○ 実行契機手動 ○ ○ ○ 時間 ○ ○ ○ Webhook ○ × ○ Workflow の機能タスク返り値による分岐 △ できるが面倒 ○ ○ 引数付き実行 ○ × ○ 失敗箇所からの再実行 × ○ ○ タスク並列実行 ○ ○ ○ タスク分散実行 ○ 実行ノード指定可能 △ 各ノードに分散される △ Runnerに分散される管理 Workflowのファイル分割 ○ ○ ○

Slide 23

Slide 23 text

Copyright© 2017 NTT TechnoCross Corporation 23 Jenkins, digdagのユニークな機能 • ジョブ毎にWorkspaceを自動作成する • Git上のWorkflowファイルを動的に取得して実行できる • Workflowを動作させるノードを指定する記述が可能 • Workflowの実行結果を視覚的に表示できる • 無料でRBACができる • ローカルでWorkflowを実行可能 • 単体でWorkflowファイルのバージョン管理が可能 • TreasureData, Embulkなどのデータ処理ツールとの連携機能がデフォルトセット

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright© 2017 NTT TechnoCross Corporation 25 比較の結論 • Jenkinsはコードの自動ビルド、テストに向いてる・自動で専用の作業ディレクトリを作ってくれるなど、ビルド用Workflowの記述量を抑えられる仕組みがある。・Git上でWorkflowファイルを単体管理することができるので、開発物に依存するビルド手順などをセットで管理できる。・ビルド、デプロイ、テストそれぞれについて、Ansibleなどを使わず任意のノード上で実行できる

Slide 26

Slide 26 text

Copyright© 2017 NTT TechnoCross Corporation 26 比較の結論 • digdagは定時、定型的なデータ処理に向いてる・大量データを捌くための外部アプリ連携機能 (TreasureData, Embulk)が標準搭載なので、定期的なデータ処理をWorkflowとして表現しやすい。・失敗箇所からの再実行も可能なので、長大な処理に向いている。・「いつ実行するか」をWorkflow内に記述できるので、実行タイミングと手順をセットで管理することに向いている。

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Copyright© 2017 NTT TechnoCross Corporation 28 参考: 自動ビルドWorkflowの記述比較 vars: clone_dir: ‘/tmp/{{ action_contents.execution_id}}’ chain: - name: git_clone ref: git.clone parameters: source: ‘https://~’ ref: ‘master’ destination: ‘{{ clone_dir }}’ on-success: bundle_install - name: bundle_install ref: core.local parameters: cmd: ‘bundle install’ cwd: ‘{{ clone_dir }}’ node(server1){ stage ‘git clone’ git url: ‘https://~’ stage ‘bundle install’ sh: ‘bundle install’ } +git_clone: sh>: > tasks.git_clone.sh --src=‘https://~’ --dest=‘/tmp/${session_uuid}’ --ref=‘master’ +bundle_install: sh>: > /tmp/${session_uuid} bundle install Jenkins Pipelineが最も記述が短くなり、意図をシンプルに表現できている

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Copyright© 2017 NTT TechnoCross Corporation 31 監視アラートに応じた自動復旧 (Auto Remediation) イベント = 監視基盤 (ELK, Zabbixなど)からのアラートやること = 所定の復旧作業&通知監視基盤監視 Ruleに従って所定の復旧手順 (Workflow)を流すどんなエラーを拾ったらどういう webhookを飛ばすかは事前定義状況、結果を通知

Slide 32

Slide 32 text

Copyright© 2017 NTT TechnoCross Corporation 32 Auto RemediationにおけるWorkflowの動作例 • ActiveなWebサーバが503を返した →・LBが正しく状態を拾っているかチェック・プロセスの状態チェック・プロセス再起動、疎通チェック・サーバ再起動、疎通チェック・sby機の起動・LBがsby機に振り分け開始しているかチェック (よい意味で)人間味のあるトラブルシュート、復旧が可能

Slide 33

Slide 33 text

Copyright© 2017 NTT TechnoCross Corporation 33 Workflowの記述例それぞれの操作をActionとして抽象化しておけば、書きやすく読みやすいコードになる chain: - name: block_ip ref: fw.block parameters: ip: ‘{{ ip }}’ phy_port: ‘{{ global }}’ on-success: get_ip_info - name: get_ip_info ref: ip.reverse_resolv parameters: global_ip: ‘{{ ip }}’ publish: whois: ‘{{ get_ip_info.stdout }}’ on-success: post_slack # 後略例) 特定のアドレスからアクセスが集中 → ・FWを操作してアクセスを遮断・IPの逆引き情報などを管理者に通知

Slide 34

Slide 34 text

Copyright© 2017 NTT TechnoCross Corporation 34 Auto-Remediationを試してみたい人向け • StackStorm公式が設定例を載せてるので、気軽に試せる → Auto-remediation by example: handling out-of-disk-space. https://stackstorm.com/2015/10/05/auto-remediation-out-of-disk-space/ • 検証環境を作るのが面倒な方へ → Vagrantを使ってVirtualboxなどで立てるのがオススメ https://github.com/StackStorm/st2vagrant

Slide 35

Slide 35 text

Copyright© 2017 NTT TechnoCross Corporation 35 StackStormによるAutoRemediationの実例 • Auto-Remediation with StackStorm & Splunk → https://stackstorm.com/2016/10/21/auto-remediation-stackstorm-splunk/ • Event Driven Auto-Remediation with the Elastic Stack → https://stackstorm.com/2017/01/12/event-driven-auto-remediation-elastic-stack/ • Netflix: StackStorm-based Auto-Remediation – Why, How, and So What → https://stackstorm.com/2015/11/21/netflix-stackstorm-based-auto-remediation-why-how- and-so-what/

Slide 36

Slide 36 text

Copyright© 2017 NTT TechnoCross Corporation 36 おまけ: 興味のある使い方 Amazon Lambda Amazon Step Functions Step Functions = Workflowと考えたら、 Lambda = Rule + Actionに近い → Lambdaのようにシンプルなコード実行基盤を StackStormで実現できるのでは？冒頭に出した例

Slide 37

Slide 37 text

Copyright© 2017 NTT TechnoCross Corporation 37 おまけ: 興味のある使い方 = FaaS 既に実現されていて、OpenStack Summit Bostonで発表されてる Serverless on OpenStack with Docker Swarm, Mistral, and StackStorm https://www.openstack.org/videos/boston-2017/serverless-on-openstack-with-docker-swarm- mistral-and-stackstorm • StackStormとDockerで実現されていて、 OSS版Lambdaっぽい仕組み • どういうユースケースがあるか考え中。使って嬉しいものを作りたい！