磁盘使用率超80%时应自动清理：先用df检测，再执行docker builder prune、image prune（72小时内未引用）和container prune分步清理，避免误删CI依赖网络。
磁盘使用率超阈值时自动触发清理
直接用 df 查根分区或 Docker 数据盘使用率，超过 80% 就该动手了——别等 no space left on device 报错才反应。关键不是“能不能删”，而是“删哪些不影响正在跑的构建任务”。CI 构建机上，镜像往往只被当前 job 引用一次，旧镜像基本无后续依赖，但得避开正在构建中、刚 pull 完还没 run 的镜像。
用 docker system df 精准定位空间大户
执行 docker system df 能立刻看到四类资源的占用明细：Images、Containers、Local Volumes、Build Cache。CI 机上最常被忽略的是 Build Cache，它可能占几 GB 却 100% 可回收；而 Local Volumes 通常少，除非你显式挂了 -v 存构建产物。重点看 RECLAIMABLE 列，它告诉你不重启服务就能释放多少空间。
组合命令实现“安全+按需”清理
不要一上来就 docker system prune -a --force ——它会清掉所有未使用的网络，而某些 CI 工具（如 GitLab Runner）依赖自定义网络通信，误删会导致 job 失败。推荐分步执行：
-
docker builder prune -f：必做，构建缓存不绑定任何容器，删了不影响运行中任务 -
docker image prune -f --filter "until=72h"：只删 72 小时内没被任何容器（含已退出）引用的镜像，比-a更保守 -
docker container prune -f：清理已退出的构建容器，它们的可写层还在占空间 - 卷（
volumes）不加--volumes参数，CI 场景极少持久化数据，但万一用了cache或artifacts卷，得单独判断
写进 CI 构建前钩子的最小可行脚本
把清理逻辑塞进构建流程开头，比依赖 cron 更及时——毕竟构建高峰时空间压力最大。示例脚本片段（Bash）：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
#!/bin/bash
DISK_USAGE=$(df /var/lib/docker | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 80 ]; then
echo "⚠️ Disk usage ${DISK_USAGE}%, triggering cleanup..."
docker builder prune -f > /dev/null
docker image prune -f --filter "until=72h" > /dev/null
docker container prune -f > /dev/null
logger "CI cleanup triggered at ${DISK_USAGE}%"
fi
注意：路径 /var/lib/docker 要和你的 docker info | grep "Docker Root Dir" 输出一致；如果 Docker 数据盘在 /data/docker，就得换路径。另外，logger 写系统日志，方便事后审计哪次构建触发了清理。
真正容易被忽略的是镜像层共享关系——哪怕你删了一个标签，只要同一 IMAGE ID 还被其他镜像引用着，底层层数据就不会丢。所以不用怕删错，Docker 的分层机制天然兜底；但得提防脚本里写死的路径、硬编码的阈值，这些在不同环境迁移时最容易失效。
