为何Docker容器的文件系统比其镜像占用空间更小？

镜像的存储与容器的文件系统逻辑 #

• Docker镜像是由多个只读层组成的，每层对应Dockerfile里的一条指令（如COPY、RUN），这些层在本地存储时是解压后的状态，镜像仓库里的镜像是压缩打包的。docker images显示的镜像大小是所有只读层未压缩的总大小。
• 启动容器时，Docker不会复制镜像的所有层，而是在镜像的只读层之上添加一个可写层。通过联合文件系统（如overlay2），把只读镜像层和可写容器层合并成一个统一的虚拟文件系统：
  • 读取文件：直接从对应的只读镜像层读取，无需额外复制。
  • 修改文件：采用**写时复制（Copy-on-Write）**机制，先把要修改的文件从只读层复制到可写层，之后的操作都在可写层进行，原镜像层的文件保持不变。

为什么镜像占用空间比容器显示的大？ #

你看到的容器大小（比如docker ps -s里的SIZE字段）仅统计可写层的占用，也就是容器运行中新增、修改的文件大小，不包含共享的只读镜像层。而镜像的大小是所有只读层的总大小（未压缩），所以看起来镜像比容器大很多——实际上容器的整个可用文件系统是镜像层+可写层的总和，只是镜像层是多个容器共享的，不会重复计算到每个容器的存储占用里。

镜像中的代码如何在容器内执行？ #

镜像里的代码和依赖已经以文件形式存储在只读层中（拉取镜像时已解压到本地），容器启动时，联合文件系统会让容器进程看到完整的文件系统（包含所有镜像层的内容），进程直接读取这些文件并执行即可。整个过程不需要再“解压”镜像到容器里，而是通过挂载只读层实现文件的访问。

内容的提问来源于stack exchange，提问作者morismarmotti