Event-Driven Ansible Controller ユーザーガイド
Event-Driven Ansible Controller を設定して使用し、自動化を強化および拡張する方法
概要
はじめに
Event-Driven Ansible Controller は、一貫性と復元力を実現しながら IT の速度と俊敏性を向上させることで、自動化を強化および拡張する新しい方法です。Red Hat によって開発されたこの機能は、シンプルさと柔軟性を考慮して設計されています。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ)
技術的な内容に関するフィードバックをお寄せいただきありがとうございます。皆様のご意見をお待ちしています。コメントの追加、Insights の提供、誤字の修正、および質問を行う必要がある場合は、ドキュメントで直接行うこともできます。
Red Hat アカウントがあり、カスタマーポータルにログインしている必要があります。
カスタマーポータルからドキュメントのフィードバックを送信するには、以下の手順を実施します。
- Multi-page HTML 形式を選択します。
- ドキュメントの右上にある Feedback ボタンをクリックします。
- フィードバックを提供するテキストのセクションを強調表示します。
- 強調表示されたテキストの横にある Add Feedback ダイアログをクリックします。
- ページの右側のテキストボックスにフィードバックを入力し、Submit をクリックします。
フィードバックを送信すると、自動的に問題の追跡が作成されます。Submit をクリックすると表示されるリンクを開き、問題の監視を開始するか、さらにコメントを追加します。
第1章 Event-Driven Ansible Controller の概要
Event-Driven Ansible は、他のソフトウェアベンダーのモニタリングツールなどのイベントソースと連携する、拡張性が高く柔軟な自動化機能です。このようなツールは、IT ソリューションを監視してイベントを特定し、ルールブックに記述された変更や対応を自動的に実装して、そのイベントを処理します。
ユーザー設定は次の手順で行います。
第2章 プロジェクト
プロジェクトはルールブックの論理的なコレクションです。これは git リポジトリーである必要があり、http プロトコルのみがサポートされます。プロジェクトのルールブックは、プロジェクトのルートの /rulebooks フォルダー、または Ansible コレクション内の Event-Driven Ansible コンテンツ用に定義されたパス /extensions/eda/rulebooks に配置する必要があります。
2.1. 新しいプロジェクトの設定
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- 必要に応じて、認証情報が設定されている。詳細は、Automation Controller ドキュメントの Credentials セクションを参照してください。
- Automation Controller が使用する、リポジトリーに含まれている Playbook と統合されたルールブックを含む既存のリポジトリーがある。
手順
- Event-Driven Ansible Controller ダッシュボードにログインします。
- ナビゲーションパネルから、Projects → Create project を選択します。
以下を入力します。
- Name
- プロジェクト名を入力します。
- Description
- このフィールドは任意です。
- SCM type
- Git のみ使用できます。
- SCM URL
GitHub や GitLab などのリポジトリーの HTTPS プロトコルアドレス。
注記プロジェクトの作成後に SCM URL を編集することはできません。
- Credential
- このフィールドは任意です。これは、SCM URL を利用するために必要なトークンです。
- Create Project を選択します。
プロジェクトが作成され、Projects 画面で管理できるようになります。
新しいプロジェクトを保存すると、プロジェクトの詳細ページが表示されます。詳細ページまたは Projects リストビューから、プロジェクトを編集または削除できます。
2.2. Projects リストビュー
Projects ページでは、作成したプロジェクトを ステータス および Git ハッシュ とともに確認できます。
ソース管理でルールブックが変更された場合は、Projects リストビューでプロジェクトの横にある同期アイコンを選択することで、プロジェクトを再同期できます。Git ハッシュ の更新は、そのリポジトリー上の最新のコミットを表します。更新されたプロジェクトを使用する場合は、アクティベーションを再開または再作成する必要があります。
2.3. プロジェクトの編集
手順
- Projects リストビューで、目的のプロジェクトの横にある More Actions アイコン ⋮ を選択します。
- Edit project を選択します。
- 必要な変更を入力し、Save project を選択します。

