Dockerfile指令详解上

COPY复制文件指令

和RUN命令一样，COPY命令也有两种格式，一种类似与命令行，一种类似与函数调用，命令格式如下：

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

COPY将构建上下文中目录中的文件或则目录复制到复制到镜像内的目录位置中。比如：

COPY data.json /opt/data/

原路径可以有多个，甚至是通配符，但是通配符要符合GO语言的通配符规范，比如：

COPY data* /mydir/
COPY dat?.txt /mydir/

<目标路径> 可以是容器内的绝对路径，也可以是相对于工作目录的相对路径（工作目录可以用 WORKDIR 指令来指定）。目标路径不需要事先创建，如果目录不存在会在复制文件前先行
创建缺失目录。还需要注意一点，使用 COPY 指令，源文件的各种元数据都会保留。比如读、写、执行权限、文件变更时间等。这个特性对于镜像定制很有用。特别是构建相关文件都在使用 Git进行管理的时候。

ADD更高级的复制文件指令

ADD 指令和 COPY 的格式和性质基本一致。但是在 COPY 基础上增加了一些功能。比如 <源路径> 可以是一个 URL ，这种情况下，Docker 引擎会试图去下载这个链接的文件放到 <目标路径> 去。下载后的文件权限自动设置为 600 ，如果这并不是想要的权限，那么还需要增加额外的一层 RUN 进行权限调整，另外，如果下载的是个压缩包，需要解压缩，也一样还需要额外的一层 RUN 指令进行解压缩。所以不如直接使用 RUN 指令，然后使用 wget 或者 curl 工具下载，处理权限、解压缩、然后清理无用文件更合理。因此，这个功能其实并不实用，而且不推荐使用。

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

在某些情况下，这个自动解压缩的功能非常有用，比如官方镜像 ubuntu 中：

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

但在某些情况下，如果我们真的是希望复制个压缩文件进去，而不解压缩，这时就不可以使
用 ADD 命令了。适合使用 ADD 的场合，就是所提及的需要自动解压缩的场合。

另外需要注意的是， ADD 指令会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。因此在 COPY 和 ADD 指令中选择的时候，可以遵循这样的原则，所有的文件复制均使用COPY 指令，仅在需要自动解压缩的场合使用 ADD 。

CMD容器启动命令

CMD 指令的格式和 RUN 相似，也是两种格式：

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

之前介绍容器的时候曾经说过，Docker 不是虚拟机，容器就是进程。既然是进程，那么在启动容器的时候，需要指定所运行的程序及参数。 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"]

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

比如执行下面的命令:

CMD service httpd start

启动的时候会发现容器执行后就立马退出了这是因为没有搞明白前台，后台的概念，没有区分容器和虚拟机的差异，依旧以虚拟机的角度去理解容器。对于容器而言，其启动程序就是容器应用进程，容器就是为了主进程而存在的，主进程退出，容器就失去了存在的意义，从而退出，其它辅助进程不是它需要关心的东西。上面的例子中实际上是以upstart来以后台守护进程的方式启动httpd，而上面的命令在实际的执行中会变为 CMD ["sh","-c","service httpd start"],实际上主进程是sh，当命令运行结束后，主进程就退出了，自然就会令容器退出。

正确的做法是直接执行 httpd 可执行文件，并且要求以前台形式运行。比如：

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

ENTRYPOINT 入口点

ENTRYPOINT 的格式和 RUN 指令格式一样，分为 exec 格式和 shell 格式。ENTRYPOINT 的目的和 CMD 一样，都是在指定容器启动程序及参数。 ENTRYPOINT 在运行时也可以替代，不过比 CMD 要略显繁琐，需要通过 docker run 的参数 --entrypoint 来指定。

当指定了 ENTRYPOINT 后， CMD 的含义就发生了改变，不再是直接的运行其命令，而是将CMD 的内容作为参数传给 ENTRYPOINT 指令，换句话说实际执行时，将变为：

<ENTRYPOINT> "<CMD>"

那么有了 CMD 后，为什么还要有 ENTRYPOINT 呢？这种 "" 有什么好处么？让我们来看几个场景。

场景一：让镜像变成像命令一样使用

假设我们需要一个得知自己当前公网 IP 的镜像，那么可以先用 CMD 来实现：

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" ]

假如我们使用 docker build -t myip . 来构建镜像的话，如果我们需要查询当前公网 IP，只需要执行:

sudo docker run myip

这么看起来好像可以直接把镜像当做命令使用了，不过命令总有参数，如果我们希望加参数呢?这时候可以使用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 就是新的 CMD ，因此会作为参数传给 curl ，从而达到了我们预期的效果。

场景二：应用运行前的准备工作

启动容器就是启动主进程，但有些时候，启动主进程前，需要一些准备工作。比如 mysql 类的数据库，可能需要一些数据库配置、初始化的工作，这些工作要在最终的mysql 服务器运行之前解决。此外，可能希望避免使用 root 用户去启动服务，从而提高安全性，而在启动服务前还需要以 root 身份执行一些必要的准备工作，最后切换到服务用户身份启动服务。或者除了服务外，其它命令依旧可以使用 root 身份执行，方便调试等。这种情况下，可以写一个脚本，然后放入 ENTRYPOINT 中去执行，而这个脚本会将接到的参数（也就是 ）作为命令，在脚本最后执行。比如官方镜像 redis 中就是这么做的：

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

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

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

该脚本的内容就是根据 CMD 的内容来判断，如果是 redis-server 的话，则切换到 redis用户身份启动服务器，否则依旧使用 root 身份执行。

ENV 设置环境变量

ENV指令的格式有两种：

• ENV
• ENV = =...

这个指令很简单，就是设置环境变量而已，无论是后面的其它指令，如 RUN ，还是运行时的
应用，都可以直接使用这里定义的环境变量。

ENV命令的换行使用'' 如果key或则value有空格的话使用""包括起来

定义了环境变量，那么在后续的指令中，就可以使用这个环境变量。使用环境变量使用$符号即可。

下列指令可以支持环境变量展开：

ADD 、 COPY 、 ENV 、 EXPOSE 、 LABEL 、 USER 、 WORKDIR 、 VOLUME 、STOPSIGNAL 、 ONBUILD 。

可以从这个指令列表里感觉到，环境变量可以使用的地方很多，很强大。通过环境变量，我
们可以让一份 Dockerfile 制作更多的镜像，只需使用不同的环境变量即可。

ARG 构建参数

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

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

Dockerfile 中的 ARG 指令是定义参数名称，以及定义其默认值。该默认值可以在构建命令
docker build 中用 --build-arg <参数名>=<值> 来覆盖。

未完待续