Golang容器镜像自动清理脚本分享

本文深入剖析了用 Golang 开发容器镜像自动清理脚本时极易踩坑的核心难点：盲目删除不仅可能中断运行中的服务，还会破坏构建缓存、拖慢后续 CI/CD 流程；真正安全的清理必须基于 docker system df -v 和 docker images 的结构化输出精准识别镜像状态，结合 docker ps -a、inspect、buildx du 等多维度交叉验证引用关系，规避 dangling 判断失效、时间过滤误伤、并发超载、权限缺失等常见陷阱——它不是简单的命令封装，而是一场对 Docker 内部依赖图谱的严谨测绘与敬畏式操作。

用 docker system df 和 docker images 做清理前的准确判断

直接删镜像容易误伤正在运行的容器或未打标签的中间层，得先确认哪些真能删。Golang 脚本里别自己解析 docker images -q 输出再拼接过滤逻辑——那会漏掉 镜像和 dangling 层。正确做法是调用 docker system df -v 获取 JSON 输出（加 --format "{{json .}}" 更稳），再结合 docker images --format "{{.ID}}\t{{.Repository}}:{{.Tag}}\t{{.CreatedSince}}" 补充元数据。

常见错误是只看 REPOSITORY 为 就删，但有些构建缓存层虽然没标签，却被当前 Dockerfile 的后续阶段依赖；还有些镜像被本地 buildx 构建器隐式引用，删了会导致下次构建拉取失败。

• 用 docker images -f "dangling=true" -q 只能捕获部分 dangling 镜像，必须配合 docker builder prune --dry-run 检查 build cache 引用
• CreatedSince 字段在不同 Docker 版本输出格式不一致，建议统一用 CreatedBefore 过滤（如 --filter "before=2024-01-01"）
• 脚本启动时加 --prune-system 参数才触发 docker system prune -f，否则只清理镜像不碰构建缓存和网络

用 exec.Command 安全调用 Docker CLI，别手写 HTTP 请求

有人想绕过 CLI 直连 Docker daemon 的 /images/json API，结果卡在 TLS 验证、socket 路径硬编码、版本兼容上。Golang 标准库的 exec.Command 更可靠：它复用用户环境里的 Docker CLI 配置（包括 DOCKER_HOST、DOCKER_CONTEXT、~/.docker/config.json 认证），且自动处理退出码和 stderr 重定向。

关键点是别忽略 cmd.Run() 的 error 类型——Docker CLI 返回非零码时，exec.ExitError 包含真实退出码，比如 125 是权限不足，126 是命令不可执行，127 是找不到命令。直接用 err.Error() 会丢掉这个信息。

• 用 cmd.CombinedOutput() 代替 cmd.Output()，避免 stderr 被吞导致调试困难
• 设置 cmd.Timeout（如 30 秒），防止 Docker daemon 卡死拖垮整个脚本
• 对 docker rmi 批量操作，每次最多传 50 个 ID，超长参数列表在某些 shell 下会触发 Argument list too long

按引用关系递归清理，而不是按时间硬删除

单纯按创建时间删镜像最危险：一个上周构建的 base 镜像可能正被今天跑的容器使用，删了容器就起不来。Golang 脚本得先跑 docker ps --format "{{.Image}}" 拿到所有运行中容器的镜像名，再用 docker image inspect 查它们的 Id 和 RepoDigests，最后比对要删的镜像 ID 是否出现在任一容器的 Image 或 RepoDigests 里。

更隐蔽的是 build cache 引用：docker builder ls 不暴露具体镜像 ID，得用 docker buildx du --verbose 解析 JSON 输出里的 CacheReferences 字段。这部分常被忽略，导致清理后下次 docker build 慢三倍。

• 检查容器状态时用 docker ps -a 而非 docker ps，避免漏掉已退出但未清理的容器所依赖的镜像
• RepoDigests 是数组，内容形如 "registry.example.com/app@sha256:abc123"，需提取 sha256:... 部分与待删镜像的 Id 做前缀匹配
• 对 multi-stage 构建生成的中间镜像，docker images -f "dangling=true" 未必能覆盖全，得靠 docker system df -v 里的 Layers 字段反向查归属

清理失败时保留上下文，别静默跳过

脚本遇到 docker rmi 失败，不能只打一行 log.Printf("skip %s: %v", id, err) 就完事。得记录完整命令、退出码、stderr 内容、当前镜像的 docker image inspect 输出片段——否则线上出问题根本没法回溯是权限问题、还是被容器锁定、或是 registry 认证失效。

另一个坑是并发清理：Golang 里开 goroutine 调 docker rmi 看似快，但 Docker daemon 本身是单线程处理删除请求，大量并发反而触发排队超时，还可能因竞争导致部分镜像被重复删除报错。

• 失败时把原始 exec.ExitError.Stderr 写入临时文件（路径用 os.TempDir() + 时间戳），文件名带镜像 ID 前缀
• 用 sync.WaitGroup 控制并发数，上限设为 3～5，比默认的 100 更稳妥
• 对 permission denied 类错误，附加检查 /var/run/docker.sock 的权限和当前用户是否在 docker 组里

真正难的不是写几行 exec.Command，而是搞清每个镜像背后谁在用、为什么不能删、删了影响什么——这些关系藏在 Docker daemon 的状态里，不在你的 Go 代码里。

到这里，我们也就讲完了《Golang容器镜像自动清理脚本分享》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！