OCI Functionsサービスでイベント通知メールを成型してみる（2）

クラウドサービス部の石田です。

OCI Functionsサービス（以下、Functions）でのイベント通知のメール成型をご紹介する連載の第2回です。前回はFunctionsを作成して実際に実行するところまでやってみました。今回は通知メール成型機能の実装に向けて、実際にFunctionsをイベント・サービスから呼び出してみましょう。

まずは、今回使用することになるイベント・サービスについて説明していきます。

イベント・サービスとは

Oracle Cloud Infrastructure（以下、OCI）上のイベントは、自動または手動でリソースの状態が変化するたびに発生します。イベント・サービスとは特定のイベントの発生を監視し、検知すると別のOCIサービスにイベント内容を渡して処理させるサービスです。

イベントを渡せるサービスには以下のようなものがあります。

• 通知
• ストリーミング
• Functions

今回は、この3番目のFunctionsを利用します。1番目の「通知」は、連載第3回以降で使用するので、そちらで説明します。2番目の「ストリーミング」は本稿の範囲から外れるので、説明は割愛します。

イベント・サービスからファンクションを起動する

それではイベント・サービスからFunctionsを呼び出すよう設定します。まずは、呼び出されるファンクションを作りましょう。ファンクション名・アプリケーション名はともに「event-test」とします。

アプリケーションとファンクションの作成

アプリケーション「event-test」と、ファンクション「event-test」を作成します。

前回やった通りOCIコンソール画面上の指示をコピペ・修正しながら進めていくのですが、作業したクラウドシェルの環境が残っていれば手順の項番2～6は省略可能です。項番7以降の手順も同様に、適宜コマンドラインを修正しながら実行します。今の時点ではコードは手をつけず、このファンクションをイベントから呼び出すようにします。

ファンクションログの有効化

Functionsは実行状態がユーザから見えないため、想定外の動作をした時に参照できる情報を別途出力し、保管しておく必要があります。そのためにOCIのログ・サービスを有効にします。一般に業務として使用するファンクションは、ログは有効にしておくことをお勧めします。特に今回はイベントから実行するので、想定された結果が得られなかった場合、そもそもファンクションが本当に実行されたかすらユーザからは分かりません。それではテストにならないのでログ出力を設定します。

アプリケーションの画面左下のメニューから「Logs」を選択すると設定画面が表示されるので、そこで「Function Invocation Logs」の「ログの有効化」スイッチをオンにします。

すると、ログの設定画面が表示されます。今回は専用のログ・グループとして「Functions」というログ・グループを作成して利用します。コンパートメントはファンクションと同じ所にし、後はデフォルトのままで「ログの有効化」をします。

以下のように、ログが有効になりました。ログ名の部分をクリックするとログの表示画面に遷移します。

まだ何も実行していないので「No data to display」と言われていますが、ファンクションを実行するとログが蓄積され、ここから検索可能になります。ちなみに、OCIメニューから「監視および管理」、「ロギング」、「ログ」の順でクリックしてもこの画面を表示できます。

イベント・ルールの設定

次はイベント・サービスを設定しましょう。イベント・サービスの設定内容としては、まず検知するイベントの種類を設定し、次に検知した際に起こすアクションを設定します。今回は検証用に手動で発生させやすいイベントにしたいので、コンピュート・インスタンスの起動停止の操作のイベント検知を行ってみます。「server01」というインスタンスを対象にします。

OCIメニューの「監視および管理」、「イベント・サービス」、「ルール」の順に選択するとイベント・ルールの画面が表示されるので、「ルールの作成」ボタンを押します。

ルールの設定画面が表示されるので、以下のように設定します。

「表示名」は、「server01-power-op」とします。次にルール条件を設定します。「条件」のリストボックスを開くと「イベント・タイプ」か「フィルタ・タグ」を選べますが、今回はイベント検出に利用するので、デフォルトの「イベント・タイプ」のままにしておきます。

イベント・タイプの指定

次は検知したいイベント発生元のサービスを設定します。今回はコンピュートについてのイベントなので「Compute」を設定します。「サービス名」のリストから選択してください（このリストはインクリメンタルサーチが使えます）。その後、イベント・タイプを設定します。このイベント・タイプはドキュメントにまとめられているので^※1、それを参考に監視したいイベントを指定します。

ただ、このドキュメントだけでは監視したいものが実際どれにあたるのかわかりにくいこともあるので、実際に発生させられるイベントであれば、発生させて監査ログで確認するようにした方が良いでしょう。

※1 Services that Produce Events｜Oracle Cloud Infrastructure Documentation

監査ログを使った対象イベントのタイプ確認方法

監査ログで実際に発生するイベントを確認したい場合は、まず目的の操作を実際に実行し、その後そのイベントを監査ログで特定し表示します。すると、「タイプ」という項目があり、これがイベント・ルールで設定すべき値になります。

監査ログで確認すると、起動停止の操作の際には操作開始時に「com.oraclecloud.computeApi.InstanceAction.begin」というイベントが発生することがわかります。これを先述の公式ドキュメントと照らし合わせると「Instance Action Begin」にあたるので、これをルール設定画面のイベント・タイプに設定します。

属性指定の追加

