Docker技术入门与实战 第二版-学习笔记-3-Dockerfile 指令详解

前面已经讲解了FROM、RUN指令，还提及了COPY、ADD，接下来学习其他的指令

5.Dockerfile 指令详解

1> COPY 复制文件

格式:

• COPY  <源路径> ...<目标路径>
• COPY ["<源路径1>",..."<目标路径>"]

和 RUN指令一样，也有两种格式，一种类似于shell命令行，一种类似于exec函数调用

COPY指令将从构建上下文目录中 <源路径>的文件/目录复制到新的一层的镜像内的 <目标路径>位置。比如:

 COPY package.json /usr/src/app/

<源路径>可以是多个，甚至可以是通配符，其通配符规则要满足 Go 的 filepath.Match规则，如

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

1）如果 <源路径>是一个文件，且<目标路径>是以/结尾的，则docker会把目标路径当作一个目录，会把源文件拷贝到该目录下。

2）如果 <源路径>是一个文件，且<目标路径>不是以/结尾的，则docker会将其视为一个文件，那么可能分下面几种情况：

• 如果目标文件不存在，将会以该目标文件名字为名创建一个文件，内容与源文件相同；
• 如果目标文件存在，就直接用源文件的内容覆盖目标文件的内容，目标文件名不变；
• 如果这个不是以/结尾的<目标路径>其实就是一个目录，那么会将源文件拷贝到该目录下。⚠️这种情况下最好还是加/

3）如果<源路径>是个目录，且<目标路径>并不存在，则会先创建<目标路径>，然后将<源路径>的所有内容拷贝进来

4）如果<源路径>是个目录，<目标路径>存在，则直接拷贝即可

5）<目标路径>可以是容器内的绝对路径，也可以是相对于工作目录的相对路径(工 作目录可以用 WORKDIR指令来指定)。目标路径不需要事先创建，如果目录不存在会在复制文件前先行创建缺失目录。

此外，还需要注意一点，使用 COPY指令，源文件的各种元数据都会保留。比如 读、写、执行权限、文件变更时间等。这个特性对于镜像定制很有用。特别是构建 相关文件都在使用 Git 进行管理的时候。

2> ADD 更高级的复制文件(相对于COPY)——但是尽可能使用COPY（除了需自动解压缩的情况）

其在COPY的基础上增加了一些功能，如：

1）比如<源路径>可以是一个 URL，这种情况下，Docker 引擎会试图去下载这个链接的文件放到<目标路径>去。下载后的文件权限自动设置为600，如果这并不是想要的权限，那么还需要增加额外的一层 RUN 进行权限调整

2）如果下载的是个压缩包，需要解压缩，也一样还需要额外的一层 RUN 指令进行解压缩。

所以不如直接使用 RUN指令，然后使用 wget或者 curl 工具下载，处理权限、解压缩、然后清理无用文件更合理。因此，这个功能其实并不实用，而且不推荐使用。

3)具有自动解压缩的功能：如果 <源路径>为一个 tar压缩文件的话，压缩格式为gzip , bzip2以及 xz的情况下， ADD指令将会自动解压缩这个压缩文件到 <目标路径>去,如：

FROM scratch
ADD ubuntu-xenial-core-cloudimg-amd64-root.tar.gz /

但是如果我们仅仅只是希望复制整个压缩文件，而不希望将其解压缩时，就不能够使用ADD指令了

⚠️所以尽可能的使用COPY ，因为 COPY的语义很明确，就是复制文件而已，而 ADD则包含了更复杂的功能，其行为也不一定很清晰。最适合使用 ADD的场合，就是所提及的需要自动解压缩的场合。

而且指令会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。

3> CMD 容器启动命令（就是声明容器启动时会执行的命令）

格式：

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

容器就是进程。因此在启动容器时，需要指定所运行的程序和参数。

CMD指令就是用于指定默认的容器主进程的启动命令的。

在运行时，可以指定新的命令来替代镜像设置中的这个默认命令，如ubuntu镜像中默认的CMD为/bin/bash,如果运行docker run -it ubuntu,就会直接进入bash.

我们也可以直接在运行时指定其他命令，如docker run -it ubuntu cat /etc/os-release.这样cat /etc/os-release这个输出系统版本信息的命令就会替代/bin/bash命令

