Golang打造Docker镜像清理工具教程

本文详细讲解了如何使用 Go 语言开发一个安全、精准、生产可用的 Docker 镜像清理工具，直击 `docker system prune` 的粗粒度缺陷——它无差别删除悬空资源，而实际场景常需按镜像前缀、创建时间、保留数量等条件智能筛选，并严格跳过所有被运行或已停止容器引用的镜像；文章推荐采用稳定兼容的 `docker images --format '{{json .}}'` 解析方案替代复杂脆弱的 Docker SDK，结合容器镜像白名单构建、ID 去重、时间字段正确解析、分批删除及 PATH 安全检查等关键实践，帮你避开 CI/CD 和共享环境中的误删雷区，写出真正可靠、可维护的自动化运维工具。

为什么 docker system prune 不够用

它会删掉所有悬空镜像、容器、网络和构建缓存，但你往往只想清理特定前缀的镜像（比如 myapp-dev-），或保留最近 N 个标签，又或者只删 镜像但保留正在运行容器所依赖的。直接调 docker system prune -f 容易误伤，尤其在 CI/CD 节点或共享开发机上。

用 exec.Command 调 Docker CLI 比直接连 Docker socket 更稳妥

虽然 Go 有 github.com/docker/docker/api/types 等 SDK，但版本耦合紧、文档弱、错误处理琐碎；而解析 docker images --format '{{json .}}' 输出稳定、兼容性好，且不用处理 TLS 认证或 socket 权限问题。

实操建议：

• 始终用 --format '{{json .}}' 获取结构化输出，避免解析人眼友好的表格格式
• 用 encoding/json 解码到结构体，字段包括 Repository、Tag、ID、CreatedSince、Size
• 过滤前先调 docker images --all --quiet 确认是否能拿到 ID 列表，避免因权限失败静默跳过
• 删除时用 docker rmi -f 而非 docker image rm，前者对已悬空镜像更鲁棒

如何安全识别并跳过被容器引用的镜像

Docker 不会阻止你删正在被运行容器使用的镜像，但删完后 docker ps 仍显示容器，只是 Image 列变成 ID，后续 docker commit 或重建可能出错。必须提前排除。

做法是：

• 先执行 docker ps --format '{{.Image}}' 获取所有运行中容器的镜像名（含 tag 或 ID）
• 再执行 docker ps -a --format '{{.Image}}' 获取所有容器（含已停止）的镜像引用
• 将这些值归一化：若为 repo:tag，转成镜像 ID（通过 docker inspect -f '{{.Image}}' ）；若已是 ID，则直接加入白名单
• 最终比对时，只删那些 ID 不在白名单里的目标镜像

按时间或数量做保留策略时的边界陷阱

比如“保留最近 3 个 myapp:v* 镜像”，看似简单，但要注意：

• CreatedSince 字段是字符串（如 "2 hours ago"），不能直接排序；应解析为 time.Time 再比较
• 同一镜像多个 tag（如 myapp:v1.2 和 myapp:latest）指向同一个 ID，删 tag 不等于删镜像层；需按 ID 去重后再按创建时间选保留项
• 用 strings.HasPrefix(repo, "myapp-") && tag != "" 过滤时，注意 是字面量，不是空字符串
• 批量删除时别一次性传太多 ID 给 docker rmi，Linux 命令行长度有限制，建议每 20 个一组调用

最常被忽略的一点：没有检查 docker 命令是否存在或是否在 PATH 中——工具在最小化镜像（如 alpine）里跑会直接 panic，得提前 exec.LookPath("docker")。

今天关于《Golang打造Docker镜像清理工具教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！