これでルールを設定できましたが、このままの状態だと該当コンパートメント内の全てのインスタンスの起動停止に反応してしまいます。そのためさらに条件を追加して、目的のインスタンスの操作のみでイベントが発生するように絞り込んでいきます。

「＋別の条件」ボタンを押し、条件記載欄を追加します。ここで「条件」のリストを開くと、先ほど確認した際の「イベント・タイプ」と「フィルタ・タグ」に加え、新しく「属性」という選択肢が増えているのがわかります。これは先ほど指定したイベントの属性値による条件設定になります。

イベントにどのような属性があるかはリストボックスから選べますが、そこにあるもの以外も直接手入力することによって設定可能です。イベント属性はJSONにまとめられてイベントに渡される^※2ので、そのJSONを実際に見て設定可能な属性を確認します。

※2 イベント・メッセージの内容｜Oracle Cloud Infrastructureドキュメント

イベントJSONの例を取得するには2つの方法があります。サンプル・イベントJSONを確認する方法と、監査ログからJSONを確認する方法です。

• 1.サンプル・イベントJSONを確認
  ルール設定画面の右側の「サンプル・イベントの表示（JSON）」というリンクから確認できます。リンクをクリックするとサンプルのイベントがJSON化されたものが表示されるので、利用可能な属性を確認します。

  

  例として、今回のインスタンスの起動停止操作の場合は以下のようなサンプルJSONが出力されます。

  {
    "eventType": "com.oraclecloud.computeapi.instanceaction.begin",
    "cloudEventsVersion": "0.1",
    "eventTypeVersion": "2.0",
    "source": "ComputeApi",
    "eventTime": "2019-08-16T12:07:14.623Z",
    "contentType": "application/json",
    "data": {
      "compartmentId": "ocid1.compartment.oc1..unique_ID",
      "compartmentName": "example_compartment",
      "resourceName": "my_instance",
      "resourceId": "ocid1.instance.oc1.phx.unique_ID",
      "availabilityDomain": "availability_domain",
      "additionalDetails": {
        "imageId": "ocid1.image.oc1.phx.unique_ID",
        "instanceActionType": "start",
        "shape": "VM.Standard2.1",
        "type": "CustomerVmi"
      }
    },
    "eventID": "unique_ID",
    "extensions": {
      "compartmentId": "ocid1.compartment.oc1..unique_ID"
    }
  }

• 2.監査ログからJSONを確認
  監査ログからも確認できます。先ほど同様、対象のイベントを再現できる場合のみ可能な方法です。監査ログに対象のイベントが格納される話は先ほどしましたが、その表示画面の右側に下向き矢印があるので、それをクリックすると実際に発生したイベントのJSONが表示されます。

  

  この方法は実際の属性値も確認でき、サンプル・イベントJSONを確認する方法では出てこない属性もあるので、利用可能ならばこちらの方がお勧めです。ちなみに特に成型処理を行わないと、イベントの通知メールはこのJSONがメール本文にそのまま入れられて送られてきます。成型処理が必要なわけですね......。

これらの方法で確認したJSONを元に、キー名を確認しルールの属性値に設定していきます。JSONの階層構造は無視されるのでキー名だけを確認します。JSONは、ファンクションのコードを開発する際に参照したり動作確認に使ったりすることが多いので、コピペしてクラウドシェルや開発環境にファイル化して配置しておくと便利です。

今回の対象イベント（「server01」というサーバの起動停止の操作のイベント）を絞り込む属性を探してみると、JSONの「resourceName」と言うキーがインスタンス名を示しています。そのため、この属性が「server01」のイベントを検知するように設定します。「条件」は「属性」、「属性名」は「resourceName」、「属性値」は「server01」と、それぞれ入力していきます（属性値は直接手入力）。

アクションの設定

次は「アクション」を設定します。先ほど作成した「event-test」ファンクションを呼び出したいので、以下のように設定します。

項目	設定値
アクション・タイプ	ファンクション
コンパートメント	ファンクションが存在するコンパートメント
ファンクション・アプリケーション	event-test
ファンクション	event-test

全て入力すると以下のような画面になっているはずです。

全部設定できたら「ルールの作成」ボタンで確定します。これで、「server01」というサーバの起動停止の操作のイベントが発生すると「event-test」ファンクションが実行される準備が整いました。

イベントからの起動テスト

それでは実際に起動するか確認してみましょう。インスタンス「server01」を起動させてみます。

「event-test」ファンクションはサンプルコード状態なので、目に見える処理が実行されるわけではありません。確認するには先ほど設定したファンクションのログを見ます。

すると、以下のように3つのエントリが発生していることがわかります。なお、画面表示されている順番は降順なので逆になっています。

• ファンクションの開始リクエスト
• ファンクションコード内からの「Inside Python Hello World function」というメッセージ（画面例では見切れていますが）
• ファンクションが実時間でどれほどかかったか等の実行情報

ちゃんとインスタンス操作を検知してファンクションが実行されているようですね。

おわりに

これでイベント・サービスからファンクションを呼び出せるようになりましたが、中身はサンプルコードなので処理は何も実行されていません。次回はコードを用意して、成形メールの送付まで実現したいと思います。お楽しみに。

プロフィール