github.com/lmars/docker@v1.6.0-rc2/docs/man/docker-build.1.md (about) 1 % DOCKER(1) Docker User Manuals 2 % Docker Community 3 % JUNE 2014 4 # NAME 5 docker-build - Build a new image from the source code at PATH 6 7 # SYNOPSIS 8 **docker build** 9 [**--help**] 10 [**-f**|**--file**[=*PATH/Dockerfile*]] 11 [**--force-rm**[=*false*]] 12 [**--no-cache**[=*false*]] 13 [**--pull**[=*false*]] 14 [**-q**|**--quiet**[=*false*]] 15 [**--rm**[=*true*]] 16 [**-t**|**--tag**[=*TAG*]] 17 [**-m**|**--memory**[=*MEMORY*]] 18 [**--memory-swap**[=*MEMORY-SWAP*]] 19 [**-c**|**--cpu-shares**[=*0*]] 20 [**--cpuset-cpus**[=*CPUSET-CPUS*]] 21 22 PATH | URL | - 23 24 # DESCRIPTION 25 This will read the Dockerfile from the directory specified in **PATH**. 26 It also sends any other files and directories found in the current 27 directory to the Docker daemon. The contents of this directory would 28 be used by **ADD** commands found within the Dockerfile. 29 30 Warning, this will send a lot of data to the Docker daemon depending 31 on the contents of the current directory. The build is run by the Docker 32 daemon, not by the CLI, so the whole context must be transferred to the daemon. 33 The Docker CLI reports "Sending build context to Docker daemon" when the context is sent to 34 the daemon. 35 36 When a single Dockerfile is given as the URL, then no context is set. 37 When a Git repository is set as the **URL**, the repository is used 38 as context. 39 40 # OPTIONS 41 **-f**, **--file**=*PATH/Dockerfile* 42 Path to the Dockerfile to use. If the path is a relative path then it must be relative to the current directory. The file must be within the build context. The default is *Dockerfile*. 43 44 **--force-rm**=*true*|*false* 45 Always remove intermediate containers, even after unsuccessful builds. The default is *false*. 46 47 **--no-cache**=*true*|*false* 48 Do not use cache when building the image. The default is *false*. 49 50 **--help** 51 Print usage statement 52 53 **--pull**=*true*|*false* 54 Always attempt to pull a newer version of the image. The default is *false*. 55 56 **-q**, **--quiet**=*true*|*false* 57 Suppress the verbose output generated by the containers. The default is *false*. 58 59 **--rm**=*true*|*false* 60 Remove intermediate containers after a successful build. The default is *true*. 61 62 **-t**, **--tag**="" 63 Repository name (and optionally a tag) to be applied to the resulting image in case of success 64 65 # EXAMPLES 66 67 ## Building an image using a Dockerfile located inside the current directory 68 69 Docker images can be built using the build command and a Dockerfile: 70 71 docker build . 72 73 During the build process Docker creates intermediate images. In order to 74 keep them, you must explicitly set `--rm=false`. 75 76 docker build --rm=false . 77 78 A good practice is to make a sub-directory with a related name and create 79 the Dockerfile in that directory. For example, a directory called mongo may 80 contain a Dockerfile to create a Docker MongoDB image. Likewise, another 81 directory called httpd may be used to store Dockerfiles for Apache web 82 server images. 83 84 It is also a good practice to add the files required for the image to the 85 sub-directory. These files will then be specified with the `COPY` or `ADD` 86 instructions in the `Dockerfile`. 87 88 Note: If you include a tar file (a good practice), then Docker will 89 automatically extract the contents of the tar file specified within the `ADD` 90 instruction into the specified target. 91 92 ## Building an image and naming that image 93 94 A good practice is to give a name to the image you are building. There are 95 no hard rules here but it is best to give the names consideration. 96 97 The **-t**/**--tag** flag is used to rename an image. Here are some examples: 98 99 Though it is not a good practice, image names can be arbitrary: 100 101 docker build -t myimage . 102 103 A better approach is to provide a fully qualified and meaningful repository, 104 name, and tag (where the tag in this context means the qualifier after 105 the ":"). In this example we build a JBoss image for the Fedora repository 106 and give it the version 1.0: 107 108 docker build -t fedora/jboss:1.0 109 110 The next example is for the "whenry" user repository and uses Fedora and 111 JBoss and gives it the version 2.1 : 112 113 docker build -t whenry/fedora-jboss:V2.1 114 115 If you do not provide a version tag then Docker will assign `latest`: 116 117 docker build -t whenry/fedora-jboss 118 119 When you list the images, the image above will have the tag `latest`. 120 121 So renaming an image is arbitrary but consideration should be given to 122 a useful convention that makes sense for consumers and should also take 123 into account Docker community conventions. 124 125 126 ## Building an image using a URL 127 128 This will clone the specified Github repository from the URL and use it 129 as context. The Dockerfile at the root of the repository is used as 130 Dockerfile. This only works if the Github repository is a dedicated 131 repository. 132 133 docker build github.com/scollier/Fedora-Dockerfiles/tree/master/apache 134 135 Note: You can set an arbitrary Git repository via the `git://` schema. 136 137 # HISTORY 138 March 2014, Originally compiled by William Henry (whenry at redhat dot com) 139 based on docker.com source material and internal work. 140 June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>