【Puppet】Hieraによる「データとコードの完全分離」：運用を自動化ではなく「自律化」させる設計術
Puppetを単なる「設定ファイル配布ツール」だと思っているなら、今すぐその認識を捨ててほしい。Puppetの真価は、言語としてのPuppet DSLと、設定データ層である「Hiera」を完全に切り離すことで、「何度実行しても同じ状態になる（冪等性）」という強固な土台の上で、環境ごとの差異を完全に抽象化できる点にある。
本稿では、コードの再利用性を最大化し、運用コストを極限まで下げるためのHiera戦略を伝授する。
—
1. Hieraは「if文」を殺すためのツールである
マニフェスト（`.pp`ファイル）の中に `if $environment == ‘production’ { … }` を書いているチームは、即刻そのコードを削除すべきだ。
Hieraを導入する最大のメリットは、ロジックと設定値のデカップリングにある。Hieraは単なるデータストアではない。ノードの属性（OS、ホスト名、環境など）に基づいて、動的にパラメータを解決する「階層型検索エンジン」だ。これを使えば、マニフェストは「何をすべきか（宣言）」に集中でき、Hieraは「どの値を使うか（事実）」に集中できる。
2. `hiera.yaml`：検索の優先順位こそが「神」である
`hiera.yaml`は、設定の継承関係を決定する心臓部だ。以下の構成は、大規模インフラにおいて最も破綻しにくい「階層構造」のベストプラクティスだ。
hiera.yaml (Puppet 5以降のv5フォーマット)
version: 5
defaults:
datadir: data
data_hash: yaml_data
hierarchy:
- name: “Per-node data” # 1. 特定のノード専用設定（緊急修正用）
path: “nodes/%{trusted.certname}.yaml”
- name: “Per-environment data” # 2. 環境ごとの設定
path: “environments/%{server_facts.environment}.yaml”
- name: “Common data” # 3. 全環境共通の設定
path: “common.yaml”
プロの極意:
`%{trusted.certname}` を使うのが肝だ。クライアント側で勝手に定義された変数ではなく、CAによって署名された証明書名（信頼されたソース）をキーにすることで、セキュリティと一貫性を担保する。
3. 実践：環境別パラメータの定義
ディレクトリ構成は以下のように整理するのが正解だ。
control-repo/
├── data/
│ ├── common.yaml # NTP設定、DNSなど全ノード共通
│ ├── environments/
│ │ ├── production.yaml # 本番環境のDB接続先、リソース制限
│ │ └── staging.yaml # ステージング環境の設定
│ └── nodes/
│ └── web01.example.com.yaml # 個別チューニングが必要なノード
production.yaml の例:
—
複雑な設定はHashで持たせ、lookupをスマートにする
my_module::db_config:
host: ‘db-prod.internal’
port: 5432
pool_size: 20
4. マニフェストからの呼び出し：`lookup()`の活用
古い `hiera()` 関数はもう使うな。`lookup()` 関数を使え。型チェック（Data Types）を併用することで、予期せぬ型エラーをコンパイル時に検知できる。
マニフェスト内での呼び出し
class my_module::db_setup {
# 型を指定してlookupする。型が合わなければ即座にエラーになり、デバッグが容易になる
$db_config = lookup(‘my_module::db_config’, Hash[String, Any])
file { ‘/etc/db_config.conf’:
ensure => file,
content => epp(‘my_module/db_config.epp’, { ‘config’ => $db_config }),
}
}
—
チーム開発を加速させる「エンジニアの作法」
隠れたキーボードショートカット & ツール
- Puppet Lint: `puppet-lint` はCIに必須。コードの品質を強制的に一定にする。
- VS Code プラグイン: `Puppet` 拡張機能を入れるのは当然として、`YAML` 拡張機能で「スキーマ」を定義せよ。JSON Schemaを当てれば、YAML編集時のタイポを即座に発見できる。
- `puppet lookup –explain`: これを使いこなせ。どのファイルからどの値が採用されたかを追跡できる、デバッグの最強ツールだ。
チームで共有すべき「ルール」
1. デフォルト値は `common.yaml` に置くな: `common.yaml` は「全社共通のインフラ定義」だけに留め、モジュールごとのデフォルト値は `module/data/` 内に含める「モジュールデータ」機能を使うのがモダンな設計だ。
2. `lookup`の第3引数を見極めろ: `first` (最初に見つかったもの) か `deep` (Hashをマージする) か。`deep` を多用すると設定の追跡が困難になる。基本は `first` で、明示的に上書きする構造を好め。
最後に：自動化の先にあるもの
Hieraを完璧に使いこなすと、インフラは「コードの集まり」ではなく「データの集合体」として管理できるようになる。新しい環境を構築する際、必要なのは新しいマニフェストを書くことではなく、`environments/` 配下に新しいYAMLファイルを置くことだけだ。
これが、我々SREが到達すべき「Infrastructure as Data」の境地である。明日からのデプロイメントで、ぜひこの設計思想を取り入れてほしい。君のインフラは、もっとエレガントになれるはずだ。