Packerとは？HashiCorpのマシンイメージ自動構築をTerraform・構成管理との違いと実装視点で解説

Packerは、単一の設定ファイルから、AWSのAMIやAzure・GCPのイメージ、Dockerイメージまでを同時に自動構築する、HashiCorp製のオープンソースツールです。サーバを一台ずつ手作業でセットアップする代わりに、必要なソフトと設定を焼き込んだ「golden image（ゴールデンイメージ）」をコードから量産できます。「Terraformと何が違うのか」「Ansibleのような構成管理ツールと役割がかぶらないのか」で判断が止まる技術選定者は多いはずです。本記事は、builders/provisioners/post-processorsという仕組みとHCL2テンプレート、Terraformや構成管理ツールとの役割分担、イメージ自動化のワークフロー、そしてPackerを採用すべき組織と見送るべき場面までを、実装の解像度で整理します。

まとめ：Packerの要点とイメージ自動化を採用するかの判断軸

先に結論を置きます。Packerは、一時的なインスタンスを起動し、そこにソフトウェアを入れて設定し、その状態をマシンイメージとして保存する——この一連を自動化するツールです。同じソース設定から、AWS・Azure・GCP・Docker・VMwareなど複数のプラットフォーム向けに、中身の揃ったイメージを並行して焼けます。作られたイメージは、あとからTerraformなどで配置してサーバとして起動します。

Packerの立ち位置は、Terraformや構成管理ツールと対比すると掴めます。Terraformが「インフラのリソースをどう配置するか」を担うのに対し、Packerは「配置する前のイメージをどう焼くか」を担います。AnsibleやChefのような構成管理が「起動済みのサーバを実行時に構成する」のに対し、Packerは「ビルド時にイメージへ焼き込む」。工程の場所が違うため、これらは競合ではなく組み合わせて使う関係にあります。

判断の軸は明確です。同じ構成のサーバを何台も並べる、サーバを更新のたびに作り直す（イミュータブルインフラ）、複数のクラウドやオンプレへ同一のイメージを配りたい——こうした組織はPackerが見合います。逆に、サーバが数台で更新も稀、あるいはアプリの配布単位がすでにコンテナで完結している組織では、Packerを挟む前に構成管理やコンテナで足りることが多いです。まず「イメージを標準化して量産する必要が実在するか」を先に問うのが、導入を判断する順序です。

Packerの定義とマシンイメージを単一設定から自動構築する仕組み

Packerを理解する近道は、それが何を入力に何を出力するのかを押さえることです。中身は「一時インスタンスを起動→中身を作り込む→イメージ化して保存→一時インスタンスを破棄」という単純な流れで、その各段を担う部品が用意されています。

builders・provisioners・post-processorsの三つの部品

Packerのテンプレートは、大きく三種類の部品で組み立てます。まず builders（ビルダー）が、どのプラットフォーム上で元となる一時インスタンスを起動し、何としてイメージ化するかを決める部品です。AWSのAMI、Azureのmanaged image、GCPのイメージ、Docker、VMware、VirtualBox、QEMUなど、対象ごとにビルダーが分かれています。次の provisioners（プロビジョナー）は、起動した一時インスタンスにソフトウェアを入れ、設定を施す段。シェルスクリプトのほか、AnsibleやChef、PowerShellなども呼び出せます。post-processors（ポストプロセッサ）は、できたイメージの圧縮やタグ付け、レジストリへの登録といった後処理を担う部品です。この三段を一つのテンプレートに書けば、素のOSから必要な状態まで作り込んだイメージが、コマンド一つで焼き上がります。

HCL2テンプレートとプラグイン方式でプラットフォーム対応を広げる仕組み

テンプレートの記述形式は、現在はHCL2（HashiCorp Configuration Language 2）が標準です。TerraformなどHashiCorpの他ツールと同じ構文系なので、片方に慣れていれば読み書きの学習コストは小さく収まります。従来はJSON形式のテンプレートも使えましたが、いまはレガシー扱いで、既存のJSONは hcl2_upgrade でHCL2へ変換できます。加えて、builders・provisioners・post-processorsは本体から切り離されたプラグインとして提供され、必要なものを packer init で取得する方式です（1.7系で確立）。これにより、クラウドやツールが増えても本体を肥大化させずにビルダーを足していけます。どのプラットフォームに対応するかは、入れるプラグイン次第で広がる設計です。

