刚接手运维就发现 Docker 有大量的 none 镜像，一下子慌了！
今天聊聊Docker里那些烦人的镜像：怎么来的，怎么删，怎么防
接手一个Docker环境，发现里面躺着一堆
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
问题很常见，但处理起来有门道。下面就从根源说起。
1. none镜像是怎么产生的？
先说结论：这些
最常见的来源有四个：
（1）反复构建（Build）同一个标签
这是头号“元凶”。比如，你习惯用`latest`标签来构建镜像：
docker build -t app-api:latest .第一次构建，一切正常。但当你第二次执行同样的命令时，新镜像生成，`latest`这个标签就自动从旧镜像身上“跳槽”，贴到了新镜像上。被抛弃的旧镜像，就变成了`
（2）Docker Compose或CI/CD流水线自动构建
在`docker-compose.yml`里配置了`build`，并且镜像名用了`latest`标签：
build: .
image: app-api:latest那么，每次执行`docker-compose up --build`，都会生成一个新镜像并覆盖`latest`标签，从而制造出一个新的
（3）构建过程失败或中断
构建过程中如果因为错误或手动中断而失败，Docker可能已经生成了部分镜像层，但没来得及成功打上最终的标签，这些中间产物也会以
（4）手动操作标签
这种情况相对较少，比如手动给镜像重打标签(`docker tag`)或删除某个标签，也可能导致原镜像失去标签，变成
2. 删了，磁盘空间却不降？
这才是最让人困惑的地方：明明用`docker rmi`把那些
关键在于，你删除的镜像层并没有真正从磁盘上抹去，而是从“镜像层”的身份，转变成了“构建缓存（Build Cache）”。
为什么会这样？
现在Docker默认使用BuildKit来构建镜像，它非常“聪明”地考虑了构建效率。当你删除一个由`docker build`生成的镜像时，BuildKit会识别到这些镜像层可能对下一次构建有用，于是就把它们“收编”进了构建缓存里，以备不时之需。
看看下面的对比就一目了然了：
删除前，镜像占用空间：
删除后，镜像少了，但构建缓存增加了：
两图一对比就很清楚了：Images列表是清爽了，但Build Cache的体积却涨上去了。磁盘空间自然没有实质性释放。
3. 如何正确删除（释放空间四步法）
按照下面这个顺序来操作，既能清理干净，又不会影响正在运行的服务。当然，为求万无一失，操作前给环境做个快照总是个好习惯。
第一步：清理已停止的容器
docker container prune这步是基础清理，移除那些已经停止运行的容器实例。
第二步：清理
docker image prune这个命令会交互式地询问你是否删除所有未被使用的悬空镜像（dangling images），也就是那些
第三步：清理构建缓存（关键步骤）
docker builder prune这才是释放磁盘空间的“杀手锏”。它会清理无用的构建缓存。需要提醒的是，执行这步后，下次构建镜像时会因为缓存缺失而变慢一些，但为了换取宝贵的磁盘空间，这个代价通常是值得的。
第四步：验证空间释放情况
docker system df
df -h分别用Docker自带的磁盘查看命令和系统命令检查一下，这时候你应该能看到磁盘使用率有了明显的下降。
4. 避坑操作：这些雷千万别踩
清理有方法，蛮干有风险。下面这两个操作，尤其要警惕。
（1）慎用“核弹”命令：docker system prune -a
docker system prune -a这个命令威力巨大，它会删除所有未被容器使用的镜像，包括那些有正常标签的镜像。如果你有些镜像只是暂时没被运行，但后续还需要，这个命令就会导致镜像丢失。它还可能清理掉停止的容器（其中若有重要数据就麻烦了），虽然默认不删除数据卷，但整个操作风险较高，非必要不推荐。
（2）绝对不要手动删除Docker数据目录
有些人一着急，看到`/var/lib/docker/overlay2`目录占空间大，直接上手`rm -rf`。这无异于“自杀式”操作。这个目录是Docker存储镜像层和容器数据层的核心位置，直接删除文件系统内容，会导致Docker引擎彻底故障，所有容器和镜像都可能无法恢复。
所以，记住上面的“清理四步法”就足够了，千万别去动底层文件。
说到底，比学会删除更重要的，是理解Docker磁盘占用的这套机制。搞明白了镜像、容器、缓存之间的关系，以后再遇到这类问题，你就能从容应对，游刃有余了。
相关攻略
1 先搞清楚一个核心事实 在深入探讨之前，我们必须锚定一个核心事实：Kubernetes 本身并不会自动“迁移”Pod。 它的处理逻辑非常直接：删除 → 重建 → 再调度。一旦Pod被调度到某个节点，它就会“粘”在那里，不会被整体挪动。这跟虚拟机的热迁移完全是两码事，K8S的哲学就是这么简单直接。
今天聊聊Docker里那些烦人的镜像：怎么来的，怎么删，怎么防 接手一个Docker环境，发现里面躺着一堆镜像，是不是有点无从下手？这事儿不少运维同行都遇到过。别急，今天咱们就把这事儿掰开揉碎了讲清楚：这些“无名氏”镜像到底是怎么冒出来的，怎么才能彻底清理干净，以及如何从源头上避免它们再次泛滥。 问
当数据库无法启动：深入解析 innodb_force_recovery 的“急救”艺术 在 MySQL 的日常运维中，最让人“心跳加速”的场景之一，莫过于数据库突然无法启动，错误日志里赫然写着： InnoDB: Database was not shut down normally! InnoDB:
Komorebi：给 Windows 铺上隐形的轨道，让窗口自动归位 如果你也厌倦了在堆积如山的窗口里大海捞针，那么 Komorebi 这个项目绝对值得一试。它就像为 Windows 铺好了隐形的轨道，能让窗口自动、精准地归位，大幅提升多任务处理的效率。 常在 GitHub 上探索工具的朋友，可能已
Atuin 是什么 对于经常与命令行打交道的开发者来说，一个痛点想必都深有体会：历史命令散落在不同终端会话、不同机器上，查找起来费时费力。而 Atuin 的出现，正是为了解决这个看似微小却影响效率的顽疾。 简单来说，Atuin 是一个用 Rust 编写的 Shell 历史增强工具。它的核心思路很巧妙
热门专题
热门推荐
智能查询产品介绍 说到能帮我们省时省力的在线工具，有一个平台确实值得一提。它就像一个功能齐全的“数字瑞士军刀”，把各种实用查询和计算服务都整合在了一起。这个网站覆盖的领域相当广泛，几乎能触达日常生活的方方面面： 教育学习：从查汉字、找成语到在线翻译，它能实实在在地帮用户解决语言学习中的疑难杂症。 生
官宣：rain加盟100 Thieves 尘埃落定。在为FaZe Clan效力了近十年之后，传奇选手“雨神”rain终于找到了他的新归宿——100 Thieves。这不仅仅是简单的选手转会，更是一个时代的微妙转折。 消息已得到官方确认，rain正式签约100 Thieves，成为这支俱乐部宣布回归C
以下是本站为您精心整理的档案管理员年度工作总结范文，内容详实，可供参考。更多档案管理工作总结范文，请持续关注本站档案年度工作总结专栏。 档案管理员年度工作总结范文【一】 时光飞逝，自加入XXXX公司以来，已度过四个多月充实的工作时光。这份档案管理工作对我个人而言，不仅是职业生涯的重要开端，更是一段极
Spirit赛后动态 sh1ro：不知道哪出了问题 IEM成都站小组赛的赛果，多少有些出人意料。在确认止步之后，Spirit战队的几名队员陆续在社交平台上更新了状态，字里行间能品出不少东西。 核心选手sh1ro的发言很短，却透着浓浓的困惑：“输了。我不知道哪出了问题，也没什么好说的了，回头见。”这种
线刷宝集成三星GALAXY S4 Zoom (C101)刷机资源与教程 对于需要为三星GALAXY S4 Zoom (C101)进行刷机、救砖或升级固件的用户来说，线刷宝平台提供了一个集中的资源库。这里不仅提供该机型的官方ROM包、固件包，也集成了对应的Odin五件套或一体包，堪称一个功能全面的下载