LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

Packer（HashiCorp Packer）は、1つの設定ファイルから、複数のプラットフォーム向けに同じ中身のマシンイメージを作るツールです。マシンイメージとは、設定済みのOSと導入済みのソフトウェアをひとまとめにしたもので、そこから新しいサーバーをすぐに起動できます。AWSのAMI（Amazon Machine Image）がその代表です。一般語のpacker（荷造りの道具）とは別物です。

サーバーを起動するたびにパッケージを入れていると、時間がかかり、起動した時期によって中身もずれます。Packerは、その手順を前もってイメージに焼き込む役を受け持ちます。本記事では、テンプレートの構成、近い道具との役割分担、実際に動かしたコマンドの結果、つまずきやすい点を整理します。

Packerとは

Packerは、HashiCorpが開発しているイメージ作成のツールです。公式ドキュメントでは、マシンイメージの形式はプラットフォームごとに違い、EC2のAMI、VMwareのVMDKとVMX、VirtualBoxのOVFといった例が挙げられ、PackerはChefやPuppetのような構成管理を置き換えるものではなく、イメージを作るときにそれらを使える、と説明されています。^*1 起動した後のサーバーを設定し続ける道具と、起動する前のイメージを用意する道具は、受け持つ時点が違います。

2026年10月1日時点の現行版は、2026年9月18日に出た1.16.1です。1.10.0からは、amazonやdockerなどのプラグインが本体に同梱されなくなり、packer initかpacker pluginsで入れる形になりました。^*2 ライセンスにも触れておきます。HashiCorpは2023年8月10日、今後のリリースのライセンスをMPL 2.0からBSL（Business Source License）1.1に変えると告知しました。^*3 1.16.1の配布物に入っているLICENSE.txtでは、対象をPacker 1.10.0以降とし、各版の公開から4年後にMPL 2.0へ移ると定めています。^*4 Packerを組み込んだサービスを他社に提供する場合は、利用許諾の範囲を法務に確かめておきます。

テンプレートを組む4つのブロック

Packerの設定ファイルは、HCL2（HashiCorp Configuration Language）で書き、拡張子を.pkr.hclにします。中身は主に4つのブロックで組み立てます。

• source：どのビルダーで、どこに、何を元にイメージを作るかの設定。AWSならamazon-ebs、コンテナならdockerといったビルダーの種類と、リージョンや元のイメージを書く
• build：どのsourceを動かし、どう設定し、成果物にどんな後処理をするかをまとめる^*5
• provisioner：起動した一時的なマシンにソフトウェアを入れ、設定する。シェルスクリプトのほか、AnsibleやChefも使える
• post-processor：できた成果物を受け取って後処理をする。チェックサムを付ける、別の場所へ取り込む、成果物の一覧を書き出すといった用途

post-processorには気をつけたい既定の動きがあります。後処理に渡した元の成果物は、既定で消されます。元の成果物も残したいときは、keep_input_artifactをtrueにします。^*6

手で作業したサーバーをそのままイメージにするやり方と違い、どの手順で作ったかがテンプレートとして残ります。

近い3つの道具との違い

Packerと並べて語られやすいTerraform・Ansible・Dockerfileとは、受け持つ範囲で分けると整理できます。

Terraformは、Packerが作ったイメージを使う側です。IaCとTerraformの導入は「IaC/Terraform基盤構築の外注費用と委託先選びの判断軸」で扱っています。Ansibleとは組み合わせて使う関係で、基本は「Ansible入門」にまとめています。

Packerのdockerビルダーはコンテナを起動してprovisionerを実行し、それをエクスポートするかイメージとしてコミットします。Dockerfileを使わないので、Dockerに縛られないスクリプトや構成管理の道具でコンテナを設定できます。^*7 ただし、レイヤーの分け方まで細かく制御したいなら、Dockerfileのほうが素直です。コンテナだけを作るチームなら、Dockerfileのままで足りる場面が多いでしょう。

具体例：amazon-ebsでAMIを作る

amazon-ebsビルダーは、元のAMIからEC2インスタンスを起動し、そのマシンを設定してから、そこから新しいAMIを作ります。作業は利用者自身のAWSアカウントの中で行われ、作業中だけ使うキーペアやセキュリティグループのルールもPackerが用意します。^*8 次のsourceブロックは、東京リージョンで最新のAmazon Linux 2023のAMIを元にする設定です。

source "amazon-ebs" "web" {
  region        = "ap-northeast-1"
  instance_type = "t3.micro"
  ssh_username  = "ec2-user"
  ami_name      = "web-{{timestamp}}"
  source_ami_filter {
    filters = {
      name                = "al2023-ami-2023.*-x86_64"
      virtualization-type = "hvm"
    }
    owners      = ["amazon"]
    most_recent = true
  }
}

source_ami_filterで、元にするAMIを名前とAMIの所有者で絞り、most_recentで一番新しいものを選びます。IDを直接書くと、OSの更新のたびに書き換えが要るためです。続くbuildブロックで、Webサーバーのnginxを入れる手順と、できたAMIの一覧をファイルに書き出す後処理を指定します。

build {
  sources = ["source.amazon-ebs.web"]
  provisioner "shell" {
    inline = ["sudo dnf -y install nginx", "sudo systemctl enable nginx"]
  }
  post-processor "manifest" {
    output = "manifest.json"
  }
}

実際のファイルでは、先頭のpackerブロックのrequired_pluginsで、amazonプラグインの入手元と版の条件を指定しています。packer buildを実行するとEC2インスタンスが実際に起動し、料金がかかります。本記事では、AWSの認証情報を置かない環境で次の節のコマンドだけを実行し、ビルドは実行していません。

validateとfmtで実行前に確かめる

ビルドは時間も費用もかかるため、書いたテンプレートは先に手元で確かめます。packer validateはテンプレートの構文と設定を検査し、問題が無ければ終了コード0を返します。^*9 packer fmtは、HCL2のファイルを決まった書式に整えます。-checkを付けると書き換えはせず、書式が崩れていれば0以外の終了コードを返します。^*10 公式の配布元から入手した1.16.1で、上のテンプレートに実行した結果です。

$ packer version
Packer v1.16.1
$ packer fmt -check .
web.pkr.hcl
$ packer fmt .
web.pkr.hcl
$ packer validate .
The configuration is valid.

# ssh_username の行を消したファイルで validate
$ packer validate .
Error: 1 error(s) occurred:

* An ssh_username must be specified

最初のfmt -checkでファイル名が出ているのは、required_pluginsの中の「=」の位置がそろっていなかったためで、終了コードは3でした。fmtで整えた後はvalidateが通り、ssh_usernameの行を消したファイルでは、接続に使うユーザー名が無いという誤りで止まっています。どちらもAWSに接続せずに確かめられるので、CIの最初の段階に入れておきます。

なお-evaluate-datasourcesを付けるとデータソースまで評価し、外部のサービスへの問い合わせで費用がかかる場合があります。CIの既定の検査には付けないでおくのが無難です。

使いどころ

Packerが向いているのは、同じ構成のサーバーを何度も起動する場面です。台数が増えるたびに初期設定を流す方式では起動に時間がかかり、パッケージの配布元が止まっていると起動に失敗します。入れ終えたイメージから起動すれば、この待ち時間と失敗の要因を外せます。

OSの入れ替えにも使えます。土台のOSが変わるときは、テンプレートの元のAMIを差し替えてビルドし直し、検証環境で確かめてから切り替えます。Amazon Linux 2のサポート終了への対応は「Amazon Linux 2 サポート終了への対応」で扱っています。

AWSだけで完結するなら、AWSのEC2 Image Builderも候補になります。Image Builderはサーバーイメージの作成・管理・配布を自動化するフルマネージドのサービスで、Image Builder自体の利用料はかからず、作成の途中で使うEC2などの料金がかかります。^*11 複数のクラウドや仮想化基盤をまたぐならPacker、AWSの中で管理の手間を減らしたいならImage Builder、という分け方が目安です。

作ったイメージの版を組織で管理したい場合は、HashiCorpのHCP Packerがあります。保存するのはイメージそのものではなく、いつ・どのGitのコミットで作ったかといったメタデータで、本番向けのチャネルを決めたり、古いイメージを取り消して使わせないようにしたりできます。EssentialsとStandardの2つのエディションがあります。^*12

つまずきやすい点

