こんにちは、インフラ本部の大山裕泰です。
ここでは 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’ を暗号化して設定します。
ただ、これには 文字列型しか設定できない制限 が存在するため、使用する際には注意が必要になります。
