Docker 删除 none 镜像:一次真实的清理记录
2026-09-20 07:21 AlfredZhao 阅读(0) 评论(0) 收藏 举报笔者在服务器上执行 docker images 时,发现列表里堆了一排 <none> 镜像,占用从 511 MB 到 826 MB 不等。它们既没有仓库名,也没有标签,看起来像“幽灵”。这篇文章记录笔者如何定位根源并清理掉它们。
01 | none 镜像从哪来
<none>:<none> 常见于以下场景:构建新镜像时旧层被顶替(产生悬空镜像)、镜像被重新打标签后原标签被移走、多阶段构建的中间层、构建失败残留等。其中悬空镜像(dangling)通常可被 docker image prune 清理,而无标签镜像不一定。
笔者环境里,docker image prune -f 能清掉大部分悬空镜像,但有一条始终清不掉:
<none> <none> d989eed1eb19 8 days ago 825 MB
它反复出现,说明它可能并非能被 prune 直接清理的普通悬空层,需要进一步排查是否仍被容器引用,或是否被其他镜像作为父层依赖。
下面这张图概括了 none 镜像的两种来源,以及它们与“能否被 prune 清理”之间的关系:
02 | 为什么 prune 删不掉
docker image prune 默认只清理没有被任何容器引用的悬空(dangling)镜像;加 -a 后会删除所有未被任何容器使用的镜像(包括有标签但未被使用的镜像)。如果某个已停止的容器仍然指向这个镜像,prune 就会跳过它。
笔者检查后发现,根源是一个已经停止的容器 ontoforge_app_1。容器虽然停了,但它引用的镜像 ID 正是 d989eed1eb19,于是这个 none 镜像被“锁”住了。
从清理前后的对比可以更直观地看到这条“顽固”镜像的处境:
| 阶段 | 命令 | 结果 |
|---|---|---|
| 清理前 | docker images |
多条 <none> 镜像,其中 d989eed1eb19(825 MB)始终存在 |
| 批量清理 | docker image prune -f |
大部分悬空镜像被删除,d989eed1eb19 仍保留 |
| 定位根源 | docker ps -a |
查看已停止容器,确认 ontoforge_app_1 的 IMAGE 列指向 d989eed1eb19 |
| 删除容器 | docker rm ontoforge_app_1 |
容器被移除,镜像解除占用 |
| 删除镜像 | docker rmi d989eed1eb19 |
镜像及依赖层逐层删除 |
03 | 两步清理
思路很简单:先删掉占用镜像的容器,再删镜像。注意:删除容器前请确认该容器不再需要,并检查是否有需要保留的数据卷或挂载数据;生产环境建议先备份或在测试环境验证。
docker rm ontoforge_app_1
docker rmi d989eed1eb19
执行 docker rm 后,容器被移除;再执行 docker rmi,镜像及其依赖层被逐层删除,输出了一长串 Deleted: 记录。再次执行 docker images,那条 825 MB 的 none 镜像已经消失。如果 docker rmi 报错提示镜像仍被引用,可先用 docker ps -a --filter ancestor=d989eed1eb19 查找并处理相关容器。
整个清理流程可以归纳为下面几步:
04 | 小结
遇到删不掉的 none 镜像,不要反复 prune。先确认是否有停止的容器还在引用它;确认该容器不再需要后,用 docker rm 清掉容器,再用 docker rmi 删除镜像即可。日常维护中,定期清理停止的容器,能避免这类镜像长期占着磁盘。
关注我,和AI一起成长~
转载请注明原文链接:https://www.cnblogs.com/jyzhao/p/23042208
👋 感谢阅读,欢迎关注我的公众号 「赵靖宇」
浙公网安备 33010602011771号