》中介绍了镜像分层、写时复制以及内容寻址存储(content-addressable storage)等技术特性，为了支持这些特性，docker 设计了一套镜像元数据管理机制来管理镜像元数据。另外，为了能够让 docker 容器适应不同平台不同应用场景对存储的要求，docker 提供了各种基于不同文件系统实现的存储驱动来管理实际镜像文件。
/repositories.json 中，下图显示了 docker 使用 aufs 存储驱动时 repositories.json 文件的路径：
当前 docker 默认采用 SHA256 算法根据镜像元数据配置文件计算出镜像 ID。上图中的两条记录本质上是一样的，第二条记录和第一条记录指向同一个镜像 ID。其中 sha256:c8c275751219dadad8fa56b3ac41ca6cb22219ff117ca98fe82b42f24e1ba64e 被称为镜像的摘要，在拉取镜像时可以看到它：
我们也可以直接指定一个镜像的摘要进行 pull 操作：
其中构建镜像的历史信息和 rootfs 组成部分除了具有描述镜像的作用外，还将镜像和构成该镜像的镜像层关联了起来。Docker 会根据历史信息和 rootfs 中的 diff_ids 计算出构成该镜像的镜像层的存储索引 chainID，这也是 docker 1.10 镜像存储中基于内容寻址的核心技术。/imagedb/content/sha256/
452a96d81c30a1e426bc250428263ac9ca3f47c9bf086f876d11cb39cf57aeec 就是镜像的ID。其内容如下(简洁起见，省略中间大部分的内容)：
，进而获取每一个镜像层的文件内容。注意，每个 diff_id 对应一个镜像层。上面的 diff_id 的排列也是有顺序的，从上到下依次表示镜像层的最低层到最顶层：
/layerdb/sha256/
/layerdb/mounts/
。在 Linux 环境下，mountID 是随机生成的并保存在 mountedLayer 的元数据 mountID 中，持久化在 image/aufs/layserdb/mounts/
-init 命名的文件夹作为最后一层只读层，这个文件夹用于挂载并重新生成如下代码段所列的文件：接下来我们统一观察 mnt 对应的 mountID 下的变化。
