服务器镜像清理必须作用于仓库服务本身并启用垃圾回收机制，而非仅依赖本地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
</p>

关键点：永远先 --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 天后强制删除（仅作最后防线，非推荐主流程）