当前位置：首页 > 全部内容 > Device Mapper插件调整Docker容器大小的方法详解

Device Mapper插件调整Docker容器大小的方法详解

作者：技术拾光时间：2026-07-25 09:16:16浏览：585

在 CentOS、RHEL、Fedora 或其他默认没有 AUFS 支持的 Linux 发行版上使用 Docker 时，Device Mapper 存储插件几乎成为必要的选择。一旦将其设为默认存储后端，所有容器都会被放入一个 100GB 的稀疏文件中，且每个容器默认仅有 10GB 的上限。这个限制在

在 CentOS、RHEL、Fedora 或其他默认没有 AUFS 支持的 Linux 发行版上使用 Docker 时，Device Mapper 存储插件几乎成为必要的选择。一旦将其设为默认存储后端，所有容器都会被放入一个 100GB 的稀疏文件中，且每个容器默认仅有 10GB 的上限。这个限制在生产环境中常常令人困扰——要么存储池不够大，要么单个容器的容量不足。本文旨在介绍如何突破这一限制，并将容器的存储迁移至指定分区或 LVM 卷，从而提升性能和数据管理的灵活性。

它的工作原理

要真正理解后续操作，需先了解 Device Mapper 插件的工作机制。它基于 Device Mapper 的“精简目标”（thin provisioning）特性，本质上是对目标块设备进行快照。所谓“精简”，即允许超额配置：存在一个（通常较大的）可用存储块池，然后从此池中创建任意大小的块设备（虚拟磁盘）。只有在实际读写后，那些存储块才会被标记为已用，并从池中扣除。

这意味着你可以进行极端的配置——在一个 100GB 的池中创建数千个 10GB 的卷，甚至在一个 1GB 的池中创建一个 100TB 的卷，只要实际写入的块总量不超过池容量，系统就不会报错。此外，精简目标还支持快照：随时可创建已有卷的浅拷贝。从用户角度看，相当于拥有两个一模一样的卷，各自独立修改，但存储空间不会翻倍——只有真正发生变化的块才会从池中额外分配。

从实现层面看，“精简目标”实际使用两个存储设备：一个大的存储块池，以及一个小的元数据设备。元数据中记录了所有卷、快照，以及每个卷或快照的块到存储池中物理块的映射关系。

当 Docker 使用 Device Mapper 存储插件时，它会在 /var/lib/docker/devicemapper/devicemapper/data 和 /var/lib/docker/devicemapper/devicemapper/metadata 下创建两个文件（如果不存在）。这两个文件分别扮演存储池和元数据的角色。好处是免安装、零配置——无需额外分区或 LVM 即可直接运行。但缺点同样明显：存储池默认只有 100GB，且由稀疏文件支持。从磁盘利用效率看，稀疏文件表现不错（如同精简池中的卷，初始很小，写多少占多少），但从性能角度则不太友好——VFS 层会引入额外开销，尤其是在“第一次写入”时。

在讨论如何调整单个容器大小之前，先来看如何给整个池扩容。

我们需要一个更大的池

警告：以下操作会删除所有容器和镜像。务必确保已备份重要数据！

如前面所述，Docker 在启动时会检查数据和元数据文件是否存在，不存在则自动创建。因此解决方案很简单：在 Docker 启动之前，自行创建文件。

  1. 停止 Docker 守护进程——需重新设置存储后端，运行时删除文件会引发灾难。
  2. 擦除 /var/lib/docker。再次警告：这会清空所有容器和镜像。
  3. 创建存储目录：
    mkdir -p /var/lib/docker/devicemapper/devicemapper
  4. 创建存储池：
    dd if=/dev/zero of=/var/lib/docker/devicemapper/devicemapper/data bs=1G count=0 seek=250
    此命令会创建一个 250GB 的稀疏文件。注意使用 seek=250 而非 count=250，后者会生成一个普通文件（占满 250GB 真实磁盘）。
  5. 重启 Docker 守护进程。提示：如果系统本身支持 AUFS，Docker 默认会优先使用之；若要强制使用 Device Mapper，启动时加上 -s devicemapper 选项。
  6. 用 docker info 检查 Data Space Total 的值是否正确。

我们需要一个更快的池

警告：同样会删除所有容器和镜像。务必把重要镜像推送到 registry，将容器内的关键数据备份出来。

要获得更好的性能，最简单的办法是用真实块设备替代基于文件的循环设备。假设有一块全新的硬盘 /dev/sdb，希望将其全部用于容器存储，操作步骤几乎一样：

  1. 停止 Docker 守护进程。
  2. 移除 /var/lib/docker（似曾相识）。
  3. 创建存储目录：
    mkdir -p /var/lib/docker/devicemapper/devicemapper
  4. 在目录下创建数据软链接，指向设备：
    ln -s /dev/sdb /var/lib/docker/devicemapper/devicemapper/data
  5. 重启 Docker。
  6. 用 docker info 验证 Data Space Total。

