docker-build

Build a Docker image using the Dockerfile in the current directory

$ docker build .

$ docker build [github.com/creack/docker-firefox]

$ docker build [[-t|--tag]] [name:tag] .

$ docker build [[-t|--tag]] [name:tag] - < [Dockerfile]

$ docker build --no-cache [[-t|--tag]] [name:tag] .

$ docker build [[-f|--file]] [Dockerfile] .

$ docker build --build-arg [HTTP_PROXY=http://10.20.30.2:1234] --build-arg [FTP_PROXY=http://40.50.60.5:4567] .

docker build [OPTIONS] PATH | URL | -

-f, --file
    Specifies the path to the Dockerfile to use. Defaults to 'Dockerfile' in the build context.

-t, --tag
    Names and optionally tags the image in the 'name:tag' format. Multiple tags can be specified.

--build-arg
    Sets build-time variables that can be used by Dockerfile instructions (e.g., ENV, ARG).

--no-cache
    Instructs Docker not to use cache when building the image, forcing a fresh build for all layers.

--progress
    Sets the type of progress output (e.g., 'plain' for simple text, 'tty' for interactive progress bars).

--platform
    Specifies the platform of the image if the server is multi-platform capable (e.g., 'linux/amd64').

--target
    Builds only up to the specified stage defined in a multi-stage Dockerfile.

-q, --quiet
    Suppresses the build output and prints only the image ID on successful completion.

--pull
    Always attempts to pull a newer version of the image specified in the FROM instruction.

--rm
    Removes intermediate containers after a successful build. Defaults to true.

The docker build command is a core utility for creating Docker images. It processes a Dockerfile, which is a plain text file containing a series of instructions that Docker executes to construct an image. These instructions can specify the base image, run commands to install software, copy files from the build context, expose network ports, and define the default command to execute when a container is launched from the image.

During the build process, Docker sends the 'build context' (the set of files and directories located at the specified PATH or URL) to the Docker daemon. Each instruction in the Dockerfile typically creates a new read-only layer in the image. This layered architecture enables efficient caching, allowing subsequent builds to reuse unchanged layers, significantly reducing build times.

docker build is indispensable for developers to package their applications and their dependencies into self-contained, reproducible, and portable Docker images, ready for deployment as containers or distribution via container registries.

Optimizing your build context and effectively using a .dockerignore file are crucial for faster builds, especially for remote builds, as only necessary files are sent to the daemon. Understand Docker's build cache: any change to a Dockerfile instruction or a file copied into a layer invalidates all subsequent layers, forcing a rebuild from that point onward. Arrange your Dockerfile instructions to leverage caching, placing less frequently changing instructions earlier. For production, consider using multi-stage builds to create lean, secure images by discarding build-time tools and dependencies.

The build context refers to the set of files and directories at the specified PATH or URL that docker build sends to the Docker daemon. The COPY and ADD instructions in your Dockerfile can only access files that are part of this context. To prevent sending unnecessary files and speed up the build, it's highly recommended to use a .dockerignore file. This file functions similarly to .gitignore, specifying patterns of files and directories to exclude from the build context.

The Dockerfile is a script that contains all the commands a user could call on the command line to assemble an image. Each instruction in the Dockerfile (e.g., FROM, RUN, COPY, EXPOSE, CMD, ENTRYPOINT) creates a read-only layer in the image. This file is the primary input for the docker build command and dictates the entire image creation process, from the base operating system to application dependencies and runtime configurations.

Docker images are constructed as a stack of read-only layers, with each layer corresponding to a single instruction in the Dockerfile. When docker build processes a Dockerfile, it attempts to reuse existing layers from its cache. If an instruction and its corresponding inputs (e.g., the contents of files being copied) have not changed, Docker skips executing that instruction and uses the cached layer. This caching mechanism dramatically speeds up iterative builds. The cache is invalidated from the first changed instruction onwards, requiring subsequent layers to be rebuilt.

The docker build command has been a cornerstone of the Docker platform since its inception in 2013. It provided the fundamental mechanism for converting human-readable instructions in a Dockerfile into reproducible container images. Early development focused on robust basic functionality and efficient layering. A significant advancement came with the introduction of multi-stage builds in Docker 17.05, which revolutionized image optimization by enabling developers to create smaller, more secure final images by separating build-time dependencies from runtime requirements. Its stable and continuously improved feature set has cemented its role as one of the most frequently used Docker commands.

docker run(1), docker push(1), docker images(1), docker rmi(1), Dockerfile(5)