packer initからpacker buildまでの実行の流れ

実際のビルドは、二つのコマンドが中心です。おおまかな流れは次のとおりです。

1. packer init：テンプレートが要求するプラグイン（ビルダー等）を取得する
2. packer build：ビルダーが一時インスタンスを起動し、provisionerで中身を作り込む
3. 作り込んだ状態をマシンイメージとして保存し、post-processorで後処理する
4. 役目を終えた一時インスタンスは自動で破棄され、成果物のイメージだけが残る

ビルドのたびに使い捨てのインスタンスを起こして焼き、終わったら消すため、手元の環境を汚さずに再現性の高いイメージが得られます。この「毎回まっさらから焼き直す」性質が、後述するイミュータブルインフラと相性を生みます。

PackerとTerraform・構成管理ツールとの役割分担

Packerで最も誤解されやすいのが、Terraformや構成管理ツールとの線引きです。名前が近く同じHashiCorp製のTerraformとは、実は担当する工程がまったく別です。ここを分けて押さえます。

Terraformが配置し、Packerがイメージを焼くという分業

TerraformとPackerは、どちらもHashiCorp製でHCL系の設定を書きますが、担当が分かれています。Packerは「サーバの中身（イメージ）を作る」、Terraformは「そのイメージを使ってサーバやネットワークを配置する」役です。定番の流れは、Packerでアプリと依存関係を焼き込んだイメージを用意し、そのイメージIDをTerraformが受け取ってインスタンスとして起動する、というものです。片方だけでも使えますが、両方を組み合わせると「焼く」と「並べる」が分業でき、イメージの中身とインフラの構成をそれぞれコードで管理できます。Terraform側の具体的な管理・バージョニングはTerraformによるインフラコードの管理とバージョン管理で扱っており、Packerはその前段でイメージを供給する位置づけです。

Ansible等の構成管理ツールとの「焼き込み」対「実行時構成」の差

AnsibleやChef、Puppetといった構成管理ツールとPackerは、いつ構成を当てるかが異なります。構成管理は、すでに起動しているサーバへ実行時に接続し、パッケージ導入や設定を施します。Packerは、ビルド時に一時インスタンスへ同じことを施し、その結果をイメージへ焼き込みます（bake）。前者は「動いているサーバを継続的に整える」向き、後者は「整った状態を固めて量産する」向きです。両者は排他ではなく、PackerのprovisionerとしてAnsibleを呼び、焼き込みの中身を構成管理の記述で書く、という併用がよく取られます。役割で言えば、Packerが器を焼き、構成管理がその中身の作り方を担うイメージです。

コンテナイメージとPackerのマシンイメージのビルド対象の違い

「Dockerでイメージを作るのと何が違うのか」もよく挙がる論点です。Dockerfileが焼くのはコンテナイメージで、アプリとその依存をコンテナランタイム上で動かす単位。Packerが焼くのはマシンイメージ（VMやクラウドインスタンスのAMI等）で、OSごと丸ごと固める単位です。レイヤが一段違い、コンテナは「アプリの箱」、Packerのイメージは「サーバそのものの型」を作る単位です。実際にはPackerでコンテナのホストとなるVMイメージを焼き、その上でコンテナを動かす重ね方もあります。コンテナイメージのビルド作法はDockerfileの書き方と主要命令・ベストプラクティスで整理しており、対象とするレイヤの違いを押さえると使い分けが見えてきます。

Packerによるイメージ自動化のワークフローとイミュータブルインフラ

Packerの値打ちは、単体のコマンドより、それを組み込んだ運用の型に出ます。ゴールデンイメージとイミュータブルインフラという二つの考え方を軸に、実務での使われ方を見ます。

