Summary of common commands in Dockerfile

Syntax composition:

1 Annotation information
2 Commands --- Parameters [usually capitalized | not actually case sensitive]
3 Sequential execution
4 The first non-comment line must be from [based on that base image]
5 Need a dedicated directory [create it yourself]
6 The first letter must be capitalized --- Dockerfile
7 When making an image that depends on files or package groups, you must prepare them in a dedicated directory in advance

.dockerignore file -- define an ignore file in each line
--Create in the working directory
For example: pam.d/su*

.........................................................

Common instructions in Dockerfile:

1 FROM ---Specify the base image

If the base image does not exist, it will be pulled from Docker Hub using the following format:
FROM <image>:[tag]
FROM <image>@digest[checksum]
If the current host does not have this image, it will automatically go to the official website HUB to download it
..............................................

2 MAINTANIER -- Provide Dockerfile The creator provides personal information

[gradually abandoned]
LABLE -- replaces MAINTANIER
Specific use:
LABLE maintainer="Author information"

Use format:

MAINTANIER "guowei <[email protected]>"

.......................................................

3 COPY --Copy the files in the host machine to the image!

The file should be in the Dockerfile working directory
src original file
-- Support wildcards
--Usually a relative path
dest destination path
--Usually an absolute path

Strings separated by whitespace characters need to be separated by "", otherwise they will be treated as two files!

File Copy Guidelines:
1 src must be a path in the build context, not its parent directory
2 If src is a directory, its internal files or subdirectories will be recursively copied
But the src directory itself will not be copied
3 If multiple srcs are specified, or wildcards are used in src, dest must be a
Directory, and must end with /
4 If the dest directory does not exist, it will be created automatically, including its parent directory.
..............................................................

4 ADD - similar to the COPY command

Support URL path----If the network can be accessed, it will access the network to download to the local and then package it into the image!

Operating Guidelines:
1 If src is a URL and dest does not end with /, the file specified by src will be downloaded and created directly as dest; if dest ends with /, the file specified by the file name URL will be downloaded directly and saved as dest/filename

2 If it is a compressed package, it will be decompressed, but the tar file obtained through the URL path will not be expanded

3 If there are multiple srcs, or if wildcards are used directly or indirectly, dest must be a directory path ending with /. If dest does not end with /, it is considered a normal file.
The contents of src will be written directly to dest!

...............................................................

5 WORKDIR --Specify the working directory

Each time it will only affect the subsequent instructions of this instruction

ADD nginx-1.14.2.tar.gz /usr/local/src/ -- not affected

WORKDIR /usr/local/src/

ADD nginx-1.14.2.tar.gz ./ --Affected

.............................................................

6 VOLUME

Only volumes managed by Docker can be defined:
VOLUME /data/mysql

When running, a volume directory will be randomly generated under the host directory!
................................................................

7 EXPOSE Open the specified listening port for the container to communicate with the outside world

Use format:
EXPOSE 80/tcp 23/udp

If no protocol is specified, the default value is TCP.

Use the -P option to expose the port specified here!
But the host's port associated with this port is random!
..............................................................

8 ENV

Used to define the required environment variables for the image and can be called by other commands following it in the Dockerfile file

Calling format:
$A or ${A}

ENV <key> <value>
ENV <key>=<value>

In the first format, everything after key will be considered as part of <value>. Therefore, only one variable can be set at a time!

The second format can be used to set multiple variables at once, each variable is a <key>=<value>
If <value> contains spaces, you can escape them with a backslash (\) or enclose <value> in quotation marks. In addition, backslash can also be used for continuation

When defining multiple variables. The second method is recommended to complete all functions in the same layer. Specific usage:
ENV JAVA_HOME /usr/local/jdk
ENV JRE_HOME $JAVA_HOME/jre
ENV CLASSPATH $JAVA_HOME/lib/:$JRE_HOME/lib/
ENV PATH $PATH:$JAVA_HOME/bin/

ENV A /web/html

COPY index.html ${A:-/web/html}

Passing variables in docker run:
docker run -e [list] passes variable values. If you assign variables in dockerfile, you can continue to assign values ​​in docker run.
docker run --name b1 --rm -e A=xx [image ID]
It will not affect the docker build process!

printenv -- output environment variable information

..............................................................

9 RUN command:

Use format:
RUN <command>
RUN ["<executable>","<param1>","<param2>"]

In the first format, <command command is usually a shell command and is run as "/bin/sh -c">. This means that the PID of this process in the container cannot be 1 and cannot receive Unix signals. Therefore, when the docker stop command is used to stop the container, this process will not receive the signal.

The parameter in the second syntax format is an array in JSON format, where <executable> is the command to be run, and the following
<paramN> is an option or parameter passed to the command. However, the command specified in this format will not be run as "/bin/sh -c">, so common shell operations such as variable substitution and wildcard substitution will not be performed. However, if the command to be run depends on this shell feature, it can be replaced with the following format:
RUN ["/bin/bash","-c","<executable>","<param1>"]

........................................................................

10 CMD command: run in docker run

