1. 从一次真实的磁盘告警说起那天下午我正在调试一个微服务突然收到服务器监控的告警邮件“磁盘使用率超过85%”。登录服务器一看/var/lib/docker目录已经快被撑爆了其中overlay2文件夹是绝对的“罪魁祸首”。这场景对于任何一个重度使用 Docker 的开发者或运维来说都再熟悉不过了。Docker 的便利性毋庸置疑但它的“垃圾”清理问题尤其是overlay2存储驱动下的空间占用几乎成了每个容器化环境运维的必修课。很多人可能只是简单地执行docker system prune -a但这往往治标不治本甚至可能误删正在使用的镜像和容器。今天我就结合自己多次“踩坑”和“救火”的经验详细拆解overlay2目录空间膨胀的根源并分享一套从“治标”到“治本”、从“手动”到“自动”的完整清理策略。无论你是个人开发者还是负责生产环境的运维这篇文章都能帮你彻底搞懂并解决这个顽疾。2. 深入理解 Overlay2空间被“吃”掉的元凶要清理首先得知道“垃圾”从哪来。Docker 默认使用的存储驱动是overlay2它是一种联合文件系统。简单来说它像是一叠透明的幻灯片。最底层是只读的镜像层lowerdir上面叠加了可写的容器层upperdir。当我们查看容器内的文件时看到的是所有这些层合并后的视图merged。还有一个workdir用于准备文件操作。2.1 Overlay2 的目录结构解剖进入/var/lib/docker/overlay2你会看到很多以随机哈希命名的目录。每个目录代表一个层。关键要理解这几个子目录diff/这一层相对于其父层所做的修改内容。比如你在容器里新建了一个文件这个文件就会出现在容器对应层的diff目录里。link一个包含短名称的文件用于兼容旧版。lower一个文件里面记录了所有下层父层的短名称ID用:分隔。这指明了层的继承关系。merged/该层与其所有下层合并后的统一视图容器运行时挂载的正是这个路径。空间占用主要来自diff目录。每一次docker run基于镜像创建新容器、每一次在容器内写入文件包括日志、应用数据、临时文件、甚至每一次docker build生成新的镜像层都会在overlay2下创建新的diff目录或增加其内容。2.2 空间膨胀的四大核心原因停止的容器Stopped Containers容器停止后其可写层upperdir仍然占据着磁盘空间。这些数据包含了容器运行期间产生的所有变更。如果你习惯docker run测试一下就跑又不清理那么大量停止的容器就会成为“空间僵尸”。悬空镜像Dangling Images也称为“虚悬镜像”。当你构建新镜像时Docker 会为每一层创建一个中间镜像。如果构建失败或者你用docker image prune清理时不够彻底这些没有标签且不被任何容器引用的中间镜像层就会残留下来。它们同样占用overlay2的空间。未使用的镜像Unused Images所有你拉取pull过但当前没有任何容器包括停止的基于其运行的镜像。比如你为了测试拉取了多个版本的nginx、node用完后只保留了最新版在运行旧版本就变成了“未使用的镜像”。构建缓存Build Cache这是最容易被忽视的一点。Docker 在构建镜像时会利用缓存来加速。每一层指令如RUN apt-get update的结果都会被缓存。长期进行镜像构建尤其是Dockerfile频繁变动时会产生巨量的缓存层它们也存储在overlay2中。注意很多人误以为docker system prune能解决所有问题。实际上这个命令默认不会删除以下内容a) 正在运行的容器b) 至少被一个容器使用的镜像即使是停止的容器c) 被使用的卷。因此对于被停止容器占用的空间它可能无能为力。3. 手动清理实战从安全到彻底的完整操作流在动手之前强烈建议先查看磁盘占用情况做到心中有数。这里有几个关键命令# 查看Docker整体磁盘使用情况最直观 docker system df # 详细查看镜像、容器、本地卷、构建缓存各自占用的空间 docker system df -v # 直接定位overlay2目录的大小 du -sh /var/lib/docker/overlay2/看到具体数据后我们可以开始分级清理。原则是先安全后彻底先清理无状态垃圾再处理有状态数据。3.1 第一级清理无风险的“软垃圾”这部分操作通常不会影响正在运行的服务。1. 清理所有悬空镜像和构建缓存docker image prune -a加上-a参数会删除所有未被任何容器引用的镜像而不仅仅是悬空镜像。执行前会交互式确认可以加-f强制删除。这是释放空间最直接有效的一步之一。2. 清理停止的容器# 列出所有停止的容器 docker ps -a --filter statusexited # 删除所有停止的容器 docker container prune如果你只想删除特定停止的容器可以使用docker rm [容器ID]。3. 清理未使用的卷卷Volume是持久化数据通常不应随意删除。但确实存在一些创建后未被任何容器引用的“孤儿卷”。docker volume prune重要提示执行此命令前请务必确认这些卷确实没有重要数据。生产环境慎用或先备份。完成以上三步后再次运行docker system df你会看到RECLAIMABLE可回收空间大幅减少。3.2 第二级针对性清理大体积镜像和容器有时即使没有很多停止的容器或悬空镜像空间依然紧张可能是因为存在个别“巨无霸”镜像或容器。1. 找出占用空间最大的镜像docker images --format table {{.Repository}}\t{{.Tag}}\t{{.Size}} | sort -k 3 -h -r | head -20这个命令会按镜像大小倒序列出前20个很容易找到那些包含完整操作系统、SDK或编译工具链的大体积镜像。2. 找出容器内可写层占用大的容器docker ps -a --sizeSIZE列显示了容器可写层的大小。一个持续运行并产生大量日志或数据的容器其可写层可能非常大。3. 处理大体积容器日志驱动检查容器的日志驱动。默认的json-file日志驱动会不断累积日志文件在主机上。可以考虑配置日志轮转或使用外部日志驱动如journald,syslog,awslogs等。# 查看容器日志文件大小对于json-file驱动 find /var/lib/docker/containers/ -name *-json.log -exec du -sh {} | sort -rh | head -20清理容器内日志对于正在运行的容器如果日志文件在容器内部如/var/log可以进入容器清理但这只是临时方案。根本方案是优化应用日志级别和输出。数据卷管理如果容器将大量数据写入其可写层应考虑将这些数据挂载到宿主机的卷Volume或绑定挂载Bind Mount中这样数据生命周期就和容器解耦了。3.3 第三级直接操作 Overlay2 目录高风险这是最后的手段操作前务必备份并确认无重要容器在运行当 Docker 命令无法清理干净或者你想手动检查时可以这么做。停止 Docker 服务确保没有容器在读写overlay2。sudo systemctl stop docker # 或者 sudo service docker stop手动分析与清理进入/var/lib/docker/overlay2。使用du -sh * | sort -rh找出最大的目录。关键一步关联性检查。你需要确定哪些目录是正在被使用的。一个相对安全的方法是记录下当前所有容器和镜像使用的层ID。# 在停止Docker前获取所有容器使用的层ID docker inspect $(docker ps -aq) --format{{.GraphDriver.Data.MergedDir}} | xargs -I {} basename {} # 获取所有镜像的层ID更复杂通常镜像层ID在docker image inspect的RootFS.Layers中删除那些明确不被任何容器或镜像使用的、且体积巨大的目录。但请注意手动删除目录可能导致 Docker 数据库状态不一致引发更严重的问题。重启 Dockersudo systemctl start docker重启后Docker 会检查其元数据。如果删除了正在被引用的层相关容器或镜像将无法启动并报错“layer does not exist”。此时只能恢复数据或删除损坏的容器/镜像。个人经验我极少走到第三步。99% 的情况下前两级操作结合定期维护就能解决问题。手动删除overlay2目录就像直接操作数据库的底层文件风险极高除非你非常清楚每一个目录的归属否则不要尝试。有一次我误删了一个被隐藏的中间镜像层导致一批镜像需要重新构建教训深刻。4. 构建与运行习惯从源头减少空间占用清理是“治标”优化习惯才是“治本”。下面这些实践能从根本上缓解overlay2的空间压力。4.1 优化 Dockerfile减少镜像层数与体积合并 RUN 指令每一条RUN、COPY、ADD都会创建一个新层。# 不佳的做法 RUN apt-get update RUN apt-get install -y package1 RUN apt-get install -y package2 RUN apt-get clean # 推荐的做法使用 连接命令并在一行内清理 RUN apt-get update \ apt-get install -y package1 package2 \ apt-get clean \ rm -rf /var/lib/apt/lists/*使用 .dockerignore 文件避免将不必要的文件如node_modules,.git, 日志文件复制到构建上下文中它们不仅拖慢构建速度还可能被意外加入镜像。选择更小的基础镜像用alpine、slim版本替代完整的Debian或Ubuntu镜像。例如python:3.9-alpine比python:3.9小得多。多阶段构建Multi-stage Builds这是减少镜像体积的“杀手锏”。在第一个阶段如包含完整的编译工具链完成编译在第二个阶段一个干净的小镜像只复制编译好的二进制文件。# 第一阶段构建 FROM golang:1.19 AS builder WORKDIR /app COPY . . RUN go build -o myapp . # 第二阶段运行 FROM alpine:latest WORKDIR /root/ COPY --frombuilder /app/myapp . CMD [./myapp]最终镜像只包含alpine和你的二进制文件而不包含golang编译器和源码。4.2 优化容器运行习惯为容器设置适当的重启策略对于非持久化容器使用--restartno或--restarton-failure避免容器异常退出后不断重启累积旧实例。使用--rm参数运行临时容器对于一次性任务或测试使用docker run --rm ...容器停止后会自动删除其可写层非常清爽。合理管理数据将需要持久化的数据数据库文件、上传内容、日志通过-v挂载到宿主机目录或 Docker Volume 中而不是写在容器内部。及时清理测试环境开发或测试后养成习惯清理停止的容器和未使用的镜像。5. 自动化与监控建立长效维护机制对于生产环境或个人长期使用的服务器手动清理不是长久之计。我们需要建立自动化机制。5.1 配置 Docker 守护进程的日志轮转编辑/etc/docker/daemon.json如果不存在则创建{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }这会将每个容器的日志文件大小限制在10MB最多保留3个文件当前日志2个归档。修改后需要重启 Docker 服务生效。5.2 使用定时任务Cron Job自动清理创建一个脚本例如/usr/local/bin/docker-cleanup.sh#!/bin/bash # 记录日志 echo $(date): Starting Docker cleanup /var/log/docker-cleanup.log # 1. 删除所有悬空镜像和构建缓存 docker image prune -af 21 /var/log/docker-cleanup.log # 2. 删除所有停止的容器超过24小时 docker container prune --filter until24h -f 21 /var/log/docker-cleanup.log # 3. 删除所有未被使用的卷谨慎生产环境可注释掉或加更多过滤条件 # docker volume prune -f 21 /var/log/docker-cleanup.log # 4. 删除所有未被使用的网络通常占用空间小可选 docker network prune -f 21 /var/log/docker-cleanup.log echo $(date): Docker cleanup finished /var/log/docker-cleanup.log给脚本执行权限chmod x /usr/local/bin/docker-cleanup.sh。然后通过crontab -e添加定时任务例如每天凌晨3点执行0 3 * * * /usr/local/bin/docker-cleanup.sh注意docker volume prune在生产环境要极其小心最好根据实际情况注释掉或添加更严格的过滤器如--filter。我个人的策略是只对明确标记为temp或cache的卷进行自动清理。5.3 集成到监控告警系统将 Docker 磁盘使用率纳入你的监控系统如 Prometheus Grafana, Zabbix。当/var/lib/docker分区使用率超过某个阈值如80%时自动触发告警并可以联动执行清理脚本或通知人工处理。这实现了从被动清理到主动预防的转变。6. 进阶排查当清理后空间仍未释放的诡异情况有时候执行了所有清理命令df -h显示磁盘空间已释放但du -sh /var/lib/docker/显示的大小和df报告的总使用量对不上。或者空间释放后很快又被占满。这可能涉及到更深层次的文件系统问题。6.1 已删除文件被进程占用空间未释放这是 Linux 系统的一个经典问题。如果一个文件被进程打开例如一个容器日志文件被 Docker 守护进程打开即使你从文件系统中删除了它rm只要进程不关闭文件句柄该文件占用的磁盘空间就不会被释放。排查方法# 使用 lsof 命令查找被删除但仍被进程占用的文件 lsof L1 | grep deleted你会看到类似这样的输出COMMAND是dockerdNAME后面有个(deleted)dockerd 1234 root 123u REG 253,0 1048576000 123456 /var/lib/docker/containers/xxx/xxx-json.log (deleted)这表示一个100MB的日志文件已被删除但句柄还被dockerd持有。解决方案重启持有该文件句柄的进程最直接的方法是重启 Docker 服务 (sudo systemctl restart docker)。这会关闭所有句柄空间立即释放。但这是有损操作会重启所有容器。通知进程重新打开日志对于某些应用可以发送信号如SIGUSR1让其重新打开日志文件。但 Docker 守护进程通常不支持。预防配置日志轮转如前文所述限制单个日志文件大小让 Docker 自动关闭并归档旧日志文件句柄。6.2 文件系统碎片化或 Inode 耗尽虽然现代文件系统如ext4、xfs碎片化问题不严重但在极端频繁的创建删除小文件场景下比如大量临时容器仍可能发生。更常见的是inode 耗尽。排查方法# 查看磁盘空间使用 df -h # 查看 inode 使用情况 df -i如果Use%列在df -h中不高但在df -i中接近100%说明 inode 用完了。即使有剩余磁盘空间也无法创建新文件或目录。解决方案清理大量小文件。在 Docker 场景下可能是成千上万个停止容器的微小层或者构建缓存产生的大量小文件。如果/var/lib/docker是独立分区考虑在创建时分配更多的 inode 数量使用-N参数格式化。但这通常需要重新规划分区。6.3 Overlay2 的 “l” 目录硬链接问题在overlay2的每个层目录里你可能还会看到一个l目录里面包含了一些硬链接。这是overlay2用于共享相同数据块、节省空间的机制。通常不需要手动干预。但如果 Docker 的元数据出现损坏可能会导致硬链接计数异常但这种情况非常罕见。经过以上六个部分的拆解从原理到实操从手动到自动从治标到治本你应该对docker overlay2的空间管理有了一个全面且深入的理解。最关键的是养成好的习惯使用多阶段构建、及时清理、挂载数据卷、配置日志轮转。最后把那个自动清理的 Cron 任务设置好让它默默地在后台为你工作从此告别磁盘空间告警的烦恼。