1つ目は、イメージの肥大化です。provisionerでパッケージを入れると、パッケージマネージャーのキャッシュや作業用のファイルもそのまま残ります。イメージが大きくなると保存料金が増え、コピーにも時間がかかります。provisionerの最後にキャッシュと一時ファイルを消す手順を入れ、容量をビルドごとに記録しておくと、増え方に気づけます。

2つ目は、秘密情報の焼き込みです。ビルドの途中でAPIキーやパスワードをファイルに書くと、それはイメージに残り、そのイメージから起動したすべてのサーバーに配られます。変数にsensitiveを付けると、値はPackerの出力の上で伏せられます。^*13 ただしこれは画面やログの表示の話で、イメージの中に書き込んだファイルを消してくれるわけではありません。秘密情報はイメージに入れず、起動した後にシークレット管理のサービスから読み込む形にします。考え方は「クラウドのシークレット管理(KMS)運用と外注の判断軸」でも扱っています。

3つ目は、古いイメージの放置です。amazon-ebsビルダーはAMIを管理せず、作ったAMIを使うのも消すのも利用者の役目です。^*8 さらにAWSのドキュメントによれば、AMIの登録を解除しても既定では作成時のスナップショットは消えず、保存の料金がかかり続けます。^*14 何世代残すか、誰がいつ消すかを、ビルドを始める前に決めておきます。古いイメージには修正前の脆弱性も残っています。

外部に委託するときに確認しておきたい点

イメージ作りを外部に頼む場合、できたイメージだけを受け取ると、次にOSを更新するときに同じものを作り直せません。テンプレート、provisionerのスクリプト、プラグインの版を固定した設定を、自社のGitリポジトリに納めてもらう契約にしておきます。

• テンプレートと関連スクリプトが自社のリポジトリにあり、validateとfmt -checkがCIで回っているか
• ビルドに使うAWSの権限が、インスタンスの起動とAMIの作成に必要な範囲に絞られているか
• 秘密情報をイメージに入れない方法（起動後に読み込む仕組み）が設計に書かれているか
• 古いAMIとスナップショットを何世代残し、誰が消すかが運用の手順に入っているか
• Packerのライセンスの条件と、自社の使い方が合っているかを確かめたか

ビルドを自動で回す仕組みの作り方は「CI/CD構築支援を外注するメリットと進め方・費用の考え方」も参考になります。

まとめ：Packerで確かめておきたい3つの点

Packerを使い始めるうえで確かめておきたい点は3つです。第一に、Packerはイメージを作る道具で、インフラを作るTerraform、動いているサーバーを設定するAnsibleとは受け持つ時点が違うこと。第二に、テンプレートはsource・build・provisioner・post-processorで組み、ビルドの前にvalidateとfmt -checkで確かめること。第三に、秘密情報をイメージに入れない方法と、古いイメージを消す決まりを、ビルドを回し始める前に用意することです。この3点を押さえておけば、手で作ったイメージに頼る運用から、同じものを何度でも作り直せる運用へ移りやすくなります。

よくある質問

出典

