'docker history'命令:当列包含图层时,为什么列标签会显示'IMAGE'？

Question

我已经和Docker一起工作了好几个月了,而且我还没有docker history经常使用这个命令.

然而,我曾经使用它的少数几次让我开始假设有大量的"依赖图像 "与我的"顶级"图像相关联,而不是层.

现在我已经明白,上面的大部分假设是基于这样一个事实:很久以前,当我发出docker history命令时,最左边一列的标题是IMAGE,而事实上,这些行确实列出了与之相关的层.单个图像,而不是图像.

以下是示例docker history命令的屏幕截图:

Docker中的图像和图层之间存在着重要的区别,这就是为什么这真的是一个严肃的问题.

我坦率地对此问题感到非常惊讶.如何通过Docker剥离出如此重要的东西？

我花了一段时间来寻找对这个问题的讨论或回答.令人惊讶的是,即使是Docker'历史'命令文档也没有提到这一点.我见过的唯一真正的'确认'来自这个链接.

有人可以告诉我为什么列的标题docker history是'IMAGE',而条目本身是图层？

Answer 1

这是复杂的;)本帖由奈杰尔·布朗是超级理解这个有用的,但我会在这里拔出相关的问题.

历史上(前Docker v1.10),每次由于提交操作而创建新图层时,Docker还会创建相应的图像,该图像由随机生成的256位UUID标识,通常称为图像ID (在UI中显示为短12位十六进制字符串或长64位十六进制字符串).

因此,从历史上看,它们只是图像,只是没有"人性化"标签的中间图像(尽管它们可以被标记).

从Docker v1.10开始,通常,图像和图层不再是同义词.相反,图像直接引用一个或多个最终贡献于派生容器的文件系统的层.

如果你docker history在拉动的图像上做一个,你会看到类似的东西(摘自文章):

$ docker history swarm
IMAGE               CREATED             CREATED BY                                      
SIZE                COMMENT  
c54bba046158        9 days ago          /bin/sh -c #(nop) CMD ["--help"]                0 B  
<missing>           9 days ago          /bin/sh -c #(nop) ENTRYPOINT &{["/swarm"]}      0 B  
<missing>           9 days ago          /bin/sh -c #(nop) VOLUME [/.swarm]              0 B  
<missing>           9 days ago          /bin/sh -c #(nop) EXPOSE 2375/tcp               0 B  
<missing>           9 days ago          /bin/sh -c #(nop) ENV SWARM_HOST=:2375          0 B  
<missing>           9 days ago          /bin/sh -c #(nop) COPY dir:b76b2255a3b423981a   0 B  
<missing>           9 days ago          /bin/sh -c #(nop) COPY file:5acf949e76228329d   277.2 kB  
<missing>           9 days ago          /bin/sh -c #(nop) COPY file:a2157cec2320f541a   19.06 MB  

您将看到IMAGE列报告<missing>,这些不是图像,而是作为图像组成部分的图层.

所以他们不是图像!到底是什么,为什么这个专栏命名为？(回到你原来的问题).好吧,除了......:

但是,在本地Docker主机上构建映像期间提交层时,会同时创建"中间"映像.与所有其他图像一样,它具有配置项,该配置项是要作为图像的一部分合并的层摘要的列表,并且其ID或摘要包含配置对象的散列.中间图像没有标记名称,但是,它们有一个"父"键,其中包含父图像的ID.

实际上,当你在本地构建时,那些构成层是图像(就像以前一样,即使你从其他地方拉出它们,直到v1.10),并且用于促进构建缓存(使构建快速的部分)如果你已经建立了那个层了).

所以答案是......有时它们是图像(技术上),有时它们是图层(然后在该列中表示为<missing>).我猜这是因为IMAGEa)历史原因和b)因为它们实际上是出现在那里的东西的图像,否则它只是显示<missing>.我可以看到它们可能有点令人困惑,当然可能还有其他技术细节,但我希望它有所帮助!

免责声明:我为Docker工作,但我的观点/帖子是我自己的,等等......

Answer 2

正如约翰提到的，这些实际上是图像 ID，由您的本地构建产生。这些层埋得更深一些，如果您检查每个连续的图像 ID，您可以看到这些层的堆积。这是我在本地构建的图像：

\n\n

