服务器镜像清理必须作用于仓库服务本身并启用垃圾回收机制，而非仅依赖本地docker image prune；DOCR、Harbor等支持自动GC，但需验证配置并配合干运行校验、日志记录与告警脚本及配套治理策略。
服务器镜像清理不能只靠本地 docker image prune，因为对象存储（如 DOCR、Harbor 后端 S3/MinIO、自建 Registry 的存储）里的镜像数据是独立于宿主机的。自动清理必须作用于仓库服务本身，并配合其垃圾回收（Garbage Collection）机制，而非简单删除本地缓存。
确认目标仓库是否支持自动 GC
不是所有私有 Registry 都默认启用 GC。需先验证：
- DigitalOcean Container Registry（DOCR）：原生支持，通过
doctl registry garbage-collect触发 - 开源 Docker Distribution（官方 Registry）：需手动执行
bin/registry garbage-collect，且配置文件中delete.enabled: true必须开启 - Harbor：提供 UI 和 API 清理策略，支持按项目、标签正则、保留天数等规则自动清理
- 自建 Registry + S3/MinIO 后端：GC 成功后，底层对象存储中的未引用 layer blob 才会被真正删除（前提是后端支持 delete 操作且权限正确）
编写安全可靠的定时清理脚本
以 DOCR 为例，一个生产可用的每日清理脚本应包含干运行校验、日志记录和失败告警：
#!/bin/bash # docr-daily-gc.sh LOGFILE="/var/log/docr-gc-$(date +\%Y\%m\%d).log" echo "=== $(date) ===" >> $LOGFILE <h1>1. 先干运行，记录哪些 layer 将被清理</h1><p>doctl registry garbage-collect --dry-run 2>&1 >> $LOGFILE DRY_RESULT=$?</p><h1>2. 若干运行无严重错误，再执行真实 GC</h1><p>if [ $DRY_RESULT -eq 0 ]; then echo "Starting real garbage collection..." >> $LOGFILE doctl registry garbage-collect --verbose 2>&1 >> $LOGFILE REAL_RESULT=$? if [ $REAL_RESULT -eq 0 ]; then echo "✅ GC completed successfully." >> $LOGFILE else echo "❌ GC failed with exit code $REAL_RESULT" | mail -s "DOCR GC Alert" admin@example.com fi else echo "⚠️ Dry-run failed. Skipping real GC." | mail -s "DOCR GC Warning" admin@example.com fi
关键点：永远先 --dry-run；检查返回码而非仅输出文本；失败时触发邮件或 webhook 告警。
绑定到系统定时任务
将脚本加入 crontab，例如每天凌晨 2:30 执行：
30 2 * * * /usr/local/bin/docr-daily-gc.sh
确保运行环境已配置好：
-
doctl已安装且DOCTL_TOKEN环境变量或默认配置已就绪 - 脚本具有可执行权限：
chmod +x /usr/local/bin/docr-daily-gc.sh - 使用
sudo crontab -e或系统用户 crontab，避免权限不足导致 registry 访问失败
配套治理策略不可少
光靠 GC 脚本治标不治本。必须同步落地以下措施：
- CI/CD 流水线中禁止无节制打
latest或 commit-hash 标签，改用语义化版本 + 自动过期策略 - 为每个项目设置镜像保留规则（如：最多保留最近 5 个 tag，或 30 天内未拉取的镜像自动下线）
- 定期审计
docker images -f dangling=true和docker system df，确认本地与远端清理效果一致 - 在对象存储控制台（如 AWS S3 Lifecycle Policy）配置兜底规则：对未被 GC 清理的残留 blob，7 天后强制删除（仅作最后防线，非推荐主流程）