2.4. プロジェクトの削除
手順
- Projects リストビューで、目的のプロジェクトの横にある More Actions アイコン ⋮ を選択します。
- Delete project を選択します。
- ポップアップウィンドウで、Yes, I confirm to delete this project を選択します。
- Delete project を選択します。
第3章 意思決定環境
意思決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。意思決定環境は、自動化の依存関係を伝達するための共通言語を作成し、自動化環境をビルドおよび配布するための標準的な方法を提供します。デフォルトの意思決定環境は Ansible-Rulebook にあります。
独自の意思決定環境を作成するには、Ansible Automation Platform 内での Event-Driven Ansible のカスタム意思決定環境のビルド を参照してください。
3.1. 新しい意思決定環境の設定
次の手順では、Event-Driven Ansible Controller ダッシュボードに意思決定環境をインポートする方法を説明します。
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- 必要に応じて、認証情報が設定されている。詳細は、Automation Controller ドキュメントの Credentials セクションを参照してください。
-
意思決定環境イメージをイメージリポジトリーにプッシュしたか、registry.redhat.io で提供されている
de-supportedイメージを使用することを選択した。
手順
- Event-Driven Ansible Controller ダッシュボードに移動します。
- ナビゲーションパネルから、Decision Environments → Create decision environment を選択します。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Image
- これは、コンテナーレジストリー、イメージ名、およびバージョンタグを含む完全なイメージの場所です。
- Credential
- このフィールドは任意です。これは、意思決定環境イメージを利用するために必要なトークンです。
- Create decision environment を選択します。
これで意思決定環境が作成され、Decision Environments 画面で管理できるようになります。
新しい意思決定環境を保存すると、意思決定環境の詳細ページが表示されます。詳細ページまたは Decision Environment リストビューから、意思決定環境を編集または削除できます。
3.2. Ansible Automation Platform 内での Event-Driven Ansible のカスタム意思決定環境のビルド
デフォルトの意思決定環境では利用できない、メンテナンス対象またはサードパーティーのカスタムイベントソースプラグインを提供するために、カスタム意思決定環境が必要な場合は、このセクションを参照してください。
前提条件
- Ansible Automation Platform 2.4 以降
- Event-Driven Ansible
- Ansible Builder 3.0 以降
手順
de-supported意思決定環境を追加します。このイメージは、de-minimalと呼ばれる Red Hat が提供するベースイメージからビルドされます。注記Red Hat は、Ansible Builder でベースイメージとして de-minimal を使用して、カスタム意思決定環境をビルドすることを推奨しています。
以下は、ansible.eda コレクションでカスタム意思決定環境をビルドするために、ベースイメージとして de-minimal を使用する Ansible Builder 定義ファイルの例です。
version: 3
images:
base_image:
name: 'registry.redhat.io/ansible-automation-platform-24/de-minimal-rhel8:latest'
dependencies:
galaxy:
collections:
- ansible.eda
python_interpreter:
package_system: "python39"
options:
package_manager_path: /usr/bin/microdnfさらに、他の python パッケージまたは RPM が必要な場合は、1 つの定義ファイルに以下を追加します。
version: 3
images:
base_image:
name: 'registry.redhat.io/ansible-automation-platform-24/de-minimal-rhel8:latest'
dependencies:
galaxy:
collections:
- ansible.eda
python:
- six
- psutil
system:
- iputils [platform:rpm]
python_interpreter:
package_system: "python39"
options:
package_manager_path: /usr/bin/microdnf第4章 トークンの設定
Automation Controller には、Event-Driven Ansible ルールブックと連携するように設計された Playbook を含むリポジトリーをベースとしたプロジェクトが含まれている必要があります。Automation Controller には、そのプロジェクト内の Playbook に基づいて設定された対応するジョブテンプレートも必要です。
4.1. Ansible Automation Platform Controller に対して認証するためのトークンの設定
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- ユーザーを作成している。
- Event-Driven Ansible Controller ダッシュボードにログインできるか、組織内のユーザーとして追加されている。
手順
- Event-Driven Ansible Controller ダッシュボードに移動します。
- 上部のナビゲーションパネルからプロファイルを選択します。
- User details に移動します。
- Controller Tokens → Create controller token を選択します。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Token
Automation Controller でトークンを作成します。トークンの作成に関する詳細は、Automation Controller ユーザーガイドの Users - Tokens のセクションを参照してください。
注記トークンは write-scope である必要があります。
- Create controller token を選択します。
新しいトークンを保存すると、Controller Tokens タブが表示され、そこでトークンを削除できます。
第5章 ルールブックアクティベーション
ルールブックアクティベーションは、特定のルールブックを実行する意思決定環境によって定義されるバックグラウンドで実行されるプロセスです。
5.1. ルールブックアクティベーションの設定
前提条件
- Event-Driven Ansible Controller ダッシュボードに Content Consumer としてログインしている。
- プロジェクトを設定している。
- 意思決定環境を設定している。
- Automation Controller のトークンを設定している。
手順
- Event-Driven Ansible Controller ダッシュボードに移動します。
- ナビゲーションパネルから、Rulebook Activations → Create rulebook activation を選択します。
以下を入力します。
- Name
- 名前を入力します。
- Description
- このフィールドは任意です。
- Project
- プロジェクトはルールブックの論理的なコレクションです。
- Rulebook
- 選択したプロジェクトに応じてルールブックが表示されます。
- Decision environment
- 意思決定環境は、Ansible ルールブックを実行するためのコンテナーイメージです。
- Restart policy
これは、ルールブックを再起動する条件を決定するためのポリシーです。
Policies:
- Always: ルールブック終了時に再起動します。
- Never: 終了時にルールブックを再起動しません。
- On failure: 失敗した場合にのみ再起動します。
- Rulebook activation enabled?
- これを選択すると、ルールブックアクティベーションが自動的に有効になります。
- Variables
-
ルールブックの変数は JSON/YAML 形式です。内容は、ansible-rulebook コマンドの
--varsフラグによって渡されるファイルと同等です。
- Create rulebook activation を選択します。
ルールブックアクティベーションが作成され、Rulebook Activations 画面で管理できるようになります。
新しいルールブックアクティベーションを保存すると、ルールブックアクティベーションの詳細ページが表示されます。詳細ページまたは Rulebook Activations リストビューから、ルールブックアクティベーションを編集または削除できます。
5.2. ルールブックアクティベーションのリストビュー
Rulebook Activations ページでは、作成したルールブックアクティベーションを、アクティベーションステータス、ルールブックに 関連付けられたルールの数、起動数、および 再起動数 とともに確認できます。
Activation Status が Running の場合、ルールブックのアクティベーションがバックグラウンドで実行されており、ルールブックで宣言されたルールに従って必要なアクションが実行されていることを意味します。
Rulebook Activations リストビューからアクティベーションを選択すると、詳細を確認できます。
![Rulebook activation][width=25px](https://access.redhat.com/webassets/avalon/d/Red_Hat_Ansible_Automation_Platform-2.4-Event-Driven_Ansible_controller_user_guide-ja-JP/images/2b2fdf25e67d6f64b92e05f42a6918c4/eda-rulebook-activations-list-view.png)
実行されたすべてのアクティベーションについて、Details タブと History タブを表示して、実行結果に関する詳細情報を取得できます。
5.2.1. アクティベーションの出力の表示
アクティベーションの出力は History タブで確認できます。
手順
- History タブを選択して、すべてのアクティベーションインスタンスのリストにアクセスします。1 つのアクティベーションインスタンスは、1 回のアクティベーションの実行を表します。
- 対象のアクティベーションインスタンスを選択すると、その特定の実行によって生成された Output が表示されます。

アクションをトリガーした受信イベントを表示するには、Event-Driven Ansible コントローラーダッシュボードの Rule Audit セクションを使用できます。
5.3. ルールブックアクティベーションの有効化および無効化
- 行レベルのスイッチを選択して、選択したルールブックを有効または無効にします。
- ポップアップウィンドウで、Yes, I confirm that I want to enable/disable these X rulebook activations 選択します。
- Enable/Disable rulebook activation を選択します。
5.4. ルールブックアクティベーションの再起動
ルールブックアクティベーションが現在有効であり、作成時に再起動ポリシーが Always に設定されていた場合にのみ、ルールブックアクティベーションを再起動できます。
- Rulebook Activation enabled/disabled トグルの横にある More Actions アイコン ⋮ を選択します。
- Restart rulebook activation を選択します。
- ポップアップウィンドウで、Yes, I confirm that I want to restart these X rulebook activations を選択します。
- Restart rulebook activations を選択します。
5.5. ルールブックアクティベーションの削除
- Rulebook Activation enabled/disabled トグルの横にある More Actions アイコン ⋮ を選択します。
- Delete rulebook activation を選択します。
- ポップアップウィンドウで、Yes, I confirm that I want to delete these X rulebook activations を選択します。
- Delete rulebook activations を選択します。
5.6. Webhook ルールブックのアクティブ化
Openshift 環境では、ルールブックアクティベーションの Kubernetes サービスを公開するルートを作成することで、Webhook が特定のポートを介して activation-job-pod に到達できるようにすることが可能です。
前提条件
- Event-Driven Ansible Controller ダッシュボードでルールブックアクティベーションを作成している。
特定の Webhook を含むルールブックの例を以下に示します。
- name: Listen for storage-monitor events
hosts: all
sources:
- ansible.eda.webhook:
host: 0.0.0.0
port: 5000
rules:
- name: Rule - Print event information
condition: event.meta.headers is defined
action:
run_job_template:
name: StorageRemediation
organization: Default
job_args:
extra_vars:
message: from eda
sleep: 1手順
サービスを公開するためのルートを (OpenShift Container Platform 上に) 作成します。以下は、意思決定環境 Pod のポート 5000 で POST を要求する ansible-rulebook ソースのルートの例です。
kind: Route apiVersion: route.openshift.io/v1 metadata: name: test-sync-bug namespace: dynatrace labels: app: eda job-name: activation-job-1 spec: host: test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com to: kind: Service name: activation-job-1 weight: 100 port: targetPort: 5000 wildcardPolicy: Noneルートを作成したら、ルート URL へのポスト を使用してテストします。
curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'注記ポートはルート (targetPort) で指定されているため、必要ありません。
5.7. Kubernetes を使用したテスト
Kubernetes を使用すると、Ingress の作成やポートの公開を行うことができます。ただし、これは実稼働環境用のものではありません。
手順
次のコマンドを実行して、クラスター上の特定のサービスのポートを公開します。
kubectl port-forward svc/<ACTIVATION_SVC_NAME> 5000:5000
localhost:5000に対して HTTP リクエストを実行して、ルールブックをトリガーします。curl -H "Content-Type: application/json" -X POST test-sync-bug-dynatrace.apps.aap-dt.ocp4.testing.ansible.com -d '{}'
第6章 ルール監査
ルール監査では、ある時点においてアクティブ化されたすべてのルールによってトリガーされたルールを監査できます。
Rule Audit リストビューには、ルールブック内の条件と一致してアクションをトリガーしたイベントを受信した各タイミングのリストが表示されます。リストにはルールブック内のルールが表示され、各見出しに実行されたルール名が表示されます。
6.1. ルール監査の詳細の表示
Rule Audit リストビューから、特定のアクションをトリガーしたイベントを確認できます。

手順
- ナビゲーションパネルから Rule Audit を選択します。
- 目的のルールを選択すると、Details タブが表示されます。
ここから、作成日時、最後に起動した日時、および対応するルールブックアクティベーションを確認できます。
6.2. ルール監査イベントの表示
手順
- ナビゲーションパネルから Rule Audit を選択します。
- 目的のルールを選択すると、Details タブが表示されます。アクションをトリガーしたすべてのイベントを表示するには、Events タブを選択します。選択すると、アクションをトリガーしたイベントが表示されます。
- イベントを選択すると、Event log が Source type と Timestamp とともに表示されます。

6.3. ルール監査アクションの表示
手順
- ナビゲーションパネルから Rule Audit を選択します。
- 目的のルールを選択すると、Actions タブが表示されます。
ここから、実行されたアクションを確認できます。一部のアクションは Automation Controller にリンクされています。そこで出力を確認できます。