StackStorm 運用 TIPS ー config.yaml と config.schema.yaml の違い

 こんにちは、インフラ本部の大山裕泰です。
 ここでは 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’ を暗号化して設定します。

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

JANOG39ミーティング、本日最終日です!

始まったと思ったらもう最終日。
3日間、本当にあっという間でした。

2日目に行われた懇親会でツチノコNOCに参加してくれた学生たちがライトニングトークを行いました。

IMG_0074

2日間で起きたトラブル?!について

ホール入り口のアクセスポイントに繋がりにくい!

立ち見が出るセッションもありホールは大盛況。
アクセスポイント毎のアソシエート数を見ていると入り口付近は接続数が伸びていないことがわかりました。

会場図

立ち見の参加者さんが、アクセスポイントからの電波を通りにくくする壁となっていました。
そのため、該当のアクセスポイントの出力を下げ、他のアクセスポイントに逃がし繋がりにくさを回避しました。

接続数が少ないアクセスポイントの対応について

会場内に設置したアクセスポイントのなかで、極端に接続数が少ないものが確認できました。

接続数減少AP

現地を確認するとアクセスポイントの角度が設置時時よりずれていることがわかりました。
角度を戻すと少しずつ接続数が増えていき正常な動作に戻りました。

接続数減少AP2

用意したパトランプは…

パトランプ

Zabbixに連動したパトランプを用意しましたが、鳴り響いたのは撤去作業の時のみでした。
(監視の止め忘れによるもの)

最後に

短い時間で資料をまとめ、懇親会会場で発表をした学生ツチノコNOCメンバーお疲れさまでした。
小さな事項を挙げればキリがないですが、大きなトラブルもなく会場ネットワークを提供できたかと思います。

ご利用いただいたJANOGerの皆さまありがとうございました!
ご協力いただいたツチノコNOCメンバーのみんなありがとうございました!

今回の会場ネットワーク構築について、ツチノコブログで更新していきますのでお見逃しなく!

 

JANOG39ミーティングはじまりました!

本日からJANOG39ミーティングがはじまりました!
雪景色の金沢は、初日から大盛況です。

ツチノコNOCもフル稼働!

ツチノコNOCは午前中からフル稼働で設営を行いました。
プログラムの構成上、Day1が一番部屋を使うので準備が山積みです。

朝のブリーフィングでは、部屋の暖房が効き始めるまでコートが脱げないメンバーたち。

朝のMTGⅢ 朝のMTG2

まずは、譜面台にAPをくくりつけます。
レクチャーを受けながらもくもくと作業が進みます。

譜面台Ⅲ 譜面台4

各部屋に設置される前のAP群。
譜面台2 譜面台5

そして、配置。
譜面台6

続いて、ケーブル配線です。

ケーブル配線Ⅲ ケーブル配線1

ケーブル養生も忘れずに。

養生 養生2

お昼前に設営を完了し、ランチを食べて午後からの開場に備えます。

ランチ

いざ、開場!
会場ネットワークのweatermapを見ると会場のネットワークのトラフィックの様子がわかって面白いですよ。

https://weathermap.tnoc.party/

こちらはJANOG初日のWiFiアクセスポイントへの接続数です。
アクセスポイント毎に色分けしてあるのですが、BoFの時間に人が会場を移動した様子が良くわかります。

201701181640

最後に

ホールの入り口は協賛一覧のパネルがお出迎えしてくれます!
協賛してくださった企業様、ありがとうございました!

ホール入り口

明日、明後日も会場でお会いできることを楽しみにしています!
凍っている道路もありますので、足元お気を付けください。

JANOG39ミーティングに向け、Wi-Fi機材を発送しました!

ご挨拶が遅くなりましたが、あけましておめでとうございます。
今年もどうぞよろしくお願いいたします!

2017年、1本目のブログはもちろんツチノコNOCの話題です。

機材を発送しました

下見を終えたツチノコNOCは、設計・構築(ホットステージ)を終え、機材を金沢に発送しました。

OLYMPUS DIGITAL CAMERA

OLYMPUS DIGITAL CAMERA

・ケーブル:5箱
・AP :2箱
・ルータ :1箱
・スイッチ:5箱
・ACアダプタ類:1箱
・スタッフパーカー:2箱

どんな機材を使ったか・どんな構成にしたかは、別途記事にしたいと思っています!
お楽しみに!

スタッフパーカーができました

弊社デザインチームがデザインしてくれたスタッフパーカーが届きました。
ツチノコブログでおなじみのチーノくんがデザインされたとってもキュートなパーカーです♥

IMG_0960 IMG_0961

ツチノコNOCのメンバーはこのパーカーを着ているので、よかったら探してみてくださいね。

金沢観光アプリ「金沢すきま旅」のご紹介

最後に、弊社で配信しているアプリのご紹介です。

金沢すきま旅
http://labo.dmm.com/special/sukima/

App StoreでiPhoneアプリを配信しています!
空いている時間を指定するとおすすめの観光施設を案内してくれる金沢観光にぴったりのアプリです!
JANOGで金沢に来たので観光もしたいな~という人におすすめです。
ぜひ、ご利用ください♪

最後に

JANOG39ミーティングの開催まで1週間をきりました!
来週の今頃は何事もなく会が終わっているといいな★と、願っております。

週末の北陸地方は雪予報がでています。
JANOG当日もお足元が悪い可能性がありますので、防寒などなどご準備くださいませ。