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

1.9GB大小不是图像，而是图像及其历史记录。使用docker history textbox检查占用的空间是多少。

另见Why are Docker container images so large?

要缩小尺寸，您可以更改构建图像的方式（取决于您的操作，请参阅上面链接中的答案），使用docker export（请参阅How to flatten a Docker image?）或使用{{3 }}

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语句ADD语句外，还会创建新的图像图层。无论您以何种方式添加到图像中保留在历史记录中并依赖于总图像大小。您无法暂时ADD件事，然后将其删除，以便他们不会指望总尺寸。

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

一个好的做法是仅ADD那些意图留在图像上的东西。应尽可能使用单个RUN语句添加和清除临时内容。