Docker容器大小远远大于实际大小 [英] docker container size much greater than actual size

问题描述

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

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

推荐答案

是否通过文档文件构建该映像？这样做时，请注意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语句添加和清理临时内容。

这篇关于Docker容器大小远远大于实际大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！