ゴールデンイメージを量産して環境差をビルドの段階で消し込む運用

ゴールデンイメージとは、OS・ミドルウェア・自社アプリ・セキュリティ設定まで作り込んだ「基準となるイメージ」です。これをPackerで焼いておけば、開発・検証・本番のどの環境でも、同じ土台からサーバを起こせます。手作業でサーバを立てると、担当や時期によって微妙に構成がずれ、「本番だけ動かない」の温床になりがち。Packerでイメージを一元管理すれば、環境差はビルドの段階で消し込めます。CI/CDに組み込み、アプリの更新やパッチのたびにイメージを焼き直す運用が、常に最新のゴールデンイメージを供給する形です。GitHub Actions等との連携で焼く工程を自動化する型は、TerraformとGitHub ActionsでCI/CDを構築する手順と同じ発想で組めます。

更新のたびにイメージから作り直すイミュータブルインフラでの位置づけ

イミュータブルインフラとは、稼働中のサーバに手を入れて更新する代わりに、新しいイメージから作り直して丸ごと入れ替える運用思想です。パッチ当てや設定変更を稼働サーバ上で繰り返すと、状態が少しずつ食い違い、再現できない構成が積み上がります。イミュータブルインフラでは、変更はイメージの側で行い、Packerで焼き直した新イメージからインスタンスを起こして旧環境と差し替えます。Packerは、この「作り直す型」の入り口であるイメージ生成を担う中核です。ロールバックも「前のイメージへ戻す」で済むため、切り戻しの見通しが良くなります。イミュータブルインフラは、クラウドネイティブが掲げる原則の一つでもあります。

HCP Packerでイメージの来歴とバージョンを集約して管理する

焼いたイメージが増えると、「どのイメージが本番可か」「どのビルドから来たものか」の管理が課題になります。HCP Packerは、HashiCorp Cloud Platform上で、イメージのメタデータ・バージョン・来歴（provenance）を集約するmanagedレジストリです。チャネルという仕組みで「本番用の最新イメージ」を指し示し、Terraform側はそのチャネルを参照して常に承認済みのイメージを使えます。OSS版のPacker本体がイメージを焼く層だとすれば、HCP Packerはそれを台帳として束ねる層で、位置づけはHCP Terraform（旧Terraform Cloud）の機能と料金と同じく、OSSツールに対するmanaged商用サービスにあたります。イメージの数がチームで管理しきれなくなった段階で検討する選択肢です。

Packerを採用すべき組織とイメージ量産を見送るべき場面の条件

ここは立場を明確にします。Packerは強力ですが、すべての組織に要るものではありません。導入が見合う条件と、挟まないほうがよい条件を分けて示します。

Packerの導入が見合うイメージ標準化・量産が実在する要件

次の条件が当てはまるほど、Packerの導入が見合います。

• 同じ構成のサーバを何台も並べる、あるいはオートスケールで頻繁に起動する
• イミュータブルインフラを採り、更新のたびにイメージから作り直したい
• AWS・Azure・GCP・オンプレなど複数基盤へ、中身の揃ったイメージを配りたい
• 環境差（開発と本番のずれ）を、ビルドの段階で消し込みたい

これらはいずれも「イメージを標準化して量産する必要」が実在するケースです。既存の構成管理（Ansible等）をprovisionerとして流用でき、Terraformと組めば焼く工程と配置する工程を分けて管理できます。マシンイメージの標準化やクラウド移行の基盤づくりを外部の手で進めたい場合は、AWS・Google Cloud・Azureのインフラ構築で、イメージ設計からTerraformでの配置、CI/CD整備まで対応しています。

構成管理ツールやコンテナで足りてPackerを見送るべき条件

逆に、次の場合は無理にPackerを挟むべきではありません。第一に、サーバが数台で更新も稀な小規模構成です。イメージを焼くパイプラインを用意する手間が、得られる再現性の値打ちを上回りがちです。既存の構成管理ツールで実行時に整えるだけで足ります。第二に、アプリの配布単位がすでにコンテナで完結している場合です。ビルドがコンテナイメージで閉じているなら、その手前でマシンイメージを焼く必然は薄く、Dockerfileとコンテナレジストリで回せます（ホストVMの標準化が要る段階で初めてPackerが効きます）。第三に、マネージドサービスやサーバレスが中心で、そもそも自前のサーバイメージを持たない構成です。この場合はイメージ管理という課題自体が発生しません。まず「イメージを量産・標準化する必要が実在するか」を確かめ、必要が立ってから導入を検討する。この順序が、道具先行の過剰投資を避けます。

Packerの仕組み・使い方・採用判断についてのよくある質問

検討段階でよく挙がる質問をまとめます。Terraformや構成管理との役割分担と、採用判断に絞って答えます。

PackerとTerraformはどちらを使えばよいですか？

役割が別なので、多くの場合は両方を組み合わせます。Packerはサーバの中身（マシンイメージ）を焼くツール、Terraformはそのイメージを使ってインフラを配置するツールです。イメージを標準化して量産したいならPacker、リソースの配置をコード管理したいならTerraform、という担当分けになります。イメージを焼く必要がなく既存のイメージで足りるならPackerは不要ですし、逆に配置は手動でイメージだけ量産したいならPacker単体でも使えます。定番はPackerで焼いてTerraformで並べる分業です。

Packerと構成管理ツール（Ansible等）は競合しますか？

競合しません。当てるタイミングが違うためです。Ansible等の構成管理は起動済みのサーバを実行時に構成し、Packerはビルド時にイメージへ焼き込みます。むしろ併用が一般的です。PackerのprovisionerとしてAnsibleを呼び、焼き込む中身の作り方を構成管理の記述で書けます。更新のたびに作り直すイミュータブルインフラならPackerで焼く側に寄せ、稼働サーバを継続的に整える運用なら構成管理を実行時に回す、という重心の置き方で使い分けます。

PackerとDockerイメージは何が違うのですか？

ビルドする対象のレイヤが違います。Dockerが作るのはコンテナイメージで、アプリと依存をコンテナランタイム上で動かす単位です。Packerが作るのはマシンイメージで、OSごと固めるVMやクラウドインスタンス（AMI等）の単位です。コンテナは「アプリの箱」、Packerのイメージは「サーバの型」と捉えると整理できます。両者は排他ではなく、PackerでコンテナホストとなるVMイメージを焼き、その上でコンテナを動かす、という重ね方もあります。

Packerのテンプレートはどの形式で書きますか？

現在はHCL2形式が標準です。TerraformなどHashiCorpの他ツールと同じ構文系のため、片方に慣れていれば学習は移せます。以前はJSON形式のテンプレートも使えましたが、いまはレガシー扱いで、既存のJSONは hcl2_upgrade コマンドでHCL2へ変換する形です。テンプレートにはbuilders・provisioners・post-processorsのブロックを書き、必要なプラグインは packer init で取得します。新規に書き始めるならHCL2を選ぶのが素直です。

Packerは無料で商用利用できますか？

OSS版のPacker本体は、オープンソースとして提供され、商用利用が可能です。CLIでイメージを焼く範囲は自前で完結します。一方、イメージのメタデータ・バージョン・来歴を集約したい場合のHCP Packerは、HashiCorp Cloud Platform上のmanaged商用サービスで、無料枠と有料プランが分かれます。まずOSS版でイメージ構築を回し、イメージの数がチームで管理しきれなくなった段階でHCP Packerを検討する、という順序が実務的です。

関連記事

• Terraformを用いた効率的なインフラコードの管理とバージョン管理：Packerが焼いたイメージを配置する側。焼く工程と並べる工程の分業で組み合わせる
• Dockerfileとは｜書き方・主要命令・ベストプラクティスを解説：コンテナイメージのビルド。Packerのマシンイメージとはレイヤが別で対比の対象
• HCP Terraformとは？旧Terraform Cloudの料金・機能とHCPでの位置づけ：同じHashiCorpのmanaged商用サービス。HCP Packerと同じ層の位置づけ