使用Device Mapper插件改变Docker容器大小的方法详解

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