转载请注明出处 https://www.cnblogs.com/majianming/p/9536975.html
在每执行一个命令时，便会commit形成一个层，最后形成堆栈式的结构。最后的镜像是各个分层按照顺序堆叠起来的结果。
其中镜像层的内容并不能被之后的命令修改，也就是一个层的文件都是只读的，如果需要修改文件，那么只是在顶端添加一层，然后在最上一层添加修改之后的文件，并对上层屏蔽修改之前的文件，修改之前的文件仍然原样存在原本的层中。
比如接下来的场景，使用了wget下载了nginx并解压（忽略编译等步骤），然后删除
RUN wget --no-check-certificate -O /tmp/nginx-1.15.2.tar.gz http://nginx.org/download/nginx-1.15.2.tar.gz
RUN cd /tmp/ && tar zxf nginx-1.15.2.tar.gz
RUN rm nginx-1.15.2.tar.gz
原本看起来没有什么不正确，先看nginx-1.10.2.tar.gz，解压后的压缩文件应该删除是没有错的，但是按照上面说的，这样的删除实际上是没有用的，只是层镜像屏蔽了对这个文件的可见性而已，这个文件还是存在于上层镜像，所以最后的镜像大小并不会因为执行了这个命令而减少。
（D 表示delete，删除； A表示add，添加；C表示change，修改）
上图也说明了一点，如果尝试删除镜像中已经存在的文件，因为文件实际上并没有被删除，只是被屏蔽致使上层不可见，所以并不会减少镜像的大小（还可能增大，什么时候会可能增大？因为删除过程中还可能修改了其他文件，那么这些被修改的文件需要复制一份到顶层，然后修改，而原来的镜像文件并没有变化）
那么反正没有用，我们不删除？
这个也是不对的，在构建过程中，要随手删除产生的额外文件，这里并没有和上面所说的矛盾，准确来说是在同一个命令中删除无用的文件。那么上面的命令应该改为
RUN wget –no-check-certificate -O /tmp/nginx-1.10.2.tar.gz http://nginx.org/download/nginx-1.10.2.tar.gz && cd /tmp/ && tar zxf nginx-1.10.2.tar.gz && rm nginx-1.10.2.tar.gz
这样这个命令执行完毕时，commit形成的新的镜像也就不会存在nginx-1.10.2.tar.gz，同理，在nginx编译过程中会产生许多的中间文件，为了保证最后的镜像的最小，也需要在同一个命令中删除文件。
上面提到了对于dockerfile的每一个命令都会自动commit形成，如果使用aufs文件系统，会受到42层的限制，所以按照这个理论应该减少层的形成，但是应该与以下情况相权衡
如果是在docker镜像中编译java文件，那么常常会出现以下的情况
# 拷贝文件
COPY . /opt/`
# 执行构建
RUN mvn clean package
这样的话，在执行构建的情况下，会依照pom文件下载相应的依赖库，但是在很多情况下这些依赖库是不会改变的，所以可以缓存起来，所以可以先复制pom文件，然后下载相应的依赖，再复制容易改变的源代码等文件后进行构建,充分利用缓存
COPY pom.xml /opt/
RUN mvn verify clean --fail-never -f /opt/pom.xml
COPY src/ /opt/src
RUN mvn clean package
参考
AUFS https://coolshell.cn/articles/17061.html
aufs wiki https://zh.wikipedia.org/wiki/Aufs
docker 存储驱动 https://docs.docker.com/storage/storagedriver/select-storage-driver/#supported-storage-drivers-per-linux-distribution
docker 实战（docker in action中文版）
aufs文件系统的42层限制 https://stackoverflow.com/questions/39382518/whats-the-reason-for-the-42-layer-limit-in-docker
联合文件系统 https://yeasy.gitbooks.io/docker_practice/underly/ufs.html