我想我已经找到了一个非常不错的Docker使用案例。你是不是会觉得这是一篇写Docker有多好多好的文章，开始之前我想和你确认，这篇文章会介绍如何把文件系统作为持久性的数据结构。
因此，这篇文章的见解同样适用于其他的 copy-on-write文件系统，如BTRFS和ZFS。
问题让我们从这个我试图解决的问题开始。我开发了一个会运行很长时间的构建脚本，这个脚本中包含了很多的步骤。
这个脚本会运行1-2个小时。
它会从网络下载比较大的文件（超过300M）。
后面的构建步骤依赖前期构建的库。
但最最烦人的是，运行这个脚本真的需要花很长的时间。
文件系统是固有状态我们一般是通过一种有状态的方式与文件系统进行交互的。我们可以添加、删除或移动文件。我们可以修改文件的 权限或者它的访问时间。大部分独立的操作都可以撤销，例如将文件移动到其它地方后，你可以将文件恢复到原来的位置。但我们不会通过快照的方式来将它恢复到 原始状态。这篇文章我将会介绍如何在耗时较长的脚本中充分利用快照这一特性。
使用联合文件系统的快照Docker使用的是联合文件系统叫做AUFS（译者注：简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统）。联合文件系统实现了Union mount。顾名思义，也就是说不同的文件系统的文件和目录可以分层叠加在单个连贯文件系统之上。这是通过分层的方式完成的。如果一个文件出现在两个文件系统，那最高层级的文件才会显示（该文件其它版本也是存在于层级中的，不会改变，只是看不到的）。
在Docker中，每一个在Union mount转哦给你的文件系统都被称为layers（层）。使用这种技术可以轻松实现快照，每个快照都是所有层的一个Union mount。
生成脚本的快照使用快照可以帮助构建一个长时运行的脚本。总的想法是，将一个大的脚本分解为许多小的脚本（我喜欢称之为 scriptlets），并单独运行这些小的脚本，脚本运行后为其文件系统打一个快照 （Docker会自动执行此操作）。如果你发现一个scriptlet运行失败，你可以快速回退到上次的快照，然后再试一次。一旦你完成脚本的构建，并且 可以保证脚本能正常工作，那你就可以将它分配给其它主机。
回过头来再对比下，如果你没有使用快照功能了？当你辛辛苦苦等待了一个半小时后，脚本却构建失败了，我想除了少部分有耐心的人外，很多人是不想再来一次了，当然，你也会尽最大努力把系统恢复到失败前的状态，比如可以删除一个目录或运行make clean。
但是，我们可能没有真正地理解我们正在构建的组件。它可能有复杂的Makefile，它会把把文件放到文件系统中我们不知道的地方，唯一真正确定的途径是恢复到快照。
使用快照构建脚本的Docker在本节中，我将介绍我是如何使用Docker实现GHC7.8.3 ARM交叉编译器的构建脚本。Docker非常适合做这件事，但并非完美。我做了很多看起来没用的或者不雅的事情，但都是必要的，这都是为了保证将开发脚本的总时间降到最低限度。构建脚本可以在这里找到。
用Dockerfile构建Docker通过读取Dockerfile来构建镜像。Dockerfile会通过一些命令来具体指定应该执行哪些动作。具体使用说明可以参考这篇文章。在我的脚本中主要用到WORKDIR、ADD和RUN。ADD命令非常有用因为它可以让你在运行之前将外部文件添加到当前Docker镜像中然后转换成镜像的文件系统。你可以在这里看到很多scriptlets构成的构建脚本。
设计1. 在RUN之前ADD scriptlets
如果你很早就将所有的scriptletsADD在Dockerfile，您可能会遇到以下问题：如果你的脚本构建失败，你回去修改scriptlet并再次运行docker build。但是你发现，Docker开始在首次加入scriptlets的地方构建！这样做会浪费了大量的时间并且违背了使用快照的目的。
出现这种情况的原因是由于Docker处理它的中间镜像（快照）的方式。当Docker通过Dockerfile构建镜像时，它会与中间镜像比较当前命令是否一致。然而，在ADD命令的情况下被装进镜像的文件里的内容也会被检查。如果相对于现有的中间镜像，文件已经改变，那么Docker也别无选择，只能从这点开始建立一个新的镜像。因为Docker不知道这些变化会不会影响到构建。