GoogleHomeとStackStorm

NTT Engineers Festa ＃1で発表したネタ。
GoogleAssistantを使った対話型アプリの裏処理をst2にやらせるための実装に用いる機能や実装案についてザックリまとめたものです。

#GoogleAssistant #GoogleHome #StackStorm #st2

Transcript

1. GoogleHome × StackStorm Wataru Manji <wataru@manj.io>
2. エクストリーム出勤をキメた (所要時間5時間半)
4. 山奥の無人駅で電車が緊急運休
6. 山中の茶畑を彷徨い、 なんとかタクシーを拾って駅へ...
7. はい
8. 自己紹介 Name : 萬治 渉 (マンジ ワタル) Account : # call me まんじまる ・Slack : @manji0 ・Twitter : @___manji0 Occupation : # 入社してからそろそろ丸2年 ・NTT-TXのOpenStackチームに所属 - StackStormを使って運用やテストの効率化 - Ansibleを使ってOpenStack構築資材を作成 - 若手特権で色々なイベントへお邪魔 ・研究所のとある案件に50%くらい投入中 - NW運用、工事などを自動化するシステムの方式検討 - 機器操作抽象化ツールの方式検討、調査、試作など
11. はじめに GoogleHome...というか、GoogleAssistantを使った • 基本的なGoogleAssistantアプリの実装方法 • StackStormを組み合わせるとできることがどう広がるか • StackStormと組み合わせた実装の方式検討の内容 なんかについて話します。 やってること自体にそこまで意義は無いのですが、 いわゆるChatOpsや運用自動化の実装について考える キッカケになればいいなと思ってます。 時間が20分しかないので、まとまった話ができるか不安。
12. 前提：GoogleAssistantについて • Google版のSiriみたいなやつ • GoogleHomeとか、Android搭載スマホとかから使える • SDKが公開されており、自分で拡張を書くことができる • IFTTTやDialogflowなどを用いて簡単に拡張を実装できる
13. GoogleAssistantアプリ(=拡張) の作成について 非常に乱暴なまとめ: • ガチで作るならSDK使ってゴリゴリ実装すれば何でもできる • POST Request投げっぱなしでよいならIFTTTでOK • Request → 結果のpolling → 結果を返す... 程度ならDialogflowを使え 非常に乱暴なチャート: 実行系をWeb APIで キックできる？ リクエスト投げっぱなしで OK？ 返り値を元に複雑な処理を してから返したい？ SDKで ゴリゴリ
14. IFTTT, Dialogflowのたたきかた カット
15. 複雑さのレベル • リクエスト投げっぱなしでいいもの ◦ 家電の操作 ◦ 定型連絡 (今日休みます！とか ) • リクエストを投げる&結果をそのまま返してくれればいいもの ◦ 列車の運行状況取得 ◦ アサインされてるチケットの確認 • 複雑な操作が絡むもの, etc... ◦ 複数のサービスへの一括操作 (特に認証情報の管理が必要なやつなど ) ◦ Internet Reachableでない機器、サービスの操作
16. リクエストの先はどこへ？ • 手堅くやるなら API Gateway → Lambda (→ Step Functions) ◦ メリット : ▪ 構成を組むための情報が豊富 • 日本語で書かれた入門記事がいくらでもある • 社内に1人くらいはめっちゃ詳しい人がいるので頼れる ▪ 良心的なレートの従量課金 • 個人的な実験なら数十円とか • GoogleAssistantで遊ぶ系の記事でも大抵上記の構成を使ってる • しかし、前項の「複雑な操作が絡むもの, etc...」には対応しにくい
17. リクエストの先はどこへ？ • ここでStackStorm ◦ メリット : ▪ 1サービスでAPI Gateway, Lambda, StepFunctions相当の リソースを作成、管理できる ▪ 各種サービス、機器に対応した拡張パッケージが豊富 ▪ 各種サービスの認証情報を簡単に管理できる • ただし、市中に情報が少ない ◦ ドキュメントはほぼ英語 ◦ 英語ですら「使ってみた」系の記事が少ない ◦ (情報に需要はあるっぽいが、供給が追い付いてない感じ...)
18. 実装するために必要そうな機能の解説
19. StackStormの機能とAWS各サービスとの対応 • Rule : 各種イベントやWebhookのendpointなどの起動契機と、 起動するAction | Workflow及び引数の対応の定義 • Action : Python/bash/etc… で記述される実行コード • Workflow : OpenStack Mistralなどで記述されるワークフロー定義 StackStorm AWS Rule API Gateway + Lambda(Event hook) Action Lambda(Execution) Workflow Step Functions
20. StackStormと連携できるサービス、機器など StackStorm Exchange にまとまっているので参照すべし。 サービス毎に「Pack」という単位でActionなどのパッケージが提供されている。 • 対応しているサービスの例 : ◦ Github, Gitlab ◦ AWS ◦ OpenStack ◦ Bitcoin(送金のみ) ◦ ActiveDirectory, MS Exchange ◦ etc... • 対応している機器の例 : ◦ Junos, ios, eos ▪ napalm-packによるconfig, 状態確認に対応 ▪ napalm-logsによるSNMPメッセージ契機のhookに対応 ◦ Linux, Windows ▪ Ansible-packによる操作に対応 ▪ 基本機能でsshによる操作に対応
21. 各サービスの認証情報の管理について StackStormにはPack毎に「Config」という名前空間を用意しており、 任意の変数を登録することができる。 Configの特徴 : • 同一Pack内のAction, Workflowから参照可能 • secret属性を指定することが可能 (ログに変数の中身が残らない) • APIで管理可能 機微な情報をAction, Workflowから分離し、かつ簡易な管理ができる。 積極的に使ってほしい機能の1つ。 参考: https://docs.stackstorm.com/reference/pack_configs.html
22. StackStormのREST APIについて 基本的にはStackStom APIを見れば全部載ってる。 注意したいのは以下のポイント。 • WebhookによってAction/Workflowをキックした場合、 POSTの返り値でexecution idが取れず、実行結果の追跡が難しい。 → 実行結果を追跡したいならexecutionのAPIを叩こう POST api/v1/execution • 実行結果を追跡する場合、単純にexecutionをGETするループを書くのは 非効率。 → Real time Action Outputを使おう GET api/v1/execution/<id>/output
23. StackStormのキック→結果取得の方法 前項の注意点を踏まえた 1. /executionにPOSTしてst2をキックする 2. キックされた処理が終了するまで待機し、結果を取得する 3. 1→2→returnの手続き という処理の疑似コードを記す。 例のまま書いてくれというよりは、st2のここを叩け的な例です。
24. 1. /executionにPOSTしてst2をキックする function postSt2Exec (app, parameters) { let opts = { “Header”: { “x-st2-auth-token”: ‘hoge’, “Contents-Type”: ‘application/json’, “Connection”: ‘keep-alive’ }, “Data”: { “action”: ‘hoge.hoge’, “parameters”: parameters } }; let resp = http.post(‘https://st2.manj.io/api/v1/execution’, opts); return resp; }
25. 2. 処理が終了するまで待機&結果取得 function getSt2Exec (executionID) { const execURL = “https://st2.manj.io/api/v1/executions/” + executionID; http.get(execURL + ‘/output’); # 待機 return http.get(execURL)[“body”] # 結果を取得 }
26. 3. 1→2→returnの手続き function main (app, parameters) { const executionID = postSt2Exec(parameters)[“execution_id”]; const result = getSt2Exec(executionID); # listで返ってくると仮定 const isExsistListItem = result.length == 0 ? True : False; if (isExsistListItem) { return(“結果はありません”); } else { return(“結果は” + result.join(“ ”) + “の” + str(result.length) + “件です”); } }
27. 実装方式を検討してみる
28. インターフェースの機能レベル • レベル1: ただ処理をキックするだけ ◦ 例: 家中のPCのウィルスチェックを起動する ◦ GoogleAssistant: IFTTTでST2のWebhookをキック ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル2: 同期的に返事を喋らせる ◦ 例: 任意の担当者にアサインされているチケットの数と番号を喋らせる ◦ GoogleAssistant: Dialogflowで ▪ ST2のexecutionをキック ▪ 続けてexecutionをGETして結果を喋らせる ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル3: 非同期的に返事を喋らせる ◦ 例: 新しいチケットがアサインされたら GoogleHomeが名前を呼んでくれる、など ◦ GoogleAssistant: 命令通り喋るだけ ◦ ST2: GoogleAssistantのAPIを叩いて喋らせる
29. GoogleAssistant×StackStormのレベル感 • レベル1: ただ処理をキックするだけ ◦ 例: 家中のPCのウィルスチェックを起動する ◦ GoogleAssistant: IFTTTでST2のWebhookをキック ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル2: 同期的に返事を喋らせる ◦ 例: 任意の担当者にアサインされているチケットの数と番号を喋らせる ◦ GoogleAssistant: Dialogflowで ▪ ST2のexecutionをキック ▪ 続けてexecutionをGETして結果を喋らせる ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル3: 非同期的に返事を喋らせる ◦ 例: 新しいチケットがアサインされたら GoogleHomeが名前を呼んでくれる、など ◦ GoogleAssistant: 命令通り喋るだけ ◦ ST2: GoogleAssistantのAPIを叩いて喋らせる
30. レベル2の問題点: タイムアウト問題 Dialogflowでスクリプトを実行するとき、タイムアウトが5秒しかない！ → 5秒以上かかるAction, Workflowの状態をGETできない！ 解決策: レベル1+レベル3で代用する
31. GoogleAssistant×StackStormのレベル感 • レベル1: ただ処理をキックするだけ ◦ 例: 家中のPCのウィルスチェックを起動する ◦ GoogleAssistant: IFTTTでST2のWebhookをキック ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル2: 同期的に返事を喋らせる ◦ 例: 任意の担当者にアサインされているチケットの数と番号を喋らせる ◦ GoogleAssistant: Dialogflowで ▪ ST2のexecutionをキック ▪ 続けてexecutionをGETして結果を喋らせる ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル3: 非同期的に返事を喋らせる ◦ 例: 新しいチケットがアサインされたら GoogleHomeが名前を呼んでくれる、など ◦ GoogleAssistant: 命令通り喋るだけ ◦ ST2: GoogleAssistantのAPIを叩いて喋らせる
32. GoogleAssistant×StackStormのレベル感 • レベル1: ただ処理をキックするだけ ◦ 例: 家中のPCのウィルスチェックを起動する ◦ GoogleAssistant: IFTTTでST2のWebhookをキック ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル2: 同期的に返事を喋らせる ◦ 例: 任意の担当者にアサインされているチケットの数と番号を喋らせる ◦ GoogleAssistant: Dialogflowで ▪ ST2のexecutionをキック ▪ 続けてexecutionをGETして結果を喋らせる ◦ ST2: Workflowに応じて淡々とActionを実行 • レベル3: 非同期的に返事を喋らせる ◦ 例: 新しいチケットがアサインされたら GoogleHomeが名前を呼んでくれる、など ◦ GoogleAssistant: 命令通り喋るだけ ◦ ST2: GoogleAssistantのAPIを叩いて喋らせる
33. レベル3の問題点: L2 Reachableじゃないと喋れない？ GoogleHomeに非同期に任意の文章を喋らせられるようなアプリが google-home-notiferしか見つからなかった。 Webサーバとして動き、同一L2内のGoogleHomeを喋らせるAPIを 受け付けてくれる代物。 • https://github.com/noelportugal/google-home-notifier (ngrokを使えば外部に公開できるけど...) 解決策: GoogleHomeとST2、notifierを同一NW内に。ST2にnotifierを叩かせる # もしくはSDKを使って自分でゴリゴリ作る
34. 完成系 1. GoogleHomeに話しかける 2. IFTTTでStackStormのWebhookを叩く 3. StackStormがWorkflowなどの処理を実行 4. StackStormが処理の結果をテキストに直し、notifierサーバにPOST 5. notifierサーバの命令に従い、GoogleHomeが喋る
35. まとめ • StackStormでVoiceOps, ChatOpsを作るときに必要そうな機能と使い方 • StackStormが対応しているサービス • GoogleAssistant契機で複雑な処理をする時に、ST2を使って解決 。。。大したこと話してない気がしますが、 st2に関する情報自体はそこそこ有用じゃないかと思っています。 st2に興味ある人は、GoogleHomeと組み合わせたオモチャ作りからどうぞ。 加筆、修正、追加調査のリクエストお待ちしております。
36. おまけ: ST2のセキュリティについて 素だとガバい。無償版でRBACが使えず、adminのapi-keyを使うしかない。 • アクセス元を制御したり、標準でリバプロとして搭載されているnginxを 魔改造してなんとかするしかない。 • 商用版(Workflow Composer)にはRBACの機能がついてる。 そっちはそこそこまとも。 • adminのapi-keyがあればst2が動作してるサーバのroot取れるから マジ気をつけて
37. おまけ: データの永続性 • Actionの実行履歴 • Pack(Action, Workflow, Rule, Sensor,...)の登録情報 • Datastore(st2についてるKVS)のデータ • (有償版だと) RBACのデータ あらゆるものがMongoDBで管理されてる 以上 # レプリケーションとか大変そうですね...
38. おわり