当前位置：首页 > news >正文

别再只会用`docker system prune`了！聊聊Docker磁盘清理的5个隐藏场景与实战命令

news 2026/5/23 19:12:31

别再只会用`docker system prune`了！聊聊Docker磁盘清理的5个隐藏场景与实战命令

Docker作为现代开发与运维的核心工具，其便捷性背后往往隐藏着磁盘管理的复杂性。当docker system prune成为大多数人的清理"万能药"时，真正棘手的磁盘问题却常常出现在那些未被充分讨论的角落——容器日志的失控增长、overlay2目录的神秘膨胀、构建缓存的隐形堆积……这些场景需要的不是一刀切的清理，而是精准的手术刀式操作。

1. 容器日志轮转：从根源解决`/var/lib/docker/containers`爆满问题

当df -h显示/var分区即将爆满时，/var/lib/docker/containers往往是罪魁祸首。默认情况下，Docker容器会将所有标准输出日志以JSON格式存储在此目录，且没有自动轮转机制。我曾见过一个生产环境的Nginx容器在三个月内产生了47GB的日志文件。

1.1 即时清理与日志定位

首先用以下命令快速定位磁盘占用最高的容器日志：

du -d 1 -h /var/lib/docker/containers/ | sort -h

找到目标容器ID后，可以临时清空日志文件（注意：这会丢失所有历史日志）：

truncate -s 0 /var/lib/docker/containers/<container_id>/<container_id>-json.log

1.2 配置日志轮转策略

更专业的做法是在容器启动时配置日志驱动和轮转参数：

docker run --log-driver json-file \ --log-opt max-size=100m \ --log-opt max-file=3 \ nginx

关键参数说明：

max-size：单个日志文件最大尺寸（支持k,m,g单位）
max-file：保留的历史日志文件数量

对于已运行的容器，修改/etc/docker/daemon.json全局配置并重启Docker服务：

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

提示：修改全局配置会影响所有新创建的容器，已存在的容器需要重建才能生效

2. 解剖`overlay2`：读写层异常增长的诊断与修复

Docker存储驱动采用的overlay2文件系统，会在/var/lib/docker/overlay2下为每个容器创建读写层（merged目录）。当这些目录异常增长时，常规清理往往无效。

2.1 定位问题容器

使用以下命令查看各容器占用的磁盘空间（包括读写层）：

docker ps -s --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"

输出示例：

CONTAINER ID NAMES SIZE a1b2c3d4e5f6 mysql_db 2.45GB (virtual 1.2GB)

其中"SIZE"列显示的是读写层大小，"(virtual)"表示镜像基础大小。

2.2 深入分析具体容器

对可疑容器进行深入检查：

docker exec -it <container_id> bash -c "du -h --max-depth=1 / | sort -h"

常见问题根源：

应用程序生成的临时文件未清理
数据库未配置自动清理（如MySQL的binlog）
上传目录缺乏定期清理机制

2.3 针对性清理方案

对于MySQL容器，可以设置自动清理binlog：

SET GLOBAL expire_logs_days = 3;

对于临时文件问题，建议在Dockerfile中加入清理指令：

RUN apt-get update && \ apt-get install -y package && \ rm -rf /var/lib/apt/lists/*

3. 构建缓存管理：超越`docker builder prune`的精细控制

Docker构建缓存虽然加速了构建过程，但长期积累会占用大量空间。docker builder prune虽然简单，但缺乏针对性。

3.1 查看缓存详细组成

docker builder du --verbose

输出示例：

Build Cache: 5.7GB - 3.2GB FROM alpine:latest - 1.1GB RUN apk add --no-cache python3 - 0.8GB COPY . /app - 0.6GB RUN pip install -r requirements.txt

3.2 精准清理特定缓存层

保留基础镜像缓存，仅清理应用层：

docker builder prune --filter type=exec.cachemount

可选过滤器：

type=regular：常规Dockerfile指令产生的缓存
type=internal：内部使用的缓存
type=source.local：本地源文件缓存

3.3 构建时控制缓存行为

在Dockerfile中合理使用--mount=type=cache：

RUN --mount=type=cache,target=/var/cache/apt \ apt-get update && \ apt-get install -y build-essential

这样既保持了构建速度，又避免了缓存污染主镜像。

4. 镜像深度清理：区分悬空镜像与中间层

docker image prune默认只清理悬空镜像（dangling images），但中间层（intermediate layers）才是真正的空间杀手。

4.1 识别不同类型的镜像

docker images -a --filter dangling=true # 悬空镜像 docker images -a --format "{{.ID}}\t{{.CreatedSince}}\t{{.Size}}" | sort -k2 -h

4.2 安全清理中间层

先查看可清理的空间预估：

docker system df -v

然后使用带过滤器的清理命令：

docker image prune -a --filter "until=24h" # 清理24小时前的未使用镜像

4.3 保留关键镜像的策略

给重要镜像打上保留标签：

docker tag my_image:latest my_image:keep

这样在执行prune时可以通过--filter排除：

docker image prune -a --filter="label!=keep"

5. 自动化清理：安全可靠的crontab方案

手动清理终究不是长久之计，但自动化清理需要特别注意安全性。

5.1 基础清理脚本

创建/usr/local/bin/docker-cleanup：

#!/bin/bash # 清理超过7天的已停止容器 docker container prune --force --filter "until=168h" # 清理未使用的镜像（保留最近3个版本） docker image prune -a --force --filter "until=72h" # 清理构建缓存 docker builder prune --force --filter "until=24h" # 清理网络和卷 docker network prune --force docker volume prune --force

5.2 安全增强措施

添加资源使用限制和日志记录：

#!/bin/bash LOG_FILE="/var/log/docker-cleanup.log" MAX_DISK_USAGE=90 current_usage=$(df -h /var/lib/docker | awk 'NR==2 {print $5}' | tr -d '%') if [ "$current_usage" -lt "$MAX_DISK_USAGE" ]; then echo "$(date) - Disk usage ${current_usage}% below threshold. Skipping cleanup." >> "$LOG_FILE" exit 0 fi echo "$(date) - Starting cleanup (Current usage: ${current_usage}%)" >> "$LOG_FILE" # ...原有清理命令...