Ansible Callback Pluginで構築する「攻め」の運用監視：Slack/Teams通知の極意
「また、Ansibleの実行結果を見逃して障害対応が遅れた」
そんなセリフは、今日で卒業しよう。
SREの現場において、IaCは「実行して終わり」ではない。「実行された事実と、その結果の可視性」をチーム全員で共有することこそが、システムを堅牢にするための最初の一歩だ。
今回は、Ansible標準のログを垂れ流すだけの受動的な運用から脱却し、Callback Pluginを活用して「誰が、何を、どう変えたか」をチャットツール（Slack/Teams）へリアルタイムにプッシュする仕組みを解説する。
—
1. なぜ「Callback Plugin」なのか？
Ansibleの実行結果を通知する際、`post_tasks`で`uri`モジュールを叩くのはアンチパターンだ。なぜなら、そのタスクが失敗した瞬間に通知処理そのものがスキップされるリスクがあるからだ。
Callback Pluginは、Ansibleのイベントループをフックする特等席に位置している。
Playbookの実行開始、タスクの失敗、完了といったあらゆるイベントをトリガーに、非同期で外部へ情報を飛ばせる。これこそが、冪等性を担保するインフラエンジニアが選ぶべき「正解」だ。
—
2. 実装：カスタムCallbackのベストプラクティス
今回はSlackを例に取るが、Webhook URLを変えればTeamsでも同じロジックが使える。
ディレクトリ構成
まずは、Ansibleのプロジェクト構造を整理する。
.
├── ansible.cfg # Callbackを有効化する設定
├── callback_plugins/ # ここにプラグインを配置
│ └── slack_notifier.py
└── playbooks/
必須のプラグインコード (`callback_plugins/slack_notifier.py`)
冗長なログは不要だ。「何が起きたか」を一目で判断できるサマリーを送るのがプロの作法である。
import json
import requests
from ansible.plugins.callback import CallbackBase
class CallbackModule(CallbackBase):
CALLBACK_VERSION = 2.0
CALLBACK_TYPE = ‘notification’
CALLBACK_NAME = ‘slack_notifier’
def __init__(self):
super(CallbackModule, self).__init__()
self.webhook_url = “https://hooks.slack.com/services/YOUR/WEBHOOK/URL”
def v2_playbook_on_stats(self, stats):
“””Playbookの実行終了時に呼び出されるメソッド”””
summary = f”🚀 Ansible Execution Finished\n”
summary += f”Changed: {stats.changed} | Failures: {len(stats.failures)} | OK: {stats.ok}”
payload = {“text”: summary}
requests.post(self.webhook_url, json=payload)
def v2_runner_on_failed(self, result, ignore_errors=False):
“””タスク失敗時にスタックトレースの一部を通知”””
host = result._host.get_name()
msg = f”❌ Task Failed on {host}: {result._task.name}\n”
msg += f”Details: {result._result.get(‘msg’, ‘Unknown error’)}”
requests.post(self.webhook_url, json={“text”: msg})
—
3. チームの生産性を爆上げする「設定共有化」ルール
プラグインを入れるだけでは不十分だ。チームで開発するなら、以下のルールを徹底せよ。
`ansible.cfg` の環境最適化
リポジトリのルートに置く`ansible.cfg`で、callbackのロードパスを指定する。
[defaults]
実行時間を計測し、ボトルネックを可視化せよ
callback_whitelist = slack_notifier
callback_plugins = ./callback_plugins
stdout_callback = yaml
display_skipped_hosts = no
隠れたキーボードショートカットと神プラグイン
1. `ansible-lint`: CI/CDパイプラインに必須。YAMLの書き方で揉める時間をゼロにする。
2. `ansible-vault`: 機密情報の暗号化は必須だが、`ansible-vault view`よりも、VS Codeの「Ansible拡張機能」を使って暗号化された変数を安全に扱うのが現代的だ。
3. ショートカット: `Ctrl + R`で履歴から過去の`ansible-playbook`コマンドを呼び出すのは基本中の基本。さらに、`ansible-playbook -v` (詳細) から `-vvv` (デバッグ) への切り替えを意識的に使い分けろ。
—
4. プロの視点：失敗を「通知」から「自動修復」へ
通知が届いたら、次は「なぜ失敗したのか」を即座に特定できる環境を作ることだ。
- 冪等性の検証: `ansible-playbook –check –diff` を定期的に実行し、差分を通知せよ。
- 構造化ログ: チャットツールに送るメッセージには、必ず「実行環境（Staging/Production）」と「担当者」を含めろ。Ansibleの`extra_vars`を活用し、実行時に`–extra-vars “executor=$USER”`を渡す仕組みをCI側で組み込むのだ。
最後に：なぜここまでやるのか
「自動化」は手段であり、目的ではない。目的は、エンジニアが「インフラの細かい作業」から解放され、より価値のあるアーキテクチャの設計に集中できる時間を作ることだ。
Ansibleはただのツールではない。君たちのインフラに対する「意思」をコード化し、それをチーム全体で共有するための言語だ。今日紹介したCallback Pluginの構築が、君たちのチームの運用を、一段上のレベルへと引き上げることを確信している。
さあ、コードを書け。そして、Slackに通知を飛ばせ。現場は君たちの手によって、より静かで、より強固になるはずだ。