The root of this repository contains the officially supported HashiCorp Dockerfile to build the hashicorp/packer docker image. The dev
docker image should be built for local dev and testing, while the production docker image, release
, is built in CI and makes use of CI-built binaries. The light
and full
docker images are built using the official binaries from releases.hashicorp.com.
Refer to the Makefile of this repository, especially the docker
and docker-dev
targets to build a local version of the dev image based on the sources available.
This repository automatically builds containers for using the packer
command line program. It contains three distinct varieties of build: a light
version, which just contains the binary, a full
build, which contains the Packer binary with pre-installed plugins, and a dev
version, which compiles the binary from source inside the container before exposing it for use.
light
The light
version of this container will copy the current stable version of the binary, taken from releases.hashicorp.com, into the container. It will also set it for use as the default entrypoint. This will be the best option for most uses, especially if you are just looking to run the binary from a container. The latest
tag on DockerHub also points to this version.
You can use this version with the following:
docker run <args> hashicorp/packer:light <command>
full
The full
version of the container builds upon light
and pre-installs the plugins officially maintained by HashiCorp.
You can use this version with the following:
docker run <args> hashicorp/packer:full <command>
You can view the list of pre-installed plugins with the following:
docker run <args> hashicorp/packer:full plugins installed
dev
The dev
version of this container contains all of the source code found in the current ref of this repository. Using Google's official golang
image as a base, this container will copy the source from the current branch, build the binary, and expose it for running. Because all build artifacts are included, it should be quite a bit larger than the light
image. This version of the container is most useful for development or debugging.
You can use this version with the following:
docker run <args> hashicorp/packer:dev <command>
The easiest way to run a command that references a configuration with one or more template files, is to mount a volume for the local workspace.
Running packer init
docker run \ -v `pwd`:/workspace -w /workspace \ -e PACKER_PLUGIN_PATH=/workspace/.packer.d/plugins \ hashicorp/packer:latest \ init .
~> Note: packer init is available from Packer v1.7.0 and later
The command will mount the working directory (pwd
) to workspace
, which is the working directory (-w
) inside the container. Any plugin installed with packer init
will be installed under the directory specified under the PACKER_PLUGIN_PATH
environment variable. PACKER_PLUGIN_PATH
must be set to a path inside the volume mount so that plugins can become available at packer build
.
Running packer build
docker run \ -v `pwd`:/workspace -w /workspace \ -e PACKER_PLUGIN_PATH=/workspace/.packer.d/plugins \ hashicorp/packer:latest \ build .
For old-legacy JSON, the build command must specify the template file(s).
docker run \ -v `pwd`:/workspace -w /workspace \ hashicorp/packer:latest \ build template.json
For the manual installation of third-party plugins, we recommended that plugin binaries are placed under a sub-directory under the working directory. Add -e PACKER_PLUGIN_PATH=/workspace/<subdirectory_plugin_path>
to the command above to tell Packer where the plugins are.
To pass a var file (var.json
) to the build command:
docker run \ -v `pwd`:/workspace -w /workspace \ hashicorp/packer:latest \ build --var-file var.json template.json
var.json
is expected to be inside the local working directory (pwd
) and in the container's workspace mount.