PuppetDBを「ただの保存庫」にするな：REST APIでインフラの「真実」を可視化せよ
Puppetを単なる「設定配布ツール」として使っているなら、君は宝の山の上で泥遊びをしているようなものだ。PuppetDBは、インフラの現在の状態（Current State）と過去の変遷（Historical State）が刻まれる、いわば「インフラのリアルタイム・データベース」である。
今回は、PuppetDBのREST APIをハックし、監視ツールと連携させて「インフラの健康状態を秒単位で可視化する」ための、現場でしか語られない極意を伝授する。
—
1. なぜPuppetDB APIなのか？
PuppetDBは単なるカタログの格納庫ではない。`nodes`, `facts`, `resources`, `reports` という4つの軸で構成されたグラフデータベースに近い。これらを直接叩くことで、管理画面からは見えない「コンプライアンスの綻び」を早期発見できる。
現場で必須の「神」クエリパターン
APIを叩く際は `curl` を直打ちするのではなく、`jq` をパイプラインの友とせよ。
【特定のパッケージがインストールされていないノードを即座に抽出】
証明書認証を介してPuppetDBから「特定のパッケージが存在しない」ノードを取得
curl -s –cert /etc/puppetlabs/puppet/ssl/certs/$(hostname -f).pem \
–key /etc/puppetlabs/puppet/ssl/private_keys/$(hostname -f).pem \
–cacert /etc/puppetlabs/puppet/ssl/certs/ca.pem \
“https://puppetdb.internal:8081/pdb/query/v4/resources” \
–data-urlencode ‘query=[“and”, [“=”, “type”, “Package”], [“=”, “title”, “nginx”], [“=”, “ensure”, “absent”]]’ | jq .
このクエリをCronやCIジョブで回せば、脆弱性のあるパッケージが混入した瞬間に検知可能だ。
—
2. Prometheus x PuppetDB：インフラの「状態」をメトリクス化せよ
Prometheusの `puppet_exporter` を使うのも良いが、真のエンジニアは「独自の指標」をAPIから引き抜く。
構築のベストプラクティス
1. Exporterの自作: PythonやGoで簡単なスクリプトを書き、PuppetDBのクエリ結果をPrometheusのテキスト形式で出力させる。
2. コンプライアンス監視: `resources` クエリを使い、「許容されていない設定ファイル（`file`タイプ）」が含まれているノード数をカウントする。
3. Grafanaでの可視化: 「前回適用から時間が経過しているノード（Stale Nodes）」を時系列グラフにマッピングせよ。これがアラートの「予兆」になる。
—
3. チームの生産性を爆速化する「設定の作法」
チーム開発において、PuppetのコードとPuppetDBの活用は密接にリンクしている。以下のルールを強制せよ。
隠れたキーボードショートカット & ツール
- `puppet lookup –explain`: なぜその値が設定されたのか？APIを叩く前に、ローカルでノードごとの評価結果を深掘りする癖をつけろ。
- `puppet-lint`: CIのパイプラインに必須。コードの臭いを自動検知させる。
- `r10k` または `bolt`: プロビジョニングを自動化し、手動修正を徹底排除する。「手動変更は罪」という文化をコードで強制するのだ。
YAML構成の「神」ベストプラクティス
PuppetのHiera（YAML）は肥大化しやすい。以下の構成でディレクトリを分離せよ。
/etc/puppetlabs/code/environments/production/data/nodes/web-01.yaml
—
役割ごとにインクルードし、詳細を共通化する
classes:
- profile::webserver
秘匿情報は必ずepp/eyamlで暗号化すること
profile::webserver::timeout: 30
profile::webserver::max_connections: 500
鉄則: `common.yaml` に全てを書くな。ノード固有の設定は `nodes/` ディレクトリへ。環境ごとの差異は `environments/` で管理する。この階層構造を守るだけで、障害調査の時間が半分になる。
—
4. 現場のテックリードへ：次の一手
PuppetDBの真の力は、「イベント・ドリブンなインフラ」を作れることにある。
Puppetの実行結果（Reports API）を購読し、「設定適用に失敗したノードがあれば、即座にそのノードの全FACTs情報をSlackへ通知する」といった仕組みを作れ。これにより、障害発生時に「まず何が起きたのか」を調べる手間がゼロになる。
まとめ：君がやるべきこと
1. 証明書ベースのAPI認証を完全にマスターする。
2. `jq` を極める。APIのレスポンスを自在に操れないなら、インフラは管理できない。
3. 監視ダッシュボードに「Puppetの適用状況」を組み込む。これこそが、SREが「インフラの神」であるための証明だ。
インフラは生ものだ。PuppetDBは、その生き物であるサーバーたちの「脈拍」を記録している。その脈拍をリアルタイムに監視し、異常があれば即座に治療する。それこそが、我々エンジニアが目指すべき「完全自動化された世界」の入り口だ。
コードを書け。APIを叩け。そして、インフラの真実を可視化せよ。