The docker Packer builder builds Docker images using
Docker. The builder starts a Docker container, runs provisioners within this
container, then exports the container for reuse or commits the image.

Packer builds Docker containers without the use of
Dockerfiles. By not using
Dockerfiles, Packer is able to provision containers with portable scripts or
configuration management systems that are not tied to Docker in any way. It also
has a simple mental model: you provision containers much the same way you
provision a normal virtualized or dedicated server. For more information, read
the section on Dockerfiles.

The Docker builder must run on a machine that has Docker Engine installed.
Therefore the builder only works on machines that support Docker and does not
support running on a Docker remote host. You can learn about what
platforms Docker supports and how to install onto them
in the Docker documentation.

Below is an example using the changes argument of the builder. This feature
allows the source images metadata to be changed when committed back into the
Docker environment. It is derived from the docker commit --change command
line option to
Docker.

Example uses of all of the options, assuming one is building an NGINX image
from ubuntu as an simple example:

aws_token (string) - The AWS access token to use. This is different from the
access key and secret key. If you're not sure what this is, then you
probably don't need it. This will also be read from the AWS_SESSION_TOKEN
environmental variable.

ecr_login (boolean) - Defaults to false. If true, the builder will login in
order to pull the image from
Amazon EC2 Container Registry (ECR).
The builder only logs in for the duration of the pull. If true
login_server is required and login, login_username, and
login_password will be ignored. For more information see the
section on ECR.

exec_user (string) - Username or UID (format: [:])
to run remote commands with. You may need this if you get permission errors
trying to run the shell or other provisioners.

login (boolean) - Defaults to false. If true, the builder will login in
order to pull the image. The builder only logs in for the duration of
the pull. It always logs out afterwards. For log into ECR see ecr_login.

login_username (string) - The username to use to authenticate to login.

login_password (string) - The password to use to authenticate to login.

privileged (boolean) - If true, run the docker container with the
--privileged flag. This defaults to false if not set.

pull (boolean) - If true, the configured image will be pulled using
docker pull prior to use. Otherwise, it is assumed the image already
exists and can be used. This defaults to true if not set.

run_command (array of strings) - An array of arguments to pass to
docker run in order to run the container. By default this is set to
["-d", "-i", "-t", "{{.Image}}", "/bin/bash"]. As you can see, you have a
couple template variables to customize, as well.

volumes (map of strings to strings) - A mapping of additional volumes to
mount into this container. The key of the object is the host path, the value
is the container path.

container_dir (string) - The directory inside container to mount
temp directory from host server for work file provisioner.
By default this is set to /packer-files.

fix_upload_owner (boolean) - If true, files uploaded to the container will
be owned by the user the container is running as. If false, the owner will depend
on the version of docker installed in the system. Defaults to true.

Once the tar artifact has been generated, you will likely want to import, tag,
and push it to a container repository. Packer can do this for you automatically
with the docker-import and
docker-push post-processors.

Note: This section is covering how to use an artifact that has been
exported. More specifically, if you set export_path in your configuration.
If you set commit, see the next section.

The example below shows a full configuration that would import and push the
created image. This is accomplished using a sequence definition (a collection of
post-processors that are treated as as single pipeline, see
Post-Processors for more information):

In the above example, the result of each builder is passed through the defined
sequence of post-processors starting first with the docker-import
post-processor which will import the artifact as a docker image. The resulting
docker image is then passed on to the docker-push post-processor which handles
pushing the image to a container repository.

If you want to do this manually, however, perhaps from a script, you can import
the image using the process below:

If you committed your container to an image, you probably want to tag, save,
push, etc. Packer can do this automatically for you. An example is shown below
which tags and pushes an image. This is accomplished using a sequence definition
(a collection of post-processors that are treated as as single pipeline, see
Post-Processors for more information):

In the above example, the result of each builder is passed through the defined
sequence of post-processors starting first with the docker-tag post-processor
which tags the committed image with the supplied repository and tag information.
Once tagged, the resulting artifact is then passed on to the docker-push
post-processor which handles pushing the image to a container repository.

Going a step further, if you wanted to tag and push an image to multiple
container repositories, this could be accomplished by defining two,
nearly-identical sequence definitions, as demonstrated by the example below:

With this builder, you can repeatedly create Docker images without the use of a
Dockerfile. You don't need to know the syntax or semantics of Dockerfiles.
Instead, you can just provide shell scripts, Chef recipes, Puppet manifests,
etc. to provision your Docker container just like you would a regular
virtualized or dedicated machine.

While Docker has many features, Packer views Docker simply as an container
runner. To that end, Packer is able to repeatedly build these containers
using portable provisioning scripts.

By default, Packer creates a temporary folder under your home directory, and
uses that to stage files for uploading into the container. If you would like to
change the path to this temporary folder, you can set the PACKER_TMP_DIR
environment variable. This can be useful, for example, if you have your home
directory permissions set up to disallow access from the docker daemon.