【技業LOG】
技術者が紹介するNTTPCのテクノロジー

2019.01.10
その他

StackStormを使ってSlackからネットワーク装置を制御してみよう

加藤 史章

ネットワークエンジニア

加藤 史章

StackStormとは

イベントドリブンなワークフローエンジンを特徴としているStackStormというOSSを紹介いたします。
StackStormはイベントの検知/判断/その後の動作を定義することで日々の運用や故障時の自動的な対処を容易にすることができます。
今回はこのStackStormの概要と簡単なイベント処理を行ってみたいと思います。

動作の概要

StackStormではイベントを検知して動作するという動きをSensor/Trigger、Rule、Actionという処理を定義することで実現します。
それぞれの役割は次の通りです。

  1. Sensor/Trigger: イベントの検知の定義をします。Sensor部が検知し、Triggerとして処理されます。
  2. Rule: Triggerを受け取った場合、その後どのActionを実施するかを定義します。
  3. Rule: Triggerを受け取った場合、その後どのActionを実施するかを定義します。
  4. Action: 動作を定義します。複数のActionを組み合わせたワークフローを定義することもできます。

例えば、nttpc@nttpc.co.jpからのメールを受信したら
装置をrebootするという動作を自動的に行おうと思ったら

  1. Sensor/Triggerでメールを受け取る、
  2. Ruleで送信元がnttpc@nttpc.co.jpならばrebootアクションを実行する、
  3. Actionで装置にログインし、rebootコマンドを実行する。

という定義をそれぞれ作っておくことになります。

また、このような一連のセットをPackとして配布することが可能となっており、利用者が作成した他のOSSと連携するためのPackが配布されています。
今回はこの中のSlack PackとAnsible Packを利用してSlackで話かけられたらネットワーク装置のshowコマンドの結果を返すchatbotを作成してみようと思います。

Demo

  • 次のDemoの手順では、事前にdocker-composeのインストール、SlackでのHubotアプリの登録が必要ですが、その手順については省略いたします。

今回はDocker版のStackStormを利用して実施します。
Docker版の利用にはGitHubのst2-dockerのREADMEにある手順で導入していきます。
chatopsを利用するため、起動時に/etc/init/st2chatops.overrideを削除するシェルスクリプトをruntime/entrypoint.d/に作っておく必要があります。

# git clone git@github.com:stackstorm/st2-docker
# cd st2-docker
# make env
# vi runtime/entrypoint.d/chatops.sh
---次の中身のファイルを作成----
#!/bin/bash
sudo rm /etc/init/st2chatops.override
-------
# docker-compose up -d
# docker-compose exec stackstorm bash

コンテナにログインできたら、まずは次のコマンドでAPI-Keyの作成を行います。
コマンドを実行するとAPI-Keyが出力されますのでメモしておきます。(下記のabcd...)

# st2 apikey create -k -m '{"name":"slack-hubot"}'
abcdefghijklmnopqrstuvwxyz

次にchatopsの設定ファイルの修正を行います。

#vi /opt/stackstorm/chatops/st2chatops.env
  • 次の3行を修正します。
export ST2_API_KEY= abcdefghijklmnopqrstuvwxyz
 (先ほど作成したAPI-Keyを指定します。)
export HUBOT_ADAPTER=slack
 (コメントアウトを削除します。)
export HUBOT_SLACK_TOKEN=xoxb-1234567890
 (コメントアウトを削除し、SlackのHubotのAPIトークンの値を指定します。)

修正が終わると保存し、次のコマンドでプロセスを再起動します。

# service st2chatops restart

成功するとSlackで離籍中状態だったHubotがアクティブ状態になります。
SlackのチャンネルにHubotを招待して、 !help と発言し、Hubotが次のように返答すると正常に動作しています。
(Hubotの返答が!helpと!help <query>の2行のみの場合はAPI-Keyの誤り等でStackStormが正常に応答出来ていない状態となります。)
これでchatopsの準備が出来ました。

StackStorm 動作の概要 Demo画面

次にStackStormでAnsibleを利用するAnsible Packのインストールを行います。
Ansible PackではREADMEの通り、事前にライブラリのインストールが必要ですので、事前にライブラリのインストールを行います。

# apt-get install gcc libkrb5-dev
# st2 pack install ansible

Ansible Packが正常にインストールできたら、HubotからAnsible PackのActionの呼び出しが行えるよう、aliasの設定を行います。
ネットワーク装置の制御にはplaybookを利用する方が容易ですので、ansible.playbookのActionを呼び出して利用します。
alias、playbook、inventory_fileのサンプルをインストールするPackを用意しましたので、こちらのPackをインストールして利用します。

# st2 pack install https://github.com/f-kato/st2_ansible_chatops_sample.git

Packのインストール後、Slackで再度!helpと発言するとHubotからの返答に次の行が追加されます。
!ansible_playbook {{inventory_file}} {{playbook}} - run ansible playbook

また、Packがインストールされると次の場所にinventory_fileとplaybookがあります。
内容がCiscoのノードに対してshow ip routeを実施するものになっていますので、実施したい内容に修正して下さい。

  • inventory_file
    /opt/stackstorm/packs/st2_ansible_chatops_sample/etc/inventory_file
  • playbook
    /opt/stackstorm/packs/st2_ansible_chatops_sample/etc/playbook.yml

これで準備は完了になります。
Slackで次の発言を行うとStackStormのansible.playbookのActionが呼び出され、ansible-playbookが実行されます。

!ansible_playbook /opt/stackstorm/packs/st2_ansible_chatops_sample/etc/inventory_file /opt/stackstorm/packs/st2_ansible_chatops_sample/etc/playbook.yml
 (1行のコマンドです)
StackStorm 動作の概要 Demo画面

サンプルのPackでは細かい設定を行っていないため、見づらくなっていますが、show ip routeの結果を取得することが出来ました。

以上のようにSlackで命令を送り装置を制御することが可能となりました。
以外と簡単だったのではないでしょうか?

最後に

今回はStackStormを用いた簡単なchatopsの紹介をいたしました。
StackStormは他にも様々なOSSと連携することが可能となっています。
また、ワークフローを定義することで複雑な分岐を用いた切り分けや対応が行うことが可能です。
Ansible等でパーツは準備しているけど、開始の判断やパーツ毎の繋ぎは人が行っているので何か導入したいなという方にはStackStormを検討しては如何でしょうか?
そのような方やStackStormに興味があるけど試せていなかったという方に今回の紹介が参考になれば幸いです。

参考資料:

おすすめ記事

PageTop