dockerfilephp镜像技巧_docker系列根本课程运用 Dockerfile 定制镜像

文章索引：

1、docker入门之镜像、容器和仓库

2、docker的安装与镜像加速器的配置

3、docker系列根本课程--如何获取镜像、列出镜像和删除镜像

4、docker系列根本课程：利用commit 理解镜像构成

=====================================================

在上面的文章中我们学习了 docker commit，现在可以知道，镜像的定制实际上便是定制每一层所添加的配置、文件。
如果我们可以把每一层修正、安装、构建、操作的命令都写入一个脚本，用这个脚本来构建、定制镜像，那么之前提及的无法重复的问题、镜像构建透明性的问题、体积的问题就都会办理。
这个脚本便是 Dockerfile。

Dockerfile 是一个文本文件，其内包含了一条条的 指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，便是描述该层应该如何构建。

还以之前定制 nginx 镜像为例，这次我们利用 Dockerfile 来定制。

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

$ mkdir mynginx$ cd mynginx$ touch Dockerfile

其内容为：

FROM nginxRUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html

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

FROM 指定根本镜像

所谓定制镜像，那一定因此一个镜像为根本，在其上进行定制。
就像我们之前运行了一个 nginx 镜像的容器，再进行修正一样，根本镜像是必须指定的。
而 FROM 便是指定 根本镜像，因此一个 Dockerfile 中 FROM 是必备的指令，并且必须是第一条指令。

在 Docker Hub 上有非常多的高质量的官方镜像，有可以直接拿来利用的做事类的镜像，如 nginx、redis、mongo、mysql、httpd、php、tomcat 等；也有一些方便开拓、构建、运行各种措辞运用的镜像，如 node、openjdk、python、ruby、golang 等。
可以在个中探求一个最符合我们终极目标的镜像为根本镜像进行定制。

如果没有找到对应做事的镜像，官方镜像中还供应了一些更为根本的操作系统镜像，如 ubuntu、debian、centos、fedora、alpine 等，这些操作系统的软件库为我们供应了更广阔的扩展空间。

除了选择现有镜像为根本镜像外，Docker 还存在一个分外的镜像，名为 scratch。
这个镜像是虚拟的观点，并不实际存在，它表示一个空缺的镜像。

FROM scratch...

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

不以任何系统为根本，直接将可实行文件复制进镜像的做法并不罕见，比如 swarm、etcd。
对付 Linux 下静态编译的程序来说，并不须要有操作系统供应运行时支持，所需的统统库都已经在可实行文件里了，因此直接 FROM scratch 会让镜像体积更加小巧。
利用 Go 措辞 开拓的运用很多会利用这种办法来制作镜像，这也是为什么有人认为 Go 是特殊适宜容器微做事架构的措辞的缘故原由之一。

RUN 实行命令

RUN 指令是用来实行命令行命令的。
由于命令行的强大能力，RUN 指令在定制镜像时是最常用的指令之一。
其格式有两种：

RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.htmlexec 格式：RUN [\"大众可实行文件\公众, \"大众参数1\公众, \"大众参数2\"大众]，这更像是函数调用中的格式。

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

FROM debian:stretchRUN apt-get updateRUN apt-get install -y gcc libc6-dev make wgetRUN wget -O redis.tar.gz \"大众http://download.redis.io/releases/redis-5.0.3.tar.gz\公众RUN mkdir -p /usr/src/redisRUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1RUN make -C /usr/src/redisRUN make -C /usr/src/redis install

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

而上面的这种写法，创建了 7 层镜像。
这是完备没故意义的，而且很多运行时不须要的东西，都被装进了镜像里，比如编译环境、更新的软件包等等。
结果便是产生非常臃肿、非常多层的镜像，不仅仅增加了构建支配的韶光，也很随意马虎出错。
这是很多初学 Docker 的人常犯的一个缺点。

Union FS 是有最大层数限定的，比如 AUFS，曾经是最大不得超过 42 层，现在是不得超过 127 层。

上面的 Dockerfile 精确的写法该当是这样：

FROM debian:stretchRUN 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 制作出了很臃肿的镜像的缘故原由之一，便是忘却了每一层构建的末了一定要清理掉无关文件。

构建镜像

好了，让我们再回到之前定制的 nginx 镜像的 Dockerfile 来。
现在我们明白了这个 Dockerfile 的内容，那么让我们来构建这个镜像吧。

在 Dockerfile 文件所在目录实行：

$ docker build -t nginx:v3 .Sending build context to Docker daemon 2.048 kBStep 1 : FROM nginx ---> e43d811ce2f4Step 2 : RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html ---> Running in 9cdc27646c7b ---> 44aa4490ce2cRemoving intermediate container 9cdc27646c7bSuccessfully built 44aa4490ce2c

从命令的输出结果中，我们可以清晰的看到镜像的构建过程。
在 Step 2 中，犹如我们之前所说的那样，RUN 指令启动了一个容器 9cdc27646c7b，实行了所哀求的命令，并末了提交了这一层 44aa4490ce2c，随后删除了所用到的这个容器 9cdc27646c7b。

这里我们利用了 docker build 命令进行镜像构建。
其格式为：

docker build [选项] <高下文路径/URL/->

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

镜像构建高下文（Context）

如果把稳，会看到 docker build 命令末了有一个 .。
. 表示当前目录，而 Dockerfile 就在当前目录，因此不少初学者以为这个路径是在指定 Dockerfile 所在路径，这么理解实在是不准确的。
如果对应上面的命令格式，你可能会创造，这是在指定 高下文路径。
那么什么是高下文呢？

首先我们要理解 docker build 的事情事理。
Docker 在运行时分为 Docker 引擎（也便是做事端守护进程）和客户端工具。
Docker 的引擎供应了一组 REST API，被称为 Docker Remote API，而如 docker 命令这样的客户端工具，则是通过这组 API 与 Docker 引擎交互，从而完成各种功能。
因此，虽然表面上我们彷佛是在本机实行各种 docker 功能，但实际上，统统都是利用的远程调用形式在做事端（Docker 引擎）完成。
也由于这种 C/S 设计，让我们操作远程做事器的 Docker 引擎变得轻而易举。

当我们进行镜像构建的时候，并非所有定制都会通过 RUN 指令完成，常常会须要将一些本地文件复制进镜像，比如通过 COPY 指令、ADD 指令等。
而 docker build 命令构建镜像，实在并非在本地构建，而是在做事端，也便是 Docker 引擎中构建的。
那么在这种客户端/做事真个架构中，如何才能让做事端得到本地文件呢？

这就引入了高下文的观点。
当构建的时候，用户会指定构建镜像高下文的路径，docker build 命令得知这个路径后，会将路径下的所有内容打包，然后上传给 Docker 引擎。
这样 Docker 引擎收到这个高下文包后，展开就会得到构建镜像所需的统统文件。

如果在 Dockerfile 中这么写：

COPY ./package.json /app/

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

因此，COPY 这类指令中的源文件的路径都是相对路径。
这也是初学者常常会问的为什么 COPY ../package.json /app 或者 COPY /opt/xxxx /app 无法事情的缘故原由，由于这些路径已经超出了高下文的范围，Docker 引擎无法得到这些位置的文件。
如果真的须要那些文件，该当将它们复制到高下文目录中去。

现在就可以理解刚才的命令 docker build -t nginx:v3 . 中的这个 .，实际上是在指定高下文的目录，docker build 命令会将该目录下的内容打包交给 Docker 引擎以帮助构建镜像。

如果不雅观察 docker build 输出，我们实在已经看到了这个发送上下文的过程：

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

理解构建高下文对付镜像构建是很主要的，避免犯一些不应该的缺点。
比如有些初学者在创造 COPY /opt/xxxx /app 不事情后，于是干脆将 Dockerfile 放到了硬盘根目录去构建，结果创造 docker build 实行后，在发送一个几十 GB 的东西，极为缓慢而且很随意马虎构建失落败。
那是由于这种做法是在让 docker build 打包全体硬盘，这显然是利用缺点。

一样平常来说，该当会将 Dockerfile 置于一个空目录下，或者项目根目录下。
如果该目录下没有所需文件，那么该当把所需文件复制一份过来。
如果目录下有些东西确实不肯望构建时传给 Docker 引擎，那么可以用 .gitignore 一样的语法写一个 .dockerignore，该文件是用于剔除不须要作为高下文通报给 Docker 引擎的。

那么为什么会有人误以为 . 是指定 Dockerfile 所在目录呢？这是由于在默认情形下，如果不额外指定 Dockerfile 的话，会将高下文目录下的名为 Dockerfile 的文件作为 Dockerfile。

这只是默认行为，实际上 Dockerfile 的文件名并不哀求必须为 Dockerfile，而且并不哀求必须位于高下文目录中，比如可以用 -f ../Dockerfile.php 参数指定某个文件作为 Dockerfile。

当然，一样平常大家习气性的会利用默认的文件名 Dockerfile，以及会将其置于镜像构建高下文目录中。

其它 docker build 的用法

直接用 Git repo 进行构建

或许你已经把稳到了，docker build 还支持从 URL 构建，比如可以直接从 Git repo 中构建：

$ docker build https://github.com/twang2218/gitlab-ce-zh.git#:11.1Sending build context to Docker daemon 2.048 kBStep 1 : FROM gitlab/gitlab-ce:11.1.0-ce.011.1.0-ce.0: Pulling from gitlab/gitlab-ceaed15891ba52: Already exists773ae8583d14: Already exists...

这行命令指定了构建所需的 Git repo，并且指定默认的 master 分支，构建目录为 /11.1/，然后 Docker 就会自己去 git clone 这个项目、切换到指定分支、并进入到指定目录后开始构建。

用给定的 tar 压缩包构建

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

如果所给出的 URL 不是个 Git repo，而是个 tar 压缩包，那么 Docker 引擎会下载这个包，并自动解压缩，以其作为高下文，开始构建。

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

docker build - < Dockerfile

或

cat Dockerfile | docker build -

如果标准输入传入的是文本文件，则将其视为 Dockerfile，并开始构建。
这种形式由于直接从标准输入中读取 Dockerfile 的内容，它没有高下文，因此不可以像其他方法那样可以将本地文件 COPY 进镜像之类的事情。

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

$ docker build - < context.tar.gz

如果创造标准输入的文件格式是 gzip、bzip2 以及 xz 的话，将会使其为高下文压缩包，直接将其展开，将里面视为高下文，并开始构建。