1. Docker Build Cache 的磁盘空间占用分析第一次在服务器上执行docker system df命令时看到 Build Cache 占用了 17GB 空间我整个人都不好了。这就像你家的储物间不知不觉就被各种可能有用的东西塞满了。Docker 的构建缓存机制本意是好的 - 它缓存了镜像构建过程中的中间层下次构建时可以直接复用显著提升构建速度。但长期积累下来这些缓存会像滚雪球一样占用大量磁盘空间。docker system df的输出分为四个部分Images所有镜像占用的空间包括拉取的和本地构建的Containers运行中的容器占用的读写层空间Local Volumes容器挂载的本地数据卷空间Build Cache使用 BuildKit 时产生的构建缓存Docker 18.09关键要看最后一列RECLAIMABLE这表示可以安全回收的空间大小。在我的案例中Build Cache 的 17.17GB 居然 100% 都可以回收这就好比发现储物间里堆的全是过期的快递盒随时可以清理。2. 基础清理命令与风险控制2.1 一键清理所有构建缓存最简单的清理命令是docker builder prune这相当于大扫除时把储物间清空。但要注意这会删除所有未被使用的构建缓存不会影响正在使用的缓存比如最近构建的镜像依赖的缓存层系统会要求确认操作除非加上-f强制参数我建议第一次清理时不要用-f先看看系统准备删除哪些内容。有一次我盲目用了-f结果把 CI 流水线需要的缓存层删了导致后续构建变慢。2.2 按时间保留最近缓存更聪明的做法是保留近期缓存docker builder prune --filter until240h这个命令会保留最近 240 小时10天的构建缓存删除更早的未使用缓存适合需要平衡磁盘空间和构建速度的场景在 CI 环境中我通常设置为保留 7 天缓存因为我们的代码库基本每周都有更新保留一周缓存可以保证大部分增量构建都能受益。3. 高级清理策略与实战技巧3.1 多维度组合清理当磁盘空间真的告急时我会采用组合拳# 先清理构建缓存 docker builder prune --filter until72h -f # 再清理悬空镜像 docker image prune -f # 最后清理停止的容器 docker container prune -f这种渐进式清理比直接用docker system prune -a安全得多。有一次我在生产环境用了-a参数结果把备用的容器镜像全删了导致紧急回滚时差点出事。3.2 BuildKit 专属优化如果你使用 BuildKit现代 Docker 默认启用还可以# 查看详细的缓存使用情况 docker buildx du # 只删除特定构建器的缓存 docker buildx prune --builder my-builder在 CI 流水线中我习惯在每个 job 结束时清理当前构建器的缓存# 在GitLab CI中的示例 after_script: - docker buildx prune --builder $CI_PROJECT_NAME --filter until48h -f4. 预防性维护与自动化方案4.1 定期清理脚本这是我用在生产环境的清理脚本#!/bin/bash THRESHOLD85 # 磁盘使用率阈值 CURRENT$(df / | awk NR2 {print $5} | sed s/%//) if [ $CURRENT -ge $THRESHOLD ]; then echo 磁盘使用率 ${CURRENT}%开始清理... # 保留最近3天缓存 docker builder prune --filter until72h -f # 清理其他资源 docker system prune -f # 记录日志 echo $(date): 自动清理完成 /var/log/docker_clean.log fi配合 crontab 每小时检查一次0 * * * * /usr/local/bin/docker-cleanup.sh4.2 构建时优化建议从源头减少缓存积累合理使用.dockerignore文件多阶段构建中明确标记缓存阶段# 明确指定缓存来源 FROM node:16 as builder RUN npm install # 这层会被缓存 FROM builder as build COPY . . RUN npm run build FROM nginx:alpine COPY --frombuild /app/dist /usr/share/nginx/html在 CI 中使用--no-cache参数构建基础镜像docker build --no-cache -t base-image .5. 疑难问题排查与恢复5.1 清理后构建变慢怎么办如果发现清理缓存后构建速度明显下降检查是否保留了基础层的缓存docker history your-image重建缓存基准# 先构建一次生成缓存 docker build -t temp-image . # 立即构建第二次应该会快很多 docker build -t temp-image .5.2 误删恢复方案如果不小心删除了重要缓存检查本地是否有镜像备份docker images --all从镜像仓库重新拉取docker pull your-registry/your-image使用docker build --cache-from指定缓存源docker build --cache-fromyour-registry/your-image -t your-image .记得下次清理前先用docker builder prune --dry-run查看将要删除的内容。这个教训是我用一次生产事故换来的 - 当时清理了 50GB 缓存后全团队的构建时间翻了三倍。