Docker文件系统优化策略与实战

在本文中，我们来实战构建一个Docker镜像，然后实例化容器，在Docker的生命周期中详细分析一下Docker的文件存储情况和DockerFile优化策略。

附：docker yum快速安装和命令大全

在开始实战之前，我们先介绍一个概念，联合文件系统（Union File System）。联合文件系统是实现Docker镜像的技术基础，支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下。镜像的分层存储和继承就是基于此特性实现。

下面是Docker官方的一张描述文件系统的图片，显示了一张联合文件系统在串联镜像层和容器层起到的作用

Docker支持多种联合文件系统，常见的有aufs，deviceMapper，overlay，overlay2，本文章中使用的系统版本为debian9.1，Docker版本为17.06.2-ce，默认使用是overlay2。

看到这里如果你已经对Docker文件系统有了简单的概念，那么让我们开始实战，来对分层文件系统的存储方式进行更加深入的了解。

镜像层

这是一个云信私有化项目中基于debian系统镜像创建的jdk8基础镜像，为了方便阅读和分析，我们Dockerfile进行了一些精简，只保留核心部分内容

FROM hub.c.163.com/library/debian:stretch
MAINTAINER nim
#下载jdk
ADD http://10.173.11.100/nim/jdk-8u202-linux-x64.tar.gz /usr/local/nim/
#解压jdk并删除
RUN tar -xzvf /usr/local/nim/jdk-8u202-linux-x64.tar.gz -C /usr/local/nim/ \
&& rm /usr/local/nim/jdk-8u202-linux-x64.tar.gz
#设置环境变量
ENV JAVA_HOME=/usr/local/nim/jdk1.8.0_202
ENV PATH=$JAVA_HOME/bin:$PATH
CMD ["/bin/bash"]

根据构建镜像，查看构建结果，原基础镜像100M，构建后镜像体积697M。

镜像存储

现在开始看一下构建镜像工作在文件层存储情况。首先我们使用Docker history查看一下刚刚构建镜像情况，可以看到基础镜像占用100M，两个镜像分层占用194MB和403M。

接下来我们看查看一下文件系统中的存储情况，本环境使用overlay2，Docker镜像层存储默认路径为/var/lib/Docker/overlay2/，可以看到镜像存储目录下有4个目录，其中110M的对应是基础镜像，另外两个为ADD JDK（186M）和解压JDK压缩包的镜像分层（389M）。

其中的l目录包含了所有层的软连接，软链接使用短名称，避免mount时候参数达到页面大小限制。

下面我们了解一下，每个分层中的文件内容。基础镜像分层包含diff文件夹和link文件，diff文件夹中存放当前分层内容，link文件记录短名称。

接下来看一下COPY JDK生成的内容，diff文件夹保存了jdk压缩包，本层相比基础镜像层，多了lower，merged，work三个文件/文件夹，其中lower记录了此层的下层ID（基础镜像层），merged目录作为提供了统一视图，在容器层读写层被使用，work目录用于联合挂载指定的工作目录，使用过程对用户不可见。

解压JDK层的文件夹结构内容和上一层类似，主要关注jdk压缩包占用空间为0，表示已被删除。

现在来重点关注一个问题，镜像大小等于所有分层相加，在后续分层中被删除的jdk压缩包仍然要占用存储空间，这并不是我们原本意图，因此这里就出现了镜像文件进行优化的点。优化后的Dockerfile如下

FROM hub.c.163.com/library/debian:stretch
MAINTAINER nim
RUN curl -o /usr/local/nim/jdk-8u202-linux-x64.tar.gz http://10.173.11.100/nim/jdk-8u202-linux-x64.tar.gz \
&& tar -xzvf /usr/local/nim/jdk-8u202-linux-x64.tar.gz -C /usr/local/nim/ \
&& rm /usr/local/nim/jdk-8u202-linux-x64.tar.gz \
&& export JAVA_HOME=/usr/local/nim/jdk1.8.0_202 \
&& export PATH=$JAVA_HOME/bin:$PATH
CMD ["/bin/bash"]

借这个优化后的内容，我们再谈一下构建Docker镜像时在时间和空间可优化的点：

1. 组合运行语句：合并相同类型构建语句，可以有效减少镜像分层；
2. 利用镜像构建缓存：时间同步，基础软件安装等固定内容在镜像前部分处理，镜像重新构建时会使用缓存，节省时间；
3. 清理中间产物：注意安装过程中使用的软件和压缩包在一定要同一层里清理，否则仍然会占用镜像空间；
4. 构建语句优化：比如ADD在处理本地文件时可以直接解压缩，起到COPY + RUN tar的作用；
5. 优化基础镜像源：国内高校和大型IT企业都有创建镜像站，选择一个稳定更新及时的镜像站可以有效缩短构建时间；

举例的镜像中优化策略涉及1,3条，用curl替代add，与解压和删除合并为一层，Dockerfile减少了层数，清理中间过程的jdk安装包，下图是优化后镜像体积变化：

构建镜像真的是层数越少越好吗？当然不是这么绝对，尤其在早期镜像版本不是很稳定或是后续迭代比较频繁时，合理的镜像分层会减少编译时间，降低出错概率，也可以让Dockerfile更具有可读性。可以再稳定版本形成之后对镜像进行二次优化。

镜像元数据

分析一个镜像元数据我们主要关注三个目录

/var/lib/Docker/image/overlay2/imaged/
/var/lib/Docker/image/overlay2/layerdb/
/var/lib/Docker/overlay2/

第一个目录保存镜像基础元数据，第二个目录保存镜像分层元数据，第三个是上文提到的分层存储目录，保存实际分层内容。下面就根据实际情况来看一下，元数据与存储信息是如何关联起来的。

Docker镜像的基本信息保存在/var/lib/Docker/image/overlay2/imaged/content/sha256/下面，可以根据Docker image ID在此目录下查找到对应ID开头文件。此文件中以json的形式保存了该镜像的分层文件系统、构建信息、相关容器等内容。

第二个目录/var/lib/Docker/image/overlay2/layerdb/sha256/保存分层元数据，每一个分层元数据目录下有cache-id，diff，size信息，其中cache-id对应分层存储层，diff关联镜像基础元数据信息。

容器层

首先我们来启动一个容器，挂载宿主机/opt/yunxin目录到容器/usr/local/yunxin目录