Dockerfile
External
Internal
Overview
A Dockerfile is a plain text file that defines how a container should look at build time. It contains all the steps that are required to create the image.
Each line in the Dockerfile generates a new layer in the image. Multiple commands can be combined on a single line, to reduce the number of layers.
The Dockerfile is used as the argument of the docker build command.
Examples
- Dockerfile Example
- A Dockerfile that builds a Centos-based image: https://github.com/NovaOrdis/playground/blob/master/docker/simplest-dockerfile/Dockerfile
Syntax
<instruction> <arguments>
Example
Instructions
Instructions are also known as "directives", and they are part of a DSL.
FROM
A valid Dockerfile must start with a FROM instruction (ARG is the only instruction that can precede FROM). FROM specifies the base image upon which other layers are built.
FROM node:0.10
If the only Dockerfile instruction is FROM, the build command simply downloads the base image into the local registry, listing the image's repository and tag.
FROM can appear multiple times in a Dockerfile.
ARG
COPY
COPY <src> [src2 ...] <dest>
The COPY instruction copies new files or directories from <src> and adds them to the filesystem of the container at the path <dest>. The source paths are relative to the build context.
ADD
Copies files from the local filesystem into the image.
ADD /something/something_else.conf $MY_PATH
CMD
Defines the command that launches the process to be executed in the container.
CMD /opt/loop
CMD [ "somehting", "-arg" ]
See:
ENTRYPOINT
USER
The user to run a container's processes as.
Also see Docker Security
ENV
Declares environment variable accessible to the processes in the container:
ENV SOMETHING "something else"
RUN
The RUN instruction will execute any command in a new layer on top of the current image, and commit results. The resulted committed image will be used for the next step in the Dockerfile. Layering RUN instructions and generating commits conforms to the core concepts of Docker where commits are cheap and containers can be created from any point in an image’s history, much like source control. However, in practice, it is a good idea to reduce the number of RUN commands - and layers they generate.
It has two forms:
- Shell form:
RUN <command>
- Exec form:
RUN ["executable", "param1", "param2", ...]
Running commands like yum in the Dockerfile is discouraged because it increases the time it takes for the build to finish. The alternative is to use base images that already have these updates applied.
WORKDIR
Changes the working directory within the context of the image being built, for the rest of the build instructions. If the WORKDIR doesn’t exist, it will be created. If a relative path is provided, it will be relative to the path of the previous WORKDIR instruction.
The WORKDIR instruction can resolve environment variables previously set using ENV.
... ENV SOMEDIR /some/dir WORKDIR $SOMEDIR
MAINTAINER
LABEL
Applies a label to the image.
LABEL "something"="something else" "other label"="some other content"
VOLUME
The VOLUME instruction creates a mount point inside the container and marks it as holding an externally mounted volume from the native host. The docker run command initializes the newly created volume with any data that exists at the specified location in the base image. At runtime, the storage driver will be bypassed when written data into the volume, so the I/O will be performed at native speeds.
VOLUME /data
VOLUME [ "/data" ]
The native host directory cannot be declared in Dockerfile: it is by its nature host-dependent and it presence cannot be guaranteed, so to preserve portability, the native host mount point must be specified when creating the container with docker run --mount. The actual location of the volume on the native host is a directory whose path is returned by the corresponding "Source" entry in output of:
docker inspect -f '{{json .Mounts}}' <container-id>
For more details about data volumes see:
EXPOSE
The 'EXPOSE' instruction serves as a hint (documentation) of the fact that the container listens on the specified ports at runtime, and those ports may be published. The instruction does not actually publish the port. Publishing is done with -p flag or -P flags in the docker run command.