Docker Dockerfile

Docker Dockerfile

What is a Dockerfile?

A Dockerfile is a text file used to build an image. The text contains a list of instructions and descriptions needed to build the image.

Customizing images with Dockerfile

Here we only explain how to run the Dockerfile file to customize a mirror, the detailed instructions in the Dockerfile file will be described in the next section, here you just need to know the build process.

1. Here’s how to customize a nginx image (a /usr/share/nginx/html/index.html file will be included in the built image)

In an empty directory, create a new file called Dockerfile and add the following to the file.

FROM nginx
RUN echo 'This is a local build of the nginx image' > /usr/share/nginx/html/index.html

2. What the FROM and RUN directives do

FROM: The custom image is based on the FROM image, where nginx is the base image needed for the customization. Subsequent operations are based on nginx.

RUN: Used to execute the command line commands that follow. There are two formats.

shell format:

RUN <command line>
# <command line> is equivalent to a shell command operated from a terminal.

exec format:

RUN ["executable", "parameter1", "parameter2"]
# For example:
# RUN ["./test.php", "dev", "offline"] Equivalent to RUN ./test.php dev offline

Note: Each execution of the Dockerfile command creates a new layer on top of the docker. So too many meaningless layers will cause the image to bloat too much. For example:

FROM centos
RUN yum -y install wget
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz"
RUN tar -xvf redis.tar.gz

The above execution creates a 3-layer image. This can be simplified to the following format:

FROM centos
RUN yum -y install wget \
    && wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" \
    && tar -xvf redis.tar.gz

As above, connect the commands with && symbols, so that only 1 level of mirroring will be created after execution.

Start building the image

Execute the build action in the directory where the Dockerfile file is stored.

In the following example, you build a nginx:v3 (image name:image tag) from the Dockerfile in the directory

Note: The last . represents the context path for this execution, which is described in the next section.

$ docker build -t nginx:v3 .

Docker Dockerfile

The above shows that the build was successful.

Context path

In the previous section, it was mentioned that the last . is a context path, so what is a context path?

$ docker build -t nginx:v3 .

Context path, means docker is building the image, sometimes you want to use the files to the local machine (for example, copy), docker build command learns this path, will pack all the contents under the path.

Explanation: Since docker runs in C/S mode, our local machine is C and the docker engine is S, the actual build process is done under the docker engine, so we can’t use our local files at this time. We need to package the files in the specified directory on our machine and make them available to the docker engine.

If the last parameter is not specified, then the default context path is the location of the Dockerfile.

Note: Do not put useless files in the context path, because they will be packaged together and sent to the docker engine, and too many files will slow down the process.

Command Details

COPY

Copy command to copy a file or directory from the context directory to the specified path in the container.

Format.

COPY [--chown=<user>:<group>] <Source path 1>...  <Target Path>.
COPY [--chown=<user>:<group>] ["<Source path 1>",...  "<Target Path>"]

[--chown=<user>:<group>]: optional parameter, user changes the owner and group of the files copied to the container.

`<Source path>: source file or source directory, where it can be a wildcard expression with wildcard rules that satisfy Go’s filepath.Match rule. For example

COPY hom* /mydir/
COPY hom?.txt /mydir/

`<Target Path>: the specified path in the container, the path does not need to be built beforehand, it will be created automatically if the path does not exist.

ADD

The ADD command is similar to COPY (the official recommendation is to use COPY for the same requirements). The functions are similar, but the differences are as follows.

  • Advantage of ADD: If thefile is a tar archive, it will be automatically copied and decompressed to the if the compression format is gzip, bzip2 or xz.
  • Disadvantage of ADD: It is not possible to copy a tarball without decompressing it. It will invalidate the image build cache, which may make image builds slower. Whether or not to use this depends on whether or not you want to automatically unpack.

CMD

Similar to the RUN command, it is used to run programs, but the two run at different points in time:

  • CMD is run at docker run.
  • RUN is run at docker build.

**The program specified by the CMD command can be overridden by the program specified in the docker run command line argument.

Note: If there are multiple CMD directives in the Dockerfile, only the last one takes effect.

Format.

CMD <shell Command> 
CMD ["<Executable file or command>","<param1>","<param2>",...] 
CMD ["<param1>","<param2>",...]  # This is written to provide default parameters for the program specified by the ENTRYPOINT directive

