AnsibleからPuppetへ：なぜ今、大規模インフラは「プル型」の規律を求めているのか
こんにちは。長年インフラの最前線でコードを書き、システムの信頼性と格闘してきたエンジニアとして、今日は少し「玄人好み」の話をしようと思います。
最近、「AnsibleからPuppetへ移行したい」という相談をよく受けます。Ansibleは確かに手軽で強力ですが、規模が拡大し、管理対象が数千台を超えたとき、私たちは「ある壁」に突き当たります。今日は、その壁を乗り越えるための「Puppet移行の真髄」を、技術の本質に触れながら解説します。
—
1. プッシュ型（Ansible） vs プル型（Puppet）：運用の哲学の違い
Ansibleのプッシュ型は、操作者が「今、この瞬間に」命令を送るモデルです。これは「即時性」において最強ですが、「構成ドリフト（放置された設定の不一致）」という宿命的な課題を抱えています。
対するPuppetのプル型は、エージェントが自律的に「現在の状態」を監視し、あるべき姿（Desired State）との差異を自動修正し続けます。
- Ansible: 「明日、全サーバーをアップデートしろ」と命令する（実行時の状態に依存）。
- Puppet: 「常にこの設定状態であれ」と定義する（状態の永続性を保証）。
大規模環境において、後者の「状態の永続性」こそが、深夜のトラブルコールを減らす最大の鍵となります。
—
2. 移行を検討すべきユースケース
以下のような兆候があれば、Puppetへの移行を真剣に考えるべきタイミングです。
- 構成ドリフトの放置: 手動修正が横行し、Ansibleの実行結果が毎回「Changed（変更あり）」になる。
- 「いつの間にか設定が変わっている」恐怖: 監査要件が厳しく、コンプライアンス維持にコストがかかる。
- 大規模分散環境: 接続元から全ノードへSSH接続し続けるのがネットワーク的に辛い。
—
3. Puppetの世界へ：Hello Worldまでの最短距離
まずは、Puppetの真骨頂である「状態宣言」を体験してみましょう。
手順1: インストール（Agent側）
Puppetの公式リポジトリからエージェントを導入します。
Puppetの公式リポジトリを追加（CentOS系の場合）
rpm -ivh https://yum.puppet.com/puppet7-release-el-7.noarch.rpm
エージェントのインストール
yum install -y puppet-agent
手順2: 最初のマニフェスト（HelloWorld的な設定）
Puppetでは、処理手順ではなく「あるべき状態」を記述します。`/etc/puppetlabs/code/environments/production/manifests/site.pp` に以下を記述してください。
ファイルの存在と内容を保証する宣言
file { ‘/tmp/hello_world.txt’:
ensure => file, # ファイルが存在していること
content => “Puppetによる状態管理の始まりです\n”, # 内容を強制する
owner => ‘root’,
mode => ‘0644’,
}
手順3: 動作確認
手動でエージェントを動かし、適用します。
/opt/puppetlabs/bin/puppet apply /etc/puppetlabs/code/environments/production/manifests/site.pp
ここで重要なのは、「何度実行しても結果が変わらない」ことです。これが冪等性の極致です。試しに `/tmp/hello_world.txt` を削除してから再度コマンドを打ってみてください。一瞬で修復されるはずです。これがPuppetの信頼性の源泉です。
—
4. 移行時の注意点と落とし穴
「明日から全部Puppet！」というフルスクラッチ移行は、往々にして失敗します。現場の知恵として以下のステップを推奨します。
1. 段階的移行: まずはAnsibleで「SSHキーの配布」や「Puppet Agentのインストール」を行い、Puppetが管理できる環境を整える。
2. モジュール分割: 最初から複雑なコードを書かず、まずは「パッケージ管理」「サービス管理」など、小さな単位からPuppetへ移していく。
3. Hieraの活用: Puppetにおいて最も重要な機能は、設定値をコードから切り離す「Hiera」です。これを使いこなさないと、Puppetはただの複雑なスクリプト集になってしまいます。
—
最後に：エンジニアとして成長するために
AnsibleからPuppetへの移行は、単なるツールの乗り換えではありません。「命令（Command）」から「宣言（Declaration）」へ、思考を切り替えるプロセスです。
最初は戸惑うかもしれません。しかし、一度この「あるべき姿（Desired State）」をコード化する感覚を掴めば、あなたはインフラの些細な不整合に悩まされることから解放され、より高次元のアーキテクチャ設計に集中できるようになります。
インフラ管理は「作業」ではなく「エンジニアリング」です。このコードが生きている限り、あなたのサーバーは眠っている間も自分自身を守り続けてくれます。さあ、Puppetの深淵を楽しんでください。