Ansible Rulebook とは

Ansible® Rulebook とは、イベント駆動型自動化モデルで IT 関連のアクションを実行するために Event-Driven Ansible が使用する条件付きルールセット (ルールブック) です。ルールブックを使用すると、監視対象のイベントソースに加え、そのイベントが発生し特定の条件が満たされたときに実行する処理を Event-Driven Ansible に指示できます。

ルールブックは、人間が読める YAML で記述します。この点は、Ansible Playbook と同様ですが、ルールブックでは、if-this-then-that 条件付きルールを使用してイベントアクションのトリガータイミングを定義します。ルールブックの指示に従い、Event-Driven Ansible では、イベントのターゲットソースを監視します。イベントが発生したらそれを認識し、適切なアクションを自動実行します。 

Ansible Rulebook を使用すると、必要な意思決定を体系化し、特定の条件が満たされたときに実行するアクションを設計できます。これにより、毎回同じ方法でアクションを実行することが可能です。条件が満たされたときには、既存の Ansible Playbook を開始することもできるため、チームが時間をかけて構築し拡張してきた Playbook の価値がさらに引き出されます。 

チームの知識に基づいてルールブックを作成して Event-Driven Ansible を使用すれば、人が介在しない自動化を実装できます。そのため、たとえば疲れた人間が繰り返し作業を行うことで生じるエラーを最小限に抑え、より効率的で一貫性のある IT プロセスを構築することができます。

時間のかかるタスクを自動化したり、あらゆる IT ドメインでの変化する条件に対応したりするにはイベント処理が必要となりますが、Event-Driven Ansible を導入すると、そのための機能を得られます。具体的には、IT 環境の状況に関する個別のインテリジェンスが含まれるイベントを処理して、イベントへの適切な対応を決定します。その後、アクションを自動実行し、イベントの対処や修復を行います。さらに、チケットの強化、修復、ユーザー管理といった IT サービス管理タスクに加え、IT 環境全体で実行するさまざまなタスクの自動化も可能です。

たとえば、可観測性ツール (イベントソース) でネットワークルーターを監視しているとしましょう。ルーターから応答がないことをこのツールが検出し、イベントとして認識します。このイベントを Event-Driven Ansible が受信し、イベントデータをルールブックの条件に照らし合わせて、それに一致する目的のアクション (構成の再適用、ルーターのリセット、サービスチケットの作成、トラフィックの再ルーティングなど) を判断します。その後、ルールブックの指示に従って、ルーターをリセットするというアクションをトリガーし、通常の機能に復元します。Event-Driven Ansible なら、そうした処理をいつでも実行できます。ネットワークエンジニアが直接対応できない深夜であっても実行可能なのです。

Event-Driven Ansible は Ansible Rulebook によって柔軟に活用できます。ルールを介してイベントソースと対応するアクションを結び付けることができるためです。

Ansible Rulebook にはイベントソースと条件付き指示 (ルール) が含まれます。こうしたルールによって、特定の条件が満たされたときに実行するアクションを指定します。ルールには、1 つの条件とそれに対応するアクションを記述します。複数のルールとアクションをグループ化したものをルールセットと呼び、Ansible Rulebook には、複数のルールセットを含めることができます。

Ansible Rulebook は柔軟であることが意図されており、以下のように構成できます。

• 1 つのソースを監視する、または複数のソースを監視する。 
• 1 つのルールを含める、または複数のルールを含める。
• 1 つのアクションをトリガーする、または複数のアクションをトリガーする。 

ソース、ルール、アクションのこうした柔軟性が、Event-Driven Ansible にも組み込まれるため、IT 環境で特定の条件が検出された際に必要なアクションを自由に設定できます。

(動画) ルールブックの概要 (再生時間：4:23)

ルールブックの先頭では、イベントを監視するソースを定義します。Event-Driven Ansible では、外部の監視ツールやアプリケーションといった、インテリジェントなイベントソースを利用してイベントを識別し、それらに関するデータを収集しています。Event-Driven Ansible をこうしたソースに接続してイベントをリッスンできるようにするには、イベント・ソース・プラグインを使用します。 

ansible.eda の Red Hat® Ansible Certified Content Collection には、数多くのビルド済みイベント・ソース・プラグインが収められており、これによって Event-Driven Ansible の使用を今すぐに始められます。ただし、Red Hat ではパートナーやベンダーに対して、自社の技術に特化して設計したカスタムプラグインを提供することで統合プロセスを単純化し、イベントデータからより多くの価値を引き出せるようにすることを推奨しています。

