Docker在输出中缺少图层ID

Question

我刚刚使用官方指南在Ubuntu上安装了Docker:https://docs.docker.com/engine/installation/linux/ubuntulinux/

当我使用"sudo docker pull ubuntu"然后"sudo docker history ubuntu"拉动图像时,它会返回列中缺少的图层ID.使用文档示例(https://docs.docker.com/engine/reference/commandline/history/),我的输出是:

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,其余部分为"缺失".我尝试在连接到不同网络的另一台Ubuntu机器上安装,它对我下载的任何图像都有同样的问题.

有人知道是什么导致了这个或能够帮助我修复它吗？我依赖这个图层ID,因为我正在收集有关图层可重用性的一些统计信息,所以我需要这个ID才能正确显示.

谢谢

Answer 1

正如您在20131年的问题中所提到的,这可能是新的docker 1.10内容可寻址迁移的结果

来自Docker博客文章:

从v1.10开始,我们完全改变了Docker处理磁盘上图像数据的方式.
以前,每个图像和图层都使用随机分配的UUID.
在1.10中,我们基于图像和层数据的安全散列,使用ID实现了内容可寻址方法.

这就是thaJeztah评论的原因:

我认为这是预期的; 内容可寻址存储不再使用"父"图像将图像层链接在一起.
新拉出的图像也不再显示中间图像(这些"缺失"图像仅显示在主机上存在但已迁移到新存储的图像)

2016年6月更新(3个月后)

奈杰尔布朗有一篇关于那些"失踪"图像的详细文章.

解释Docker镜像ID

在Docker镜像构建过程中创建一个图层或'diff',并在命令在容器中运行时产生结果,这会生成新的或修改过的文件和目录.
这些新的或修改过的文件和目录被"提交"为新层.

历史上(前Docker v1.10),每次由于提交操作而创建新图层时,Docker还会创建相应的图像,该图像由随机生成的256位UUID标识,通常称为图像ID

改变的一个重要驱动因素来自于缺乏检测图像内容是否在推送到或从注册表(如Docker Hub)中拉出时被篡改的方法.这导致整个社区的强烈批评,并导致一系列变化,最终导致内容可寻址ID.

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

图层现在由摘要标识,采用格式算法:hex;

Docker镜像现在由一个配置对象组成,其中包含一个有序的层摘要列表,它使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  

除了图像的一个层之外的所有字段中的<missing>值IMAGE都是误导性的,有点不幸.它传达了错误的建议,但没有错误,因为图层不再与相应的图像和ID同义.
我认为把这个领域留空是更合适的.

此外,图像ID似乎与最上层相关联,但实际上,图像ID不属于任何层.相反,这些层共同属于图像,并提供其文件系统定义.

但是(本地与远程图像):

Docker主机上本地构建的映像的处理方式略有不同.
本地构建的映像的通用内容保持不变 - 它是包含配置项的配置对象,包括层摘要的有序列表.

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

在此示例中,前两个层是在本地映像构建期间创建的,而底层是来自构建的基本映像(例如Dockerfile指令FROM debian).

我们可以使用该docker inspect命令查看与图像关联的图层摘要:

该docker history命令将图像显示为具有四个图层,但docker inspect仅建议三个图层.
这是因为两条CMD指令为图像生成元数据,不添加任何内容,因此'diff'为空.
摘要5f70bf18a08a是空图层的SHA256哈希值,由两个相关层共享.

当本地构建的图像被推送到注册表时,它只是与其组成层一起上传的叶子图像,并且随后由另一个Docker主机拉动将不会产生任何中间父图像.

这是因为一旦图像通过注册表可供不同Docker主机上的其他潜在用户使用,它实际上变为只读,并且不再需要支持构建缓存的组件.
而不是图像ID,<missing>将其插入到其位置的历史输出中.

最后:

Docker用于Docker主机上的图层'diffs'的摘要包含diff的tar存档内容的sha256哈希.
在将图层作为推送的一部分上载到注册表之前,会对其进行压缩以提高带宽效率.还创建清单来描述图像的内容,并且它包含压缩层内容的摘要.因此,清单中的层的摘要与在其未压缩状态下生成的摘要不同.