There are three ways to write grammar
1. CMD ["executable","param1","param2"] -- Start the specific instance of the process with ID 1:

CMD ["/bin/sh","-c","/bin/httpd","-f","-h /web/html]

2. CMD ["param1","param2"]
3. CMD command param1 param2 -- directly operate as a subprocess of the shell
param*=execution parameters, such as the second one:
CMD ["nginx"]

docker run -it -p 8888:80 172.20.23.31/server1/nginx-base:v1 nginx

Double quotes only!

CMD ["param1","param2"]
--This usage is used to provide default parameters for the ENTRYPOINT instruction

Can be used to execute scripts:
Add script:

ADD run_tomcat.sh /apps/tomcat/bin/run_tomcat.sh

RUN chmod +x /apps/tomcat/bin/run_tomcat.sh

RUN chown -R tomcat:tomcat /apps /data/tomcat

CMD ["/apps/tomcat/bin/run_tomcat.sh"] -- reference the script!

..............................................................

11 ENTRYPOINT

A function similar to the CMD instruction is used to specify a default running program for the container, making the container like a separate executable program

Unlike CND, the program started by this instruction will not be overwritten by the parameters specified in the docker run command line. Moreover, these command line parameters will be passed as parameters to the program specified by ENTRYPOINT.

Use format:

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

The command parameters passed to the docker run command will overwrite the contents specified by CMD and appended to ENTRYPOINT
The command is finally used as its parameter

There can be multiple such instructions in the Dockerfile file, but only the last one takes effect!

When running docker run, the command passed using the --entrypoint string option can override the ENTRYPOINT instruction defined in the Dockerfile.

How to allow Nginx configuration files to receive parameters

Create a script:

#!/bin/bash
#
cat > /etc/nginx/conf.d/www.conf <<EOF
server {
server_name ${HOSTNAME};
listen ${IP:-0.0.0.0}:${PORT:-80};
root ${ROOT:-/web/html};
}
EOF
exec "$@"
chmod +x nginx-conf.sh

Dockerfile:

FROM xxx
ENV ROOT='/web/html/'
ADD index.html ${ROOT}
ADD nginx-conf.sh /bin/nginx-conf.sh
CMD ["/usr/sbin/nginx","-g","daemon off;"]
ENTRYPOINT ["/bin/nginx-conf.sh"]
docker run --name b1 --rm -P -e "PORT=8080" [image ID]

Note: Double quotes are required! ! !
................................................................................

12 USER command:

Used to specify any RUN, CMD or ENTRYPOINT when running an image or running a Dockerfile
The user name or UID of the program specified by the command

By default, the container runs as root.

Format:
USER <UID>|<UserName>

Note that <UID> can be any number, but in practice it must be a valid number for a user in /etc/passwd.
UID otherwise the docker run command will fail!

Must exist in the /etc/passwd file in the container

....................................................................................

13 HEALTHCHECK

Health status monitoring
HEALTHCHECK NONE -- Do not monitor

Common options:
--interval=DURATION The default is 30 seconds-how often to monitor
--timeout=DURATION default 30 seconds--monitoring timeout
--start-period=DURATION --When the Docker container is started, how long will it take to perform a health check? The default is 0 seconds
--retries=N The default is 3 times. The default number of checks is considered a failure.

Response value:
0 - Success
1--Failure
2--Customization

Application examples:

HEALTHCHECK --interval=5m --timeout=3s CMD curl -f http://localhost/ || exit1

Application in Dockerfile:

HEALTHCHECK --start-period=3s CMD wget -O - -q http://{IP:-0.0.0.0}:${PORT:-80}/

It can also be defined in docker run:

--health-cmd string
--health-interval duration
--health-retries int
--health-start-period duration
--health-timeout duration

.................................................................

14 SHELL command:

["cmd","/S","/C"] --windons

............................................................

15 STOPSIGNAL command:

STOPSIGNAL Signal name

Defines the signal for the stop command!

SIGKILL --9 signal

.............................................................

16 ARG parameters:

Used in the docker build process

Can be passed as a parameter by --build-arg!
Specific applications:

ARG auther=tim
LABLE maintainer=${author}
docker build --build-arg auther=tom -t xxx ./

If the arg variable in the dockerfile is set with the --build-arg variable during docker build, the variable value in the command line interface will be the final value!
.................................................................

17 ONBUILD

Used to define a trigger in a Dockerfile
Dockerfile is used to build an image file, which can also be used as a base image by another
Dockerfile is used as the parameter specified by from and uses it to build a new impact file

When the from specification in the following Dockerfile is executed during the build process, it will trigger the trigger specified by ONBUILD that creates the Dockerfile file of its base image.

Format:
ONBUILD Dockerfile instructions to execute

Although any command can be registered as a trigger command, ONBUILD cannot be nested within itself and will not trigger from and maintainer commands.

Images built using a Dockerfile that contains the onbuild directive should use a special tag such as ruby:2.0-onbuild

Be extremely careful when using the add or copy directives in an onbuild directive, as the build process context will fail if the specified source files are missing!

It will be executed when others reference this image! It will not be executed during the first build process