ansible.eda 認定コンテンツプラグイン

ansible.eda コレクションのイベント・ソース・プラグインを使用すると、イベント処理をすぐに開始できます。こうしたソースプラグインにより、Event-Driven Ansible がイベントをリッスンできるようになり、これによって、ルールブックの条件付きロジックを使用してイベントを処理し、実行するアクションを決定できます。イベントがルールブックの条件を満たさない場合、Event-Driven Ansible はアクションをトリガーせず、イベントは破棄されます。 

ansible.eda コレクションに収められた一般的なソースプラグインには、Webhook、Kafka、Prometheus Alertmanager などがあり、これらは、各種システムやツール、メッセージキュー、そして Prometheus などのエンタープライズ・イベント監視システムのアラートから送信される一般的なウェブフックに対応しています。 

こうしたプラグインに加え、Red Hat パートナーからも、自社の技術とソリューションに特化して作られた認定イベント・ソース・プラグインが提供されています。これらのプラグインは、Event-Driven Ansible がパートナーの技術と効果的に連携できる追加機能を備えていることがあります。また、独自のイベントソース用に独自のソースプラグインを作成することもできます。

たとえば、稼働しているネットワークスイッチでポートがダウンしたときのみ通知を受けたい場合、パートナーは Event-Driven Ansible がリッスンすべきスイッチ情報を厳密に指定するプラグインを構築できます。このパートナープラグインを使用すれば、スイッチで発生する全イベントの重要でない情報が昼夜を問わず次々に届くことがありません。認定プラグインの場合、デバイスのホスト名、問題、インシデント番号のみが配信されますが、Webhook などの汎用プラグインからは、その他の詳細情報、たとえば、送信者名、URL、トラブルシューティングのアクションに関係のないデータなどが届く場合があります。

ソースプラグインがイベントを検出し、そのイベントに関する情報を配信すると、Event-Driven Ansible がルールブックの条件付きルールを使用してそのデータをフィルタリングし、実行するアクションを決定します。ルールでは、柔軟な if-this-then-that シナリオを設定して、イベントデータが特定の条件を満たした場合に実行する手順を定義します。 

たとえば、ソースプラグインでネットワークルーターのポートを監視している場合、「ポートがダウンし、5 分間応答しない場合は、ルーターを再起動する」などのルールを指定します。イベントデータがこのルールでフィルタリングされ、条件を満たさなかった場合、アクションは実行されません。 

ルールブックは次のことが可能です。

• 1 つのルールを含める。または、複数のルールを含める。 
• 1 つの条件を含める。または、イベントステータスがすべて一致する必要のある複数の条件を含める。または、1 つだけ一致する必要のある複数の条件を含める。 
• =、≠、>、< といった従来のすべての数学演算子に対応する。
• 整数、文字列、ブール値 (and、or、not など)、浮動小数点数、null 条件の各データ型に対応する。 

たとえば、1 つのイベントを評価していて、複数の条件に一致させる場合は、ブール値 and を使用できます。つまり、アクションがトリガーされるには、これらの各条件が満たされる必要があります。
 

name: Combining ‘and’ operators
condition: event.version == "2.0" and event.name == "test" and event.alert_count > 10
action:
  debug:

複数のイベントを監視していて、複数の条件に一致させる場合は、all を使用できます。つまり、条件が一致したと見なされるには、各条件が満たされなければなりません。これらの条件は、複数のイベントに関連しているため、行を分けて記述しています。
 

name: Condition using both a fact and an event
condition:
  all:
    - fact.meta.hosts == "localhost"
    - event.target_os == "windows"
action:
  debug:

any を使用すると、いずれかの条件が満たされたときに条件が一致したと見なされ、アクションがトリガーされます。前述の例と同様に、このコードは複数のイベントを対象にしているため、行を分けて条件を記述しています。
 

name: Any condition can match
condition:
  any:
    - event.target_os == "linux"
    - event.target_os == "windows"
action:
  debug:

注：上記の例では、デバッグアクションにより、イベント情報が出力され、そのデータが Event-Driven Ansible に表示されるようにしています。

イベントデータがルールブックの条件を満たすと、Event-Driven Ansible によって、指定したアクションがトリガーされます。 

一般的なアクションを次に示します。

