Docker Dockerfile

What is Dockerfile?

Dockerfile is a text file used to build images, which contains instructions and descriptions required to build images.

Using Dockerfile to customize an image

Customizing an image with Dockerfile

1, and here we only explain how to run the Dockerfile file to customize an image, the detailed instructions of the Dockerfile file will be introduced in the next section, here you just need to know the construction process. /usr/share/nginx/html/index.html file)

In an empty directory, create a Dockerfile file and add the following content to it:

FROM nginx
RUN echo 'This is a locally built nginx image' >　/usr/share/nginx/html/index.html

2The role of FROM and RUN instructions

FROM:Custom images are based on the FROM image, here nginx is the base image required for customization. All subsequent operations are based on nginx.

RUN:Used to execute the command line command following it. There are two formats:

shell format:

RUN <command line command>
# <command line command> is equivalent to, the shell command operated in the terminal.

exec format:

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

Note:Each instruction executed in Dockerfile adds a new layer to docker. Therefore, too many unnecessary layers can cause the image to become too large. For example:

RUN yum install wget
RUN wget　-O redis.tar.gz \//download.redis.io/releases/redis-5.0.3.tar.gz"
RUN tar　-xvf redis.tar.gz
The above execution will create　3　layer image. It can be simplified to the following format:

RUN yum install wget \",
　　　　　-O redis.tar.gz \//download.redis.io/releases/redis-5.0.3.tar.gz\
　　　　&& tar　-xvf redis.tar.gz

As shown above, connect commands with the && symbol, so that after execution, only 1 layer image.

Start building the image

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

The following example, builds an nginx:v3(Image name: image tag).

Note: The last 　. 　represents the context path of this execution, which will be introduced in the next section.

$ docker build　-t nginx:v3　ENV　NODE_VERSION

As shown above, it indicates that the build has been successful.

Context path

In the previous section, it was mentioned that the last 　. 　of the instruction is the context path, then what is the context path?

$ docker build　-t nginx:v3　ENV　NODE_VERSION

: The context path refers to the path docker uses to build images. Sometimes, we want to use files on our local machine (such as copying), and the docker build command will package all contents under this path after knowing the path.

Parsing: Due to docker's running mode is C/S. Our local machine is C, the docker engine is S. The actual build process is completed under the docker engine, so we cannot use our local machine's files at this time. This requires us to package the files in the specified directory on our local machine and provide them to the docker engine for use.

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

Note: Do not place unnecessary files under the context path, as they will be packaged and sent to the docker engine together, which may cause the process to slow down if there are too many files.

Detailed instructions

COPY

Copy instruction, copies files or directories from the context directory to the specified path within the container.

Format:

COPY [--chown=<user>:<group>]  <source path1>...  <target path>
COPY [--chown=<user>:<group>]  ["<source path1>",...  "<target path>"]

[--chown=<user>:<group>]: Optional parameter, allows the user to change the owner and group of the file copied into the container.

<source path>: Source file or source directory, which can be a wildcard expression here, and the wildcard rules must meet the Go's filepath.Match rules. For example:

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

<target path>: The specified path within the container, this path does not need to be created in advance, and if the path does not exist, it will be automatically created.

ADD

The usage format of ADD command is consistent with that of COPY (the official recommendation is to use COPY under the same requirements). The functions are also similar, the differences are as follows:

• ADD's advantages: When executing <source file> as a tar compressed file, the compression format is gzip, bzip2 And in the case of xz, it will automatically copy and decompress to <target path>.

• ADD's disadvantages: Cannot copy tar compressed files without decompression. It may cause the image build cache to become invalid, which may make the image build process slower. Whether to use it can be decided according to whether automatic decompression is needed.

CMD

Similar to the RUN instruction, used to run programs, but the two run at different times:

• CMD runs at docker run.

• RUN is during docker build.

Function: Specifies the default program to be run by the starting container. When the program specified by the CMD instruction ends, the container also ends. The program specified by the CMD instruction can be overridden by the program specified by the docker run command line parameters.

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

Format:

CMD <shell command>　
CMD ["<executable or command>","<param1">","<param2">,...]　
CMD ["<param1">","<param2">,...]  # This syntax provides default parameters for the program specified by the ENTRYPOINT instruction

It is recommended to use the second format, as the execution process is clearer. The first format will actually be automatically converted to the second format during execution, and the default executable file is sh.

ENTRYPOINT

Similar to CMD instruction, but it will not be overridden by the command line parameters specified by docker run, and these command line parameters will be passed as parameters to the program specified by the ENTRYPOINT instruction.

However, if you use --The entrypoint option overrides the program specified by the CMD instruction.

Advantages: When running docker run, you can specify the parameters required for ENTRYPOINT.

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

Format:

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

Can be used with the CMD command: CMD is generally used for variable parameters, here CMD is actually passing parameters to ENTRYPOINT, the following examples will be mentioned.

Example:

Assuming that the nginx:test image has been built through Dockerfile:

FROM nginx
ENTRYPOINT ["nginx", "-c"]  # fixed parameters
CMD ["/etc/nginx/nginx.conf"]  # variable parameters

1to run without parameters

$ docker run nginx:test

The container will run the following commands by default to start the main process.

nginx　-c　/etc/nginx/nginx.conf

2to pass parameters

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

The container will run the following commands by default to start the main process (/etc/nginx/new.conf: assuming the file exists within the container)

nginx　-c　/etc/nginx/new.conf

ENV

ENV

Format:

Set environment variables, after defining the environment variable, it can be used in subsequent instructions.
ENV　<key>　<value>1>　<key1ENV　<key2>　<key2>=<value

>... 7ENV　NODE_VERSION2The following example sets NODE_VERSION =

.0, which can be referenced in subsequent instructions as $NODE_VERSION:　7ENV　NODE_VERSION2.
.0　-&&　curl//SLO　"https:/nodejs.org/dist/RUN　curl-dist-node-linux64x
　　.tar.xz"　\　-&&　curl//SLO　"https:/nodejs.org/dist/v$NODE_VERSION256SHASUMS

.txt.asc"

ARG

build parameters, which have the same effect as ENV. However, the scope is different. The environment variables set by ARG are only valid within the Dockerfile, that is, only valid during the docker build process, and the built image does not contain this environment variable. --The build command docker build can use-build

Format:

arg <parameter name>=<value> to override.

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

VOLUME

It is just to declare the port.

• Define an anonymous data volume. If the data volume is not mounted when starting the container, it will be automatically mounted to an anonymous volume.

• Avoid important data from being lost due to container restarts, which is very fatal.

Format:

Avoid the container from growing continuously.1VOLUME　["<path2>",　"<path
>"...]

VOLUME　<path> -When starting the container docker run, we can use

v parameter modifies the mount point.

EXPOSE

It is just to declare the port.

• Function:

• Helps the user of the image understand the守护端口 of this image service, making it convenient to configure mapping. -When using random port mapping at runtime, that is, docker run

Format:

When P is used, the port exposed will be automatically mapped to a random port.1EXPOSE　<port2>　[<port

>...]

WORKDIR

Specify the working directory. The working directory specified by WORKDIR will exist in every layer of the image being built. (The working directory specified by WORKDIR must be created in advance).

Format:

In the process of building an image with docker build, each RUN command is a new layer. Only the directories created by WORKDIR will exist permanently.

USER

Used to specify the user and user group for executing subsequent commands; here it is just to switch the user for executing subsequent commands (the user and user group must already exist).

Format:

USER　<用户名>[:<用户组>]

USER　<Username>[:<User Group>]

HEALTHCHECK

Format:

Used to specify a program or command to monitor the running status of docker container services.
HEALTHCHECK　[Options]　CMD　<Command>：Sets the command to check the health status of the container
HEALTHCHECK　NONE：If the base image has a health check instruction, this line can disable the health check instruction

HEALTHCHECK　[Options]　CMD　<Command>　:　The command following CMD can be used, and you can refer to the usage of CMD.

ONBUILD-used for delaying the execution of build commands. Simply put, the commands specified by ONBUILD in the Dockerfile will not be executed in this image build process (assuming the image is test-build），when a new Dockerfile uses the image FROM test previously built-The commands specified by ONBUILD in the Dockerfile for build. This is executed when the Dockerfile builds a new image, and it will execute test.

Format:

ONBUILD　<Other Commands>