一、典型场景分析

某次凌晨三点，我正盯着持续集成流水线的红色警告——"No space left on device"。此时测试环境的Runner节点磁盘占用率突破95%，导致前端构建任务集体失败。这种场景在微服务架构下尤为常见，特别是当多个项目共享同一Runner时：

  1. Docker构建产生的分层镜像缓存
  2. Node.js项目的node_modules重复安装
  3. Maven/Gradle依赖包的版本堆积
  4. 未及时清理的CI作业产物（如测试报告、编译包）

这些"数字垃圾"会以每月10-20GB的速度蚕食磁盘空间。最近处理的一个Java项目案例中，仅.m2仓库就囤积了超过50个历史版本的依赖包。

二、精准释放磁盘空间

2.1 术前诊断

我门用Linux技术栈

# 查看磁盘使用概况（人类可读格式）
df -h | grep -v tmpfs

# 定位最大目录（按大小倒序显示前10）
du -sh /* 2>/dev/null | sort -hr | head -n10

# 实时监控指定目录变化（以/var/lib/docker为例）
watch -n 5 'du -sh /var/lib/docker/{overlay2,containers}'

2.2 专项清理方案

场景A：Docker构建残留

# 清理悬空镜像和停止的容器
docker system prune -f

# 按时间过滤删除旧镜像（保留最近3个版本）
docker images | grep 'your-image-name' | tail -n +4 | awk '{print $3}' | xargs docker rmi

# 深度清理构建缓存（需停止docker服务）
systemctl stop docker
rm -rf /var/lib/docker/overlay2/*
systemctl start docker

场景B：Maven本地仓库

# 保留最近5个版本的依赖（需安装findutils）
find ~/.m2/repository/ -type d -name "*-SNAPSHOT" -mtime +30 -exec rm -rf {} +

# 定期清理metadata（防止索引膨胀）
ls -td ~/.m2/repository/**/.repositories | xargs rm

场景C：Node.js项目优化

# 使用多阶段构建减少最终镜像体积
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

三、从应急到长期方案

3.1 本地磁盘扩容（物理机场景）

# 扩展逻辑卷（假设新增/dev/sdb1）
pvcreate /dev/sdb1
vgextend centos /dev/sdb1
lvextend -l +100%FREE /dev/centos/root
xfs_growfs /dev/centos/root

3.2 云存储动态挂载（AWS示例）

# 创建并挂载EBS卷（需AWS CLI配置）
resource "aws_volume_attachment" "runner_ebs" {
  device_name = "/dev/sdh"
  volume_id   = aws_ebs_volume.runner_volume.id
  instance_id = aws_instance.gitlab_runner.id
}

# 自动格式化并挂载
mkfs -t xfs /dev/nvme1n1
mkdir /mnt/runner_storage
mount /dev/nvme1n1 /mnt/runner_storage
echo "/dev/nvme1n1 /mnt/runner_storage xfs defaults,nofail 0 2" >> /etc/fstab

3.3 分布式缓存方案

# .gitlab-ci.yml配置共享缓存
cache:
  key: "$CI_JOB_NAME"
  paths:
    - node_modules/
    - .m2/repository/
  policy: pull-push
  when: on_success
  
# 使用S3作为缓存后端（runner配置）
[[runners]]
  [runners.cache]
    Type = "s3"
    Path = "runner_cache"
    Shared = true
    [runners.cache.s3]
      ServerAddress = "s3.amazonaws.com"
      BucketName = "my-gitlab-cache"
      BucketLocation = "us-east-1"

四、技术方案对比分析

方案类型 实施难度 维护成本 恢复速度 适用场景
本地清理 ★☆☆☆☆ 周期性人工介入 立即生效 小型团队/临时应急
云存储扩容 ★★★☆☆ 按需付费 5-10分钟 云环境/弹性需求
分布式缓存 ★★★★☆ 初始配置复杂 依赖网络 大型集群/多项目共享

值得注意的隐形陷阱：

  1. Docker prune操作会清除所有悬空资源，可能误删其他项目的镜像
  2. 直接删除node_modules可能破坏项目依赖树
  3. 云存储扩容后需要检查inode使用率（df -i）
  4. 分布式缓存需设置合理的过期策略（建议不超过30天）

五、从血泪史中总结的最佳实践

经过二十多次实战处理，我总结出三条黄金法则：

  1. 预防优于治疗：在config.toml中设置offline_timeout = 3600自动清理闲置Runner
  2. 分级存储策略：将频繁变动的构建缓存（如Docker层）放在独立分区
  3. 空间水位监控：集成Prometheus+Alertmanager实现阈值预警

某金融项目通过实施上述方案后，CI/CD失败率从每周15次降至每月1次以下，构建速度提升40%。这印证了良好的磁盘管理对持续交付流水线的重要性。