为什么继承的Docker图像大小不同

我最近在用Docker做实验。为了便于维护和扩展，我尝试构建这样的映像体系结构

我用以下Dockerfiles创建了图像，并且对不同的容器大小感到好奇。为什么他们有这么大的不同

遵循base/Dockerfile生成210.9MB的图像（ubuntu:trusty有188MB，所以没关系）

apache/Dockerfile的结果是224.4MB

FROM ubuntu:trusty
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano \
    apache2
ENV TERM xterm
RUN apt-get -y autoremove && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
COPY apache2-foreground /usr/local/bin/
RUN chmod a+x /usr/local/bin/apache2-foreground
EXPOSE 80
WORKDIR /var/www/html
CMD ["apache2-foreground"]

FROM ubuntu:trusty
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano curl \
    apache2 \
    libapache2-mod-php5 php5-mysql php5-mcrypt php5-gd php5-curl php-pear php-apc && \
    curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN /usr/sbin/php5enmod mcrypt
# + last 7 lines from apache/Dockerfile

FROM apache-on-base
# + apache-php/Dockerfile without "install nano apache2"

apachephp/Dockerfile结果为266.7MB

FROM ubuntu:trusty
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano \
    apache2
ENV TERM xterm
RUN apt-get -y autoremove && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
COPY apache2-foreground /usr/local/bin/
RUN chmod a+x /usr/local/bin/apache2-foreground
EXPOSE 80
WORKDIR /var/www/html
CMD ["apache2-foreground"]

FROM ubuntu:trusty
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano curl \
    apache2 \
    libapache2-mod-php5 php5-mysql php5-mcrypt php5-gd php5-curl php-pear php-apc && \
    curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN /usr/sbin/php5enmod mcrypt
# + last 7 lines from apache/Dockerfile

FROM apache-on-base
# + apache-php/Dockerfile without "install nano apache2"

到目前为止还可以，但我们直到现在才使用继承。我们来看看,

为什么apachephp-on-base/Dockerfile会导致289.4MB？这基本上是相同的步骤，但分为两个图像。我本以为会有一点间接费用，但不是10%左右

FROM base
# + apache-php/Dockerfile without "install nano"

使用多重继承会更大：apachephp-on-base/Dockerfile上的apache-on-base/Dockerfile结果是314.9 MB

FROM ubuntu:trusty
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano \
    apache2
ENV TERM xterm
RUN apt-get -y autoremove && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
COPY apache2-foreground /usr/local/bin/
RUN chmod a+x /usr/local/bin/apache2-foreground
EXPOSE 80
WORKDIR /var/www/html
CMD ["apache2-foreground"]

FROM ubuntu:trusty
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano curl \
    apache2 \
    libapache2-mod-php5 php5-mysql php5-mcrypt php5-gd php5-curl php-pear php-apc && \
    curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN /usr/sbin/php5enmod mcrypt
# + last 7 lines from apache/Dockerfile

FROM apache-on-base
# + apache-php/Dockerfile without "install nano apache2"

其中，apacheonbase/Dockerfile当然是（导致247mb）：

问题：是否有一种方法可以防止图像增长如此之大，同时保持可维护性

更新：落实thaJeztah的建议我得到以下建议：）再次感谢

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
apache-php-on-aob   latest              2cf12a3b5872        2 minutes ago       249.9 MB
apache-on-base      latest              121c8a098ff5        3 minutes ago       203.7 MB
base                latest              ee95e4f8aaee        3 minutes ago       189.3 MB
apache-php-on-aob   v1                  e43df5e61aed        3 days ago          314.9 MB
apache-on-base      v1                  c291f91f1a10        3 days ago          247 MB
base                v1                  b181fc6f181d        3 days ago          210.9 MB
ubuntu              trusty              97434d46f197        10 days ago         188 MB

---

在没有深入分析所有差异的情况下，最可能的原因是 您没有考虑分层文件系统

Docker为Dockerfile中的每条指令创建一个新的imagelayer。基本上 发生的事情（非常简单）：

因此，这将成为第一层：

FROM ubuntu:trusty

（Docker做了一些类似的事情）

这将成为第二层：

FROM layer1
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano

（Docker做了一些类似的事情）

等等

最终图像是所有“堆叠”图像的组合。重要的是 要知道有一个文件是在“layer1”中添加的，但在“layer2”中删除的 仍然是图像的一部分；Docker只在第2层中将其标记为“已删除”，但 不会使图像变小

让我们看一下您的第一份Dockerfile。正如你所看到的，你增加了很多 在第一个

运行

指令中，添加一个仅设置 一个

ENV

var，然后是另一个

RUN

，删除所有冗余文件 从第一次

运行

。但是，这些文件不会从早期图层中删除， 因此，在最终图像中仍然占据空间

FROM ubuntu:trusty
RUN apt-get -qq update && \
    DEBIAN_FRONTEND=noninteractive apt-get -qq install \
    nano
ENV TERM xterm
RUN apt-get -y autoremove && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

在构建（

docker build-t foobar.

）之后，这给了我：

REPOSITORY  TAG      IMAGE ID      CREATED        SIZE
foobar      latest   363aa5572838  2 minutes ago  210.9 MB

进行一个小的更改，并组合两个

运行

指令，以便

apt get update

和

apt get clean

步骤在相同的

RUN

中进行，因此 同一层

这座建筑产生了这样的形象：

REPOSITORY  TAG      IMAGE ID      CREATED        SIZE
foobar      latest   ac8fb5e4db16  9 minutes ago  189.3 MB

比这个小20MB

您可以在

---

文件的第三节

尝试在您的图像上运行

docker history

，您可以看到图像之间哪些层更大/更小，以确定额外膨胀的来源。谢谢！这确实有助于我理解发生了什么：）