⚠️一般推荐使用exec格式，因为该格式在解析时会被解析成json数组，所以一定要使用双引号，不能使用单引号

如果使用的是shell格式，那么实际的命令会作为命令sh -c的参数来执行，如

CMD echo $HOME

实际上变成：

 CMD [ "sh", "-c", "echo $HOME" ]

这就是为什么可以使用环境变量$HOME的原因，因为可以被shell解析

⚠️提到 CMD就不得不提容器中应用在前台执行和后台执行的问题。这是初学者常出现的一个混淆。

Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机 里面那样，用 upstart/systemd 去启动后台服务，容器内没有后台服务的概念。

对于容器而言，其启动程序就是容器应用进程，容器就是为了主进程而存在的，主进程退出，容器就无意义了，其不关心其他辅助进程

如错误命令：

 CMD service nginx start

会发现容器执行后就立即退出了，为什么？

其实service nginx start命令是希望upstart以后台守护进程形式启动nginx服务。

但是上面的命令其实会变成CMD [ "sh", "-c", "service nginx start" ]，主进程实际上是sh。所以当service nginx start命令结束后，sh也就结束了，sh主进程将退出，自然容器也会跟着退出

正确写法是直接执行nginx可执行文件，然后以前台形式运行：

 CMD ["nginx", "-g", "daemon off;"]

4> ENTRYPOINT 入口点——指定容器启动程序及参数

与CMD相似，但是在docker build运行时需要 --entrypoint参数来指定

当指定了ENTRYPOINT指令后，CMD的内容将作为参数传给ENTRYPOINT，如上面CMD的格式3中所说

为什么有了CMD还需要ENTRYPOINT？

1）让镜像变成像命令一样使用

举例——如果我们想要知道自己当前公网IP的镜像，用CMD实现。则Dockerfile为：

FROM ubuntu:16.04
RUN apt-get update \
    && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*
CMD [ "curl", "-s", "http://ip.cn" ]

构建镜像myip：

docker build -t myip .

然后我们要查询当前公网IP，则运行：

docker run myip

这就会默认运行CMD指令中的 curl -s http://ip.cn

有问题的地方是：

如果这个时候我希望得到HTTP头信息，就是需要在curl命令后加 -i 参数，但是如果我运行：

docker run myip -i

会报错，因为实际上是用-i将整个curl -s http://ip.cn命令给覆盖了，所以只能运行：

docker run myip curl -s http://ip.cn -i

这就是CMD不好的地方，但是使用ENTRYPOINT就能够解决这个问题

ENTRYPOINT实现方案为：

FROM ubuntu:16.04
RUN apt-get update \
    && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*
ENTRYPOINT [ "curl", "-s", "http://ip.cn" ]

这时候运行docker run myip -i就能够得到想要的结果，-i会作为参数传给ENTRYPOINT

2）应用运行前的准备工作

启动容器即启动主进程，在启动主进程前需要进行一些准备工作

比如mysql类数据库需要进行一些数据库配置、初始化等工作；或者是希望避免使用root用户...

这些是与CMD无关的。这种情况一般是写一个脚本放到ENTRYPOINT执行，脚本需要的参数会写到CMD中，如官方镜像redis:

FROM alpine:3.4
...
RUN addgroup -S redis && adduser -S -G redis redis
...
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE
CMD [ "redis-server" ]

可以看到其中为了 redis 服务创建了 redis 用户，并在最后指定了 ENTRYPOINT为docker-entrypoint.sh脚本

#!/bin/sh
...
# allow the container to be started with `--user`
if [ "$1" = 'redis-server' -a "$(id -u)" = '' ]; then
    chown -R redis .
    exec su-exec redis "$0" "$@"
fi
exec "$@"

$1即传入的第一个参数，在CMD中写着，即"redis-server"。如果是"redis-server"的话，就切换到redis用户身份启动服务器；否则仍使用root身份

⚠️⚠️除此之外，CMD和ENTERPOINT的区别还有：

CMD：

• 它是容器启动时默认执行的命令
• 如果在运行docker run时指定了要运行的命令，那么CMD命令就会被忽略
• 如果在Dockerfile文件中定义了多个CMD，只有最后一个有效
• 因此可以使用ENTERPOINT来替代上面的CMD
• 而且如果执行语句 docker run -it imageName /bin/bash,那么CMD命令就不会被执行

