従来のAnsibleは優れた構成管理ツールですが、「人間がansible-playbookコマンドを実行する」という前提で設計されています。定期的なパッチ適用やプロビジョニングには向いていますが、「障害検知→即時対応」という反射的な自動化には対応できていません。
この記事では、Ansible EDA（Event-Driven Ansible）のアーキテクチャを解説します。rulebookでイベントソース・条件・アクションを定義し、AlertManagerのアラートやWebhookを受信して自動でPlaybookを実行する仕組みを、設計の考え方から実践パターンまでまとめます。
この記事のポイント
・Ansible EDAはイベント検知を契機にPlaybookを自動実行するイベント駆動型の拡張仕組み
・rulebookでsource（イベント監視）・condition（条件評価）・action（実行処理）を定義する
・ansible-rulebook CLIがrulebookを解釈してイベント待ちループを維持し、条件合致で即時起動する
・AWXのEDAコントローラーでルール管理とPlaybook実行を統合し、本番規模の自律自動化を実現できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
従来のAnsibleが抱える「人間待ち」問題
AnsibleはPlaybookを使ったプッシュ型の構成管理ツールです。コントロールノードからSSHでターゲットノードに接続し、タスクを順番に実行するアーキテクチャは、冪等性のある自動化を実現しています。ただし、このモデルには構造的な制約があります。Playbookを実行するのは常に「人間か、スケジュールされたcron」です。サーバーが異常状態になっても、誰かが気づいてコマンドを打つまでPlaybookは動き出しません。
・手動実行: エンジニアがアラートを見て判断し、ansible-playbookを実行する（応答が遅れる）
・cronスケジュール: 定時に実行するが、障害発生の瞬間には対応できない
この「人間待ち」の問題を解決するために登場したのがAnsible EDAです。イベントをトリガーにPlaybookを自動実行することで、人間の介在なしに即時対応できる「自律型自動化」を実現します。
Ansible EDAのアーキテクチャ——イベントからPlaybookまでの流れ
Ansible EDA（Event-Driven Ansible）はRed HatがAnsible Automation Platform 2.4から正式サポートしたコンポーネントで、独立したPythonパッケージ（ansible-rulebook）として提供されています。EDAの処理フローは3段階で構成されます。
1. イベントの受信（Event Source）
AlertManager、Webhook、Kafka、ファイル変更など、さまざまな発生源からイベントを取り込みます。どのイベントソースを使うかはrulebookのsourceセクションで定義します。
2. 条件の評価（Condition）
受信したイベントのペイロードに対して条件式を評価します。条件はJinja2風の式で記述し、特定フィールドがある値のときにだけアクションを起動するように制御できます。
3. アクションの実行（Action）
条件が一致したとき、指定されたアクションを実行します。代表的なアクションはrun_playbookですが、デバッグ用のprint_eventや実行中止のshutdownも用意されています。
従来のAnsibleとの比較で整理すると、以下のようになります。
・従来のAnsible（プッシュ型）: 人間またはcronがansible-playbookを実行する — 定期実行・手動実行向け
・Ansible EDA（イベント駆動型）: イベントがrulebookのconditionを満たした瞬間にPlaybookが起動する — リアルタイム対応向け
rulebookの構造を読み解く——source・condition・actionの設計
rulebookはPlaybookと同じYAML形式で記述します。最上位にリスト（複数のrulebookを定義可能）、各エントリにhosts・sources・rulesの3セクションを持ちます。基本的な構造は次のとおりです。
# rulebook: restart_on_alert.yml --- - name: サービス障害アラートに自動対応するルールブック hosts: all sources: - ansible.eda.alertmanager: host: 0.0.0.0 port: 9000 rules: - name: NginxがダウンしたらPlaybookで再起動する condition: event.alert.labels.alertname == "NginxDown" action: run_playbook: name: playbooks/restart_nginx.yml
sourceの設計判断
EDAが標準で提供するソースコレクション（ansible.eda）には以下が含まれます。
・ansible.eda.webhook: HTTP POSTを受け付けるシンプルなHTTPサーバー。外部システムからのトリガーに最適
・ansible.eda.alertmanager: Prometheus AlertManagerのルーティングEndpointとして機能。監視基盤との連携向け
・ansible.eda.kafka: Kafkaトピックをサブスクライブ。大量イベントの非同期処理向け
・ansible.eda.aws_sqs_queue: AWS SQSキューのメッセージを受信。クラウドネイティブな構成向け
・ansible.eda.watchdog: ファイルシステムの変更を監視。設定ファイルの変更検知向け
conditionの書き方
conditionはJinja2に近い式で記述します。イベントのペイロードは
event変数としてアクセスできます。複数条件はallまたはanyで組み合わせが可能です。# 単一条件: アラート名が一致する場合 condition: event.alert.labels.alertname == "HighCPU" # 複数条件(AND): アラート名かつ重大度がcriticalの場合 condition: all: - event.alert.labels.alertname == "HighCPU" - event.alert.labels.severity == "critical" # 数値比較: CPU使用率が90を超えた場合 condition: event.payload.cpu_usage > 90 # 文字列部分一致: ホスト名がweb-で始まる場合 condition: event.payload.hostname is match("web-.*")
・run_playbook: 指定したPlaybookをansible-playbookで実行する（最頻用途）
・run_module: Playbookを書かずに単一のAnsibleモジュールを実行する
・print_event: イベント内容をコンソールに出力（デバッグ用）
・shutdown: ansible-rulebookプロセスを終了する
・set_fact: 変数にイベントデータを格納してPlaybookへ渡す
この設計パターンをAnsibleの実機環境で体験したい方は、＞＞ Ansibleハンズオン講座の詳細を見る をご覧ください。
実践: Webhookイベントを受信してPlaybookを自動実行するrulebook
最もシンプルな入門として、ansible.eda.webhookソースを使ってHTTP POSTを受信し、特定のペイロードがきたときにPlaybookを実行する例を見てみましょう。動作確認環境: RHEL 9.4 / ansible-rulebook 1.0.0
1. ansible-rulebookのインストール
# Python仮想環境でインストール（推奨） python3 -m venv eda-venv source eda-venv/bin/activate pip install ansible-rulebook ansible-runner # EDA標準コレクションのインストール ansible-galaxy collection install ansible.eda # インストール確認 ansible-rulebook --version # ansible-rulebook 1.0.0
2. rulebookファイルの作成
# webhook_rulebook.yml --- - name: Webhookでサービス再起動を受け付けるルールブック hosts: webservers sources: - ansible.eda.webhook: host: 0.0.0.0 port: 5000 rules: - name: serviceフィールドがnginxのときに再起動する condition: event.payload.service == "nginx" action: run_playbook: name: playbooks/restart_service.yml extra_vars: target_service: "{{ event.payload.service }}"
3. ansible-rulebookを起動してイベント待ち状態にする
# ansible-rulebookを起動（イベント待ち状態になる） ansible-rulebook --rulebook webhook_rulebook.yml \ --inventory inventory/hosts.yml \ --verbose # 実行直後のコンソール出力（実機）: # INFO - Starting ansible-rulebook # INFO - Listening on http://0.0.0.0:5000 # INFO - Waiting for events...
4. Webhookのテスト送信と自動実行の確認
# 別ターミナルからcurlでWebhookにHTTP POSTを送信 curl -X POST http://localhost:5000 \ -H "Content-Type: application/json" \ -d '{"service": "nginx", "action": "restart"}' # ansible-rulebookのコンソールに以下が出力される（実機）: # RULE FIRED: serviceフィールドがnginxのときに再起動する # RUNNING PLAYBOOK: playbooks/restart_service.yml # PLAY [webservers] **** # TASK [nginx を再起動する] **** # changed: [web01.example.com]
本番設計のポイント——冪等性・セキュリティ・AWX連携
EDAを本番環境に導入する際には、3つの設計判断が重要になります。Playbookの冪等性を必ず確保する
EDAが自動でPlaybookを実行するということは、同じPlaybookが短時間に複数回起動する可能性があります。commandモジュールでrm -rfを実行するような冪等性のないPlaybookはEDA環境では致命的な誤動作につながります。EDAと組み合わせるPlaybookはservice・file・template等の冪等性保証モジュールで構成することが前提です。
Webhookのセキュリティ設計
ansible.eda.webhookはデフォルトで認証なしのHTTPサーバーです。本番では以下の対策が必須です。
・Webhookエンドポイントの前にNginxリバースプロキシを置き、TLS終端と認証トークン検証を行う
・hmac_secret_keyオプションでHMAC署名検証を有効にし、送信元を検証する
・送信元IPをfirewalldで制限し、許可済みシステム以外からのリクエストを遮断する
AWXのEDAコントローラーで本番規模の運用に移行する
単体のansible-rulebookはプロセスが終了するとルール監視が止まります。本番ではAWX（またはAnsible Automation Platform）のEDAコントローラーを使うことで、rulebookをActivationとして管理し、自動再起動・ログ収集・監査証跡の取得が可能になります。
# AWX UIでのEDA Activation設定手順（概要） # 1. Event-Driven Ansible > Rulebook Activations > New Activation # 2. Project: GitリポジトリのURLを登録（webhook_rulebook.ymlを含むリポジトリ） # 3. Rulebook: webhook_rulebook.ymlを選択 # 4. Inventory: production-serversを選択 # 5. Credential: Machine Credential（SSH鍵認証）を選択 # 6. Save > Activate で常時稼働開始
よくあるエラーとトラブルシュート
EDAを導入する際に現場でよく遭遇するエラーと対処法をまとめます。rulebookがイベントを受信してもPlaybookが実行されない
最も多いのはconditionの記述ミスです。イベントのペイロード構造と条件式のフィールドパスが一致していないと、conditionが常にFalseとなりアクションが起動しません。
--verboseオプションで起動すると受信したイベントのペイロードが出力されるため、フィールドパスを確認できます。# verboseで起動してペイロードを確認する ansible-rulebook --rulebook webhook_rulebook.yml \ --inventory inventory/hosts.yml \ --verbose # イベント受信時の出力例（実機）: # INFO - Received event: {'payload': {'service': 'nginx', 'action': 'restart'}} # INFO - Evaluating condition: event.payload.service == "nginx" # INFO - Condition result: True # RULE FIRED: serviceフィールドがnginxのときに再起動する
ansible-rulebookはPython 3.9以上が必要です。RHEL 8系（Python 3.6標準）では
python3.9またはpython3.11パッケージを個別にインストールして仮想環境を作成してください。※注意: ansible-rulebookはansible-playbookとは別プロセスで動作します。インストール済みのansible-coreとバージョンの互換性があるか、
pip install ansible-rulebook前に必ず確認してください。バージョン不整合はランタイムエラーの主因です。本記事のまとめ
Ansible EDAは「人間が実行する」というAnsibleの前提を超え、イベントを契機に自律的に動作する次世代の自動化基盤です。rulebookのsource・condition・actionを適切に設計することで、障害対応から定期処理まで幅広いユースケースに対応できます。| 要素 | 役割 | 代表的な設定例 |
|---|---|---|
| source | イベントの取り込み元を定義する | ansible.eda.webhook / alertmanager / kafka |
| condition | イベントペイロードの条件を評価する | event.alert.labels.alertname == "NginxDown" |
| action | 条件一致時に実行する処理を定義する | run_playbook / run_module / print_event |
| ansible-rulebook | rulebookを解釈してイベント待ちループを実行するCLI | --rulebook / --inventory / --verbose |
| EDAコントローラー | AWX/AAPでrulebookを常時稼働させる管理基盤 | Rulebook Activation / 監査ログ |
Ansible実践ハンズオンの詳細を見る ＞＞
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Ansibleのansible.cfg設計入門｜接続・実行・ログ・escalationの全セクションとプロジェクト別設定分離のパターン
- この記事の属するカテゴリ：Ansibleへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます