纵有千金何道富，不如复载五车书

---

Dockerfile文件由一些列的指令组成，它是用来构建docker镜像的，类似于java的.java文件（dockerfile），使用javac编译（构建）成.class文件（images），不过这里构建docker镜像不是使用javac，而是使用docker build命令来构建的。

用法

docker build命令可以通过Dockerfile这个文件里的指令和指定的上下文目录（递归）来进行构建，命令如下：
docker build [-f Dockerfile] .
-f 表示可以指定Dockerfile的路径，后面的点（当前目录）指定要进行构建的上下文目录，这个目录可以是本地文件的目录，也可以是远程的git目录（URL），一般Dockerfile和需要构建的上文目录放在一起，这样在上下文目录直接运行docker build .就可以进行构建了。

构建命令不是docker cli执行的，而是docker daemon执行，一旦执行，docker cli将会发送指定的上下文目录（递归）到docker daemon进行处理，构建的上下文千万不要指定/（根目录)

.dockerignore文件

在docker cli发送指定上下文目录给docker daemon之前，它首先会在指定的上下文目录的根路径上寻找是否有.dockerignore文件，如果有，它将会把里面的文件排除再发发送给docker daemon。
文件里的格式如下：

comment

/tmp*
tmp?
*.tmp

rule	behavior
#comment	#后面跟注释
*/tmp*	表示在上下文目录中的任意一级子目录中，只要文件名首字母为tmp的将被排除，如:/somedir/tmpzdf
*/*/tmp*	表示在上下文目录中的任意二级子目录中，只要文件名首字母为tmp的将被排除，一级子目录下的将不会被排除，如:/somedir/subdir/tmpzdf
*/.tmp	表示将排除上下文目录（递归）中所有以.tmp为后缀的文件
tmp?	表示在上下文目录下的tmp开头只有一个字符结尾的文件将被排除，如:tmpz，tmpd
*.tmp	表示在上下文目录下后缀为.tmp的文件将被排除
!*.tmp	表示在上下文目录下后缀为.tmp的文件将不会被排除

FROM

格式
FROM <image> [AS <name>]
FROM <image>[:<tag>] [AS <name>]
FROM <image>[@<digest>] [AS <name>]

FROM 指令后面需要写一个已存在的镜像作为基础镜像，这个镜像可以是私有仓库的镜像，也可以是公共仓库下的镜像，类似于代码中的继承。一个有效的Dockerfile文件必须是要有FROM指令且FROM指令需要在文件的最开始就出现（除了ARG指令）。

• FROM指令可以在一个Dockerfile文件出现多次，它可以创建出多个镜像，使用前一个创建出来的镜像作为另一个镜像的依赖。最终最后一个镜像会被保存，其他镜像会被清除，这个特性在构建程序时特别有用，它可以减少镜像的大小和层数。
• FROM指令的可选字段name，在构建多个镜像时特别有用，它可以通过命令FROM,COPY 的--from=<name|index>来引用相应镜像里的文件。
• tag标签是可选的，如果忽略它们，那么默认为latest。

LABEL

格式
LABEL <key>=<value> <key>=<value> <key>=<value> ...

LABEL指令为镜像提供元数据，它是一组键值对。一个镜像可以拥有超过一个的LABEL标签如下：

.
LABEL multi.label1="value1" \
multi.label2="value2" \
other="value3"

你可以使用docker inspect <image> 查看镜像的标签，标签具有继承特性，这里将会包括镜像本身的标签和基础镜像的标签（FROM base），如果它们有相同的键但是值不同，那么最新的标签将会覆盖之前的标签。

MAINTAINER

格式
````MAINTAINER <author name>``

用于设置制作镜像的作者的名字，不过这个指令已经过时，由LABEL指令代替。例如：LABEL maintainer="SvenDowideit@home.org.au"

ENV

格式
ENV <key> <value>
ENV <key>=<value> <key>=<value> ...

ENV指令用于指定环境变量，在构建镜像的过程中会被后续的RUN指令用到，在容器启动后也会存在于容器中，常用设置应用的数据库名和密码注入。在运行容器时可以通过docker run --env <key>=<value>来覆盖环境变量。一般使用第二种形式来设置环境变量，用\来进行换行，例如:

.
ENV url="mysql" \
username="root" \
password="root"

注意，环境变量的持久性也可能造成一些问题，例如ENV DEBIAN_FRONTEND noninteractive，它会让使用 Debian作为基础镜像构建的用户在运行apt-get时看不到输出，所以为了只对单一命令方式生效，请使用这种方式：RUN <key>=<value> <command>.

ADD

格式
ADD [--chown=<user>:<group>] <src>... <dest>
ADD [--chown=<user>:<group>] ["<src>",... "<dest>"] (this form is required for paths containing whitespace)

