Windows × Puppet：その「泥沼」を「コードによる支配」へ変える極限戦術
Windowsサーバーの構成管理をPuppetで始めたエンジニアが、最初の数週間で直面する絶望。それは「Linuxのようにファイル一つで全てが解決しない」という現実だ。レジストリ、COMオブジェクト、そして複雑怪奇なActive Directory（AD）の権限設定。
これらをPuppetのDSLだけで解決しようとするのは、素手で岩を砕こうとするに等しい。真のSREは、Puppetを「オーケストレーター」として使い、実務の泥臭い処理をPowerShellという「職人芸」に委ねる。
今日は、Windows環境においてPuppetを実戦レベルで使い倒すための、現場の「深淵」を共有する。
—
1. なぜ「Puppet単体」で完結させようとしてはいけないのか
PuppetのWindowsリソース（`package`, `service`, `file`）は、基本的には優秀だ。しかし、一歩踏み込んだ設定――例えば「特定のGPOを適用した後の特定レジストリの変更」や「ADユーザーの属性変更」――を行う際、Puppetのネイティブリソースだけで実装すると、コードが肥大化し、可読性が死ぬ。
現場の鉄則：冪等性（Idempotency）はPowerShellの中に埋め込め
`exec` リソースを使う際にやってはいけないのが、「毎回スクリプトを実行する」ことだ。必ず「適用が必要な状態か？」をPowerShell側で判定し、変更が必要な場合のみ処理を行う（かつ終了コードで成否を返す）設計にすること。
NG: 冪等性がなく、毎回実行される
exec { ‘apply_custom_config’:
command => ‘powershell.exe -File C:\scripts\config.ps1’,
}
OK: 判定ロジックを組み込み、Puppetのrefreshonlyやonlyifを活かす
exec { ‘apply_custom_config’:
command => ‘C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File C:\scripts\config.ps1’,
# スクリプト内で変更が必要な場合のみ Exit 0 以外を返して制御する
unless => ‘powershell.exe -Command “if((Get-ItemProperty …).Value -eq 1) { exit 0 } else { exit 1 }”‘,
provider => powershell,
}
—
2. 実務を劇的に加速させる「隠れた環境構築」
VS Code神プラグイン
Windows管理者がPuppetを書くなら、迷わず以下を入れろ。
- Puppet (by Puppet, Inc.): 言語サーバーが必須。構文チェックとドキュメント参照が爆速になる。
- PowerShell (by Microsoft): デバッガーが強力。`F8`で選択範囲の実行、`F5`でデバッグは、Windows管理者の生命線だ。
- YAML (by Red Hat): Hieraファイルを扱う際、このプラグインなしでインデントミスを避けるのは不可能。
チーム開発の「コード規約」――Hieraは「構造」で殺せ
Hieraに全てを詰め込むな。`common.yaml`に全てを書くのはアンチパターンだ。環境、ロール、ノードごとにファイルを分割し、「継承の深さを3階層以内」に制限せよ。
推奨ディレクトリ構成:
data/
├── common.yaml # 全サーバー共通設定
├── os/
│ └── windows_2022.yaml # OS固有のチューニング
└── roles/
└── web_server.yaml # ミドルウェア固有のAD連携設定など
—
3. AD連携におけるPuppetの究極解
ADドメイン参加やグループポリシーの管理は、`exec`で無理やりやらず、専用のモジュールを活用しつつ、最終的な微調整のみをPowerShellで行うのが定石だ。
実践的：PowerShellスクリプトのテンプレート化
Puppetの`file`リソースでスクリプトを配布し、それを`exec`で叩くのが最も保守性が高い。
C:\scripts\set-ad-permission.ps1
冪等性を担保したAD操作のテンプレート
[CmdletBinding()]
param()
$targetGroup = “Domain Admins”
$acl = Get-Acl “C:\Data\Secure”
すでに設定済みなら何もしない
if ((Get-AclRule -Target $acl -Group $targetGroup)) {
Write-Output “Already configured.”
exit 0
}
変更を実行
try {
# 処理内容…
exit 0
} catch {
exit 1 # Puppetに失敗を通知
}
—
4. チームの生産性を引き上げる「極意」
1. プロキシ設定の自動化: Windows ServerのPuppet Agentがプロキシ越しの場合、`puppet.conf`だけでなく、PowerShellのプロファイルにも環境変数を注入せよ。
2. ログの可視化: WindowsのイベントログにPuppetの実行結果を書き出すラッパーを書け。監視ツール（ZabbixやDatadog）と連携させる際、Puppetの標準出力だけでは不十分だ。
3. キーボードショートカットの徹底:
- `Ctrl + Shift + P` (VS Code): コマンドパレットからPuppetのLintチェックを叩く。
- `Alt + Up/Down`: 行の入れ替えを指に覚え込ませ、リファクタリングの速度を上げる。
—
最後に：コードを書くことは「文化」を作ること
PuppetでWindowsを管理するということは、単に設定を自動化するだけではない。「手動でサーバーを触る」という、最も効率が悪く、最もリスクが高い行為を組織から排除することだ。
Windowsの複雑さを理解した上で、PowerShellの力を借りてPuppetという巨大な歯車を回す。この戦略をとれば、君の管理するサーバーは「放置されるゴミ」から「いつでも再構築可能な資産」へと変わる。
泥臭い現場こそ、コードで洗練させろ。それが、伝説のSREに近づく唯一の道だ。