'docker history' command: Why does the column label say 'IMAGE' when the column contains layers?
'docker history' command: Why does the column label say 'IMAGE' when the column contains layers?
It's complicated ;) This post by Nigel Brown is super useful for understanding this, but I'll pull out the relevant points here.
Historically (pre Docker v1.10), each time a new layer was created as a result of a commit action, Docker also created a corresponding image, which was identified by a randomly generated 256-bit UUID, usually referred to as an image ID (presented in the UI as either a short 12-digit hex string, or a long 64-digit hex string).
So, historically they were images, just intermediate ones with no 'human-friendly' tag (although they could be tagged).
Since Docker v1.10, generally, images and layers are no longer synonymous. Instead, an image directly references one or more layers that eventually contribute to a derived container's filesystem.
And if you do a docker history
on a pulled image, you'll see something like (taken from the article):
$ 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
You'll see the IMAGE
column reports <missing>
, these are not images, but layers that are constituent parts of the image.
So they're not images! What the hell, why is the column named that? (back to your original question). Well, except...:
However, when a layer is committed during an image build on a local Docker host, an 'intermediate' image is created at the same time. Just like all other images, it has a configuration item which is a list of the layer digests that are to be incorporated as part of the image, and its ID or digest contains a hash of the configuration object. Intermediate images aren't tagged with a name, but, they do have a 'Parent' key, which contains the ID of the parent image.
So actually, when you build locally, those constituent layers are images (just like they used to be, even when you pulled them from somewhere else, until v1.10), and are used to facilitate the build cache (part that makes builds fast if you've already built that layer already).
So the answer is...sometimes they are images (technically), sometimes they are layers (and then represented in that column as <missing>
). I'd guess it was left as IMAGE
for a) historical reasons and b) because they actually are images when something appears there, otherwise it just shows <missing>
. I can see how they might be a little confusing, and there certainly might be additional technical detail I've glossed over here, but hope it helps!
Disclaimer: I work for Docker, but my views / posts are my own, etc...
Explaining Docker Image IDs
作者:Chuck Lu GitHub |
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· DeepSeek 开源周回顾「GitHub 热点速览」
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
2019-06-19 543. Diameter of Binary Tree
2019-06-19 Newtonsoft.Json源码的solution打开之后,无法加载project
2019-06-19 custom serializer for just one property in Json.NET
2018-06-19 NPOI设置Excel中的单元格识别为日期
2017-06-19 FileStream vs/differences StreamWriter?
2017-06-19 Excel显示当前日期
2015-06-19 编程概念--使用async和await的异步编程