こんにちは。インフラの自動化という荒野を旅するエンジニアの皆さん。
今日は、Puppetという「古豪にして最強」の構成管理ツールを、現代のCI/CDパイプラインに乗せて、「壊れないインフラ」をコードで実現する方法を伝授します。
「Puppetは古い？」——とんでもない。冪等性（何度実行しても同じ結果になること）を担保する設計思想において、Puppetほど完成されたツールは他にありません。これをGitとGitHub Actionsで武装させれば、手作業の恐怖から永遠に解放されます。
さあ、堅牢なインフラ自動化の世界へ足を踏み入れましょう。
—
1. バージョン管理戦略：Gitは「インフラの設計図」である
Puppetのコード（マニフェスト）を、単なるテキストファイルとして扱ってはいけません。Gitは「インフラの現在地」を記録する唯一の場所です。
- GitHub Flowの採用: `main`ブランチを本番の状態と一致させ、機能追加や修正は必ずフィーチャーブランチで行います。
- ディレクトリ構成の標準化: `r10k` や `Control Repo` と呼ばれる構成を意識してください。
- `manifests/`: 全体のノード定義
- `modules/`: 役割ごとの再利用可能なロジック
- `data/`: Hiera（設定の外部化）データ
2. GitHub Actionsで「構文の悪魔」を退治する
コードをプッシュするたびに、人間が目で構文チェックをするのは非効率です。ここで `puppet-lint` の出番です。
`.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-lint
run: gem install puppet-lint
- name: Run lint
# –fail-on-warningsで警告も許さない厳格さを
run: puppet-lint –fail-on-warnings .
これを導入するだけで、インデントミスや不要なスペースによる「動かない恐怖」が、プッシュした瞬間に可視化されます。
3. rspec-puppet：テスト駆動インフラの真髄
「サーバーに適用してみないと結果が分からない」……そんな博打はもう終わりにしましょう。`rspec-puppet` を使えば、実行前にコードの論理的な正しさを検証できます。
まずはGemfileを用意し、`bundle install` します。
Gemfile
source ‘https://rubygems.org’
gem ‘rspec-puppet’
gem ‘puppetlabs_spec_helper’
そして、最もシンプルなテストコード（HelloWorld的なもの）を書いてみます。`spec/classes/my_app_spec.rb` です。
require ‘spec_helper’
describe ‘my_app’ do
it { is_expected.to compile } # コンパイルエラーがないか確認
it { is_expected.to contain_package(‘nginx’).with_ensure(‘present’) } # nginxパッケージが必要であることを検証
end
このテストが通るということは、「意図したパッケージが構成に含まれている」ことが数学的に証明されたのと同じです。
4. デプロイの自動化フロー：最後の一押し
テストが通ったコードをサーバーに反映させるには、`r10k` を使うのが業界標準です。CI/CDの最後で、Puppetサーバーに対して「最新のコードを取得せよ」というコマンドを叩かせます。
Puppetサーバー側での実行コマンド例
r10k deploy environment -p
これをGitHub Actionsのデプロイジョブに組み込めば、「GitHubにマージしたら、数分後には全世界のサーバーが最新状態になる」という、夢のような世界が完成します。
—
先輩エンジニアからのアドバイス
初心者の皆さんが最初につまずくのは、「何が正しい状態か」を定義することです。Puppetの素晴らしい点は、「あるべき状態（Desired State）」を宣言するだけで、ツールが勝手に現実をそこに寄せてくれることです。
1. 小さく始める: まずは1つの設定ファイル（例：ntpの設定など）をコード化する。
2. LintとRSpecを強制する: どんなに小さくてもテストを通す癖をつける。
3. Hieraを活用する: 環境ごとの違いをコードから分離し、設定データとして管理する。
これをマスターすれば、深夜の緊急作業に呼び出されることは激減します。インフラは「管理するもの」から「コードで記述し、自動で育てるもの」へ。
さあ、次はあなたの番です。最初の `git push` を実行して、インフラをあなたの手の中に収めてください。何か詰まったら、いつでも聞いてくださいね。応援しています！