如何使用Docker构建运行时间较长的脚本

共计 3276 个字符，预计需要花费 9 分钟才能阅读完成。

让我们从这个我试图解决的问题开始。我开发了一个会运行很长时间的构建脚本，这个脚本中包含了很多的步骤。这个脚本会运行 1 - 2 个小时。它会从网络下载比较大的文件（超过 300M）。后面的构建步骤依赖前期构建的库。但最最烦人的是，运行这个脚本真的需要花很长的时间。

我们一般是通过一种有状态的方式与文件系统进行交互的。我们可以添加、删除或移动文件。我们可以修改文件的 权限或者它的访问时间。大部分独立的操作都可以撤销，例如将文件移动到其它地方后，你可以将文件恢复到原来的位置。但我们不会通过快照的方式来将它恢复到 原始状态。这篇文章我将会介绍如何在耗时较长的脚本中充分利用快照这一特性。

Docker 使用的是联合文件系统叫做 AUFS（译者注：简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统）。联合文件系统实现了 Union mount。顾名思义，也就是说不同的文件系统的文件和目录可以分层叠加在单个连贯文件系统之上。这是通过分层的方式完成的。如果一个文件出现在两个文件系统，那最高层级的文件才会显示（该文件其它版本也是存在于层级中的，不会改变，只是看不到的）。

在 Docker 中，每一个在 Union mount 转哦给你的文件系统都被称为 layers（层）。使用这种技术可以轻松实现快照，每个快照都是所有层的一个 Union mount。

使用快照可以帮助构建一个长时运行的脚本。总的想法是，将一个大的脚本分解为许多小的脚本（我喜欢称之为 scriptlets），并单独运行这些小的脚本，脚本运行后为其文件系统打一个快照（Docker 会自动执行此操作）。如果你发现一个 scriptlet 运行失败，你可以快速回退到上次的快照，然后再试一次。一旦你完成脚本的构建，并且 可以保证脚本能正常工作，那你就可以将它分配给其它主机。

回过头来再对比下，如果你没有使用快照功能了？当你辛辛苦苦等待了一个半小时后，脚本却构建失败了，我想除了少部分有耐心的人外，很多人是不想再来一次了，当然，你也会尽最大努力把系统恢复到失败前的状态，比如可以删除一个目录或运行 make clean。

但是，我们可能没有真正地理解我们正在构建的组件。它可能有复杂的 Makefile，它会把把文件放到文件系统中我们不知道的地方，唯一真正确定的途径是恢复到快照。

在本节中，我将介绍我是如何使用 Docker 实现 GHC7.8.3 ARM 交叉编译器的构建脚本。Docker 非常适合做这件事，但并非完美。我做了很多看起来没用的或者不雅的事情，但都是必要的，这都是为了保证将开发脚本的总时间降到最低限度。构建脚本可以在这里找到。

Docker 通过读取 Dockerfile 来构建镜像。Dockerfile 会通过一些命令来具体指定应该执行哪些动作。具体使用说明可以参考这篇文章。在我的脚本中主要用到 WORKDIR、ADD 和 RUN。ADD 命令非常有用因为它可以让你在运行之前将外部文件添加到当前 Docker 镜像中然后转换成镜像的文件系统。你可以在这里看到很多 scriptlets 构成的构建脚本。

如果你很早就将所有的 scriptletsADD 在 Dockerfile，您可能会遇到以下问题：如果你的脚本构建失败，你回去修改 scriptlet 并再次运行 docker build。但是你发现，Docker 开始在首次加入 scriptlets 的地方构建！这样做会浪费了大量的时间并且违背了使用快照的目的。

出现这种情况的原因是由于 Docker 处理它的中间镜像（快照）的方式。当 Docker 通过 Dockerfile 构建镜像时，它会与中间镜像比较当前命令是否一致。然而，在 ADD 命令的情况下被装进镜像的文件里的内容也会被检查。如果相对于现有的中间镜像，文件已经改变，那么 Docker 也别无选择，只能从这点开始建立一个新的镜像。因为 Docker 不知道这些变化会不会影响到构建。

此外，使用 RUN 命令要注意，每次运行时它都会导致文件系统有不同的更改。在这种情况下，Docker 会发现中间镜像并使用它，但是这将是错误的。RUN 命令每次运行时会造成文件系统相同的改变。举个例子，我确保在我的 scriptlets 我总是下载了一个已知版本的文件与一个特定 MD5 校验。

对 Docker 构建缓存更详细的解释可以在这里 ”https://docs.docker.com/articles/dockerfile_best-practices/#build-cache” 找到。

它似乎看起来很有诱惑力：使用 ENV 命令来设置所有构建脚本需要的环境变量。但是，它不支持变量替换的方式，例如 ENV BASE=$HOME/base 将设置 BASE 的值为 $HOME/base 着很可能不是你想要的。

相反，我用 ADD 命令添加一个名为 set-env.sh 文件。此文件会包含在后续的 scriptlet 中：

1.THIS_DIR="$(cd"$( dirname "${BASH_SOURCE[0]}" )"&& pwd )"
2.source $THIS_DIR/set-env-1.sh

如果你没有在第一时间获取 set-env.sh 会怎么样呢？它很早就被加入 Dockerfile 并不意味着修改它将会使随后的快照无效？

是的，这会有问题。在开发脚本时，我发现，我已经错过了在 set-env.sh 添加一个有用的环境变量。解决方案是创建一个新的文件 set-env-1.sh 包含：

1.THIS_DIR="$(cd"$( dirname "${BASH_SOURCE[0]}" )"&& pwd )"
2.source $THIS_DIR/set-env.sh
3.if ! [-e "$CONFIG_SUB_SRC/config.sub"] ; then
4.CONFIG_SUB_SRC=${CONFIG_SUB_SRC:-$NCURSES_SRC}
5.fi

然后，在所有后续的 scriptlets 文件中包含了此文件。现在，我已经完成了构建脚本，我可以回去解决这个问题了，但是，在某种意义上，它会破坏最初的目标。我将不得不从头开始运行构建脚本看看这种变化是否能成功。

一个主要缺点是这种方法是，所构建的镜像尺寸是大于它实际需求的尺寸。在我的情况下尤其如此，因为我在最后删除了大量文件的。然而，这些文件都仍然存在于联合挂载文件系统的底层文件系统内，所以整个镜像是大于它实际需要的大小至少多余的是删除文件的大小。

然而，有一个变通。我没有公布此镜像到 Docker Hub Registry。相反，我：
•使用 docker export 导出内容为 tar 文件。
•创建一个新的 Dockerfile 简单地添加了这个 tar 文件的内容。
产生尺寸尽可能小的镜像。

这种方法的优点是双重的：
•它使开发时间降至最低，不再做那些已经构建成功的子组件。你可以专注于那些失败的组件。
•这非常便于维护构建脚本。构建可能会失败，但只要你搞定 Dockerfiel，至少你不必再从头开始。

此外，正如我前面提到的 Docker 不仅使写这些构建脚本更加容易，有了合适的工具同样可以在任何提供快照的文件系统实现。

via: http://lambdalog.seanseefried.com
作者：Lambdalog 译者：田浩本文由 Linux 中国 荣誉推出

阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年，有高配

腾讯云新客低至 82 元 / 年，老客户 99 元 / 年

代金券：在阿里云专用满减优惠券