Puppetを「単なる設定ツール」から「自律的インフラの源泉」へ。CI/CDで完結させるIaCの極意
Puppetという古参ツールを「古い」と切り捨てるのは、その本質的な冪等性（Idempotency）の強みを理解していない証拠だ。宣言的記述の極致であるPuppetは、適切にGitベースのCI/CDパイプラインに組み込むことで、世界で最も信頼できる「インフラの真実の源（Single Source of Truth）」へと進化する。
本記事では、手作業によるオペミスを根絶し、変更のリードタイムを極限まで短縮するための「実戦的Puppetパイプライン構築術」を伝授する。
—
1. 構成管理コードのバージョン管理戦略：GitOpsへの第一歩
Puppetのコードを単なるファイル集団とみなしてはいけない。「環境（Environment）＝Gitブランチ」というマッピングを厳格に適用せよ。
チーム開発の鉄則
- Production用ブランチの保護: `main`（または`production`）ブランチへの直接Pushを禁止し、Pull Request（PR）経由のコードレビューを必須とする。
- 環境分離の階層化: `Hiera`を活用し、ノードごとの特性をデータとして分離せよ。コード（`.pp`）とデータ（`.yaml`）を完全に切り離すことが、スケーラビリティを確保する唯一の道だ。
—
2. GitHub Actionsで「人間をコードの検証から解放する」
エンジニアが「構文エラー」で深夜に呼び出される時代は終わらせよう。GitHub Actionsを用い、コミットの瞬間に品質を担保する。
必須のLintチェック：puppet-lint
単なる構文チェックではない。「Puppet Style Guide」に準拠しているかを確認する。
.github/workflows/lint.yml
name: Puppet Lint
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Puppet
run: sudo apt-get install puppet-agent
- name: Run puppet-lint
# –fail-on-warningsで、警告すら許さない厳格な体制を敷く
run: puppet-lint –fail-on-warnings –with-context –relative ./manifests/
—
3. 自動テスト（rspec-puppet）：変更の安全性を担保する
「このコードを適用したら、既存設定が破壊されないか？」という恐怖を払拭する唯一の手段が`rspec-puppet`だ。
現場で震えるほど役立つベストプラクティス
`spec_helper.rb`には、全ノード共通のFACTS（OSのバージョンやIPアドレス等）をモック化して記述せよ。
spec/spec_helper.rb
require ‘rspec-puppet’
RSpec.configure do |c|
c.module_path = File.join(File.dirname(__FILE__), ‘fixtures/modules’)
c.manifest_dir = File.join(File.dirname(__FILE__), ‘fixtures/manifests’)
# 冪等性をテストするためのモック環境
c.default_facts = {
puppetversion: Puppet.version,
operatingsystem: ‘Ubuntu’,
operatingsystemrelease: ‘22.04’
}
end
テストケースの書き方（例）:
it { should contain_package(‘nginx’).with_ensure(‘installed’) }
it { should contain_service(‘nginx’).with_ensure(‘running’).with_enable(true) }
これで、適用前に「nginxがインストールされ、サービスが有効化されること」が数学的に証明される。
—
4. プロの現場で差がつく生産性向上ツール
VSCodeのおすすめプラグイン
- Puppet (by Puppet): 言語サーバーとして必須。Lintエラーをリアルタイムで波線表示させる。
- YAML (by Red Hat): Hieraデータを編集する際の必須プラグイン。スキーマ検証を行う。
隠れたキーボードショートカット
- `Ctrl + Shift + P` -> `Puppet: Validate File`: ファイル保存前にサクッと構文チェック。
- `Alt + Shift + F`: 整形（Format）。コードの汚さはバグの温床。これを叩くのがルーチンだ。
—
5. Hiera構成の「神」ベストプラクティス
Hieraはコードの「入力」である。この構成が汚いと、Puppetは一気にスパゲッティ化する。
data/nodes/web-01.yaml
—
明示的に役割を記述する（レイヤー化）
classes:
- profile::webserver
秘密情報は必ずVault経由の参照にすること（平文保存は厳禁）
profile::webserver::db_password: “%{lookup(‘secrets::db_password’)}”
ポイント:
1. 階層化（Hierarchy）: `common.yaml` -> `os/%{os.family}.yaml` -> `nodes/%{fqdn}.yaml` の順で深掘りする。
2. ハードコードの追放: `manifests`内に直接値を書くのは禁止。すべてHiera経由で流し込め。
—
最後に：SREとしてのマインドセット
Puppetの真の価値は、コードを書くことそのものではない。「インフラの現状をコードとして定義し、何度でも完全に再現できる」という確信（Confidence）にある。
CI/CDパイプラインを構築し、テストを自動化し、エンジニアが「デプロイボタンを押すこと」を恐れない環境を作ること。それが、我々インフラエンジニアがチームに対して提供できる最大の価値である。
さあ、今すぐGitHubリポジトリを開き、Lintを走らせよう。その1行の修正が、明日の深夜の障害を未然に防ぐのだから。