注意：--chown参数只支持在Linux系统下运行的容器镜像。

ADD指令将复制文件，目录或者远程URL文件到镜像中的<dest>路径下。
<src>，你可以用过通配符指定多个文件或者目录，它们的路径是相对于你的上下文目录的。例如：

.
ADD hom* /mydir/ # 添加所有以hom开头文件
ADD hom?.txt /mydir/ #添加以hom开头，接一个字符，以.txt结尾的文件，如：home.txt

<dest>路径可以是一个绝对路径，也可以是一个相对于WORKDIR的相对路径。例如：

ADD test relativeDir/ # 添加test文件到WORKDIR/relativeDir/下
ADD test /absoluteDir/ # 添加test文件到/absoluteDir/下

所有复制到镜像中的文件或目录的uid和gid都为0，除非使用--chown标签指定用户和用户组，如下：

.
ADD --chown=55:mygroup files* /somedir/
ADD --chown=bin files* /somedir/
ADD --chown=1 files* /somedir/
ADD --chown=10:11 files* /somedir/

注意：如果你的镜像文件系统不包含/etc/passwd和/etc/group文件，那么你在指定--chown标签时需要使用数字，不能使用用户名或用户组，因为它们不能使用相应的文件解释成数字。

另外ADD指令还需要遵循下列规则：

• <src>目录必须是上下文目录里面的，你不能添加其他目录，因为docker build是把上下文目录发送到docker daemon。

• 如果<src>是URL，且<dest>不是以/结尾，那么URL的内容会被复制到<dest>目录下，不包括原来的目录。如果<dest>是以/结尾，那么URL的内容包括它的名字都会复制到<dest>目录下，如 ADD https://example.com/filename /example/，那么它会在/example目录下创建一个名为filename的文件或目录（/example/filename）。

• 如果<src>是一个目录，那么它目录下的内容将全部复制到<dest>下，不包括<src>目录本身。

• 如果<src>是一个.tar文件，它将会解压复制到<dest>目录下。

• 如果<src>是指多个资源，那么<dest>目录一定要以/结尾。

• 如果<src>是一个文件，<dest>没有以/结尾，它将把<src>文件的内容写到<dest>文件，如果<dest>以/结尾，那么它将被复制到<dest>目录下。

• 如果<dest>目录不存在，那么它将会在相应的路径上自动创建。

COPY

格式
COPY [--chown=<user>:<group>] <src>... <dest>
COPY [--chown=<user>:<group>] ["<src>",... "<dest>"] (this form is required for paths containing whitespace)

COPY指令和ADD指令基本是一样的，需要注意的是COPY指令不支持URL和.tar的压缩文件，在Dockerfile的最佳实践中，如果没有涉及到使用URL或者.tar的压缩文件，推荐使用COPY指令。

EXPOSE

格式
EXPOSE <port> [<port>/<protocol>...]

EXPOSE指令通知Docker daemon容器在运行时监听的端口，你可以指定监听端口的协议是TCP还是UDP，默认是TCP。EXPOSE指令并不会真正的去暴露一个端口或者是打开一个端口，它只是作为文档性的功能，意味着这个端口是构建镜像的人想要去暴露的，运行镜像的人你可以选择去暴露或者不暴露，你可以使用-p hostPort:contanerPort去指定主机上的一个端口或多个端口进行映射，也可以直接使用-P标签，这样它将会把镜像里想要暴露的端口都映射到主机的高端口上去。如下：

.
EXPOSE 80/tcp
EXPOSE 80/udp

指定主机端口映射
docker run -p 80:80/tcp -p 80:80/udp ...

随机映射主机的高位端口
docker run -P ...

VOLUME

格式
VOLUME ["/dir"]
VOLUME /dir1 /dir2

VOLUME指令将会在容器内创建一个相应名字挂载点，它可以挂载本地主机的目录或者其他容器的目录。
当执行docker run命令初始化一个新的volume，这个volume可能会包含已经在镜像文件中的数据。如下:

FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

执行docker run命令时，它会创建一个新的挂载点/myvol，并把greeting文件复制到新的挂载点下。

VOLUME指令有一些注意事项如下：

• 如果你使用的是基于windows的容器，那么你卷的目录除了不能是C盘，目录也必须不存在或者为空；
• 在build阶段， 任何在声明VOLUME目录之后的对VOLUME进行的数据操作，都将无效。
• 当使用第一种格式时，必须使用双引号
• Dockerfile中不能指定主机目录，主机目录只能在容器创建时指定。

USER

USER <user>[:<group>]
USER <UID>[:<GID>]
USER指令是设置用户和组的，当镜像运行时或者是Dockerfile文件接下来运行命令的指令RUN,，CMD，ENTRYPOINT时，将以指定的USER去运行。

