Best practices for writing Dockerfiles | Docker Documentation - 0 views
-
building efficient images
-
Docker builds images automatically by reading the instructions from a Dockerfile -- a text file that contains all commands, in order, needed to build a given image.
-
A Docker image consists of read-only layers each of which represents a Dockerfile instruction.
- ...47 more annotations...
-
The layers are stacked and each one is a delta of the changes from the previous layer
-
When you run an image and generate a container, you add a new writable layer (the “container layer”) on top of the underlying layers.
-
By “ephemeral,” we mean that the container can be stopped and destroyed, then rebuilt and replaced with an absolute minimum set up and configuration.
-
Inadvertently including files that are not necessary for building an image results in a larger build context and larger image size.
-
To exclude files not relevant to the build (without restructuring your source repository) use a .dockerignore file. This file supports exclusion patterns similar to .gitignore files.
-
minimize image layers by leveraging build cache.
-
if your build contains several layers, you can order them from the less frequently changed (to ensure the build cache is reusable) to the more frequently changed
-
avoid installing extra or unnecessary packages just because they might be “nice to have.”
-
Each container should have only one concern.
-
Decoupling applications into multiple containers makes it easier to scale horizontally and reuse containers
-
Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.
-
Use your best judgment to keep containers as clean and modular as possible.
-
do multi-stage builds and only copy the artifacts you need into the final image. This allows you to include tools and debug information in your intermediate build stages without increasing the size of the final image.
-
avoid duplication of packages and make the list much easier to update.
-
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified.
-
the next instruction is compared against all child images derived from that base image to see if one of them was built using the exact same instruction. If not, the cache is invalidated.
-
simply comparing the instruction in the Dockerfile with one of the child images is sufficient.
-
For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file.
-
If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
-
cache checking does not look at the files in the container to determine a cache match.
-
In that case just the command string itself is used to find a match.
-
-
-
Whenever possible, use current official repositories as the basis for your images.
-
Using RUN apt-get update && apt-get install -y ensures your Dockerfile installs the latest package versions with no further coding or manual intervention.
-
cache busting
-
Docker executes these commands using the /bin/sh -c interpreter, which only evaluates the exit code of the last operation in the pipe to determine success.
-
set -o pipefail && to ensure that an unexpected error prevents the build from inadvertently succeeding.
-
The CMD instruction should be used to run the software contained by your image, along with any arguments.
-
CMD should almost always be used in the form of CMD [“executable”, “param1”, “param2”…]
-
CMD should rarely be used in the manner of CMD [“param”, “param”] in conjunction with ENTRYPOINT
-
The ENV instruction is also useful for providing required environment variables specific to services you wish to containerize,
-
Each ENV line creates a new intermediate layer, just like RUN commands
-
COPY is preferred
-
COPY only supports the basic copying of local files into the container
-
the best use for ADD is local tar file auto-extraction into the image, as in ADD rootfs.tar.xz /
-
If you have multiple Dockerfile steps that use different files from your context, COPY them individually, rather than all at once.
-
using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead
-
The best use for ENTRYPOINT is to set the image’s main command, allowing that image to be run as though it was that command (and then use CMD as the default flags).
-
the image name can double as a reference to the binary as shown in the command
-
The VOLUME instruction should be used to expose any database storage area, configuration storage, or files/folders created by your docker container.
-
use VOLUME for any mutable and/or user-serviceable parts of your image
-
If you absolutely need functionality similar to sudo, such as initializing the daemon as root but running it as non-root), consider using “gosu”.
-
always use absolute paths for your WORKDIR
-
An ONBUILD command executes after the current Dockerfile build completes.
-
Think of the ONBUILD command as an instruction the parent Dockerfile gives to the child Dockerfile
-
A Docker build executes ONBUILD commands before any command in a child Dockerfile.
-
Be careful when putting ADD or COPY in ONBUILD. The “onbuild” image fails catastrophically if the new build’s context is missing the resource being added.
