Puppet Code Managerの真髄：CI/CDパイプラインを「止まらない」自動化装置に変える
Puppetを単なる「構成管理ツール」として使っているなら、それは宝の持ち腐れだ。真のSREは、インフラの変更を「デプロイ」ではなく「マージ」に昇華させる。
今回は、Code ManagerとWebhookを駆使し、手動同期の呪縛から解放された完全自動デプロイメント環境の構築を伝授する。これは、チームの生産性を劇的に向上させるための「最後のピース」だ。
—
1. アーキテクチャの核心：Code Managerの「その先」へ
Code Managerは単なる同期ツールではない。「Gitのコミットハッシュが、即座に全ノードのカタログ生成の前提条件となる」という状態を担保するパイプラインの心臓部だ。
構築のステップ
1. Puppetfileの正規化: モジュール管理は `r10k` の思想を継承し、環境ごとにロックファイルを生成する。
2. Webhookのセキュアな実装: 外部からのトリガーをPuppet Serverで正しく解釈させる。
3. 同時実行制御（Locking）: CIの多重実行によるデプロイの競合を撲滅する。
—
2. 現場で震えるほど役立つ：設定ベストプラクティス
多くのエンジニアが悩む「認証エラー」と「同期失敗」。これを解決するのは、設定の冗長さを削ぎ落とした以下の構成だ。
`r10k.yaml` の黄金比
環境ごとの `Puppetfile` を分離し、キャッシュを最適化する。
/etc/puppetlabs/r10k/r10k.yaml
:cachedir: ‘/var/cache/r10k’
:sources:
:control-repo:
remote: ‘git@github.com:org/control-repo.git’
basedir: ‘/etc/puppetlabs/code/environments’
# 重要なのは「prefix」設定。名前空間を汚染しないための鉄則
prefix: true
チーム開発のルール：`Puppetfile` の管理
手動でバージョンを書き換えるのは禁止だ。`r10k` を使い、常に `Puppetfile.lock` をコミットせよ。これにより、開発・ステージング・本番での「依存関係の不一致」という地獄を回避できる。
—
3. Webhookの自動化：トリガーから同期までの最短距離
Webhookは Puppet Server の `/etc/puppetlabs/puppetserver/conf.d/webserver.conf` で受け付ける。
認証エラーを回避する鍵
Webhookのシークレットは、環境変数として注入すべきだ。以下のスクリプトをCI（GitHub Actions等）からキックする際、`X-Hub-Signature-256` を用いた検証を必ず実装せよ。
!/bin/bash
Code Managerトリガー用スクリプトの断片
認証を省略するような甘い設定は、即座にセキュリティホールとなる
curl -X POST -H ‘Content-Type: application/json’ \
-d ‘{“deploy-all”: true}’ \
“https://puppet-master.example.com:8170/code-manager/v1/deploys” \
–cert /etc/puppetlabs/puppet/ssl/certs/admin.pem \
–key /etc/puppetlabs/puppet/ssl/private_keys/admin.pem
—
4. プロの隠し味：開発スピードを最大化するツール群
私が普段のコーディングで、時間を1秒も無駄にしないために導入しているものだ。
- VS Code神プラグイン:
- Puppet Extension: 文法チェックはもちろん、`PDK (Puppet Development Kit)` との統合は必須。
- YAML Lint: 設定ファイルのシンタックスエラーを保存時に検知し、デプロイ後の「Puppet Serverが落ちた」という事故を未然に防ぐ。
- 必須ショートカット:
- `Cmd + Shift + P` -> `Puppet: Generate Type Reference`: マニュアルをブラウザで開く時間を節約する。
—
5. トラブルシューティング：現場の知見
同時実行制御が効かない時
`r10k` がロックファイルで止まる場合、それはデプロイが長すぎる証拠だ。モジュールのサイズを精査し、必要であれば `post-run` スクリプトで不要なキャッシュをパージするルールを設けるべきだ。
「デプロイしたのに反映されない」の正体
ほとんどの場合、`environment_timeout` の設定ミスだ。開発環境では `0` (毎回スキャン) に設定し、パフォーマンスが求められる本番では `unlimited` に設定し、`code_manager` のデプロイ時にのみキャッシュをクリアする運用を徹底せよ。
—
最後に：なぜ私たちが自動化を追求するのか
構成管理は、ただの「自動設定」ではない。「インフラのコード化により、信頼性の高いシステムを何度でも再現する」というエンジニアリングの信念そのものだ。
今回紹介したWebhookによる自動デプロイメントは、単なる省力化ではない。人間が介在する余地を排除することで、ヒューマンエラーを仕組みで殺すための防波堤だ。
さあ、今すぐ `control-repo` にWebhookを仕込み、あなたのPuppet環境を「自律的に進化するインフラ」へとアップグレードしてほしい。
質問があるなら、コードを見てからにしよう。準備はいいか？