ENTERPOINT：

• 容器会以应用程序或者服务的形式来运行它，这也是上面的-i能直接作为参数传给ENTERPOINT命令的原因
• 该命令是一定会执行的，不会像CMD可能被忽略

5>ENV 设置环境变量

格式：

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

如：

ENV VERSION=1.0 DEBUG=on \
    NAME="Happy Feet"

⚠️使用\进行换行，带有空格的值要用双引号括起来

ENV NODE_VERSION 7.2.
RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NOD
E_VERSION-linux-x64.tar.xz" \
  && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS25
.txt.asc"

从上面的例子可以看见，在RUN中多次使用$NODE_VERSION来操作定制。这样以后如果版本有所更改，只用改变ENV即可，维护更方便

支持环境变量展开的指令还有：

ADD、COPY 、ENV 、EXPOSR、LABEL 、USER 、WORKDIR 、VOLUME 、STOPSIGNAL 、ONBUILD

6> ARG 构建参数

格式：ARG <参数名>[=<默认值>]

1）当实现与ENV的效果一样时，用来设置环境变量。不同在于——ARG所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。但是不要因 此就使用 ARG保存密码之类的信息，因为 docker history还是可以看到所有 值的。

2）可用于定义参数名称及其默认值。该默认值可以在构建命令docker build中用 --build-arg <参数名>=<值> 来覆盖默认值

7> VOLUME 定义匿名卷

格式：

• VOLUME ["<路径1>","<路径2>"...]
• VOLUME <路径>

容器运行时应该尽量保持容器存储层不发生写操作，对于数据库类需要保存动态数据的应用，其数据库文件应该保存于卷(volume)中

为了防止运行时用户忘记将动态文件所保存目录挂载为卷，在 Dockerfile中，我们可以事先指定某些目录挂载为匿名卷，这样在运行时如果用户不指定挂载，其应用也可以正常运行，不会向容器存储层写入大量数据。

 VOLUME /data

/data目录就会在运行时自动挂载为匿名卷，任何向 中写入的 信息都不会记录进容器存储层，从而保证了容器存储层的无状态化。当然，运行时可以覆盖这个挂载设置。比如:

 docker run -d -v mydata:/data xxxx

在这行命令中，就使用了 mydata这个命名卷挂载到了 /data这个位置，替代 Dockerfile中定义的匿名卷的挂载配置

8> EXPOSE 声明端口

格式：EXPOSE <端口1> [<端口2>...]

声明运行时容器提供服务端口，这只是一个声明，在运行时并不 会因为这个声明应用就会开启这个端口的服务

声明好处：

• 一个是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射

• 另一个用处则是在运行时使用随机端口映射时，也就docker run -p 时，会自动随机映射 EXPOSE 的端口

⚠️要将 EXPOSE和在运行时使用 -p <宿主端口>:<容器端口>区分开来

-p是映射宿主端口和容器端口，换句话说，就是将容器的对应端口服务公开给外界访问。

而 EXPOSE仅仅是声明容器打算使用什么端口而已，并不会自动在宿主进行 端口映射。

9> WORKDIR 指定工作目录

格式：WORKDIR <工作目录路径>

以后各层的当前目录就被改为指定的目录，该目录需要已经存在， WORKDIR并不会帮你建立目录。

之前提到一些初学者常犯的错误是把 等同于 Shell 脚本来书写，这种错误的理解还可能会导致出现下面这样的错误:

RUN cd /app
RUN echo "hello" > world.txt

如果将这个 Dockerfile 进行构建镜像运行后，会发现找不到 /app/world.txt文 件，或者其内容不是hello 。

原因其实很简单，在 Shell 中，连续两行是同一个进程执行环境，因此前一个命令修改的内存状态，会直接影响后一个命令;而在 Dockerfile 中，这两行 命令的执行环境根本不同，是两个完全不同的容器。

之前说过每一个 RUN都是启动一个容器、执行命令、然后提交存储层文件变更。 RUN cd/app第一层 的执行仅仅是当前进程的工作目录变更，一个内存上的变化而已，其结果不会造成任何文件变更。

而到第二层的时候，启动的是一个全新的容器，跟第一层的容器更完全没关系，自然不可能继承前一层构建过程中的内存变化。