The second format is recommended and the execution process is more explicit. The first format is actually automatically converted to the second format during runtime, and the default executable is sh.

ENTRYPOINT

is similar to the CMD command, but it is not overridden by the command line arguments specified by docker run, and they are given as arguments to the program specified by the ENTRYPOINT command.

However, if you run docker run with the –entrypoint option, it will override the program specified by the ENTRYPOINT directive.

Benefit: You can specify the parameters required for ENTRYPOINT to run when running docker run.

Note: If there are multiple ENTRYPOINT directives in the Dockerfile, only the last one will take effect.

Format.

ENTRYPOINT ["<executeable>","<param1>","<param2>",...]

It can be used with CMD command: CMD is usually used only for variable reference, here CMD is like passing a reference to ENTRYPOINT, as mentioned in the following example.

Example.

Assuming that the nginx:test image has been built via Dockerfile.

FROM nginx

ENTRYPOINT ["nginx", "-c"] # constant parameter
CMD ["/etc/nginx/nginx.conf"] # variable 

1. Run without passing parameters

$ docker run nginx:test

The following command will be run by default inside the container to start the main process.

nginx -c /etc/nginx/nginx.conf

2. Pass the reference to run

$ docker run nginx:test -c /etc/nginx/new.conf

The following command will be run by default inside the container to start the main process (/etc/nginx/new.conf: assuming this file is already in the container)

nginx -c /etc/nginx/new.conf

ENV

Set the environment variable, which is defined, then it can be used in the subsequent commands.

Format:

ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...

The following example sets NODE_VERSION = 7.2.0, which can be referenced in subsequent directives by $NODE_VERSION.

ENV NODE_VERSION 7.2.0

RUN curl -SLO "https://nodejs.org/dist/vNODE_VERSION/node-vNODE_VERSION-linux-x64.tar.xz" \
  && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc"

ARG

The build parameter is the same as ENV. The environment variable set by ARG is only valid within the Dockerfile, i.e. only during docker build, it does not exist in the built image.

The build command docker build can be overridden with –build-arg =.

Format.

ARG <arg name>[=<default value>]

VOLUME

Define anonymous data volumes. Forgetting to mount the data volume when starting the container will automatically mount it to an anonymous volume.

Role.

  • Avoid important data, which is lost due to container reboot, which is very fatal.
  • Prevents the container from constantly getting larger.

Format.

VOLUME ["<path1>", "<path2>"...]
VOLUME <path>

When starting the container docker run, we can modify the mount point with the -v parameter.

EXPOSE

Just declare the port.

Role.

  • Helps image users understand the daemon port for this image service to facilitate configuration mapping.
  • When random port mapping is used at runtime, i.e. when docker run -P, the EXPOSE ports are automatically mapped randomly.

Format.

EXPOSE <port1> [<port2>...]

WORKDIR

Specifies a working directory. The working directory specified with WORKDIR will be present at each layer of the build image. (The working directory specified by WORKDIR must be created in advance).

Each RUN command in the docker build process is a new layer. Only the directories created by WORKDIR will always exist.

Format.

WORKDIR <path to working directory>

USER

Used to specify the user and user group for executing subsequent commands, this side just switches the user for subsequent command execution (the user and user group must already exist in advance).

Format.

USER <username>[:<user group>]

HEALTHCHECK

Used to specify a program or command to monitor the running status of the docker container service.

Format.

HEALTHCHECK [option] CMD <command>: Set the command to check the container health status
HEALTHCHECK NONE: If the base image has a health check command, use this line to block its health check command

HEALTHCHECK [option] CMD <command> : The command followed by CMD here is used, you can refer to the usage of CMD.

ONBUILD

Used to delay the execution of build commands. Simply put, the command specified by ONBUILD in the Dockerfile will not be executed during this build of the image (assuming the image is test-build). When a new Dockerfile uses the previously built image FROM test-build, the commands specified by ONBUILD in test-build’s Dockerfile will be executed when the Dockerfile build of the new image is executed.

Format.

ONBUILD <other command>

LABEL

The LABEL command is used to add some metadata (metadata) to a mirror, in the form of key-value pairs, with the following syntax format.

LABEL <key>=<value> <key>=<value> <key>=<value> ...

For example, we can add the author of the mirror.

LABEL org.opencontainers.image.authors="apidemos"
Like(0)