docker 容器大小远大于实际大小

Question

我正在尝试从debian:latest. 构建后，docker images命令中报告的映像虚拟大小为 1.917 GB。我登录查看大小 ( du -sh /)，它是 573 MB。我很确定这种巨大的尺寸通常是不可能的。这里发生了什么？如何获得正确的图像大小？更重要的是，当我推送这个存储库时，大小是 1.9 GB 而不是 573 MB。

输出 du -sh /*

8.9M    /bin
4.0K    /boot
0   /dev
1.1M    /etc
4.0K    /home
30M /lib
4.0K    /lib64
4.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access '/proc/11/task/11/fd/4': No such file or directory
du: cannot access '/proc/11/task/11/fdinfo/4': No such file or directory
du: cannot access '/proc/11/fd/4': No such file or directory
du: cannot access '/proc/11/fdinfo/4': No such file or directory
0   /proc
427M    /root
8.0K    /run
3.9M    /sbin
4.0K    /srv
0   /sys
8.0K    /tmp
88M /usr
15M /var

Answer 1

您通过Dockerfile构建该映像吗？当你这样做时，请注意你的RUN陈述。当您为每个语句执行多个RUN语句时，会创建一个新的图像层，该图像层保留在图像历史记录中并计入图像总大小。

因此，例如，如果一条RUN语句下载了一个巨大的存档文件，则下一条语句会解压该存档，然后一条语句会清理该存档，该存档及其提取的文件将保留在图像历史记录中：

RUN curl <options> http://example.com/my/big/archive.tar.gz
RUN tar xvzf <options>
RUN <do whatever you need to do with the unpacked files>
RUN rm archive.tar.gz

就图像大小而言，有更有效的方法可以RUN使用运算符将​​多个步骤组合到一个语句中&&。喜欢：

RUN curl <options> http://example.com/my/big/archive.tar.gz \
    && tar xvzf <options> \
    && <do whatever you need to do with the unpacked files> \
    && rm archive.tar.gz

通过这种方式，您可以清理构建过程所需但不在生成的映像中的文件和文件夹，并将它们保留在映像历史记录之外。这是保持较小图像尺寸的一种非常常见的模式。

但是，当然，您不会拥有可以重用的细粒度图像历史记录。

更新：

除了RUN语句之外ADD，语句还创建新的图像层。无论您向图像添加什么内容，它都会保留在历史记录中并计入图像总大小。您不能暂时删除ADD它们，这样它们就不会计入总大小。

尽量减少ADD图像。特别是当您处理大文件时。是否有其他方法可以在RUN语句中临时获取这些文件，以便您可以在同一RUN执行期间进行清理？例如RUN git clone <your repo> && <do stuff> && rm -rf <clone dir>？

一个好的做法是只保留ADD那些应该留在图像上的东西。RUN如果可能的话，应使用单个语句添加和清理临时内容。

Answer 2

1.9GB 的大小不是图像，而是图像及其历史。用于docker history textbox检查什么占用了这么多空间。

另请参阅为什么 Docker 容器映像如此大？

要减小大小，您可以更改构建映像的方式（这取决于您做什么，请参阅上面链接中的答案）、使用 docker export（请参阅如何扁平化 Docker 映像？）或使用其他扩展。