動かしてみる
構築したStackStorm環境に対して、以下のようにAWSで発生したイベントを検知してアクションcore.localを実行する環境を構築します（core.localがどんな処理を行うかについては以降で解説します）。
ここではAmazon CloudWatchで検出されたAmazon EC2のリソース変更のイベントを検知し、core.localアクションを実行させます。
core.localはWorkerノードにおいて任意のコマンドを実行するアクションになります。StackStormでは次のように、アクションを単体実行することもできます。
パラメータcmdで受けたコマンドdateを、ローカルノードst2-nodeで実行しています。実行結果のresult.stdoutパラメータから、当該アクションで得られた標準出力の結果を確認できます。またstatusから、当該アクションが正常終了（succeeded）したことが確認できます。
以下では、このアクションを冒頭の図で示したようにaws.sqs_new_messageトリガが引かれた際に実行する方法を解説します。
環境構築
ここでは以下の設定を行い、AWSのイベントが呼ばれた際にcore.localアクションが実行されるようにします。
- aws packのインストール
- aws packの設定
- Amazon SQS、CloudWatchの設定
- Ruleの設定
aws packのインストール
サードパーティのさまざまなpackがStackStorm Exchangeに登録されており、ここに登録されているpackを以下のコマンドでインストールできます。ここではawsの最新のpackをインストールします。
$ st2 pack install aws
インストールされたpackは以下のコマンドで確認できます。
$ st2 pack list
aws packの設定
インストールされたpackに関連するファイルは、通常/opt/stackstorm/packs配下に展開されます。今回インストールしたaws packの場合は/opt/stackstorm/packs/awsになります。
また各packの設定ファイルconfig.yamlが、packのディレクトリのトップに配置されます。ここでawsの設定ファイルを次のように編集してください。
--- aws_access_key_id: "*****" aws_secret_access_key: "******" region: "ap-northeast-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: "notification_queue" sqs_other: max_number_of_messages: 1
冒頭のaws_access_key_id,aws_secret_access_keyおよびregionで認証情報とリージョンを設定しています。aws_access_key_idとaws_secret_access_keyの取得方法についてはAWSのドキュメントを参照してください。リージョンは東京リージョンap-northeast-1を指定します。
またイベントメッセージが通知されるAmazon SQSのキュー名notification_queueを指定します。ここで指定したキューはこの後でAWSマネジメントコンソールから作成します。
最後に、更新した設定を読み込ませるため、センサを再起動させます。
$ sudo st2ctl restart-component st2sensorcontainer
Amazon SQS、CloudWatchの設定
Amazon SQSはAmazonが提供するフルマネージのMQサービスで、CloudWatchはモニタリングサービスです。ここではCloudWatchにおいてEC2やS3などのリソースが変更された際に、Amazon SQSに通知メッセージを送るように設定します。
StackStormはSQSに送られたメッセージを取得することで、間接的にAWSのイベントをハンドリングできます。StackStormはSQSを利用する方法の他に、Amazon SNSを利用して通知を取得することもできます。後者の設定方法については、本稿では割愛します。
では、それぞれの設定を実施します。
まず以下のようにAmazon SQSのコンソールから、packの設定ファイルのsqs_sensor.input_queuesで指定した名前のキューを作成します。
続いてCloudWatchのコンソールでEC2のイベントをSQSのキューnotification_queueに送るルールを作成します。
ここまでの設定でEC2のイベントをaws packのセンサAWSSQSSensorで検知する準備が整いました。
Ruleの設定
次に、センサAWSSQSSensorがトリガaws.sqs_new_messageを引いた際に、アクションcore.localを実行するルールを定義します。
以下がルール定義の全文になります。ルール定義はYAML形式で記述します。これをホームディレクトリにec2_event_handling.yamlという名前で保存します。
---
name: 'ec2_event_handling'
description: 'A rule to get events on Amazon EC2'
enabled: True
trigger:
type: aws.sqs_new_message
action:
ref: 'core.local'
parameters:
cmd: 'echo "{{trigger.body}}" >> /tmp/results'
criteria:
trigger.queue:
pattern: 'notification_queue'
type: 'equals'
冒頭のnameとdescriptionは、それぞれルールのラベルと説明文を表します。enabledパラメータは、当該ルールを有効化するかどうかを設定するためのもので、Falseを指定した場合には、ルールで指定したトリガが引かれてもアクションを実行しません。
またtriggerとactionパラメータによって、トリガとアクションの紐付けを行っています。それぞれtrigger.typeとaction.refパラメータでどのトリガが引かれたら、どのアクションを実行するかを指定しています。
末尾のcriteriaでは、アクションを実行する条件を記述することができます。StackStormのルールエンジン（RuleEngine）は、trigger.typeで指定したトリガが引かれ、かつcriteriaで指定した条件に合致した場合にaction.refで指定したパラメータを実行します。ここでは、以下で示すトリガパラメータのqueueの値がnotification_queueだった場合に、アクションを実行する設定を記述しています。
なおcriteriaパラメータは省略可能です。その際はtrigger.typeのトリガが引かれた場合にaction.refのアクションを実行します。
アクションの指定に関してもう少し詳しく解説します。action.parametersでは、トリガからの出力パラメータとアクションへの入力パラメータの変換設定を行っています。ここでは、トリガの出力bodyパラメータをechoコマンドの引数に指定しています。
トリガとアクションがそれぞれがどういったパラメータを持っているかについてはst2 action getとst2 trigger getコマンドで確認できます。以下は、それぞれのパラメータを確認した結果です。
トリガaws.sqs_new_messageの出力としてqueueとbodyのパラメータがあり、そしてアクションcore.localの入力としてcmdとsudoパラメータがあることが分かります。またアクションの入力パラメータのうちcmdはrequired: trueとなっており、必須パラメータであることを表しています。
動作確認
ここでいよいよルールを登録してEC2にインスタンスを作成し、そのイベントを検知できるか確認します。
まずは以下のコマンドで、先ほど作成したルールを登録します。
続いてEC2のコンソールから、インスタンスtest-instanceを作成します。
程なくして、ルールで記述したechoコマンドのリダイレクト先のファイル/tmp/resultsにCloudWatchの出力が表示されることが確認できます。
ここまでEC2のイベントをStackStormで受け取り、ユーザ定義のルールに沿って処理する方法について解説してきました。ここまでの内容を応用することで、さまざまなアプリケーションサービスと連携する処理を簡単に設定することができます。
なお、本章の内容を実際に動かして確認するにはクレジットカード登録を行ったAWSアカウントが必要になり、手軽に試すことができないユーザもいるかもしれません。そうした方はツチノコブログに別の例（GitHubとRabbitMQを利用したイベントハンドリング）を示しましたので、併せてご参照ください。
