输出中缺少Docker层ID

Question

我刚刚在Ubuntu上重新安装了Docker，使用了官方指南：https://docs.Docker.com/engine/installation/linux/Ubuntulinux/

IMAGE CREATED CREATED BY SIZE COMMENT
3e23a5875458 8 days ago /bin/sh -c #(nop) ENV LC_ALL=C.UTF-8 0 B
"missing" 8 days ago /bin/sh -c dpkg-reconfigure locales && loc 1.245 MB
"missing" 8 days ago /bin/sh -c apt-get update && apt-get install 338.3 MB

有人知道是什么引起的吗？或者能帮我解决这个问题吗？我依赖于这个层ID，因为我正在收集一些关于层重用性的统计数据，所以我需要这个ID来正确显示。

Answer 1

正如您在20131期中提到的，这可能是新的Docker1.10内容寻址性迁移的结果

来自Docker博客文章：

从1.10开始，我们彻底改变了Docker对磁盘上图像数据的寻址方式。
以前，每个图像和层都使用随机分配的UUID。
在1.10中，我们基于图像和层数据的安全散列，实现了一种使用ID的内容寻址方法。

奈杰尔·布朗有一篇关于那些“缺失”图像的详细文章。

解释Docker图像ID

在Docker映像生成过程中创建层或“diff”，并在容器中运行命令时产生结果，这些命令生成新的或修改的文件和目录。
这些新的或修改的文件和目录作为一个新层“提交”。

层现在由一个摘要来标识，它采用算法的形式：十六进制；

Docker映像现在由一个configuration对象组成，其中（除其他外）包含层摘要的有序列表，这使得Docker引擎能够参考层摘要而不是父映像来组装容器的文件系统。

因此，当从注册表中提取Docker图像，并使用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  

在Docker主机上本地构建的图像的处理方式略有不同。
本地构建的图像的一般内容保持不变--它是一个包含配置项的配置对象，包括层摘要的有序列表。

但是，当在本地Docker主机上生成映像期间提交一个层时，将同时创建一个“中间”映像。
与所有其他映像一样，它有一个配置项，该项是将作为映像的一部分合并的层摘要的列表，其ID或摘要包含配置对象的哈希。中间图像没有名称标记，但它们有一个“parent”键，其中包含父图像的ID。

中间映像和对父映像的引用的目的是为了方便使用Docker的构建缓存。

$ docker history jbloggs/my_image:latest 
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT  
26cca5b0c787        52 seconds ago      /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "/bin/b   0 B  
97e47fb9e0a6        52 seconds ago      /bin/sh -c apt-get update &&     apt-get inst   16.98 MB  
1742affe03b5        13 days ago         /bin/sh -c #(nop) CMD ["/bin/bash"]             0 B  
<missing>           13 days ago         /bin/sh -c #(nop) ADD file:5d8521419ad6cfb695   125.1 MB  

Docker History命令显示图像有四个层，但Docker Inspection建议只有三个层。
这是因为两个cmd指令为图像生成元数据，不添加任何内容，因此“diff”是空的。
摘要5f70bf18a08a是空层的SHA256哈希，由两个相关层共享。

当本地构建的映像被推送到注册表时，它只是叶映像与其组成层一起上载，而另一个Docker主机随后的拉取将不会产生任何中间父映像。

这是因为一旦映像通过注册表提供给不同Docker主机上的其他潜在用户，它实际上就变成了只读的，并且不再需要支持构建缓存的组件。
代替映像ID， 被插入到历史记录输出中。

最后：

在Docker主机上，Docker用于层“diffs”的摘要包含difftar归档内容的sha256散列。
在层作为推送的一部分上传到注册表之前，为了提高带宽效率，它被压缩。还创建一个清单来描述图像的内容，它包含压缩层内容的摘要。因此，清单中层的摘要与未压缩状态下生成的摘要不同。