github.com/tonnydourado/packer@v0.6.1-0.20140701134019-5d0cd9676a37/website/source/docs/builders/docker.html.markdown (about) 1 --- 2 layout: "docs" 3 --- 4 5 # Docker Builder 6 7 Type: `docker` 8 9 The Docker builder builds [Docker](http://www.docker.io) images using 10 Docker. The builder starts a Docker container, runs provisioners within 11 this container, then exports the container for re-use. 12 13 Packer builds Docker containers _without_ the use of 14 [Dockerfiles](http://docs.docker.io/en/latest/use/builder/). 15 By not using Dockerfiles, Packer is able to provision 16 containers with portable scripts or configuration management systems 17 that are not tied to Docker in any way. It also has a simpler mental model: 18 you provision containers much the same way you provision a normal virtualized 19 or dedicated server. For more information, read the section on 20 [Dockerfiles](#toc_4). 21 22 The Docker builder must run on a machine that has Docker installed. Therefore 23 the builder only works on machines that support Docker (modern Linux machines). 24 If you want to use Packer to build Docker containers on another platform, 25 use [Vagrant](http://www.vagrantup.com) to start a Linux environment, then 26 run Packer within that environment. 27 28 ## Basic Example 29 30 Below is a fully functioning example. It doesn't do anything useful, since 31 no provisioners are defined, but it will effectively repackage an image. 32 33 <pre class="prettyprint"> 34 { 35 "type": "docker", 36 "image": "ubuntu", 37 "export_path": "image.tar" 38 } 39 </pre> 40 41 ## Configuration Reference 42 43 Configuration options are organized below into two categories: required and 44 optional. Within each category, the available options are alphabetized and 45 described. 46 47 ### Required: 48 49 * `export_path` (string) - The path where the final container will be exported 50 as a tar file. 51 52 * `image` (string) - The base image for the Docker container that will 53 be started. This image will be pulled from the Docker registry if it 54 doesn't already exist. 55 56 ### Optional: 57 58 * `pull` (boolean) - If true, the configured image will be pulled using 59 `docker pull` prior to use. Otherwise, it is assumed the image already 60 exists and can be used. This defaults to true if not set. 61 62 * `run_command` (array of strings) - An array of arguments to pass to 63 `docker` in order to run the container. By default this is set to 64 `["run", "-d", "-i", "-t", "-v", "{{.Volumes}}", "{{.Image}}", "/bin/bash"]`. 65 As you can see, you have a couple template variables to customize, as well. 66 67 ## Using the Artifact 68 69 Once the tar artifact has been generated, you will likely want to import, tag, 70 and push it to a container repository. Packer can do this for you automatically 71 with the [docker-import](/docs/post-processors/docker-import.html) and 72 [docker-push](/docs/post-processors/docker-push.html) post-processors. 73 74 The example below shows a full configuration that would import and push 75 the created image: 76 77 <pre class="prettyprint"> 78 { 79 "post-processors": [ 80 [ 81 { 82 "type": "docker-import", 83 "repository": "mitchellh/packer", 84 "tag": "0.7" 85 }, 86 "docker-push" 87 ] 88 ] 89 } 90 </pre> 91 92 If you want to do this manually, however, perhaps from a script, you can 93 import the image using the process below: 94 95 docker import - registry.mydomain.com/mycontainer:latest < artifact.tar 96 97 You can then add additional tags and push the image as usual with `docker tag` 98 and `docker push`, respectively. 99 100 ## Dockerfiles 101 102 This builder allows you to build Docker images _without_ Dockerfiles. 103 104 With this builder, you can repeatably create Docker images without the use 105 a Dockerfile. You don't need to know the syntax or semantics of Dockerfiles. 106 Instead, you can just provide shell scripts, Chef recipes, Puppet manifests, 107 etc. to provision your Docker container just like you would a regular 108 virtualized or dedicated machine. 109 110 While Docker has many features, Packer views Docker simply as an LXC 111 container runner. To that end, Packer is able to repeatably build these 112 LXC containers using portable provisioning scripts. 113 114 Dockerfiles have some additional features that Packer doesn't support 115 which are able to be worked around. Many of these features will be automated 116 by Packer in the future: 117 118 * Dockerfiles will snapshot the container at each step, allowing you to 119 go back to any step in the history of building. Packer doesn't do this yet, 120 but inter-step snapshotting is on the way. 121 122 * Dockerfiles can contain information such as exposed ports, shared 123 volumes, and other metadata. Packer builds a raw Docker container image 124 that has none of this metadata. You can pass in much of this metadata 125 at runtime with `docker run`.