こんにちは！インフラエンジニアの皆さん、日々の障害対応やサーバーのメンテナンスに追われていませんか？
「夜中にアラートが鳴り、VPNをつないで、決まりきったコマンドを叩いてサービスを再起動する……」
そんな退屈で疲れる作業、もう終わりにしましょう。
今回は、伝統的な構成管理ツールであるPuppetを、現代的な「イベント駆動型（イベントドリブン）」で動かす裏技をご紹介します。定期的なポーリング（30分に1回の定期実行など）を待つ必要はもうありません。監視システムが悲鳴を上げたその瞬間に、数秒でPuppetが駆けつけ、自動でシステムを修復してくれる――そんな夢のような仕組みを一緒に作っていきましょう。
これをマスターすれば、あなたの運用スタイルは劇的に変わり、夜中の呼び出しからも解放されますよ。それでは、極上のインフラ自動化の世界へご案内します！
—
1. なぜ「Puppet Task × API」なのか？
従来のPuppetの限界
従来のPuppetは、「Puppet Agent」が一定時間（デフォルトでは30分）ごとに「Puppet Server」に接続し、設定のズレを検知して修復するというプル型（定期ポーリング型）をとっていました。
これは大規模環境では非常に安定しますが、一つの弱点があります。
「今すぐサーバーが壊れた！今すぐ直したい！」という緊急事態に、最大30分も待たされるということです。これではリアルタイムな障害対応としては使い物になりません。
救世主「Puppet Task」とAPI
そこで登場するのが、Puppet 2017以降に導入されたPuppet Taskです。これは、エージェントの定期実行を待たず、マスターから特定のスクリプトやコマンドを「今すぐ」特定のノードにプッシュして実行する機能です。
さらに、Puppetには強力なPuppet Enterprise（PE）APIやオープンソース版のAPI（Puppet Server API）が備わっています。これらを組み合わせることで、次のようなフローが完成します。
1. 監視ツール（DatadogやPrometheus、Webhookなど）が障害を検知
2. Webhook経由でAPIサーバー（またはServerless Functions）に通知
3. APIがPuppet Taskを叩き、数秒以内にターゲットサーバーで修復スクリプトが発動
4. 数秒でサービスが自動復旧！
定期実行の呪縛から解放され、真の「イベント駆動型インフラ」が手に入るのです。
—
2. 環境の全体像とセットアップ
今回は、最もシンプルかつ強力な構成として、「Webhooksからのリクエストを受け取り、PuppetのAPIを叩いてTaskを実行する中継スクリプト（Python）」を構築します。
前提条件
- Puppet Serverが稼働していること
- ターゲットとなるPuppet Agentが接続されていること
- APIを叩くための管理者権限（またはRBACで許可された権限）があること
—
3. ステップ1：超シンプルかつ実用的な「HelloWorld」Puppet Taskを作る
まずは、Puppet Taskの基本を押さえましょう。今回は「指定したサービスの死活を確認し、死んでいたら即座に起動する」という実用的なTaskを作成します。
Puppetのモジュールディレクトリ（例: `/etc/puppetlabs/code/environments/production/modules/`）の中に、`auto_heal`というカスタムモジュールを作ります。
ディレクトリ構造
auto_heal/
└── tasks/
└── resurrect.sh
実装：`auto_heal/tasks/resurrect.sh`
このスクリプトに実行権限（`chmod +x`）を与えておきます。引数として渡されたサービス名（例: `nginx`）をチェックし、停止していれば起動するシンプルなTaskです。
!/bin/bash
—————————————————————–
Puppet Task: resurrect.sh
概要: 指定されたサービスの稼働状態を確認し、停止していれば再起動する
—————————————————————–
Puppet Taskからは環境変数 $PT_service_name でパラメータを受け取れます
TARGET_SERVICE=”${PT_service_name:-nginx}”
echo “==> [Puppet Task] Checking service: ${TARGET_SERVICE}”
サービスの稼働確認 (systemd環境を想定)
if systemctl is-active –quiet “${TARGET_SERVICE}”; then
echo “SUCCESS: ${TARGET_SERVICE} is running healthy.”
exit 0
else
echo “WARNING: ${TARGET_SERVICE} is down! Attempting to start…”
systemctl restart “${TARGET_SERVICE}”
# 再確認
if systemctl is-active –quiet “${TARGET_SERVICE}”; then
echo “SUCCESS: ${TARGET_SERVICE} has been successfully resurrected!”
exit 0
else
echo “ERROR: Failed to start ${TARGET_SERVICE}.”
exit 1
fi
fi
これだけで、Puppetの仕組みを通じて任意のサーバーでこのスクリプトをリモート実行できるようになります。手動でテストするには、PuppetのCLIツールである`bolt`や`puppet task`コマンドを使います。
puppet task run auto_heal::resurrect service_name=nginx –nodes target-web-01.example.com
おぉ、これだけでも感動的ですが、これを「人間が手動で打つのではなく、監視アラートから自動で発火させる」のが今回の本丸です。
—
4. ステップ2：APIを叩いてイベント駆動を実現する中継サーバー
監視ツール（Webhook）からの通知を受け取り、PuppetのAPIを叩いて先ほどのTaskを実行する軽量なAPIサーバーをPython（Flask）で作成します。
実装：`webhook_bridge.py`
このスクリプトは、Puppet Server上、もしくはAPIアクセス権を持つ踏み台サーバー上で動作させます。
from flask import Flask, jsonify, request
import requests
import urllib3
証明書の警告を抑制（社内検証用。本番では適切なCA証明書を設定してください）
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
app = Flask(__name__)
Puppet Enterprise / Server の設定
PUPPET_API_URL = “https://puppet-master.example.com:8143/orchestrator/v1/command/task”
実際の運用では環境変数やセキュアなストレージからトークンを読み込んでください
AUTH_TOKEN = “your_puppet_rbac_token_here”
@app.route(‘/webhook/heal’, methods=[‘POST’])
def trigger_puppet_task():
“””
監視ツールからのWebhookを受け取り、Puppet Taskをキックするエンドポイント
“””
data = request.json
# 監視ツールから送られてきたデータ（例: DatadogやAlertmanagerのペイロード）を想定
# どのサーバーのどのサービスが落ちたかを受け取る
target_node = data.get(‘hostname’)
service_name = data.get(‘service’, ‘nginx’)
if not target_node:
return jsonify({“status”: “error”, “message”: “hostname is required”}), 400
print(f”[] Alert received! Target: {target_node}, Service: {service_name}”)
# Puppet Orchestrator APIのペイロード構築
payload = {
“task”: “auto_heal::resurrect”,
“params”: {
“service_name”: service_name
},
“scope”: {
“nodes”: [target_node]
}
}
headers = {
“X-Authentication”: AUTH_TOKEN,
“Content-Type”: “application/json”
}
try:
# Puppet APIへリクエスト送信（同期的にタスク実行を指示）
response = requests.post(
PUPPET_API_URL,
json=payload,
headers=headers,
verify=False, # 必要に応じてTrueに変更
timeout=10
)
if response.status_code in [200, 201]:
result = response.json()
print(f”[+] Puppet Task triggered successfully. Job ID: {result.get(‘job’, {}).get(‘name’)}”)
return jsonify({“status”: “success”, “job_id”: result.get(‘job’, {}).get(‘name’)}), 200
else:
print(f”[-] Failed to trigger Puppet Task: {response.text}”)
return jsonify({“status”: “failed”, “details”: response.text}), 500
except Exception as e:
print(f”[-] Exception occurred: {str(e)}”)
return jsonify({“status”: “error”, “message”: str(e)}), 500
if __name__ == ‘__main__’:
# 外部からのWebhookを受け取れるように0.0.0.0で起動
app.run(host=’0.0.0.0′, port=5000)
仕組みの解説
1. 監視ツールが `http://<このサーバーのIP>:5000/webhook/heal` に対して、JSON形式で障害のあったホスト名（`hostname`）とサービス名（`service`）をPOST送信します。
2. Pythonスクリプトがその内容を受け取り、PuppetのOrchestrator API（`/orchestrator/v1/command/task`）に対して、先ほど作った `auto_heal::resurrect` タスクの実行を命令します。
3. Puppet Serverは即座にターゲットノードへ接続し、タスクを実行してサービスを復旧させます。
ここまで作れば、あとは監視ツール（Prometheus AlertmanagerやDatadog、GitHub Webhooksなど）の通知先にこのエンドポイントを指定するだけです。障害検知から数秒で自動復旧するパイプラインの完成です！
—
5. 先輩エンジニアからのアドバイス：安全な運用のために
イベント駆動型の自動化は非常にパワフルで気持ちが良いものですが、一つだけ注意点があります。それは「暴走（ループ）対策」です。
- 無限ループの防止: もしサービスが壊れた原因が「設定ファイルの構文エラー」だった場合、何度自動修復（再起動）を試みても即座にクラッシュし続けます。監視→Webhook→Puppet Task→再起動→即クラッシュ→監視…の無限ループに入ると、ログが埋まりサーバーに負荷がかかります。
- リトライ制限の導入: タスク側や監視側で「同一ホストに対する自動修復は、過去10分間に最大2回まで」といったサーキットブレーカー（回数制限）の思想を必ず組み込んでおきましょう。
—
まとめ
今回は、Puppet TaskとAPIを組み合わせて、定期実行を待たない「イベント駆動型インフラ自動修復システム」の作り方を解説しました。
- 従来のプル型（定期実行）の枠を超え、数秒単位での即時自動復旧が可能になる。
- 監視ツールのWebhookとPuppet APIを繋ぐことで、コード数行でイベントドリブンな自動化が実現できる。
- 障害対応のストレスから解放され、より本質的な設計や開発に集中できるようになる。
「これをマスターすれば、毎日の作業が劇的に楽になりますよ」。
ぜひ今回のコードを参考に、あなたのインフラにもイベント駆動の風を吹かせてみてください。次回の記事でも、現場で使える痺れるような知見をお届けします。お楽しみに！