Docker仓库垃圾回收机制与存储空间清理方法

2次阅读

清理 docker 本地垃圾需聚焦镜像缓存、悬空镜像及未引用层,避免误删共享基础层;优先用 docker image prune 清悬空镜像,再按需执行 -a 或 system prune,配合 –Filter 精准筛选,并治理构建缓存与日志轮转。

Docker仓库垃圾回收机制与存储空间清理方法

清理 Docker 仓库相关的垃圾,核心不是删远程 Registry(比如 Docker Hub),而是清理本地镜像缓存、构建中间层、悬空镜像和未被引用的层——这些才是真正吞噬磁盘空间的“隐形仓库”。关键在于理解 Docker 的分层共享机制:同一基础层被多个镜像共用,盲目删除可能无效甚至误伤。

识别真正的“垃圾镜像”

Docker 中真正可安全清理的镜像分两类:

  • 悬空镜像(dangling images):镜像 ID 存在,但仓库名和标签都是 <none>。常见于重复 docker build -t myapp:latestdocker pull 后旧镜像失去标签。查看命令:docker images -f dangling=true
  • 未被任何容器引用的镜像:包括你手动拉取后从未运行、或容器已删但镜像残留的情况。这类镜像不会自动释放,需主动清理。

分层级执行清理操作

从保守到激进,按需选择命令,避免误删:

  • 仅清悬空镜像(最安全):docker image prune —— 默认交互确认,加 -f 跳过提示
  • 清所有未被使用的镜像(含带标签但无容器在用的):docker image prune -a
  • 一键清理容器、网络、悬空镜像、构建缓存:docker system prune
  • 全量清理(含未挂载卷):docker system prune -a --volumes —— 生产环境慎用,务必确认卷中无重要数据

精准控制清理范围

--filter 避免“一刀切”,例如:

  • 只删 48 小时前创建的悬空镜像:docker image prune -f --filter "until=48h"
  • 只删特定仓库的旧镜像:docker image prune -a -f --filter "reference=myapp:*"
  • 组合条件(如某标签 + 某时间):docker image prune -a -f --filter "reference=redis:alpine" --filter "until=72h"

治理构建缓存与日志膨胀

这两类常被忽略,却是长期运行系统空间耗尽的主因:

  • 构建缓存docker builder prune 清理 BuildKit 缓存;加 -a 清全部,加 --keep-storage 2g 限制缓存上限
  • 容器日志:默认 json 日志持续追加,单个文件可达 GB 级。推荐在 /etc/docker/daemon.json 中配置轮转:
    {“log-driver”: “json-file”, “log-opts”: {“max-size”: “10m”, “max-file”: “3”}}
    修改后重启 Docker:sudo systemctl restart docker
text=ZqhQzanResources