引言

"磁盘空间不足"是许多开发者在使用Docker时遇到的噩梦。无论是本地开发环境还是生产服务器，随着镜像、容器和日志的堆积，Docker的存储占用会像滚雪球一样失控。本文将通过真实场景中的技术实践，带你一步步解决这个棘手问题。

一、Docker存储机制的核心问题分析

Docker默认使用/var/lib/docker作为存储根目录，其内容包含：

  • 镜像层（Image Layers）：每个镜像由多个只读层叠加而成
  • 容器层（Container Layers）：容器运行时产生的可写层
  • 卷数据（Volumes）：持久化存储的容器数据
  • 日志文件（Logs）：容器输出的日志记录

典型问题场景：

$ sudo du -sh /var/lib/docker/*
12G    /var/lib/docker/containers
24G    /var/lib/docker/overlay2
3.5G   /var/lib/docker/volumes

此时系统提示"No space left on device"，但常规删除文件无法解决问题，因为Docker进程仍在占用存储资源。

二、实战技巧深度解析

2.1 清理无用镜像和容器（基础必修课）

# 清理已停止的容器和悬挂镜像
$ docker system prune -a --volumes

# 强制删除特定镜像（适用于残留的中间层）
$ docker rmi -f $(docker images -q -f "dangling=true")

# 按时间过滤删除旧容器（保留最近3天）
$ docker container prune --filter "until=72h"

技术栈：Docker CLI
注意事项：

  • prune操作会删除所有未被引用的对象
  • 生产环境建议结合CI/CD流水线自动清理

2.2 调整存储驱动配置（存储引擎优化）

查看当前存储驱动：

$ docker info | grep "Storage Driver"
Storage Driver: overlay2

优化配置方案（以overlay2为例）：

# 编辑Docker配置文件
$ sudo vim /etc/docker/daemon.json

# 添加存储限制参数
{
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true",
    "overlay2.size=20G"  # 限制单个容器可写层大小
  ]
}

技术栈：Docker存储驱动
优缺点对比：

驱动类型 优点 缺点
overlay2 性能最佳，推荐使用 需要Linux内核4.0+
devicemapper 兼容旧系统 性能较差，已弃用
btrfs 支持快照 稳定性风险

2.3 使用Volume管理持久化数据（高阶技巧）

# 创建命名卷（避免匿名卷堆积）
$ docker volume create app_data

# 启动容器时绑定卷
$ docker run -d \
  --name mysql \
  -v app_data:/var/lib/mysql \
  mysql:8.0

# 定期清理未使用的卷
$ docker volume prune

技术栈：Docker Volume
应用场景：

  • 数据库文件存储
  • 需要长期保留的配置文件
  • 跨容器共享数据目录

2.4 日志文件管理（救命绝招）

# 全局日志配置（限制单个日志文件100MB，最多保留3个）
$ sudo tee /etc/docker/daemon.json <<EOF
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}
EOF

# 单个容器日志限制（Nginx示例）
$ docker run -d \
  --log-opt max-size=50m \
  --log-opt max-file=2 \
  nginx:alpine

技术栈：Docker Logging Driver
紧急处理方案：

# 手动清空正在运行的容器日志
$ truncate -s 0 $(docker inspect --format='{{.LogPath}}' 容器ID)

三、进阶优化方案

3.1 多阶段构建优化镜像体积

# 第一阶段：构建环境
FROM golang:1.19 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o app .

# 第二阶段：生产环境
FROM alpine:3.16
COPY --from=builder /app/app /usr/local/bin/
CMD ["app"]

技术栈：Docker多阶段构建
优化效果：

  • 原始镜像：~1.2GB
  • 优化后镜像：~12MB

3.2 定时清理自动化脚本

#!/bin/bash
# docker_cleaner.sh
TODAY=$(date +%Y%m%d)
LOG_FILE="/var/log/docker_clean_${TODAY}.log"

{
  echo "===== 开始Docker存储清理 ====="
  docker system prune -a -f --volumes
  docker volume prune -f
  find /var/lib/docker/containers -name "*.log" -size +100M -delete
} >> ${LOG_FILE} 2>&1

技术栈：Shell脚本 + Crontab
定时任务配置：

# 每天凌晨3点执行清理
0 3 * * * /opt/scripts/docker_cleaner.sh

四、综合应用场景分析

典型场景解决方案

场景类型 推荐方案组合
开发环境 定期prune + 日志限制
CI/CD服务器 多阶段构建 + 存储驱动限制
生产数据库 Volume管理 + 备份策略
边缘设备部署 Alpine基础镜像 + 自动清理

五、技术方案优缺点对比

技术方案 优点 缺点 适用阶段
手动清理 即时生效 不可持续 紧急处理
存储驱动优化 系统级控制 需要重启Docker 中长期预防
多阶段构建 从源头减少体积 增加构建复杂度 开发阶段
自动化脚本 持续维护 需要监控脚本运行 全生命周期管理

六、注意事项及最佳实践

  1. 生产环境谨慎操作：

    • 清理前务必确认备份重要数据
    • 避免在业务高峰期执行批量删除

  2. 存储驱动选择原则：

    • CentOS/RHEL优先选overlay2
    • 旧版内核考虑devicemapper

  3. 镜像管理规范：

    • 建立私有镜像仓库
    • 实施镜像标签版本管理

  4. 监控预警机制：

    # 磁盘使用率监控命令
$ df -h /var/lib/docker
$ docker system df

七、总结与展望

通过镜像清理、存储驱动优化、Volume管理、日志控制、构建优化和自动化脚本六个维度的组合拳，我们可以有效解决Docker的磁盘空间问题。随着容器技术的发展，未来可关注：

  • Rootless Docker：减少系统级存储占用
  • Kubernetes存储方案：动态卷供应
  • 镜像分发优化：使用zstd压缩算法