因此如果需要改变以后各层的工作目录的位置，那么应该使用 WORKDIR指令。

10> USER 指定当前用户

格式 ： USER <用户名>

USER指令和 WORKDIR相似，都是改变环境状态并影响以后的层

USER是改变之后层执行 RUN, CMD以及ENTRYPOINT这类命令的身份

但是USER只是帮助你切换到指定用户而已，这个用户必须是事先建立好的，否则无法切换，举例：

RUN groupadd -r redis && useradd -r -g redis redis
USER redis
RUN [ "redis-server" ]

如果以 root执行的脚本，在执行期间希望改变身份，比如希望以某个已经建立好的用户来运行某个服务进程，不要使用 su 或sudo者 ，这些都需要比较麻烦的配置，而且在 TTY 缺失的环境下经常出错。建议使用gosu，可以从其项目网站看到进一步的信息:https://github.com/tianon/gosu

# 建立 redis 用户，并使用 gosu 换另一个用户执行命令
RUN groupadd -r redis && useradd -r -g redis redis
# 下载 gosu
RUN wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/ releases/download/1.7/gosu-amd64" \
    && chmod +x /usr/local/bin/gosu \
&& gosu nobody true
# 设置 CMD，并以另外的用户执行
CMD [ "exec", "gosu", "redis", "redis-server" ]

11> HEALTHCHECK 健康检查

格式：

• HEALHTHCHECK [选项] CMD <命令>：设置检查容器健康状况的命令
• HEALHTHCHECK NONE ：如果基础镜像有健康检查指令，使用这行可以屏蔽掉其健康检查指令

该指令是告诉 Docker 应该如何进行判断容器的状态是否正常

当在一个镜像指定了HEALHTHCHECK指令后，用其启动容器，初始状态会为starting， 在HEALHTHCHECK指令检查成功后变为healthy ；如果连续一定  次数失败，则会变为unhealthy

支持下列选项:

• --internal=<间隔> :两次健康检查的间隔，默认为 30 秒;
• --timeout=<时长>:健康检查命令运行超时时间，如果超过这个时间，本次健康检查就被视为失败，默认 30 秒;
• --retries=<次数>:当连续失败指定次数后，则将容器状态视为unhealthy，默认 3 次。

和CMD , ENTRYPOINT一样， HEALHTHCHECK只可以出现一次，如果写了多个， 只有最后一个生效。

CMD <命令>中命令的返回值决定这次健康检查的成功与否：0为成功，1为失败，2为保留，不要使用这个返回值

假设我们有个镜像是个最简单的 Web 服务，我们希望增加健康检查来判断其 Web 服务是否在正常工作，我们可以用 curl来帮助判断，其Dockerfile 的HEALHTHCHECK可以这么写:

