制御のパラダイムシフト：なぜ今、AnsibleからPuppetへの回帰（あるいは再評価）が起きているのか
「Ansibleは手軽だ。だが、その手軽さが大規模環境では牙を剥く」。
SREの現場で長年見ている光景がある。最初は数台のサーバーを操作するのに適したAnsibleも、管理対象が数百、数千と増え、さらに「自動修復（Self-healing）」が求められるフェーズになると、その限界に直面する。
今回は、AnsibleからPuppetへの移行という「一見逆行に見えるが、実はスケーラビリティへの最適解である」戦略について、現場の血肉を通した知見を共有する。
—
1. プッシュ型（Ansible） vs プル型（Puppet）：運用の深淵
Ansibleは「その瞬間の実行」に特化したプッシュ型だ。これは「今すぐこの設定を適用せよ」という命令には強いが、サーバーが「ドリフト（設定の乖離）」を起こした場合、再度コマンドを叩かなければ状態は戻らない。
対してPuppetはプル型だ。エージェントが定期的にマスターに問い合わせ、現在の状態と定義された状態（Desired State）を比較し、自動で差異を埋める。
- Ansibleの真価: 一時的なタスク実行、CI/CDパイプラインの中でのデプロイ。
- Puppetの真価: 恒久的なシステム状態の維持。数千台のサーバーがバラバラのタイミングで起動しても、Puppetエージェントが自律的に正しい設定に収束させる。
大規模環境で「Ansibleで全台にコマンドを打ったが、ネットワーク切断で数台だけ適用漏れが発生した」という悪夢を経験したことがあるなら、Puppetのプル型アーキテクチャこそが求める救済だ。
—
2. 移行を検討すべきユースケース：判断の境界線
以下のいずれかに該当するなら、移行を真剣に検討すべきだ。
1. ドリフトの常態化: 手動変更やパッチ適用によって、設定が勝手に書き換わってしまう環境。
2. オートスケーリングの深淵: インスタンスが動的に増減し、その都度、一から全設定を適用しなければならない環境。
3. コンプライアンス要件: 「いつ、誰が、どの設定を変更したか」だけでなく、「常に規定の状態であること」を証明し続ける必要がある環境。
—
3. 段階的な移行計画：破壊を避けるロードマップ
一気にPuppetへ置き換えるのは自殺行為だ。「Puppet Bolt」を活用して、段階的に移行せよ。
- Step 1: 参照モデル化 (Read-only)
Puppetのレポート機能だけを使い、既存のAnsible環境との差異（ドリフト）を可視化する。
- Step 2: 役割の分担
ミドルウェア以下の基盤設定（OSパラメータ、ユーザー管理、NTPなど）をPuppetに移管し、アプリケーションデプロイのみをAnsible（またはCI/CDツール）に残す。
- Step 3: 完全自律化
Puppetのクラス（Class）を定義し、システム全体をコードとして完結させる。
—
4. 実戦的テクニック：プロの生産性を引き出す設定
神プラグインとショートカット
- VS Code拡張: `Puppet` (Puppet Inc.公式) は必須。これなしでマニフェストを書くのは目隠しでコードを書くようなものだ。
- キーボードショートカット: `Ctrl+Shift+P` (コマンドパレット) から `Puppet: Validate File` を即座に実行する癖をつけよ。構文チェックは呼吸と同じレベルで。
チーム開発のベストプラクティス：ディレクトリ構成例
Puppetの「Control Repository」を構築する際は、以下の構成が黄金律だ。
/manifests/site.pp
エントリポイント。ノードごとの役割を明確に分ける
node /^web-\d+\.example\.com$/ {
include profile::webserver # 役割ごとのプロファイルパターンを採用
}
/site/profile/manifests/webserver.pp
class profile::webserver {
# 冪等性を担保するための宣言的記述
package { ‘nginx’:
ensure => installed,
}
service { ‘nginx’:
ensure => running,
enable => true,
}
}
ポイント:
- Role/Profileパターンを徹底せよ。 直接Node定義にパッケージを書くのは素人のやることだ。
- Hieraを活用せよ。 設定値（JSON/YAML）をコードから分離し、環境（dev/stg/prod）ごとの切り替えはHieraの階層構造で行う。ハードコーディングは技術的負債の温床だ。
—
5. 移行時の落とし穴
1. 「Ansibleのロジック」を持ち込むな: Ansibleは手続き型（どうやってやるか）だが、Puppetは宣言型（どうあるべきか）だ。`exec`リソースでシェルスクリプトを連打するのは、Puppetを使っているようで実はAnsibleを書いているのと同じだ。
2. 冪等性の検証: 「2回実行しても結果が変わらない」ことは絶対条件だ。`noop` モード（dry-run）をCIに組み込み、常に適用結果を検証するパイプラインを作れ。
最後に
ツールは手段に過ぎない。しかし、その手段があなたの組織の「インフラ品質」を決定づける。AnsibleからPuppetへの移行は、単なるツールの変更ではなく、「サーバーを個別に管理する」という思想から、「システム全体を一つの状態として定義する」というSREの本質への昇華である。
さあ、コードでインフラを支配する準備はできたか？