深入理解Dockerfile：定制镜像的每一步操作与指令详解

使用Dockerfile订制镜像

从昨天的dockercommit的学习中，我们可以了解到，镜像的订制实际上就是订制每一层所添加的配置、文件。假如我们可以把每一层更改、安装、构建、操作的命令都写入一个脚本，用这个脚本来建立、定制镜像，这么之前提及的难以重复的问题、镜像建立透明性的问题、体积的问题就就会解决。这个脚本就是Dockerfile。

Dockerfile是一个文本文件，其内包含了一条条的指令(Instruction)，每一条指令建立一层，因而每一条指令的内容，就是描述该层应该怎样构筑。

还以之前订制nginx镜像为例，此次我们使用Dockerfile来订制。

在一个空白目录中，构建一个文本文件，并命名为Dockerfile：

$ mkdir mynginx
$ cd mynginx
$ touch Dockerfile

其内容为：

FROM nginx
RUN echo 'Hello, Docker!
' > /usr/share/nginx/html/index.html

这个Dockerfile很简单，一共就两行。涉及到了两条指令，FROM和RUN。

FROM指定基础镜像

所谓订制镜像，那一定是以一个镜像为基础，在其上进行订制。如同我们之前运行了一个nginx镜像的容器，再进行更改一样，基础镜像是必须指定的。而FROM就是指定基础镜像，因而一个Dockerfile中FROM是必备的指令，而且必须是第一条指令。

在DockerHub上有特别多的高质量的官方镜像，有可以直接用来使用的服务类的镜像，如nginx、redis、mongo、mysql、httpd、php、tomcat等；也有一些便捷开发、构建、运行各类语言应用的镜像，如node、openjdk、python、ruby、golang等。可以在其中找寻一个最符合我们最终目标的镜像为基础镜像进行订制。

若果没有找到对应服务的镜像，官方镜像中还提供了一些更为基础的操作系统镜像，如ubuntu、debian、centos、fedora、alpine等，这种操作系统的软件库为我们提供了更宽广的扩充空间。

不仅选择现有镜像为基础镜像外，Docker还存在一个特殊的镜像，名为scratch。这个镜像是虚拟的概念，并不实际存在，它表示一个空白的镜像。

FROM scratch
...

假如你以scratch为基础镜像的话，意味着你不以任何镜像为基础，接出来所写的指令将作为镜像第一层开始存在。

不以任何系统为基础，直接将可执行文件复制进镜像的做法并不罕见，对于Linux下静态编译的程序来说，并不须要有操作系统提供运行时支持，所需的一切库都早已在可执行文件里了，因而直接FROMscratch会让镜像容积愈发精巧。使用Go语言开发的应用好多会使用这些方法来制做镜像，这也是为何有人觉得Go是非常适宜容器微服务构架的语言的诱因之一。

RUN执行命令

RUN指令是拿来执行命令行命令的。因为命令行的强悍能力，RUN指令在订制镜像时是最常用的指令之一。其格式有两种：

RUN echo 'Hello, Docker!
' > /usr/share/nginx/html/index.html

既然RUN如同Shell脚本一样可以执行命令，这么我们是否就可以像Shell脚本一样把每位命令对应一个RUN呢？诸如这样：

FROM debian:stretch
RUN apt-get update
RUN apt-get install -y gcc libc6-dev make wget
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz"
RUN mkdir -p /usr/src/redis
RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1
RUN make -C /usr/src/redis
RUN make -C /usr/src/redis install

之前说过，Dockerfile中每一个指令就会构建一层，RUN也不例外。每一个RUN的行为，就和刚刚我们手工构建镜像的过程一样：新构建一层，在其上执行这种命令，执行结束后，commit这一层的更改，构成新的镜像。

而前面的这些写法，创建了7层镜像。这是完全没有意义的，但是好多运行时不须要的东西，都被装进了镜像里，例如编译环境、更新的软件包等等。结果就是形成十分臃肿、非常多层的镜像，不仅仅降低了建立布署的时间，也很容易出错。这是好多初学Docker的人常犯的一个错误。

UnionFS是有最大层数限制的，例如AUFS，以前是最大不得超过42层，如今是不得超过127层。

里面的Dockerfile正确的写法应当是这样：

