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

Question

我正在尝试从debian：最新的构建镜像。构建后，docker image命令报告的镜像虚拟大小为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

1.9GB大小不是图像，而是图像及其历史记录。使用docker历史文本框检查是什么占用了这么多空间。

另请参见Docker容器图像为什么如此大？

要减小大小，您可以更改构建图像的方式（这取决于您的操作，请参见上面链接中的答案），使用docker export（请参见如何展平docker图像？）或使用其他扩展。

Answer 2

您是否通过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语句中的文件，以便在执行相同的RUN语句时进行清理？E、 g.<代码>运行git克隆

一个好的做法是只添加那些要留在图像上的东西。在可能的情况下，应该使用一条RUN语句来添加和清理临时内容。