文件系统作为持久数据结构：一个被低估的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，更是在有策略地运用文件系统快照这一思想，来应对复杂、耗时的自动化流程。对于任何需要长时间运行且步骤间存在依赖的脚本任务，这都是一项值得掌握的技巧。
