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>