• Run_playbook：特定のアクション (サーバーのトラブルシューティングなど) の自動化を目的とした既存の Ansible Playbook を実行します。 
• Run_job_template：Red Hat Ansible Automation Platform の自動化コントローラーによってジョブテンプレートを実行します。テンプレートは Ansible Automation Platform 内で実行するため、インベントリー管理、ユーザーおよびアクセス制御、完了アクションの分析などを利用できるというメリットがあります。 
• Run_module：既存の Ansible モジュールを実行します。これにより、Playbook 全体を実行したくない場合に、より具体的な特定のアクションを実行できます。
• Post_event：実行中のルールセットにイベントを投稿します。通常、run_playbook または run_job_template アクションの後に記述することで、アクションの結果に関する情報を Event-Driven Ansible にフィードバックできます。
• Set_fact：イベントまたはアクションに関する特定のデータを記録することで、Event-Driven Ansible にそれらをフィードバックし、他のアクションに使用できるようにします。イベントデータは一時的に保持されるものですが、ファクトを設定すると、イベントに関する特定の情報を保存して、永続的に保持できます。
• Debug：Ansible Playbook のデバッグに似たアクションです。引数を指定していない場合は、一致するイベントペイロードとその他の重要な情報が出力されます。

このセクションでは、Ansible Rulebook の簡単な例をいくつか紹介します。理解したり記憶したりできない記述があっても構いません。これらの例は、完成したルールブック内でソース、ルール、アクションが一緒になってどのように機能するかについての基本的な考え方を理解していただくためのものです。 

最初の例では、かなり単純な 1 つのアクションに重点を置いています。このコードに基づくと、イベントソースで障害が発生したときに、Event-Driven Ansible によって、修復 Playbook が実行されます。
 

rules:
  - name: An automatic remediation rule
    condition: event.outage == true
    action:
      run_playbook:
        name: remediate_outage.yml

次のやや複雑なルールブックの例では、イベントソースを Dynatrace 認定ソースプラグインとして定義しています。このルールでは、リッスン対象の条件を定義しており、具体的には、アプリケーションとハードウェアの使用状況に関する条件を指定しています。
 

---
- name: Listen for events on a webhook
  hosts: all
  sources:
    - dynatrace.eda.dt_esa_api:
        dt_api_host: "https://abc.live.dynatrace.com"
        dt_api_token: "asjfsjkfjfjh"
        delay: 60 
  Rules:
    - name: Problem payload Dynatrace for CPU issue
      condition: event.payload.problemTitle contains "CPU saturation"
      action:
        run_job_template:
          name: "Remediate CPU saturation issue"
          organization: "Default"
    - name: Problem payload Dynatrace for App Failure rate increase issue
      condition: event.payload.problemTitle contains "Failure rate increase"
      action:
        run_job_template:
          name: "Remediate Application issue"
          organization: "Default"
    - name: Update comments in Dynatrace
      condition: 
        all: 
          - event.status == "OPEN"
      action:
        run_playbook:
          name: dt-update-comments.yml

イベントペイロードを受信したら「CPU saturation」または「Failure rate increase」のメッセージを確認します。ペイロード内にこうしたメッセージがあった場合、Event-Driven Ansible はこれらのイベントを修復 Playbook またはジョブテンプレートと照合して問題を解決します。

Red Hat Ansible Automation Platform では人間が読める YAML 言語が使用されるため、ユーザーは自動化コンテンツを共有、検証、管理できます。Red Hat Ansible Automation Platformには、Event-Driven Ansible、Playbook、分析など、全社的な自動化の実装に必要なあらゆるツールが揃っています。また、視覚的なダッシュボードやロールベースのアクセス制御などの機能により、IT インフラストラクチャを一元的に制御し、運用の複雑さを軽減できます。

Red Hat サブスクリプションを使うことで、堅牢なパートナーエコシステムからの認定コンテンツ、ホストされた管理サービスへのアクセス、組織全体で自動化を拡張するためのライフサイクルのテクニカルサポートを利用できます。また、数千ものお客様を支援し蓄積してきた Red Hat の専門知識を活用できます。

Red Hat Ansible Lightspeed (および IBM watsonx Code Assistant) を導入すると、初心者にも Ansible が利用しやすくなり、経験豊富な Ansible 作成者の場合は、生産性と効率が向上し、エラーのない状態するのを助けます。開発者はタスクリクエストは平易な英語で入力できます。Ansible Lightspeed は IBM watsonx 基盤モデルと対話し、Ansible Playbook を作成するために使用される推奨するコード情報を生成します。