使用 RAID 和 LVM

如果手头有多块同型号的磁盘，可通过软件 RAID10 合并成一个逻辑设备，然后链接到 /dev/md 设备。另一个更灵活的方案是将磁盘（或 RAID 阵列）放入 LVM 物理卷，再创建两个逻辑卷：一个用于数据，一个用于元数据。元数据卷的最佳大小没有硬性规定，但占数据池的 1% 通常是一个不错的起点。

操作思路与前两步一致：停止 Docker，移除数据目录，创建指向 /dev/mapper 设备的符号链接，重启 Docker。关于 LVM 的具体用法，可参考 LVM 相关文档，此处不再赘述。

扩容容器

默认情况下，使用 Device Mapper 存储插件时，所有镜像和容器都从一个初始 10GB 的文件系统中创建。现在来看如何让容器拥有更大的根文件系统。

先用 Ubuntu 镜像创建一个容器，无需运行任何程序，只要文件系统存在即可。为演示，在容器里执行 df -h / 查看根分区大小：

$ docker run -d ubuntu df -h /
4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603

接下来需要以 root 身份操作 Device Mapper 中的卷信息。所有以 # 开头的命令都必须用 root 执行；其他命令（以 $ 开头）只要有 Docker socket 访问权限即可。

先查看 /dev/mapper，会看到一个对应容器文件系统的符号链接，命名格式为 docker-X:Y-Z- 开头：

# ls -l /dev/mapper/docker-*-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603
lrwxrwxrwx 1 root root 7 Jan 31 21:04 /dev/mapper/docker-0:37-1471009-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603 -> ../dm-8

记下这个全名，后面会用到。先查看当前卷的设备映射表：

# dmsetup table docker-0:37-1471009-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603
0 20971520 thin 254:0 7

第二个数字是设备大小，表示 512 字节扇区的数量——当前值正好略高于 10GB。计算一下一个 42GB 的卷需要多少扇区：

$ echo $((42*1024*1024*1024/512))
88080384

精简快照目标有一个神奇的特性：它不会限制卷的大小。刚创建的精简卷使用 0 个块，写入时才会从共用池中分配。你可以写 0 块，也可以写 10 亿块，这与精简目标无关——真正限制文件系统大小的，是 Device Mapper 表本身。因此我们要做的，就是加载一张几乎完全相同的新表，只是扇区数加大了。

旧表是 0 20971520 thin 254:0 7。我们只改第二个数字，其余值必须原封不动保留（你的卷可能不是 7，一定要用正确的数值）。

# echo 0 88080384 thin 254:0 7 | dmsetup load docker-0:37-1471009-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603

现在激活新表：

# dmsetup resume docker-0:37-1471009-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603

再次查看表信息，应该已经变成新的扇区数量了。块设备扩容完成后，还需要调整文件系统大小，用 resize2fs 即可：

# resize2fs /dev/mapper/docker-0:37-1471009-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mapper/docker-0:37-1471009-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603 is mounted on /var/lib/docker/devicemapper/mnt/4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 3
The filesystem on /dev/mapper/docker-0:37-1471009-4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603 is now 11010048 blocks long

作为可选验证步骤，重启容器并检查空闲空间：

$ docker start 4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603
$ docker logs 4ab0bdde0a0dd663d35993e401055ee0a66c63892ba960680b3386938bda3603
df: Warning: cannot read table of mounted file systems: No such file or directory
Filesystem      Size  Used A vail Use% Mounted on
-               9.8G  164M  9.1G   2% /
df: Warning: cannot read table of mounted file systems: No such file or directory
Filesystem      Size  Used A vail Use% Mounted on
-                42G  172M   40G   1% /

希望将此过程自动化？当然可以，下面是一段脚本示例：

CID=$(docker run -d ubuntu df -h /)
DEV=$(basename $(echo /dev/mapper/docker-*-$CID))
dmsetup table $DEV | sed "s/0 [0-9]* thin/0 $((42*1024*1024*1024/512)) thin/" | dmsetup load $DEV
dmsetup resume $DEV
resize2fs /dev/mapper/$DEV
docker start $CID
docker logs $CID

扩容镜像

遗憾的是，当前版本的 Docker 暂时没有提供简单的方法来扩容镜像。你可以将镜像对应的块设备扩容，然后基于它创建容器，但新容器并不会继承正确的大小。另外，如果你提交了一个很大的容器，最终生成的镜像也不会变大——这与 Docker 为镜像准备文件系统的方式有关。这意味着，如果一个容器真的超过了 10GB，在不借助其他技巧的情况下，无法直接将其正常提交为一个镜像。

总结

Docker 将来一定会提供更优雅的扩容方案——所需的代码改动其实很小。管理一个精简池和对应的元数据本身比较复杂（涉及多种操作流程和潜在的数据迁移，再加上我们直接擦除重建的方式，也未在本文中展开讨论），但今天介绍的方法，已经足够解决大多数实际场景中的问题了。