Docker进阶-一-DockerFile解析

Dockerfile是用来构建Docker镜像的文本文件，是由一条条构建镜像所需的指令和参数构成的脚本，类似于Linux的MakeFile。现在，假设我们需要构建一个包含vim/ifconfig的ubuntu镜像，我们需要run一个原始ubuntun镜像，然后在其中安装vim/ifconfig，最后通过commit来生成镜像。但是，如果需要多次安装，就要多次重复上述commit步骤，很麻烦。那么，能不能将需要安装的东西列一个清单，然后一次性搞定呢？==> Dockerfile。

Dockerfile就像一个图纸，把镜像需要安装的东西全部写进去，然后build生成镜像时一口气直接装完。可以看到，commit是通过Container来生成镜像的，而Dockerfile则不需要操作者通过手动运行Container来对镜像进行增强。

构建过程解析

每条保留字指令都必须为大写字母，且后面要跟随至少一个参数，如COPY保留字：

指令按照从上到下，顺序执行，每条指令都会创建一个新的镜像层并对镜像进行提交，#表示注释。至于镜像层，简单来说，就是Docker镜像是一层层构成的，这样才能使我们可以在一个初始镜像的基础上生成新的镜像，具体分层概念将在下一篇博客中讲述。

【Dockerfile执行流程】

1> Docker从基础镜像运行一个Container。

2> 顺序执行一条指令并对Container作出修改。

3> 执行类似commit的操作来提交一个新的镜像层。

4> Docker再基于刚提交的镜像运行一个新的Container。

5> 执行Dockerfile中的下一条指令直到所有指令都执行完成。

从应用软件的角度来看，Dockerfile、Docker镜像与Docker容器分别代表了软件的三个不同阶段：

Dockerfile使软件的设计图纸

Docker镜像使软件的交付品

Docker容器则是软件镜像的运行态，也即运行实例

总的来说，Dockerfile定义了最终的容器进程需要的一切东西。Dockerfile涉及的内容包括执行代码或者是文件、环境变量、依赖包、运行时环境、动态链接库、操作系统的发行版、服务进程和内核进程（当应用进程需要和系统服务和内核进程打交道时，需要考虑如何设计namespace的权限控制）等等。

---

保留字

参考tomcat8的Dockerfile入门：https://github.com/docker-library/tomcat，这里罗列了12个最常用的保留字。

FROM

基础镜像，说明当前新镜像是基于哪个镜像的，指定一个已经存在的镜像作为模板，Dockerfile的第一条指令必须是FROM。

FROM [--platform=<platform>] <image> [AS <name>]  # or
FROM [--platform=<platform>] <image>[:<tag>] [AS <name>]  #or
FROM [--platform=<platform>] <image>[@<digest>] [AS <name>]

MAINTAINER

可以通过该保留字留下维护者的姓名和邮箱地址，非必须。

MAINTAINER <name>

新版本中，官方建议用LABEL来替代它：

LABEL org.opencontainers.image.authors="SvenDowideit@home.org.au"

RUN

容器构建镜像时需要运行的命令，有两种格式，shell格式和exec格式。注意，RUN是在docker build时运行的，那为什么会和容器有关呢？就像前文说的，dockerfile每一条指令实质上就是在前一步运行的新的Container上进行操作，然后通过类似commit的操作来构建新镜像，所以实际上是对容器的操作。两种格式分别为：

# shell 格式
RUN <命令行命令>
# <命令行命令>等同于，在容器终端操作的shell命令。

# exec 格式
RUN ["可执行文件","参数1","参数2"]
# RUN ["./test.php", "dev", "offline"]等价于RUN ./test.php dev offline

以shell格式为例，如果我们想要安装vim，那么在容器中就需要使用命令yum -y install vim，然后出容器使用docker commit来构建镜像。现在有了dockerfile，只需要在其中加一句RUN yum -y install vim即可，docker运行完该指令会自动commit。

EXPOSE

暴露出容器将要提供服务所开放的端口，严格来说，是用该dockerfile构建的镜像，运行出的容器提供的服务对外暴露的端口。

EXPOSE <端口1>[/传输格式] [<端口2>[/传输格式]...]
# EXPOSE 8080/tcp

注意，EXPOSE指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明就开启这个端口的服务。在Dockerfile中写入这样的声明有两个好处，一个是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射；另一个用处则是在运行时使用随机端口映射时，也就是docker run -P时，会自动随机映射EXPOSE的端口。

要将EXPOSE和docker run -p <宿主端口>:<容器端口>区分开来。-p，是将宿主端口映射向容器端口，也就是说将容器端口向宿主机外暴漏。而EXPOSE，仅仅是声明容器内暴露的端口。

一般使用docker run -p <宿主端口>:EXPOSE端口来指定宿主机端口和该容器暴露端口的映射，或者使用-P来进行随机映射。这样一想，我们最终在外部直接访问的仍然是宿主机上的端口，EXPOSE只是在设置-p/-P时提醒操作者容器内服务的端口是多少，从而构成映射吗，是不是有些鸡肋？我个人觉得是的，它只是起到声明和提醒的作用。

但是，EXPOSE也有中有趣的玩法，那就是不使用端口映射，让端口直接暴露在宿主机外。怎么做？==> host模式。在docker run时设置--net=host，这样一来容器就和宿主机公用同样的网络配置，包括端口。运行之后，使用docker inspect containerID发现没有任何端口映射信息，因为容器的端口直接就是宿主机的端口。

