Docker 镜像清理怎么在持续集成服务器上自动化管理存储配额-Docker-PHP中文网

自动化Docker镜像配额管理需分级响应磁盘水位：>80%删非latest镜像，>90%删未引用镜像并清理builder，>95%慎用system prune；结合CI流水线清理、label保护机制及定期归档至对象存储。

在持续集成服务器上自动化管理 docker 镜像存储配额，核心不是“一刀切删光”，而是建立一套响应式、可预测、带策略的清理机制。重点在于：监控磁盘水位 → 触发对应强度的清理动作 → 保留关键镜像（如 latest、prod 标签）→ 避免影响正在运行或即将构建的任务。

按磁盘使用率分级触发清理

这是最实用、最稳妥的配额管理方式。不依赖时间或标签数量，而是根据真实资源压力动态响应：

>80% 使用率：只清理非 latest 标签的镜像（保留每个镜像的最新版本）
>90% 使用率：进一步清理所有未被任何容器引用的镜像（包括有标签但闲置的），同时执行 docker builder prune
>95% 使用率：启用紧急模式，强制 docker system prune -a --volumes --force（慎用，建议加白名单保护生产镜像）

可将该逻辑写入 shell 脚本，并通过 cron 每 10 分钟检查一次：

#!/bin/bash
USAGE=$(df /var/lib/docker | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$USAGE" -gt 90 ]; then
  docker image prune -a -f --filter "label!=protected=prod"
  docker builder prune -f
elif [ "$USAGE" -gt 80 ]; then
  docker images --format "{{.Repository}}:{{.Tag}}" | grep -v ":latest$" | xargs -r docker rmi 2>/dev/null
fi

绑定 CI 流水线生命周期清理

让清理动作成为构建流程的一部分，而非后台“偷偷干”。在 Jenkins、GitHub Actions 或 GitLab CI 的 post-build 阶段加入清理步骤：

构建成功后，自动删除本次构建生成的临时标签（如 pr-123、feature/login-v2）
若本次构建打上了 dev 标签，则自动清理 7 天前的其他 dev 标签
对测试环境镜像加 label（如 docker build --label env=test ...），后续统一按 label 清理

示例（GitHub Actions）：

Docker Encyclopedia

Docker 文档优先工作流：针对 Docker 特定问题、故障排除、命令规划、镜像/构建、容器/运行时操作及 Compose 等

下载

- name: Cleanup old dev images
  if: github.event_name == 'push' && startsWith(github.head_ref, 'dev/')
  run: |
    docker images --filter "label=env=test" --format "{{.Repository}}:{{.Tag}}" | \
      sort -V | head -n -7 | xargs -r docker rmi

为关键镜像设置保护机制

避免误删导致部署中断。可通过以下任一方式标记“不可删”镜像：

使用 --label protected=prod 构建生产镜像，清理脚本中跳过带该 label 的镜像
固定保留 :latest 和 :vX.Y.Z（语义化版本）标签，用正则过滤掉 .*-dev-.*、.*-test-.* 等非正式标签
在 Harbor/Nexus 等仓库中配置 retention 策略，例如：keep last 5 images for tags matching "prod-*"