FROM nginx
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib
/apt/lists/*
HEALTHCHECK --interval=5s --timeout=3s \
  CMD curl -fs http://localhost/ || exit 1

这里我们设置了每 5 秒检查一次(这里为了试验所以间隔非常短，实际应该相对较长)，如果健康检查命令超过 3 秒没响应就视为失败，并且使用 curl -fs http://localhost/ || exit 1作为健康检查命令。

然后构建镜像：

docker build -t myweb:v1 .

然后启动容器：

docker run -d --name web -p : myweb:v1

然后可以使用docker ps查看容器最初状态为（health：starting）：

CONTAINER ID    IMAGE            COMMAND           CREATED                        STATUS                  PORTS         NAMES
03e28eb00bd0   myweb:v1  "nginx -g 'daemon off"    seconds ago    Up  seconds (health: starting)    /tcp,/tcp     web

等待几秒后再查看就变成了healthy

CONTAINER ID    IMAGE            COMMAND           CREATED                STATUS                  PORTS         NAMES
03e28eb00bd0   myweb:v1  "nginx -g 'daemon off"    seconds ago    Up  seconds (healthy)    /tcp,/tcp     web

如果连续失败超过重试次数，状态就会变成unhealthy

为了帮助排障，健康检查命令的输出(包括 stdout以及 stderr)都会被存储于健康状态里，可以用docker inspect来查看

$ docker inspect --format '{{json .State.Health}}' web | python -m json.tool
{
    "FailingStreak": ,
    "Log": [
        {
            "End": "2016-11-25T14:35:37.940957051Z",
            "ExitCode": ,
            "Output": "<!DOCTYPE html>\n<html>\n<head>\n<title>W
elcome to nginx!</title>\n<style>\n    body {\n        width:
em;\n        margin:  auto;\n        font-family: Tahoma, Verda
na, Arial, sans-serif;\n    }\n</style>\n</head>\n<body>\n<h1>We
lcome to nginx!</h1>\n<p>If you see this page, the nginx web ser
ver is successfully installed and\nworking. Further configuratio
n is required.</p>\n\n<p>For online documentation and support pl
ease refer to\n<a href=\"http://nginx.org/\">nginx.org</a>.<br/>
\nCommercial support is available at\n<a href=\"http://nginx.com
/\">nginx.com</a>.</p>\n\n<p><em>Thank you for using nginx.</em>
</p>\n</body>\n</html>\n",
            "Start": "2016-11-25T14:35:37.780192565Z"
        }
],
    "Status": "healthy"
}

12> ONBUILD 为他人做嫁衣裳

格式： ONBUILD <其他指令>

ONBUILD是一个特殊的指令，它后面跟的是其它指令，比如RUN , COPY等， 而这些指令，在当前镜像构建时并不会被执行。

只有当以当前镜像为基础镜像，去构建下一级镜像的时候才会被执行。

Dockerfile中的其它指令都是为了定制当前镜像而准备的，唯有 ONBUILD是为了帮助别人定制自己而准备的

假设我们要制作 Node.js 所写的应用的镜像。我们都知道 Node.js 使用 npm进行包管理，所有依赖、配置、启动信息等会放到 package.json文件里。在拿到程序代码后，需要先进行 npm install才可以获得所有需要的依赖。然后就可以通过 npm start来启动应用。

因此，一般来说会这样写Dockerfile :

FROM node:slim
RUN "mkdir /app"
WORKDIR /app
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/
CMD [ "npm", "start" ]

如果有相似的Node.js项目，就复制该Dockerfile。这会导致文件副本越来越多

除此之外，如果开发中发现该Dockerfile存在问题，那么对第一个项目的Dockerfile进行了更改，那么其他相似项目的Dockerfile怎么办

这些情况就可以用ONBUILD进行解决了：

1）首先构建一个基础镜像，这样各个相似的项目就能够使用这个基础镜像，这样就可以对基础镜像进行更新，各个项目不用同步Dockerfile的变化，重新构建后就继承了基础镜像的更新：

FROM node:slim
RUN "mkdir /app"
WORKDIR /app
CMD [ "npm", "start" ]

这里将项目相关的构建指令都拿了出来，放到相应子项目中去。假设上面构建的基础镜像名字为my-node,那么各个子项目中的Dockerfile就变成了：

FROM my-node
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/

基础镜像变化后，各个项目都用这个Dockerfile重新构建镜像，会继承基础镜像的更新。

2）上面只解决了一般的问题，如果子项目中Dockerfile中有东西需要调整怎么办？

比如可能npm install 突然需要添加一些参数，又该怎么办？是不可能将RUN [ "npm", "install" ]写入基础镜像的，难道又要一个个对子项目的Dockerfile进行修改吗？

上面的问题能够使用ONBUILD解决，重新写一下基础镜像的Dockerfile：

FROM node:slim
RUN "mkdir /app"
WORKDIR /app
ONBUILD COPY ./package.json /app
ONBUILD RUN [ "npm", "install" ]
ONBUILD COPY . /app/
CMD [ "npm", "start" ]

这样在构建基础镜像的时候，ONBUILD这三行并不会被执行。然后各个项目的Dockerfile就变成了简单地:

 FROM my-node

当在各个项目目录中，用这个只有一行的 Dockerfile构建镜像时，之前基础镜像的那三行ONBUILD就会开始执行，成功的将当前项目的代码复制进镜像、并且针对本项目执行 npm install，生成应用镜像。

这样，如果想要对RUN [ "npm", "install" ]添加参数 --save时，就不需要到一个个子项目的Dockerfile中去添加--save了，只用在基础镜像的Dockerfile中进行更改即可

13)LABEL

为镜像指定标签

格式：

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

可见一个Dockerfile是可以有多个标签的，如：

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