1. *1　参考：HashiCorp Developer「Introduction to Packer」（https://developer.hashicorp.com/packer/docs/intro）。出典：Packerの定義（1つの設定から複数のプラットフォーム向けに同一のマシンイメージを作る）、マシンイメージの定義と形式の例（EC2のAMI、VMwareのVMDK・VMX、VirtualBoxのOVF）、ChefやPuppetなどの構成管理を置き換えないという記述を参照（2026年10月確認）
2. *2　参考：HashiCorp「Packer CHANGELOG」（GitHub hashicorp/packer）（https://github.com/hashicorp/packer/blob/main/CHANGELOG.md）。出典：1.16.1（2026年9月18日）と1.10.0（2023年12月5日）の項を参照。1.10.0でHashiCorpが保守するプラグイン（amazon・ansible・docker など）が本体に同梱されなくなり、packer init または packer plugins で導入する形になった。現行版はHashiCorpのリリース配布元（releases.hashicorp.com）でも確認（2026年10月確認）
3. *3　参考：HashiCorp「[COMPLIANCE] License changes (#12568)」（GitHub hashicorp/packer、2023年8月10日のコミット）（https://github.com/hashicorp/packer/commit/19055df3ec612ab556aa48e8eac2cb2d401fbab5）。出典：PackerのLICENSEをMPL 2.0からBusiness Source License v1.1に置き換えたコミット。今後このプロジェクトをBSL v1.1で提供するという説明を参照。同日のHashiCorpのブログ告知（hashicorp.com/blog/hashicorp-adopts-business-source-license）もあわせて確認（2026年10月確認）
4. *4　参考：HashiCorp「Packer 1.16.1 リリース配布物 LICENSE.txt」（https://releases.hashicorp.com/packer/1.16.1/）。出典：Windows版の配布物（packer_1.16.1_windows_amd64.zip、SHA256SUMSと一致を確認）に同梱のLICENSE.txt。対象をPacker 1.10.0以降とすること、Additional Use Grant、Change Date（公開から4年）とChange License（MPL 2.0）を参照（2026年10月確認）
5. *5　参考：HashiCorp Developer「build block」（https://developer.hashicorp.com/packer/docs/templates/hcl_templates/blocks/build）。出典：buildブロックが、どのビルダーを動かし、どう設定し、成果物にどの後処理をするかを指定するという記述と、sourcesでsourceブロックを参照する書き方を参照（2026年10月確認）
6. *6　参考：HashiCorp Developer「post-processor block」（https://developer.hashicorp.com/packer/docs/templates/hcl_templates/blocks/build/post-processor）。出典：post-processorが各ビルドの後に動き成果物を受け取ること、入力の成果物が既定で消されること、keep_input_artifactを参照（2026年10月確認）
7. *7　参考：HashiCorp Developer「Docker builder」（https://developer.hashicorp.com/packer/integrations/hashicorp/docker/latest/components/builder/docker）。出典：コンテナを起動してプロビジョナーを実行し、エクスポートまたはコミットすること、Dockerfileを使わずに作ること、Docker Engineが入った環境で動かすことを参照（2026年10月確認）
8. *8　参考：HashiCorp Developer「Amazon EBS builder（amazon-ebs）」（https://developer.hashicorp.com/packer/integrations/hashicorp/amazon/latest/components/builder/ebs）。出典：元のAMIからEC2インスタンスを起動して設定し、そのマシンからAMIを作るという動き、一時的なキーペアやセキュリティグループのルールを作ること、ビルダーはAMIを管理せず使用・削除は利用者に任されるという記述を参照（2026年10月確認）
9. *9　参考：HashiCorp Developer「packer validate command reference」（https://developer.hashicorp.com/packer/docs/commands/validate）。出典：テンプレートの構文と設定を検査し、成功で終了コード0を返すこと、-syntax-only、-evaluate-datasources（外部のサービスに問い合わせ費用がかかる場合がある）を参照（2026年10月確認）
10. *10　参考：HashiCorp Developer「packer fmt command reference」（https://developer.hashicorp.com/packer/docs/commands/fmt）。出典：HCL2の設定ファイルを正規の書式に直すこと、-checkで書式が整っていなければ0以外を返すことを参照（2026年10月確認）
11. *11　参考：Amazon Web Services「What is Image Builder?」（https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html）。出典：EC2 Image Builderがサーバーイメージの作成・管理・配布を自動化するフルマネージドのサービスであること、Image Builder自体の利用料はかからず使う他のサービスの料金がかかることを参照（2026年10月確認）
12. *12　参考：HashiCorp Developer「What is HCP Packer?」（https://developer.hashicorp.com/hcp/docs/packer）。出典：HCP Packerが成果物そのものではなくメタデータを保存すること、チャネル、古くなった成果物や危険のある成果物の取り消し（revoke）、EssentialsとStandardの2つのエディションを参照（2026年10月確認）
13. *13　参考：HashiCorp Developer「Input variables」（https://developer.hashicorp.com/packer/docs/templates/hcl_templates/variables）。出典：sensitiveを付けた変数の値がPackerの出力で伏せられるという記述を参照（2026年10月確認）
14. *14　参考：Amazon Web Services「Deregister an Amazon EC2 AMI」（https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html）。出典：AMIの登録を解除しても、既定では作成時のスナップショットは消えず、保存の料金がかかり続けるという記述を参照（2026年10月確認）

Tweet