Docker镜像清理是保障容器云平台稳定、高效、安全运行的必要机制，直接影响磁盘水位、构建性能、CI/CD可靠性及漏洞暴露面；需定期用docker system df监控可回收空间，在磁盘达80%时自动执行docker image prune -a -f，并联动Harbor等仓库实施生命周期策略与漏洞扫描。
在容器云平台运维中，docker 镜像清理不是“可做可不做”的收尾动作，而是保障平台稳定、高效、安全运行的必要机制。它直接影响磁盘资源水位、构建响应速度、ci/cd 流水线可靠性，甚至潜在漏洞暴露面。
防止存储耗尽引发服务中断
容器云平台节点长期运行 CI/CD 任务、自动扩缩容、镜像预热等操作，会持续产生带标签镜像、
- 用 docker system df 定期查看可回收空间（重点关注 Images 和 Build Cache 的 RECLAIMABLE 列）
- 对生产节点建议设置磁盘水位告警阈值为85%，并在达到80%时自动触发 docker image prune -a -f
- 避免依赖 docker system prune -a -f 全量清理，它会误删正在构建中但未提交的临时资源
保障 CI/CD 构建性能与结果一致性
Docker 构建高度依赖本地缓存层匹配。当基础镜像更新（如 alpine:3.20 → 3.21）或 Dockerfile 微调后，旧缓存层若未清理，可能被错误复用，导致构建产物包含过期依赖或安全漏洞，且难以排查。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 推荐在每次发布流水线末尾加入 docker builder prune --all -f，清除 BuildKit 全量缓存
- 对多分支并行构建场景，启用 --cache-from 指向镜像仓库而非本地缓存，降低对宿主机层状态的依赖
- 在 Jenkins 或 GitLab Runner 中配置 post-build 清理步骤，避免缓存跨构建污染
降低安全合规风险
未清理的旧版本镜像常含已知 CVE 漏洞（如旧版 nginx、log4j 相关基础镜像）。它们虽未运行，但一旦被误拉取、误部署或遭内部扫描工具识别，即构成合规审计项。镜像仓库中滞留的测试镜像、debug 标签镜像，也可能泄露敏感路径或调试信息。
- 建立镜像生命周期策略：生产环境镜像保留最近3个稳定版本，其余自动标记为 deprecated 并7天后清理
- 结合 Trivy 或 Clair 对待清理镜像做离线扫描，确认无高危漏洞后再执行 docker rmi
- 禁止在镜像标签中使用 latest 部署生产服务，确保清理操作可精准控制范围
支撑镜像仓库高效协同与治理
本地 Docker daemon 清理与远端镜像仓库（如 Harbor、Nexus）需联动。若只清本地不清理仓库，团队仍会重复拉取冗余镜像；若只清仓库不规范本地缓存，CI 节点将频繁重建相同层，浪费带宽与 CPU。
- 在 Harbor 中配置项目级 Retention Policy，按标签正则（如 *-beta、*-snapshot）自动删除过期镜像
- 定期同步仓库清理日志与本地 docker images 输出，识别“仅存在于本地”的孤立镜像
- 对私有仓库开启镜像签名（Notary）和内容信任（DOCKER_CONTENT_TRUST=1），确保清理前可验证镜像来源与完整性
