在Docker中构建长时间运行的脚本的一些方法

文件系统作为持久数据结构：一个被低估的Docker实战技巧

今天要分享的，是一个关于Docker相当实用的应用场景。先别急着认为这又是一篇泛泛而谈Docker优点的文章，咱们的重点其实在于，如何把文件系统本身当作一个可持久化的数据结构来用。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

所以，这篇文章的核心思路，并不仅限于Docker或AUFS。它同样适用于其他具有写时复制特性的文件系统，比如BTRFS和ZFS。

问题：痛点在哪儿？

让我们从一个具体的痛点开始。我遇到一个需要长时间运行的构建脚本，里面步骤繁多：

• 完整跑一遍，得花上一到两个小时。
• 过程中需要从网络下载数百兆的大型文件。
• 后期的构建步骤，又严重依赖于前期生成的库文件。

最让人头疼的，莫过于那漫长的等待时间。一次失败，就意味着要推倒重来，这成本太高了。

文件系统：被忽视的状态机

我们平时和文件系统打交道，基本是一种“有状态”的交互模式：添加、删除、修改文件或权限。大多数独立操作确实可以撤销，比如把移走的文件移回来。但想要将整个工作环境精准地回退到几小时前的某个时间点？这就不是常规操作能轻松解决的了。而这，恰恰是快照技术可以大显身手的地方。

联合文件系统的快照魔法

Docker底层使用的AUFS（或类似的联合文件系统），实现了一种叫做Union Mount的技术。简单来说，它能把多个文件系统的目录像叠罗汉一样，“叠加”成一个统一的视图。底层文件是只读的，任何修改都发生在最上层的可写层。在Docker里，每一层文件系统都被称为一个“层”。

这种分层结构，天然就适合做快照。每一次提交，本质上就是创建了一个包含之前所有层的、新的联合挂载点。

用快照重构构建流程

那么，如何利用快照来“拯救”冗长的构建脚本呢？核心思路是：化整为零。

与其让一个庞大的脚本一跑到底，不如把它拆分成多个独立的小脚本单元。每成功运行完一个单元，就拍下一张文件系统的“快照”（Docker在构建镜像时会自动完成这一步）。如果下一个单元运行失败，你完全可以立刻回滚到上一个成功的快照点，调整后重试，而无需从头开始。

想象一下：在没有快照的传统模式下，苦等一个半小时后构建报错，除了极有耐心的人，谁还想从头再来？你当然可以尝试手动清理，比如删除目录或执行make clean，但对于复杂的构建过程，谁能保证完全清楚它把文件散落到了系统的哪个角落？真正可靠的“后悔药”，只有快照。

实战：用Docker快照构建GHC交叉编译器

接下来，就以我构建GHC 7.8.3 ARM交叉编译器的实际经历为例，看看Docker如何具体应用。必须承认，Docker非常适合这项任务，但实践过程中也遇到一些需要变通之处。为了将总开发时间降到最低，有些做法看起来可能不那么“优雅”，却很必要。完整的构建脚本可以在[此处找到]。

用Dockerfile构建

Docker通过读取Dockerfile中的指令来构建镜像。我的脚本主要用到WORKDIR、ADD和RUN。ADD指令特别有用，它允许你在运行命令前，将宿主机的文件添加到镜像的文件系统中。你可以看到，整个构建流程就是由一系列这样的小脚本单元组成的。

关键设计点

1. 在RUN之前，才ADD对应的脚本

如果你一开始就把所有小脚本都ADD进Dockerfile，可能会遇到麻烦：当某个脚本出错，你修改后重新运行docker build，却发现Docker从第一次添加这个脚本的地方就开始重建了！这会浪费大量时间，完全违背了使用快照的初衷。

问题出在Docker的构建缓存机制。Docker会对比当前指令和已存在的中间镜像。对于ADD指令，它不仅检查指令本身，还会检查被添加文件的内容哈希。只要文件内容有变动，Docker就必须从这里重新构建，因为它无法预知这个改动会带来什么影响。

另外，对于RUN指令，要确保它每次执行对文件系统的更改是可预期的、一致的。我采取的做法是，在脚本里下载文件时，总是指定确定的版本和MD5校验值。

2. 慎用ENV设置变量，优先使用脚本文件

用ENV指令来设置环境变量看起来很方便，但它不支持变量替换。例如，ENV BASE=$HOME/base最终会把BASE的值设为字面字符串“$HOME/base”，这通常不是我们想要的。

我的替代方案是：使用ADD命令添加一个如set-env.sh的环境变量设置文件，然后在后续的每个脚本单元里引用它。

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

你可能会问：如果set-env.sh需要修改怎么办？它不是早就被ADD了吗？修改它会不会导致后面的快照失效？

问得好，这确实是个实际问题。在开发中，我就遇到过需要往环境变量文件里添加新变量的情况。我的解决方法是：创建一个新的文件set-env-1.sh，其内容包含：

THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env.sh
# 添加新的环境变量或逻辑
if ! [ -e "$CONFIG_SUB_SRC/config.sub" ] ; then
  CONFIG_SUB_SRC=${CONFIG_SUB_SRC:-$NCURSES_SRC}
fi

然后让之后的所有脚本单元改为包含这个新文件。当然，在脚本最终定型后，完全可以回头重构，但这么做在开发阶段确实能避免从头开始的噩梦。

需要注意的缺点

这种方法一个明显的缺点是，最终生成的镜像体积会比实际需要的大。尤其如果构建过程后期删除了大量中间文件，这些被删除的文件其实仍然存在于联合文件系统的底层中，只是被上层“遮盖”了，导致整个镜像体积虚胖。

不过，有一个折中的办法：

• 先使用docker export命令将最终成功的容器导出为一个tar包。
• 然后，基于一个精简的基础镜像，创建一个新的Dockerfile，只用ADD指令将这个tar包的内容添加进去。

这样一来，就能得到一个尽可能小的、干净的交付镜像。

总结

这种基于快照的增量式构建方法，优点主要体现在两个方面：

• 极大缩短开发周期：你不需要为已经成功的构建步骤反复等待。注意力可以完全聚焦在出问题的环节，实现快速迭代。
• 显著提升脚本可维护性：构建总会因为各种原因失败，但只要Dockerfile的逻辑是逐层递进的，你至少永远拥有一个可以回退的“安全层”，而不必每次都从零开始。

说到底，这不仅仅是在用Docker，更是在有策略地运用文件系统快照这一思想，来应对复杂、耗时的自动化流程。对于任何需要长时间运行且步骤间存在依赖的脚本任务，这都是一项值得掌握的技巧。