Puppetを「定期実行ツール」から「即応型インフラヒーラー」へ進化させる極意
Puppetを単なる「30分おきの設定同期マシン」だと思っているなら、それはフェラーリを近所のコンビニへの買い物にしか使っていないのと同じだ。
我々SREの使命は、障害が起きたときにアラートを眺めることではない。「障害が起きたことを人間が認知する前に、システムが自律的に治癒している状態」を作ることだ。
今日は、Puppet TaskとAPIを駆使し、ポーリングを待たずに数秒で復旧を完了させる「イベント駆動型インフラ自動修復システム」の深淵を伝授する。
—
1. なぜ「ポーリング」では戦えないのか
Puppetの標準的な `puppet agent` は、デフォルトで30分ごとにカタログを適用する。しかし、深夜3時に発生したサービス断に対して「次の30分間」を待つ余裕などない。
ここで登場するのが Puppet Task だ。これはエージェントレス（またはエージェント経由）で、特定のノードに対して即座にスクリプトを走らせる仕組みだ。これを監視システム（Prometheus/Alertmanager）とWebhookで連結すれば、真の「Self-Healing Infrastructure」が完成する。
—
2. アーキテクチャの核心：Webhook to Taskの仕組み
監視システムが異常を検知した瞬間、中継サーバー（またはBolt）がPuppet Enterprise APIを叩き、対象ノードへTaskをデプロイする。
実践：Task呼び出しのベストプラクティス (Bolt/API)
単純なスクリプトを叩くだけではダメだ。冪等性を担保し、実行結果をログに吐く設計が不可欠だ。
tasks/repair_service.sh
冪等性を担保：既に正常なら何もしない、異常なら再起動
!/bin/bash
SERVICE_NAME=”nginx”
if systemctl is-active –quiet $SERVICE_NAME; then
echo “Service $SERVICE_NAME is already running. Nothing to do.”
exit 0
fi
echo “Attempting to recover $SERVICE_NAME…”
systemctl restart $SERVICE_NAME
復旧確認
if systemctl is-active –quiet $SERVICE_NAME; then
echo “Recovery successful.”
exit 0
else
echo “Recovery failed. Escalating to human.”
exit 1
fi
チーム開発のための設定共有ルール（Hieraの活用）
Taskの引数や閾値はハードコーディング厳禁だ。Hieraを使って環境ごとにパラメータを分離せよ。
data/nodes/web-prod-01.yaml
my_module::repair_threshold: 3
my_module::service_name: ‘nginx’
—
3. プロの生産性を引き出す「裏技」と環境設定
Puppetを日常的に扱うなら、エディタ環境を極限までチューニングせよ。
絶対に入れるべき神プラグイン (VS Code)
- Puppet Extension for VS Code: 文法チェックはもちろん、`puppet-lint` をバックグラウンドで走らせるために必須。
- YAML Lint: Hieraファイルのインデントミスは命取り。保存時に自動整形する設定を入れておけ。
開発スピードを加速させるキーボードショートカット
- `Ctrl + Shift + P` -> `Puppet: Run Puppet Apply`: 変更を加えた瞬間にローカルで即座に検証せよ。
- Task実行用Alias: CLIで毎回APIを叩くのは非効率だ。`.bashrc` に以下のAliasを仕込め。
Puppet Taskを実行する最強のショートカット
alias p-repair=’bolt task run my_module::repair_service –nodes’
使用例: p-repair web-prod-01
—
4. 現場で震えるほど役立つ「冪等性」の設計原則
Puppet Taskを設計する際、初心者は「復旧コマンド」を書こうとするが、プロは「状態確認コマンド」を書く。
1. State Check: 現在の状態を検知（プロセスは死んでいるか？メモリリークか？）
2. Idempotent Action: 何度実行しても同じ結果になるか？（二重起動防止）
3. Audit Log: 実行結果を外部ログ基盤（ELK/Datadog）に必ず流せ。
「復旧した」という事実だけでなく、「なぜその障害が起きたのか」というコンテキストをログに残すことこそが、SREの真価だ。
—
結論：自動化は「手段」であり「目的」ではない
イベント駆動型の自動修復システムを構築すると、運用は劇的に楽になる。しかし、真に重要なのは「自動化によって生まれた時間を、次のより大きな技術的負債の解消に充てること」だ。
もし、今日紹介した仕組みを導入し、深夜の呼び出しがゼロになったなら、それは君がインフラを「管理」する段階から、インフラを「設計」するステージへ上がった証拠だ。
さあ、コードを書け。そして、サーバーたちが勝手に自らを治癒する、美しいシステムを構築してくれ。
—
追伸：もしこのシステムで障害の二次被害が怖いなら、まずは「ReadOnlyモード（警告のみ）」で稼働させ、1週間ログを眺めろ。その慎重さこそが、一流エンジニアの条件だ。