这样一来，就可以在使用EXPOSE端口来访问容器内的服务了，不再需要-p/-P映射。

WORKDIR

指定构建的镜像运行出容器后，终端默认的初始工作目录，也就是落脚点。比如，tomcat容器的落脚点为/usr/local/tomcat，它的dockerfile就这样写：

ENV CATALINA_HOME /usr/local/tomcat
# ...
WORKDIR $CATALINA_HOME

USER

指定该镜像以什么样的用户去执行，如果都不指定，默认为root

USER <user>[:<group>] #or
USER <UID>[:<GID>]

ENV

用来在构建镜像过程中设置环境变量，注意，是构建过程中，不是构建后。这个环境变量可以在后续的任何RUN指令中使用，也可以在其他指令中直接使用，比如WORKDIR，引用时加$。

ENV NAME VALUE

VOLUME

容器数据卷，不用多说，相当于docker run -v ...，用于数据保存和持久化工作。

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

上述指令会在容器的/myvol目录下设置一个挂载点，并在宿主机上创建一个数据卷和其相关联，由于没有指定宿主机目录，所以是默认的，类似于 docker run -v /myvol 镜像名。可以使用docker inspect 容器名/ID来查看相关联的宿主机目录的路径，会发现数据卷名是一串编号：

/var/lib/docker/volumes/0ab0aaf0d6ef391cb68b72bd8c43216a8f8ae9205f0ae941ef16ebe32dc9fc01/_data

当然，也可以同时创建多个挂载点，每个挂载点都有独立的数据卷：

VOLUME ["/data1","/data2"]

"Mounts": [
        {
            "Name": "d411f6b8f17f4418629d4e5a1ab69679dee369b39e13bb68bed77aa4a0d12d21",
            "Source": "/var/lib/docker/volumes/d411f6b8f17f4418629d4e5a1ab69679dee369b39e13bb68bed77aa4a0d12d21/_data",
            "Destination": "/data1",
            "Driver": "local",
            "Mode": "",
            "RW": true
        },
        {
            "Name": "6d3badcf47c4ac5955deda6f6ae56f4aaf1037a871275f46220c14ebd762fc36",
            "Source": "/var/lib/docker/volumes/6d3badcf47c4ac5955deda6f6ae56f4aaf1037a871275f46220c14ebd762fc36/_data",
            "Destination": "/data2",
            "Driver": "local",
            "Mode": "",
            "RW": true
        }
    ],

COPY

把宿主机目录下的文件和目录拷贝进镜像中，将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。

COPY src dest #or
COPY ["src","dest"]
# <src源路径>：源文件或者源目录
# <dest目标路径>：容器内的指定路径，该路径不用事先建好，路径不存在的话，会自动创建

ADD

将宿主机目录下的文件拷贝进镜像且会自动处理URL和解压tar压缩包，即COPY的升级版：COPY+解压，一般用这个就行。

CMD

指定容器启动后要干的事情。注意，这个容器是运行最终镜像的容器，而不是构建镜像过程中的临时容器，也就是说，这个时候已经和镜像的构建无关了。

RUN是在docker build时运行

CMD是在docker run时运行

CMD指令和RUN的格式相似，外加了一个参数列表格式：

# shell 格式
CMD <命令>
# exec 格式
CMD ["可执行文件","参数1","参数2"...]
# 参数列表格式，在指定了ENTRYPOINT后，用CMD指定具体参数
CMD ["参数1","参数2"...]

Dockerfile中可以有多个CMD指令，但只有最后一个生效，并且，CMD会被docker run设定的运行命令替换。比如，tomcat的dockerfile的最后一行为：

CMD ["catalina.sh", "run"]

即，运行tomcat容器后会在WORKDIR下执行命令catalina.sh run。但是，如果在docker run之后加入了/bin/bash，就会发现tomcat服务并没有启动，因为原本应该执行的catalina.sh run被自己写的/bin/bash覆盖了，因此只启动了容器，并没有启动服务。

ENTRYPOINT

也是用来指定一个容器启动时要运行的命令，类似于CMD指令，但不同的是，ENTRYPOINT不会被docker run后面的命令覆盖，而且这些命令行参数会被当作参数送给ENTRYPOINT指令指定的程序。

# exec 格式
ENTRYPOINT ["executable", "param1", "param2"]
# shell 格式
ENTRYPOINT command param1 param2

ENTRYPOINT可以和CMD一起使用，一般是变参才会使用CMD，这里的CMD等于是在给ENTRYPOINT传参。当指定了ENTRYPOINT之后，CMD的含义就发生了变化，不再是直接运行其命令，而是将CMD的内容作为参数传递给ENTRYPOINT，它们两个组合成<ENTRYPOINT><CMD> 来执行。

比如，通过Dokcerfile构建nginx:test镜像，规定运行时指令，分为定参和变参两部分：

FROM nginx
#...
ENTRYPOINT ["nginx","-c"] # 定参
CMD ["/etc/nginx/nginx.conf"] # 变参

	不传参	传参
Docker命令	docker run nginx:test	docker run nginx:test /etc/nginx/new.conf
衍生出的容器命令	nginx -c /etc/nginx/nginx.conf	nginx -c /etc/nginx/new.conf

如果Dockerfile中存在多个ENTRYPOINT指令，仅最后一个生效。

总结

参考

[1] 尚硅谷docker教程
[2] dockerfile官方文档
[3] final-heart dockerfile EXPOSE