StackStorm, 勉強会

 こんにちは、インフラ本部の大山裕泰です。
 2017/03/23 に開催された StackStorm勉強会 第2回 に参加してきました。以下で各セッションの紹介と感想を書かせていただきます。

Event-driven automation, DevOps way


(Speaker: Dmitri Zimine 氏 [Brocade (StackStorm Founder & CTO)])

セッション概要

    * StackStorm は何なのかという話。一言で言うと ‘IFTTT for DevOps’
    * StackStorm のワークフローエンジンの解説。
    * ユースケース・利用事例 (Mirantis, NETFLIX など)。運用プラットフォームとして StackStorm を利用し、更に従来のオペレーションをサービス化した話など

所感

 StackStorm は様々な使い方ができてしまうため、これが一体どういったもので、どういった使い方をするのがベストなのかはっきりとはわかりませんでしたが、各社の利用事例を踏まえ、StackStorm が最大限効果を発揮する使い方について理解できました。

“If 自動化するなら Then StackStorm を使おう!


(Speaker: 小島一憲 氏 [SoftBank])

セッション概要

 従来の運用を StackStorm で一部置き換えた事例と教訓話。人間がオペレーションする前提で組まれたマニュアルをそのまま自動化させると無理が生じるケースがある(ex. “手順:アラートが上がった際の機器の時間と標準時間の誤差を出す” など) ため、自動化を前提とした運用設計を組み直す必要があるかもしれない。
 構成管理システムと連携することでよりパワフルに使える話。イベントに対して構成管理システムを参照して、オペレーションを制御するような使い方など。

所感

 とても実践的で聞き応えのある内容でした。特に構成管理システムとの連携で話では、それぞれのシステムの特性を理解したうえで使い分ける運用技法は参考になりました。

インターネット・エクスチェンジで運用自動化に StackStorm を導入した話


(Speaker: 杉本周 氏 [インターネットマルチフィード])

セッション概要

 以前はマニュアルとスクリプトで機器のオペレーションを行っていた。これを共通のフォーマットで記述されたワークフローで運用手法を定義し、構成管理システムなどの外部システムと連携して、複雑な運用を自動化させるチャレンジを実施。
 StackStorm v1.5 から使用し、最新版 (2.2) まで逐次アップデートを問題なく行って来れた。

所感

 かなり初期から StackStorm を導入し、運用しながらのアップデートを随時行ってきており StackStorm 自体の運用ノウハウは相当溜まっているのではないかと思います。

StackStormを用いたネットワーク機器の制御


(Speaker: 北川裕介 氏 [日商エレクトロニクス])

セッション概要

 Excel で記入された NW 機器設定の指示書を読んで、機器の設定を行う仕組みを StackStorm + Ansible で作った話 (Ansible を利用した理由は、既に機器の構築用の Playbook 資産を活用するためとのこと)。

所感

 斬新な使い方でした。StackStorm のアクション/ワークフローの機能は一切使わずに、単に Excel パラメータを読んで Ansible に渡すだけの処理に StackStorm を使うという妙。

おわりに

 インターネットマルチフィードや SoftBank をはじめ、前回の勉強会で登壇されたリクルートテクノロジーズなど、国内に様々なユーザが居る事実に驚きました。
 我々も StackStorm による運用改善を試みており、こうした取り組みについて OpenStack 最新情報セミナーJANOG39.5 Interim Meeting で発表するので、是非いらしてください。

おまけ

 StackStorm 公式 Slack では、1,300 人以上の StackStorm ユーザが参加し、日々情報が交わされていますが、2017/03/28 から公式の日本語チャンネルが開設されました。

 (写真の ‘dzimine’ が StackStorm CTO のアカウントです)

StackStorm, 運用管理

 こんにちは、インフラ本部の大山裕泰です。
 ここでは StackStorm の開発・運用を実際に行っている人向けに、拡張モジュール (pack) のパラメータ設定のテーマで掘り下げた内容をお届けします。

 StackStorm がどんなもので、どういう問題を解決するかについては StackStormで始める運用自動化 ~入門編~ をご覧ください。

 このエントリによって、StackStorm pack の config.yaml と config.schema.yaml の違いや、どういったケースでどのような設定方法がベストかを理解できるようになると思います。

 冒頭で紹介した CodeZine の記事でも書きましたが、レガシーな pack の設定パラメータの記述方法として、対象 pack の config.yaml ファイルに記述する方法があります。その他に config.schema.yaml で設定されたパラメータを pack の設定コマンド st2 pack config から設定する方法と、StackStorm が参照するデータストア (本校執筆時点の StackStorm では MongoDB を使用) に設定する方法があります。
 ここでは AWS の StackStorm モジュール aws pack を例に、それぞれの方法の使い方や他の設定方法との違いについて解説して行きます。

config.yaml による設定

 config.yaml による設定は、最も単純な pack の設定パラメータの記述方法です。ユーザは config.yaml 編集し、StackStorm pack に任意のパラメータを渡すことができます。これにより、StackStorm の UI を通して外部サービスのイベントハンドリングやアクションを実行できます。
 以下は aws pack のデフォルトの config.yaml の全文になります。

---
# Note: credentials under "setup" object are deprecated and have been replaced
# with top-level values which have precedence and also work with dynamic config
# values.
setup:
  region: ""
  aws_access_key_id: null
  aws_secret_access_key: null

aws_access_key_id: null
aws_secret_access_key: null
region: "us-east-1"
interval: 20
st2_user_data: "/opt/stackstorm/packs/aws/actions/scripts/bootstrap_user.sh"

service_notifications_sensor:
  host: "localhost"
  port: 12345
  path: "/my-path"

sqs_sensor:
  input_queues:

sqs_other:
  max_number_of_messages: 1

 config.yaml は全ての pack で共通して pack の管理ディレクトリ (/opt/stackstorm/packs/{pack 名}/) の直下に置かれています。aws pack の場合には config.yaml は /opt/stackstorm/pack/aws/ 配下に置かれます。

config.schema.yaml による設定

 config.yaml はとても単純な仕組みで使い勝手が良いのですが、pack の管理ディレクトリ配下のファイルが状態を持ってしまうと、運用上で不都合が生じてしまいます。

 pack は StackStorm の ‘st2 pack install’ コマンドによって StackStorm-Exchange から最新のコードを取得し、対象 pack の管理ディレクトリ (/opt/stackstorm/packs/{pack名}/) にデプロイされた後、StackStorm に登録されます。
 また pack の削除は st2 pack uninstall コマンドで行いますが、その際 pack の管理ディレクトリがそっくり削除されるため、pack のデプロイ後に編集した config.yaml も削除されます。
 pack の削除以外でも、StackStorm-Exchange の pack が更新され config.yaml のスキーマが変わった場合には、pack のアップデート時にユーザが編集した config.yaml は上書きされてしまいます。

 こうした挙動は Infrastructure as Code のプラクティスに合ったもので問題ありません。
 むしろ config.yaml の存在によってポリシーと設定が結合する格好になり、上記のような運用上の問題が発生します。また、設定項目や設定値の型はユーザが自由に記述することができるため、設定周りのテストがしづらいという問題もあります。

 これに対して config.schema.yaml で記述される 設定スキーマ (Configuration schema) の仕組みが作られました。
 設定スキーマは、予め pack の作成者が必要な pack の設定項目のスキーマをスキーマファイル (config.schema.yaml) に定義しておき、ユーザは ‘st2 pack config ‘ コマンドによって、予め規定された設定項目・型の値を設定します。

 これによりテストし易くなるという利点のほか、設定結果を pack の管理ディレクトリとは別の設定項目を管理するディレクトリ ‘/opt/stackstorm/configs’ 配下に置き、ポリシーと分離させることで、pack のバージョンや状態に関わらず設定内容を独立させることができます。

 以下に aws pack の config.schema.yaml の全文を示します。

 ’st2 pack config aws’ を実行することで、上記のスキーマファイルに沿った入力が求められ、最終的に aws 用のオリジナルの設定ファイルが生成されます。

 なお、ここでの設定は cnofig.yaml の設定よりも優先されます。なので、同じ設定項目を config.yaml と config.schema.yaml から生成された設定ファイルの両方で設定されている場合には、後者の値が読み込まれます。

データストアによる設定

 最後に、データストアによる pack の設定について解説します。
 ’st2 key set’ コマンドによって、以下のように任意の key/value をデータストアに登録させることができます。

 センサーの実装においては、上記の config.yaml/config.schema.yaml による設定は起動時に読み込まれ、ここでの設定値は動的に読み込まれるような 使い分け をしており、aws pack のセンサーではこれに沿って、データストアによる設定が優先されるように実装されています。

 また Jinja template の拡張により、以下のように config.schema.yaml から生成した設定ファイルから、データストアで設定した値を参照させることができます。

 以下で、設定ファイルで指定したキー ‘dev_api_key’ の値 ‘SecretValue’ を暗号化して設定します。

 ただ、これには 文字列型しか設定できない制限 が存在するため、使用する際には注意が必要になります。

StackStorm

 インフラ本部の大山裕泰です。今回は Brocade が買収したことで話題になった、イベントドリブンな Workflow エンジン StackStorm が一体どういう仕組みで動作しているか、ちょっと深堀した内容をお届けします。

 StackStorm 自体については、先日行われた StackStorm 勉強会で 発表された方の資料 で詳しく解説されており、使い方についても こちらこちら のページで詳しく解説されています。
 「StackStorm を使ってみたけど、裏側で何がどうなっているかイマイチよくわからん」といったユーザ向けに、StackStorm の論理構造を解説し、StackStorm の理解の手助けが出来ればと思います。

StackStorm について

 StackStorm のドキュメント を冒頭から読んでいくと、いきなり次のような図が情報します。

 一見とても複雑そうです。ターゲットに紐付く依存関係を解決してコマンドを実行する “古典的なワークフローエンジン” とは違います。
 初めて触るユーザや、とりあえず QuickStart だけやってみたユーザにとっては、なんでこんな複雑な機構なんだろうかと戸惑われたかもしれません。
 本エントリではこうしたユーザ向けに、StackStorm の概要についての理解と、上記の内部アーキテクチャの詳細についての理解の中間的な論理構成の理解を手助けする内容を提供していきます。

StackStorm の論理構造

 以下は、StackStorm がイベントを処理する仕組みについて表した図になります。

 Sensor は外部で発生したイベントを監視するモノで、外部のイベントを検知した際には予め登録された Trigger にイベントの発生を通知 (以降では “Trigger を引く” と表現) します。
 Trigger は Sensor から通知された外部イベントを Action が扱い易い形に正規化します。何も設定されていない状態では、Sensor が Trigger を引いても何も発生しません。Trigger が引かれた際にどういった処理 (Action/Workflow) を実行するかを規定したものが Rule になります。
 Rule には二つの役割があります。一つは上述した Trigger と Action/Workflow を紐づける役割で、もう一つが Trigger パラメータと Action パラメータを変換する役割です。
 StackStorm では Trigger と Action はそれぞれ独立しており、Rule によって任意の Trigger と Action を組み合わせることができます。その際、Trigger から渡されるどのパラメータを抽出し、どういったパラメータを Action に渡すかの設定を Rule に記述します。

 以下の具体的なケースに置き換えて考えてみます。

 ここでは Sensor, Trigger, Action にそれぞれ以下を使用し、GitHub の特定のリポジトリで Issue を作成(更新)した際に RabbitMQ にメッセージを送る仕組みになります。
 尚、StackStorm では Sensor, Trigger, Action を機能毎にまとめたソフトウェアコンポーネントのことを pack と呼びます。そして、上記の github は rabbitmq のようなサードパーティの pack は (本エントリ執筆時点では) StackStorm/st2contrib リポジトリで管理する運用になっています。

 Sensor ‘github.GithubRepositorySensor’ は 30 秒毎に GitHub のリポジトリの更新状況を確認し、前回の確認から更新が発生した場合には Trigger ‘github.repository_event’ を引きます。
 ここでは、この Trigger が引かれた際に Action ‘rabbitmq.publish_message’ を実行する Rule ‘example.github_event_invocation’ を記述しました。この Rule の内部で Trigger パラメータ (Issue に対する操作(opened/closed)、及びタイトルと本文) を Action パラメータ (exchange, routing-key, message) を次のように変換しています。

動かしてみる

 確認する GitHub のリポジトリは、GitHub pack の設定ファイル ‘/opt/stackstorm/packs/github/config.yaml’ で指定します。以下に設定ファイルの全文を示します。

 ここでは、この Trigger が引かれた際に Action ‘rabbitmq.publish_message’ を実行する Rule ‘example.github_event_invocation’ を記述しました。以下が設定したルールの全文になります。

 ’trigger’ / ‘action’ のパラメータで、それぞれ図の Trigger / Action を指定します。’action’ の ‘parameters’ で当該アクションに渡すパラメータを指定します。ここで Trigger から渡されるパラメータと Action パラメータの変換処理を行っています。
 ’criteria’ パラメータは、Trigger に通知されたイベントのうち Action で処理するモノを選択する際に利用します。今回の例では Trigger はリポジトリに対する Issue の更新/コメント、Fork、Watch、Push などのイベント発生時に Sensor によって引かれますが、Issue の更新イベントだけ Action を呼ぶようにしたい場合にこのように設定します。

 それでは実際に GitHub リポジトリ に Issue を作成し動作を確認します。RabbitMQ に通知された メッセージを受け取るスクリプト を実行し、リポジトリに以下のような Issue を作成します。

 こうすることで Sensor が検知したイベントを Trigger に通知し、Rule に沿って RabbitMQ にメッセージが送られます。そして、先ほど実行したスクリプトで送られたメッセージを取得できることが確認できます。

PAGE TOP