docker-latest-build (1) - Linux Manuals
docker-latest-build: Build a new image from the source code at PATH
NAME
docker-build - Build a new image from the source code at PATH
SYNOPSIS
docker build [--build-arg[=[]]] [--cpu-shares[=0]] [--cgroup-parent[=CGROUP-PARENT]] [--help] [-f|--file[=PATH/Dockerfile]] [--force-rm] [--isolation[=default]] [--label[=[]]] [--no-cache] [--pull] [-q|--quiet] [--rm[=true]] [-t|--tag[=[]]] [-m|--memory[=MEMORY]] [--memory-swap[=LIMIT]] [--shm-size[=SHM-SIZE]] [--cpu-period[=0]] [--cpu-quota[=0]] [--cpuset-cpus[=CPUSET-CPUS]] [--cpuset-mems[=CPUSET-MEMS]] [--ulimit[=[]]] [-v|--volume[=[]]] PATH | URL | -
DESCRIPTION
This will read the Dockerfile from the directory specified in PATH. It also sends any other files and directories found in the current directory to the Docker daemon. The contents of this directory would be used by ADD commands found within the Dockerfile.
Warning, this will send a lot of data to the Docker daemon depending on the contents of the current directory. The build is run by the Docker daemon, not by the CLI, so the whole context must be transferred to the daemon. The Docker CLI reports "Sending build context to Docker daemon" when the context is sent to the daemon.
When the URL to a tarball archive or to a single Dockerfile is given, no context is sent from the client to the Docker daemon. In this case, the Dockerfile at the root of the archive and the rest of the archive will get used as the context of the build. When a Git repository is set as the URL, the repository is cloned locally and then sent as the context.
OPTIONS
-f, --file=PATH/Dockerfile
--build-arg=variable
For example, if you want to pass a value for http_proxy, use
Users pass these values at build-time. Docker uses the buildargs as the
--force-rm=true|false
--isolation="default"
--label=label
--no-cache=true|false
--help
--pull=true|false
-q, --quiet=true|false
--rm=true|false
-t, --tag=""
-m, --memory=MEMORY
--memory-swap=LIMIT
The format of LIMIT is <number>[<unit>]. Unit can be b (bytes),
k (kilobytes), m (megabytes), or g (gigabytes). If you don't specify a
unit, b is used. Set LIMIT to -1 to enable unlimited swap.
--shm-size=SHM-SIZE
--cpu-shares=0
By default, all containers get the same proportion of CPU cycles.
You can change this proportion by adjusting the container's CPU share
To modify the proportion from the default of 1024, use the --cpu-shares
The proportion is only applied when CPU-intensive processes are running.
For example, consider three containers, where one has --cpu-shares=1024 and
On a multi-core system, the shares of CPU time are distributed across the CPU
For example, consider a system with more than three cores. If you start one
--cpu-period=0
Limit the container's CPU usage. This flag causes the kernel to restrict the
--cpu-quota=0
By default, containers run with the full CPU resource. This flag causes the
kernel to restrict the container's CPU usage to the quota you specify.
--cpuset-cpus=CPUSET-CPUS
--cpuset-mems=CPUSET-MEMS
For example, if you have four memory nodes on your system (0-3), use --cpuset-mems=0,1
to ensure the processes in your Docker container only use memory from the first
two memory nodes.
--cgroup-parent=CGROUP-PARENT
If the path is not absolute, the path is considered relative to the cgroups path of the init process.
Cgroups are created if they do not already exist.
--ulimit=[]
+-v, --volume=[] Create a bind mount
+ (format: host-dir:container-dir[:<suffix options>], where suffix options
+are comma delimited and selected from [ro] and [z|Z].). Read-write mode isn't supported at build time.
+In case rw is specified a warning is printed during the build and it will be changed to ro preserving any SELinux mode provided.
+
For more information about ulimit see
<https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container>
Docker images can be built using the build command and a Dockerfile:
During the build process Docker creates intermediate images. In order to
keep them, you must explicitly set --rm=false.
A good practice is to make a sub-directory with a related name and create
the Dockerfile in that directory. For example, a directory called mongo may
contain a Dockerfile to create a Docker MongoDB image. Likewise, another
directory called httpd may be used to store Dockerfiles for Apache web
server images.
It is also a good practice to add the files required for the image to the
sub-directory. These files will then be specified with the COPY or ADD
instructions in the Dockerfile.
Note: If you include a tar file (a good practice), then Docker will
automatically extract the contents of the tar file specified within the ADD
instruction into the specified target.
A good practice is to give a name to the image you are building. Note that
only a-z0-9-_. should be used for consistency. There are no hard rules here but it is best to give the names consideration.
The -t/--tag flag is used to rename an image. Here are some examples:
Though it is not a good practice, image names can be arbitrary:
A better approach is to provide a fully qualified and meaningful repository,
name, and tag (where the tag in this context means the qualifier after
the ":"). In this example we build a JBoss image for the Fedora repository
and give it the version 1.0:
The next example is for the "whenry" user repository and uses Fedora and
JBoss and gives it the version 2.1 :
If you do not provide a version tag then Docker will assign latest:
When you list the images, the image above will have the tag latest.
You can apply multiple tags to an image. For example, you can apply the latest
tag to a newly built image and add another tag that references a specific
version.
For example, to tag an image both as whenry/fedora-jboss:latest and
whenry/fedora-jboss:v2.1, use the following:
So renaming an image is arbitrary but consideration should be given to
a useful convention that makes sense for consumers and should also take
into account Docker community conventions.
This will clone the specified GitHub repository from the URL and use it
as context. The Dockerfile at the root of the repository is used as
Dockerfile. This only works if the GitHub repository is a dedicated
repository.
Note: You can set an arbitrary Git repository via the git:// scheme.
This will send the URL itself to the Docker daemon. The daemon will fetch the
tarball archive, decompress it and use its contents as the build context. The
Dockerfile at the root of the archive and the rest of the archive will get used
as the context of the build. If you pass an -f PATH/Dockerfile option as well,
the system will look for that file inside the contents of the tarball.
Note: supported compression formats are 'xz', 'bzip2', 'gzip' and 'identity' (no compression).
This option is useful in situations where you are running Docker containers on
Windows. The --isolation=<value> option sets a container's isolation
technology. On Linux, the only supported is the default option which uses
Linux namespaces. On Microsoft Windows, you can specify these values:
item default: Use the value specified by the Docker daemon's --exec-opt . If the daemon does not specify an isolation technology, Microsoft Windows uses process as its default value.
item process: Namespace isolation only.
item hyperv: Hyper-V hypervisor partition-based isolation.
Specifying the --isolation flag without a value is the same as setting --isolation="default".
March 2014, Originally compiled by William Henry (whenry at redhat dot com)
based on docker.com source material and internal work.
June 2014, updated by Sven Dowideit
<SvenDowideit [at] home.org.au>
June 2015, updated by Sally O'Malley
<somalley [at] redhat.com>
Path to the Dockerfile to use. If the path is a relative path and you are
building from a local directory, then the path must be relative to that
directory. If you are building from a remote URL pointing to either a
tarball or a Git repository, then the path must be relative to the root of
the remote context. In all cases, the file must be within the build context.
The default is
name and value of a
--build-arg=http_proxy="http://some.proxy.url"
environment context for command(s)
or for variable expansion in other Dockerfile instructions. This is not meant
for passing secret values.
Always remove intermediate containers, even after unsuccessful builds. The default is
Isolation specifies the type of isolation technology used by containers.
Set metadata for an image
Do not use cache when building the image. The default is
Always attempt to pull a newer version of the image. The default is
Suppress the build output and print image ID on success. The default is
Remove intermediate containers after a successful build. The default is
Repository names
image in case of success. Refer to
about valid tag names.
A limit value equal to memory plus swap. Must be used with the
cat /sys/fs/cgroup/cpu/cpu.shares
1024
Container CPU share Flag
{C0} 60% of CPU --cpu-shares=614 (614 is 60% of 1024)
{C1} 40% of CPU --cpu-shares=410 (410 is 40% of 1024)
Container CPU share Flag CPU time
{C0} 100% --cpu-shares=1024 33%
{C1} 50% --cpu-shares=512 16.5%
{C2} 50% --cpu-shares=512 16.5%
{C4} 100% --cpu-shares=1024 33%
PID container CPU CPU share
100 {C0} 0 100% of CPU0
101 {C1} 1 100% of CPU1
102 {C1} 2 100% of CPU2
EXAMPLES
Building an image using a Dockerfile located inside the current directory
docker build .
docker build --rm=false .
Building an image and naming that image
docker build -t myimage .
docker build -t fedora/jboss:1.0 .
docker build -t whenry/fedora-jboss:v2.1 .
docker build -t whenry/fedora-jboss .
docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .
Building an image using a URL
docker build github.com/scollier/purpletest
Building an image using a URL to a tarball'ed context
docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz
Specify isolation technology for container (--isolation)
HISTORY