一次 GitLab 无法启动的排查:Docker 日志把 500G 磁盘打满


一次 GitLab 无法启动的排查:Docker 日志把 500G 磁盘打满

一、问题现象

重启 GitLab 容器时报错:

bash 复制代码
Error response from daemon: Cannot restart container gitlab: 
open /data/docker/containers/.../.tmp-resolv.conf.hash: no space left on device

第一眼看起来像:

  • GitLab 容器损坏
  • Docker 崩溃
  • 网络异常

但真正的核心报错只有一句话:

no space left on device


二、第一步:确认磁盘状态

执行:

bash 复制代码
df -h

结果:

bash 复制代码
/dev/vdb   500G  500G  260K  100%  /data

结论:

/data 磁盘 500G 已经 100% 打满。

而 Docker 数据目录就在:

bash 复制代码
/data/docker

三、第二步:定位大目录

bash 复制代码
du -sh /data/* | sort -rh

结果:

bash 复制代码
354G   /data/docker
97G    /data/ai_iot
7.3G   /data/gitlab

可以看到:

Docker 占用了 354G。


四、第三步:继续细分 Docker 目录

bash 复制代码
du -sh /data/docker/* | sort -rh

结果:

bash 复制代码
204G   /data/docker/containers
149G   /data/docker/overlay2

关键问题找到了:

/data/docker/containers 占用了 204G。


五、containers 目录是什么?

这个目录主要存储:

bash 复制代码
/data/docker/containers/<container_id>/*-json.log

也就是:

Docker 容器运行日志文件

Docker 默认使用 json-file 作为日志驱动:

  • 不限制日志大小
  • 不自动轮转
  • 持续追加写入

如果是 CI 服务,比如:

  • GitLab
  • GitLab Runner

构建日志会非常巨大。


六、确认具体日志文件

可以查看最大日志:

bash 复制代码
ls -lh /data/docker/containers/*/*-json.log | sort -k5 -rh | head

通常会发现某个容器日志达到几十甚至上百 GB。


七、紧急处理方案(安全)

清空日志:

bash 复制代码
truncate -s 0 /data/docker/containers/*/*-json.log

特点:

  • ✅ 不删除容器
  • ✅ 不删除数据
  • ✅ 不影响运行
  • ✅ 立即释放空间

执行后:

bash 复制代码
df -h

会看到磁盘空间立即恢复。

然后重启容器:

bash 复制代码
docker restart gitlab

八、根本原因

Docker 默认日志策略:

text 复制代码
log-driver: json-file
无大小限制
无轮转
无限增长

时间一长必然爆盘。


九、长期解决方案(必须做)

编辑:

bash 复制代码
/etc/docker/daemon.json

加入:

json 复制代码
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

然后重启 Docker:

bash 复制代码
systemctl restart docker

效果:

  • 单个日志文件最大 100MB
  • 最多保留 3 个
  • 自动轮转
  • 不会再爆盘

十、经验总结

这次问题本质不是:

  • ❌ GitLab 损坏
  • ❌ 容器崩溃
  • ❌ Docker Bug

而是:

Docker 日志无限增长导致磁盘打满。

排查思路总结:

  1. 先看 df -h
  2. 找最大目录 du -sh
  3. 定位 Docker 子目录
  4. 判断是 overlay / image / containers
  5. 针对性处理

十一、推荐运维建议

如果服务器长期运行:

  • 必须设置 Docker 日志限制
  • 定期执行 docker system prune
  • 监控磁盘使用率
  • 对 CI 构建日志进行控制

否则爆盘只是时间问题。


结语

这类问题非常常见,但容易被误判为:

  • GitLab 故障
  • Docker 崩溃
  • 容器异常

其实 90% 的情况只是:

磁盘满了。

希望这次排查过程能帮到遇到类似问题的人。


相关推荐
梦想不只是梦与想10 小时前
Docker Compose文件
docker·容器·docker compose
小周学学学12 小时前
vmware-horizon第四章:事件数据库配置(docker)
运维·docker·容器
xzl0413 小时前
Ubuntu24.04 生产环境 Docker(全国内源)
运维·docker·容器
μθημα14 小时前
K8s Pod 管理实战:虚拟机环境下的具体命令与步骤
java·docker·kubernetes
梦梦代码精14 小时前
深度体验BuildingAI:一款集成商业闭环的开源智能体平台
人工智能·docker·开源·代码规范
ylj_dev15 小时前
从 0 构建 AI Workload Platform(八):受限执行环境与 Kubernetes
docker·容器·kubernetes·分布式系统·ai工作流·容器安全·ai infra
烬羽15 小时前
Dockerfile 是"做奶茶的配方"?用 todos 全栈项目看懂 Docker 构建与发布
nginx·docker·nestjs
lswzw18 小时前
K8s容器网络排查实战:从宿主机穿透命名空间定位端口监听问题
开发语言·docker·容器
悠然南风1 天前
【云原生学习】Prometheus监控、GitLab与Jenkins部署实战
kubernetes·gitlab
wazmlp0018873691 天前
k8s pod 管理
docker·容器·kubernetes