注意：如果一个用户没有指定属组，那么它将以root组的身份去运行命令

WORKDIR

格式
WORKDIR /path/to/workdir

WORKDIR指令将会为接下来的Dockerfile文件中的RUN, CMD, ENTRYPOINT, COPY 和 ADD 指令设定工作目录。如果WORKDIR指定的目录不存在，那么它将会创建，而且在Dockerfile文件中你可以指定多个WORKDIR指令，如果任何指令中给定一个相对路径，那么它是相对于上一个WORKDIR目录。如下

WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd

输出将会是/a/b/c

同时WORKDIR还支持环境变量，如下

ENV DIRPATH /path
WORKDIR $DIRPATH/$DIRNAME
RUN pwd

输出将会是/path/$DIRNAME

RUN

格式
RUN <command>
```RUN ["executable", "param1", "param2"] ``

RUN指令是指运行指定的命令，每条RUN指令将会在当前镜像的基础上执行命令，并提交为新的镜像，以供接下来Dockerfile各个步骤使用。上面第一种格式将启动shell终端运行命令，默认是/bin/sh -c；第二种格式使用exec执行，不会启动shell环境，另外，如果需要制定其他shell终端运行命令，通过第二种格式可以实现，例如RUN ["/bin/bash", "-c", "echo hello"]

使用第二种格式必须使用双引号来包括命令

CMD

格式
CMD ["executable","param1","param2"] (exec form, this is the preferred form)
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
CMD command param1 param2 (shell form)

CMD指令主要是为容器提供默认的执行指令，当它和ENTRYPOINT指令共存时，CMD指令主要是为ENTRYPOINT指令提供默认参数。关于CMD作为执行命令的两种形式的区别，可以参考之前的RUN命令。

使用shell形式
FROM ubuntu
CMD echo "This is a test." | wc -

使用exec形式
FROM ubuntu
CMD ["/usr/bin/wc","--help"]

如果你需要容器每次运行都使用相同的指令和不同的参数，那么你可以考虑结合ENTRYPOINT和CMD使用，当你使用docker run命令时，后面接上参数将会覆盖CMD命令。

注意：在Dockerfile文件中只能有一个CMD指令，如果有多个，那么只有最新的那一个会产生作用。

ENTRYPOINT

格式
ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)
ENTRYPOINT command param1 param2 (shell form)

ENTRYPOINT运行你把一个容器配置为可执行的一个进程，如下：
docker run -i -t --rm -p 80:80 nginx
它将会启动一个只包含nginx进程的容器，即nginx进程在容器里pid为1。
如果以docker run <image>运行容器，那么它的参数例如 -d将会以exec形式追加到ENTRYPOINT指令第一种形式(exec form)的后面，如/bin/nginx -d。如果你在运行时指定了CMD参数，那么它将会覆盖Dockerfile中所有已定义的CMD参数。你可以使用--entrypoint来覆盖ENTRYPOINT指令。
如果Dockerfile中使用的是第二种形式构建镜像，那么容器在启动时它的/bin/sh将会是1号进程，ENTRYPOINT指令将是它的子命令，这就意味着不能传入任何进程信号，那么在运行docker stop时，我容器里的nginx将不会收到SIGTERM信号，就不会优雅的退出。

CMD与ENTRYPOINT

CMD和ENTRYPOINT指令都定义了在运行容器时执行的命令，它们需要遵守怎样的规则？又有什么区别呢？

• Dockerfile文件应该制定至少一个CMD指令或者ENTRYPOINT指令。
• 当使用容器作为一个可执行的进程时，应该选用ENTRYPOINT指令。
• CMD指令应该作为参数的形式为ENTRYPOINT指令提供默认参数。
• 当运行容器时使用可选的参数将会覆盖CMD指令。

下表展示了两个命令在执行期间进行协作的效果：

	NO ENTRYPOINT	ENTRYPOINT exec_entry p1_entry	ENTRYPOINT [“exec_entry”, “p1_entry”]
No CMD	error	/bin/sh -c exec_entry p1_entry	exec_entry p1_entry
CMD [“exec_cmd”, “p1_cmd”]	exec_cmd p1_cmd	/bin/sh -c exec_entry p1_entry	exec_entry p1_entry exec_cmd p1_cmd
CMD [“p1_cmd”, “p2_cmd”]	p1_cmd p2_cmd	/bin/sh -c exec_entry p1_entry	exec_entry p1_entry p1_cmd p2_cmd
CMD exec_cmd p1_cmd	/bin/sh -c exec_cmd p1_cmd	/bin/sh -c exec_entry p1_entry	exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd