【入門編】Puppet Manifest（マニフェスト）の書き方入門！基本構文とリソース定義のルール – インフラ構成管理（IaC）活用バイブル

こんにちは。現場の最前線でインフラを「コード」として叩き込んできたエンジニアです。

Puppetというツールに出会ったとき、多くの人が感じるのは「なぜシェルスクリプトじゃダメなのか？」という疑問です。シェルは「手順」を書きますが、Puppetは「あるべき姿（状態）」を書きます。このパラダイムシフトこそが、大規模インフラを崩壊させずに守り抜くための唯一の道なのです。

今日は、あなたのインフラ管理を「作業」から「設計」へと昇華させるための、Puppetマニフェスト入門を伝授します。

—

シェルスクリプトで`apt-get install`を書くとき、あなたは「すでにインストールされていたらどうするか？」という条件分岐を毎回考えなければなりません。面倒ですよね。

Puppetのマニフェスト（`.pp`ファイル）には、こう書きます。
「このパッケージはインストールされているべきだ」

Puppetのエンジンは、その宣言を受け取ると、現在の状態と照らし合わせ、足りなければ足し、余計なものは放置し、間違っていれば修正します。これが冪等性（Idempotency）です。何度実行しても、結果は常に「あるべき状態」に収束する。この安心感が、SREの夜を安らかにするのです。

まずはあなたのマシンでPuppetを動かしてみましょう。Linux環境であれば、以下のコマンドでAgentをインストールします（今回は学習用としてスタンドアロンで動かします）。

Debian/Ubuntu系の場合
sudo apt update && sudo apt install -y puppet

動作確認として、`test.pp`というファイルを作り、以下のコードを書いてください。

test.pp
notify { ‘Hello, Puppet World!’: }

実行はこれだけです。

puppet apply test.pp

`notice: Hello, Puppet World!`と表示されれば、あなたの最初の一歩は成功です。

—

Puppetでは、管理対象を「リソース」と呼びます。現場で最も使う3大リソースを覚えましょう。

1. パッケージ管理
package { ‘nginx’:
ensure => installed, # インストールされている状態を強制
}

2. ファイル管理
file { ‘/etc/nginx/nginx.conf’:
ensure => file,
source => ‘puppet:///modules/nginx/nginx.conf’, # 管理下にあるファイルを配布
mode => ‘0644’,
}

3. サービス管理
service { ‘nginx’:
ensure => running, # 起動している状態を強制
enable => true, # OS起動時に自動実行させる
}

ここで重要なのはリソース間の依存関係です。「パッケージがインストールされた後で設定ファイルを置き、その後にサービスを起動する」という順番を明示する必要があります。

依存関係の制御（-> は「左が完了してから右を実行」の意）
package[‘nginx’] -> file[‘/etc/nginx/nginx.conf’] ~> service[‘nginx’]

※ `~>`（通知）を使うと、設定ファイルが変更されたときだけサービスを再起動（リロード）するという高度な制御も可能です。

—

初心者がやりがちなのは、`exec`リソースで何でもかんでもコマンドを叩くことです。しかし、`exec`は冪等性を自分で担保しなければなりません。

良い例（`creates`属性で実行条件を制限）:

exec { ‘download-source’:
command => ‘/usr/bin/wget http://example.com/source.tar.gz’,
creates => ‘/tmp/source.tar.gz’, # このファイルがあれば実行しない
}

悪い例:

毎回必ず実行されてしまう。これではPuppetの恩恵が台無しです
exec { ‘/usr/bin/apt-get update’: }

※ `apt update`などは専用のモジュールを使うのが鉄則です。

—

Puppetの学習は、まず「対象となるシステムを小さなパーツに分解する」ことから始まります。

1. 宣言的に書く: 「何をしたいか（手順）」ではなく「どうあるべきか（状態）」を書く。
2. 依存関係を意識する: `require`や`->`を使って、正しい順序を保証する。
3. 冪等性を疑う: 「このコードを100回実行しても、システムは壊れないか？」と自問する。

この思考プロセスが身につけば、あなたはもう「サーバーにログインして手作業でコマンドを打つ」という泥臭い世界から卒業です。コードをGitで管理し、CI/CDパイプラインに乗せる。それが、現代のインフラエンジニアの姿です。

さあ、次はあなた自身の手で、小さな設定をPuppetに任せてみてください。その「自動化された快感」を知ってしまえば、もう手作業には戻れなくなるはずですよ。

応援しています。何か詰まったら、いつでも聞いてくださいね。