FROM debian:stretch
RUN set -x; buildDeps='gcc libc6-dev make wget' 
    && apt-get update 
    && apt-get install -y $buildDeps 
    && wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" 
    && mkdir -p /usr/src/redis 
    && tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 
    && make -C /usr/src/redis 
    && make -C /usr/src/redis install 
    && rm -rf /var/lib/apt/lists/* 
    && rm redis.tar.gz 
    && rm -r /usr/src/redis 
    && apt-get purge -y --auto-remove $buildDeps

首先，之前所有的命令只有一个目的，就是编译、安装redis可执行文件。因而没有必要构建好多层，这只是一层的事情。为此，这儿没有使用好多个RUN一一对应不同的命令，而是仅仅使用一个RUN指令，并使用&&将各个所需命令串联上去。将之前的7层，简化为了1层。在撰写Dockerfile的时侯，要常常提醒自己，这并不是在写Shell脚本，而是在定义每一层该怎么完善。

但是，这儿为了低格还进行了换行。Dockerfile支持Shell类的行尾添加的命令换行形式，以及行首#进行注释的格式。良好的格式，例如换行、缩进、注释等，会让维护、排障更为容易，这是一个比较好的习惯。

据悉，还可以见到这一组命令的最后添加了清除工作的命令，删掉了为了编译建立所须要的软件，清除了所有下载、展开的文件，而且还清除了apt缓存文件。这是很重要的一步，我们之前说过，镜像是多层储存，每一层的东西并不会在下一层被删掉，会仍然跟随着镜像。因而镜像建立时，一定要确保每一层只添加真正须要添加的东西，任何无关的东西都应当清除掉。

好多人初学Docker制做出了很臃肿的镜像的诱因之一linux系统命令，就是忘掉了每一层建立的最后一定要清除掉无关文件。

建立镜像

好了，让我们再回到之前订制的nginx镜像的Dockerfile来。如今我们明白了这个Dockerfile的内容，这么让我们来建立这个镜像吧。

在Dockerfile文件所在目录执行：

$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB

Step 1 : FROM nginx
 ---> e43d811ce2f4
Step 2 : RUN echo 'Hello, Docker!
' > /usr/share/nginx/html/index.html
 ---> Running in 9cdc27646c7b
 ---> 44aa4490ce2c
Removing intermediate container 9cdc27646c7b
Successfully built 44aa4490ce2c

从命令的输出结果中，我们可以清晰的看见镜像的建立过程。在Step2中，就像我们之前所说的那样，RUN指令启动了一个容器9cdccdc2764627646cc77b，执行了所要求的命令，并最后递交了这一层44aa4490cece22c，此后删掉了所用到的这个容器9cdccdc2764627646cc77b。

这儿我们使用了dockerbuild命令进行镜像建立。其格式为：

docker build [选项]

在这儿我们指定了最终镜像的名称-tnginx:v3，建立成功后，我们可以像之前运行nginx:v2那样来运行这个镜像，其结果会和nginx:v2一样。

镜像建立上下文（Context）

假如注意，会听到dockerbuild命令最后有一个.。.表示当前目录，而Dockerfile就在当前目录，因而不少初学者以为这个路径是在指定Dockerfile所在路径，那么理解似乎是不确切的。假如对应里面的命令格式，你可能会发觉，这是在指定上下文路径。这么哪些是上下文呢？

首先我们要理解dockerbuild的工作原理。Docker在运行时分为Docker引擎（也就是服务端守护进程）和顾客端工具。Docker的引擎提供了一组RESTAPI，被称为DockerRemoteAPI，而如docker命令这样的顾客端工具，则是通过这组API与Docker引擎交互，因而完成各类功能。因而，即使表面上我们似乎是在本机执行各类docker功能，但实际上RAR FOR LINUX，一切都是使用的远程调用方式在服务端（Docker引擎）完成。也由于这些C/S设计，让我们操作远程服务器的Docker引擎显得轻而易举。

当我们进行镜像建立的时侯，并非所有订制就会通过RUN指令完成，常常会须要将一些本地文件复制进镜像，例如通过COPY指令、ADD指令等。而dockerbuild命令建立镜像，虽然并非在本地建立，而是在服务端，也就是Docker引擎中建立的。这么在这些顾客端/服务端的构架中，怎么能够让服务端获得本地文件呢？

这就引入了上下文的概念。当建立的时侯，用户会指定建立镜像上下文的路径，dockerbuild命令获知这个路径后，会将路径下的所有内容打包，之后上传给Docker引擎。这样Docker引擎收到这个上下文包后，展开都会获得建立镜像所需的一切文件。

若果在Dockerfile中如此写：

COPY ./package.json /app/

这并不是要复制执行dockerbuild命令所在的目录下的package.json，也不是复制Dockerfile所在目录下的package.json，而是复制上下文（context）目录下的package.json。

因而，COPY这类指令中的源文件的路径都是相对路径。这也是初学者常常会问的为何COPY../package.json/app或则COPY/opt/xxxx/app未能工作的缘由，由于这种路径早已超出了上下文的范围docker hub怎么用，Docker引擎未能获得这种位置的文件。假如真的须要这些文件，应当将它们复制到上下文目录中去。

如今就可以理解刚刚的命令dockerbuild-tnginx:v3.中的这个.，实际上是在指定上下文的目录，dockerbuild命令会将该目录下的内容打包交给Docker引擎以帮助建立镜像。

假如观察dockerbuild输出，我们或许早已听到了这个发送上下文的过程：

$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
...

理解建立上下文对于镜像建立是很重要的，防止犯一些不应当的错误。譬如有些初学者在发觉COPY/opt/xxxx/app不工作后，于是干脆将Dockerfile放在了硬碟根目录去完善，结果发觉dockerbuild执行后，在发送一个几十GB的东西，极为平缓并且很容易建立失败。那是由于这些做法是在让dockerbuild打包整个硬碟，这似乎是使用错误。

通常来说，应当会将Dockerfile放在一个空目录下，或则项目根目录下。假如该目录下没有所需文件，这么应当把所需文件复制一份过来。假如目录下有些东西确实不希望建立时传给Docker引擎，这么可以用.gitignore一样的句型写一个.dockerignore，该文件是用于剔除不须要作为上下文传递给Docker引擎的。

这么为何会有人误以为.是指定Dockerfile所在目录呢？这是由于在默认情况下，假若不额外指定Dockerfile的话，会将上下文目录下的名为Dockerfile的文件作为Dockerfile。

这只是默认行为，实际上Dockerfile的文件名并不要求必须为Dockerfile，但是并不要求必须坐落上下文目录中，例如可以用-f../Dockerfile.php参数指定某个文件作为Dockerfile。

其实，通常你们习惯性的会使用默认的文件名Dockerfile，以及会将其放在镜像建立上下文目录中。

其它dockerbuild的用法直接用Gitrepo进行完善

其实你早已注意到了，dockerbuild还支持从URL打造，例如可以直接从Gitrepo中建立：

# $env:DOCKER_BUILDKIT=0
# export DOCKER_BUILDKIT=0
$ docker build -t hello-world https://github.com/docker-library/hello-world.git#master:amd64/hello-world
Step 1/3 : FROM scratch
 --->
Step 2/3 : COPY hello /
 ---> ac779757d46e
Step 3/3 : CMD ["/hello"]
 ---> Running in d2a513a760ed
Removing intermediate container d2a513a760ed
 ---> 038ad4142d2b
Successfully built 038ad4142d2b

这行命令指定了建立所需的Gitrepo，但是指定分支为master，建立目录为/amd64/hello-world/，之后Docker都会自己去gitclone这个项目、切换到指定分支、并步入到指定目录后开始建立。

用给定的tar压缩包建立

$ docker build http://server/context.tar.gz

假如所给出的URL不是个Gitrepo，而是个tar压缩包，这么Docker引擎会下载这个包docker hub怎么用，并手动解压缩，以其作为上下文，开始建立。

从标准输入中读取Dockerfile进行重构

docker build - < Dockerfile

或

cat Dockerfile | docker build -

假如标准输入传入的是文本文件，则将其视为Dockerfile，并开始建立。这些方式因为直接从标准输入中读取Dockerfile的内容，它没有上下文，因而不可以像其他方式那样可以将本地文件COPY进镜像之类的事情。

从标准输入中读取上下文压缩包进行重构

$ docker build - < context.tar.gz

假如发觉标准输入的文件格式是gzip、bzip2以及xz的话，将会使其为上下文压缩包，直接将其展开，将上面视为上下文，并开始建立。

Hello, Docker!

Hello, Docker!

Hello, Docker!

发表回复