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