$ docker history bmitch3020/terraform-ansible\nIMAGE               CREATED             CREATED BY                                      SIZE                COMMENT\nc68a76df6362        2 months ago        /bin/sh -c #(nop)  ENTRYPOINT ["terraform"]     0B\n32b9c2451d45        2 months ago        /bin/sh -c #(nop) COPY file:a8a964b6da98146c\xe2\x80\xa6   62.7MB\n13543af79664        2 months ago        |1 ANSIBLE_KEY_ID=93C4A3FD7BB9C367 /bin/sh -\xe2\x80\xa6   80.8MB\ne5c0db134950        2 months ago        /bin/sh -c #(nop)  ARG ANSIBLE_KEY_ID=93C4A3\xe2\x80\xa6   0B\ne5153922f57d        2 months ago        /bin/sh -c apt-get update  && DEBIAN_FRONTEN\xe2\x80\xa6   85.9MB\n874e27b628fd        5 months ago        /bin/sh -c #(nop)  CMD ["bash"]                 0B\n<missing>           5 months ago        /bin/sh -c #(nop) ADD file:a71e077a42995a68f\xe2\x80\xa6   100MB\n

\n\n

现在让我们浏览每个图像以查看图层（这只是docker inspect查看“RootFS -> Layers”部分的循环）：

\n\n

$ docker history bmitch3020/terraform-ansible -q \\\n  | while read image_id; do \\\n    echo "$image_id"; \\\n    if [ "$image_id" != "<missing>" ]; then \\\n      docker inspect "$image_id" --format \'{{json .RootFS.Layers}}\' | jq .; \\\n    fi; \\\n  done\n\nc68a76df6362\n[\n  "sha256:a75caa09eb1f7d732568c5d54de42819973958589702d415202469a550ffd0ea",\n  "sha256:092445cb4dbd94421917ec3db5b8d0ee2feac691d0555e24f1b7e3451b2f9caa",\n  "sha256:4d221bea3442fd038aa42722b44c6633ddbd02e8d4eda1af0c84e5ef7deffe5f",\n  "sha256:bd39a8a25e0f87ef27495bd23f57f651b972139c11fd05c8cd7ca79e67549ad2"\n]\n32b9c2451d45\n[\n  "sha256:a75caa09eb1f7d732568c5d54de42819973958589702d415202469a550ffd0ea",\n  "sha256:092445cb4dbd94421917ec3db5b8d0ee2feac691d0555e24f1b7e3451b2f9caa",\n  "sha256:4d221bea3442fd038aa42722b44c6633ddbd02e8d4eda1af0c84e5ef7deffe5f",\n  "sha256:bd39a8a25e0f87ef27495bd23f57f651b972139c11fd05c8cd7ca79e67549ad2"\n]\n13543af79664\n[\n  "sha256:a75caa09eb1f7d732568c5d54de42819973958589702d415202469a550ffd0ea",\n  "sha256:092445cb4dbd94421917ec3db5b8d0ee2feac691d0555e24f1b7e3451b2f9caa",\n  "sha256:4d221bea3442fd038aa42722b44c6633ddbd02e8d4eda1af0c84e5ef7deffe5f"\n]\ne5c0db134950\n[\n  "sha256:a75caa09eb1f7d732568c5d54de42819973958589702d415202469a550ffd0ea",\n  "sha256:092445cb4dbd94421917ec3db5b8d0ee2feac691d0555e24f1b7e3451b2f9caa"\n]\ne5153922f57d\n[\n  "sha256:a75caa09eb1f7d732568c5d54de42819973958589702d415202469a550ffd0ea",\n  "sha256:092445cb4dbd94421917ec3db5b8d0ee2feac691d0555e24f1b7e3451b2f9caa"\n]\n874e27b628fd\n[\n  "sha256:a75caa09eb1f7d732568c5d54de42819973958589702d415202469a550ffd0ea"\n]\n<missing>\n

\n\n

您可以从上面的检查输出中看到一些自下而上的内容：

\n\n

\n
• “missing”：此行是因为这部分映像历史记录是远程构建的，并且缓存的中间映像不在本地 docker 主机上。
\n
• 874e27b628fd：这来自上游镜像的 docker pull。
\n
• e5153922f57d：我们通过一些软件包安装在此基础上添加了另一层。
\n
• e5c0db134950：这个“nop”不会创建另一个图层，但它会创建另一个图像 ID。该图像 ID 包含一些已更改的元数据，即“arg”，如果它与 arg 值匹配，则可以在以后的构建中将其用作缓存。
\n
• 13543af79664：现在我们在原始拉取的图像中添加了两个图层。
\n
• 32b9c2451d45：COPY添加一层并通过从缓存添加的文件的哈希进行跟踪。
\n
• c68a76df6362：这再次创建另一个图像 ID，而不创建另一个文件系统层。图像 ID 包含更新的元数据、入口点值，而最终的图像 ID 就是我的标签所指向的。
\n

\n