分类：虚拟化技术

Device Mapper是一个基于内核的框架，支持Linux上的许多高级卷管理技术。Docker的devicemapper存储驱动利用这个框架的精简置备和快照功能来管理镜像和容器。本文简称Device Mapper存储驱动为devicemapper，内核框架为Device Mapper。

AUFS的一个替代品

Docker刚开始是运行在Ubuntu和Debian Linux系统，使用AUFS作为存储后端。随着Docker变得流行，许多公司想在Red Hat Enterprise Linux上使用Docker。不过因为Linux内核上游主线没有包括AUFS，RHEL也没有用AUFS。
要解决这个问题，Red Hat开发人员着手调查让AUFS进内核主线。最终，他们决定开发一个新的存储后端。此外，它们基于现有的Device Mapper技术来开发新的存储后端。
Red Hat与Docker公司合作开发这个新的驱动。由于这次合作，Docker公司把Engine的存储后端重新设计成可插拔的。所以devicemapper成为Docker支持的第二个存储驱动。
从Linux内核版本2.6.9起，Device Mapper已经包含在Linux内核主线中。它是RHEL系列Linux发行版的核心部分。这意味着devicemapper存储驱动基于稳定的代码，具有大量实际生产环境部署和强大的社区支持。

镜像分层和共享

devicemapper驱动存储每个镜像和容器到它自己的虚拟设备上。这些设备是精简置备写时拷贝快照设备。Device Mapper技术工作在块级别而不是文件级别。意味着devicemapper存储驱动的精简置备和写时拷贝操作的是块而不是整个文件。
使用devicemapper创建一个镜像的过程如下：

1.devicemapper存储驱动创建一个精简池(thin pool)。这个池是从块设备或循环挂载的文件

2.下一步是创建一个base设备。一个base设备是具有文件系统的精简设备。你可以通过运行docker info命令检查Backing filesystem来查看使用的是哪个文件系统。

3.每一个新镜像(和镜像数据层)是这个base设备的一个快照。这些是精简置备写时拷贝快照。这意味着它们初始为空，只在往它们写入数据时才消耗池中的空间。

使用devicemapper驱动时，容器数据层是从其创建的镜像的快照。与镜像一样，容器快照是精简置备写时拷贝快照。容器快照存储着容器的所有更改。当数据写入容器时，devicemapper从存储池按需分配空间。
下图显示一个具有一个base设备和两个镜像的精简池。

如果你仔细查看图表你会发现快照一个连着一个。每一个镜像数据层是它下面数据层的一个快照。每个镜像的最底端数据层是存储池中base设备的快照。此base设备是Device Mapper的工件，而不是Docker镜像数据层。
一个容器是从其创建的镜像的一个快照。下图显示两个容器 – 一个基于Ubuntu镜像和另一个基于Busybox镜像。

使用devicemapper读文件

我们来看下使用devicemapper存储驱动如何进行读和写。下图显示在示例容器中读取一个单独的块[0x44f]的过程。

1.一个应用程序请求读取容器中0x44f数据块。由于容器是一个镜像的一个精简快照，它没有那数据。不过有存储在镜像堆栈下的镜像快照的数据的指针。

2.存储驱动跟随指针找到与镜像数据层a005关联的快照数据块0xf33 …

3.devicemapper从镜像快照复制数据块0xf33的内容到容器内存中。

4.存储驱动返回数据给请求数据的应用程序。

写示例

使用devicemapper驱动，通过按需分配(allocate-on-demand)操作来实现写入新数据到容器。更新存在的数据使用写时拷贝(copy-on-write)操作。由于Device Mapper是基于块的技术，这些操作发生在块级别上。
例如，当更新容器中一个大文件的一小部分，devicemapper存储驱动不会复制整个文件。它仅复制要更改的数据块。每个数据块是64KB。

写入新数据

要写入56KB的新数据到容器：

1.一个应用程序请求写入56KB的新数据到容器。

2.按需分配操作给容器快照分配一个新的64KB数据块。如果写操作大于64KB，就分配多个新数据块给容器快照。

3.新的数据写入到新分配的数据块。

覆盖存在的数据

首次更改已存在的数据时：

1.一个应用程序请求更新容器中的一些数据。

2.写时拷贝操作定位需要更新的数据块。

3.分配新的空白数据块给容器快照并复制数据到这些数据块。

4.更新好的数据写入到新分配的数据块。

容器中的应用程序不知道这些按需分配和写时拷贝操作。不过，这些操作可能会增加应用程序的读和写操作延迟。

配置Docker使用devicemapper

在一些Linux发行版本中,devicemapper是Docker的默认存储驱动。包括RHEL和它的大多数分支。目前，支持此驱动的发行版本如下：

RHEL/CentOS/Fedora

Ubuntu 12.04

Ubuntu 14.04

Debian

Arch Linux

Docker主机运行devicemapper存储驱动时，默认的配置模式为loop-lvm。此模式使用空闲的文件来构建用于镜像和容器快照的精简存储池。该模式设计为无需额外配置开箱即用(out-of-the-box)。不过生产部署不应该以loop-lvm模式运行。
你可以使用docker info命令来检查目前使用的模式：

上面的输出显示Docker主机运行的devicemapper存储驱动的模式为loop-lvm。因为Data loop file和Metadata loop file指向/var/lib/docker/devicemapper/devicemapper下的文件。这些文件是环回挂载(loopback mounted)文件。

生产环境配置direct-lvm模式

生产部署首选配置是direct-lvm。这个模式使用块设备来创建存储池。下面展示使用配置在使用devicemapper存储驱动的Docker主机上配置使用direct-lvm模式。
下面的步骤创建一个逻辑卷，配置用作存储池的后端。我们假设你有在/dev/xvdf的充足空闲空间的块设备。也假设你的Docker daemon已停止。

1.登录你要配置的Docker主机并停止Docker daemon。

2.安装LVM2软件包。LVM2软件包含管理Linux上逻辑卷的用户空间工具集。

3.创建一个物理卷
$ pvcreate /dev/xvdf

4.创建一个“docker”卷组

1. $ vgcreate docker /dev/xvdf

5.创建一个名为thinpool的存储池。
在此示例中，设置池大小为“docker”卷组大小的95％。 其余的空闲空间可以用来自动扩展数据或元数据。

1. $ lvcreate –wipesignatures y -n thinpool docker -l 95%VG
2. $ lvcreate –wipesignatures y -n thinpoolmeta docker -l 1%VG

6.转换存储池

1. $ lvconvert -y –zero n -c 512K –thinpool docker/thinpool –poolmetadata docker/thinpoolmeta

7.通过lvm profile配置存储池autoextension

1. $ vi /etc/lvm/profile/docker-thinpool.profile

8.设置thin_pool_autoextend_threshold值。这个值应该是之前设置存储池余下空间的百分比(100 = disabled)。

1. thin_pool_autoextend_threshold = 80

9.为当存储池autroextension发生时更改thin_pool_autoextend_percent值。
该值的设置是增加存储池的空间百分比（100 =禁用）

1. thin_pool_autoextend_percent = 20

10.检查你的docker-thinpool.profile的设置。一个示例/etc/lvm/profile/docker-thinpool.profile应该类似如下：

1. activation {
2.     thin_pool_autoextend_threshold=80
3.     thin_pool_autoextend_percent=20
4. }

11.应用新lvm配置

1. $ lvchange –metadataprofile docker-thinpool docker/thinpool

12.验证lv是否受监控。

1. $ lvs -o+seg_monitor

13.如果Docker daemon之前已经启动过，移动你的驱动数据目录到其它地方。

1. $ mkdir /var/lib/docker.bk
2. $ mv /var/lib/docker/* /var/lib/docker.bk

14.配置一些特定的devicemapper选项。
如果你是用dockerd命令行启动docker，使用如下参数：

1. –storage-driver=devicemapper –storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool –storage-opt=dm.use_deferred_removal=true –storage-opt=dm.use_deferred_deletion=true

你也可以在daemon.json启动配置文件设置它们，例如：

1. {
2.   "storage-driver": "devicemapper",
3.    "storage-opts": [
4.      "dm.thinpooldev=/dev/mapper/docker-thinpool",
5.      "dm.use_deferred_removal=true",
6.      "dm.use_deferred_deletion=true"
7.    ]
8. }

15.如果你用的是systemd及通过unit或drop-in文件更新daemon配置文件，重载systemd来扫描配置更改。

1. $ systemctl daemon-reload

16.启动docker daemon

1. $ systemctl start docker

启动Docker daemon后，确保你监控存储池和卷组的可用空间。虽然卷组会自动扩展，它仍然会占满空间。要监控逻辑卷，使用lvs或lvs -a来查看数据和元数据大小。要监控卷组可用空间，使用vgs命令。
当达到阈值时，可以通过日志查看存储池的自动扩展，使用如下命令:

检查主机上的devicemapper结构

你可以使用lsblk命令来查看以上创建的设备文件和存储池。

下图显示由lsblk命令输出的之前镜像的详细信息。

在这个图中，存储池名称为Docker-202:1-1032-pool，包括之前创建的data和metadata设备。devicemapper构造池名称如下：

MAJ，MIN和INO指主设备号和次设备号和inode。
因为Device Mapper在块级别操作，所以更难以看到镜像层和容器之间的差异。Docker 1.10和更高版本不再将镜像层ID与/var/lib/docker中的目录名称匹配。 但是，有两个关键目录。/var/lib/docker/devicemapper/mnt目录包含镜像层和容器层的挂载点。/var/lib/docker/devicemapper/metadata目录包含每个镜像层和容器快照对应的一个文件。这个文件包含每个快照的JSON格式元数据。

增加正在使用设备的容器

你可以增加使用中的存储池的容量。如果你的数据逻辑卷已满这会有所帮助。

对于loop-lvm模式的配置

在这个场景下，存储池配置为使用loop-lvm模式。使用docker info查看目前的配置：

Data Space值显示存储池总共大小为100GB。此示例扩展存储池到200GB。
1.列出设备的大小。

2.扩展data文件大小为200GB。

3.验证更改的大小。

4.重载数据loop设备

5.重载devicemapper存储池。
1) 先获取存储池名称。

冒号前面部分是名称。
2) 导出device mapper表：

3) 现在计算存储池的实际总扇区。
更改表信息的第二个数字（即磁盘结束扇区），以反映磁盘中512字节扇区的新数。 例如，当新loop大小为200GB时，将第二个数字更改为419430400。
4) 使用新扇区号重新加载存储池

device_tool

Docker项目的contrib目录不是核心分发的一部分。 这些工具通常很有用，但也可能已过期。这个目录的device_tool.go可以调整loop-lvm精简池的大小。
要使用该工具，首先编译它。 然后，执行以下操作调整池大小：

对于direct-lvm模式的配置

在此示例中，你将扩展使用direct-lvm模式设备的容量。此示例假设你使用的是/dev/sdh1磁盘分区。
1.扩展卷组（VG）vg-docker。

2.扩展数据逻辑卷（LV）vg-docker/data

3.重载devicemapper存储池。
1) 获取存储池名称。

2）导出device mapper表。

3）现在计算存储池的实际总扇区。 我们可以使用blockdev来获取数据lv的实际大小。
更改表信息的第二个数（即扇区数）以反映磁盘中512个字节扇区的新数。 例如，由于新数据lv大小为264132100096字节，请将第二个数字更改为515883008。

4）然后使用新的扇区号重新加载存储池。

Device Mapper及Docker性能

了解按需分配和写时拷贝操作对整体容器性能的影响很重要。

按需分配对性能的影响

devicemapper存储驱动通过按需分配操作给容器分配新的数据块。这意味着每次应用程序写入容器内的某处时，一个或多个空数据块从存储池中分配并映射到容器中。
所有数据块为64KB。 写小于64KB的数据仍然分配一个64KB数据块。写入超过64KB的数据分配多个64KB数据块。这可能会影响容器性能，特别是在执行大量小写的容器中。不过一旦数据块分配给容器，后续的读和写可以直接在该数据块上操作。

写时拷贝对性能的影响

每当容器首次更新现有数据时，devicemapper存储驱动必须执行写时拷贝操作。这会从镜像快照复制数据到容器快照。此过程对容器性能产生显着影响。因此，更新一个1GB文件的32KB数据只复制一个64KB数据块到容器快照。这比在文件级别操作需要复制整个1GB文件到容器数据层有明显的性能优势。
不过在实践中，使用devicemapper执行大量小块写入（<64KB）的容器比使用AUFS执行得更慢。

device mapper其它性能注意事项

还有其他一些影响devicemapper存储驱动性能的因素。

模式。Docker使用的devicemapper存储驱动的默认模式是loop-lvm。这个模式使用空闲文件来构建存储池，性能非常低。不建议用到生产环境。推荐用在生产环境的模式是direct-lvm。

高速存储。为获得最佳性能，应将数据文件和元数据文件放在高速存储（如SSD）上。

内存使用。devicemapper在内存使用方面不是最有效率的。启动同一容器的n个副本会把n个副本加载到内存中。这可能影响你Docker主机的内存使用。因此，dervicemapper存储驱动可能不是PaaS和其他类似用例的最佳选择。

最后一点，数据卷提供了最好的和最可预测的性能。这是因为他们绕过存储驱动，并且没有精简置备和写时拷贝引入的潜在开销。

Btrfs是下一代支持许多高级存储技术以使其更适合Docker的写时拷贝文件系统。Btrfs包含在Linux内核主线中以及现在稳定的硬盘格式(on-disk-format)。不过许多功能仍然在开发中，用户应该意识到此驱动目前正在快速发展中。
Docker的btrfs存储驱动利用Btrfs的许多功能来管理镜像和容器。这些功能是精简置备(thin provisioning)，写时拷贝和快照。
本文把Docker的Btrfs存储驱动简称为btrfs，将整个Btrfs文件系统称为Btrfs。

Btrfs的未来

Btrfs一直被誉为是一个Linux的未来文件系统。在Linux内核主线的完全支持下，一个稳定的硬盘格式(on-disk-format)，以及活跃的专注稳定性开发，离变成现实越来越近了。
就Linux平台上的Docker而言，许多人将btrfs存储驱动视为潜在的长期替代devicemapper存储驱动。不过，到目前为止，devicemapper存储驱动仍然比btrfs更安全，更稳定和更适合用于生产环境。如果你对btrfs非常熟悉且已经有Btrfs的使用经验，这时你才应该考虑把btrfs部署到生产环境中。

镜像分层与Btrfs共享

Docker利用Btrfs subvolumes和快照来管理镜像和容器数据层的硬盘组件(on-disk components)。Btrfs subvolumes看起来像一个正常的Unix文件系统。因此，他们可以有自己的内部目录结构，挂钩到更广泛的Unix文件系统。
subvolumes更新文件时涉及写时拷贝操作，写入新文件时涉及从一个底层存储池来按需分配空间的操作。它们既能嵌套也能做快照。下图显示了4个subvolumes。“subvolume 2″和”subvloume 3″是嵌套的，而“subvolume 4”显示它自己的内部目录树。

快照是在一个时间点对整一个subvolume做的一个副本。它们直接存在于从其创建的subvolume下面。你可以像下图显示的那样创建快照的快照。

Btfs从一个底层存储池给subvolumes和快照(snapshots)按需分配空间。分配单元称为块（chunk），并且块通常大小为〜1GB。
快照看起来和操作跟常规的subvolumes类似。创建快照所需的技术由于Btrfs本地的写时拷贝设计而构建进Btrfs文件系统中。这意味着Btrfs快照空间利用率高且很少或没有性能开销。下图显示一个subvolume与它的快照共享同样的数据。

Docker的btrfs存储驱动把每个镜像和容器数据层存储到Btrfs subvolume或快照。镜像的基础数据层(最底层)作为一个subvolume存储，而镜像子数据层和容器作为快照存储。如下图所示。

使用btrfs驱动的Docker主机创建镜像和容器的过程如下：

1.镜像的基础数据层存储在/var/lib/docker/btrfs/subvolumes的Btrfs subvloume中。

2.后续的镜像数据层存储为subvolume或快照的父级数据层的一个Btrfs快照中。

下图显示一个3个数据层的镜像。base layer是一个subvolume。layer 1是base layer的subvolume的一个快照。layer 2是layer1快照的快照。

从docker 1.10开始，镜像数据层ID不再与在/var/lib/docker的目录名称相关。

镜像和容器在硬盘的结构

镜像数据层和容器在docker主机的文件系统的/var/lib/docker/btrfs/subvolumes/目录可见。不过，如之前所说的，目录名不再与镜像数据层ID相关。那就是说，容器的目录即使容器已经停止都存在。这是因为btrfs存储驱动在/var/lib/docker/subvolumes/下挂载一个默认的，顶层的subvolume。所有的其它subvolumes和快照为作Btrfs文件系统对象存在，而不是作为单独挂载存在。
因为Btrfs工作在文件系统级别上而不是块级别，所以可以使用常规的Unix命令来浏览器每个镜像和容器数据层。下面的示例显示使用ls -l命令浏览一个镜像数据层：

使用Btrfs进行容器读和写

一个容器是一个镜像的空间高效利用的快照。快照的元数据指向存储池的实际数据块。这与subvolume相同。因此，对快照执行的读取与对subvolume执行的读取本质相同。所以Btrfs驱动不会产生任何性能开销。
写入一个新文件到容器涉及到一个按需分配(allocate-on-demand)操作来为容器快照分配一个新的数据块。然后文件写入到这个新空间。按需分配操作对于使用Btrfs的所有写入都是原生的，写入新数据到subvolume一样涉及到到此操作。因此，将新文件写入到容器快照的速度与本地Btrfs写入速度一样。
在容器中更新一个存在的文件将产生一个写时拷贝操作(技术上称为redirect-on-write)。驱动保留原始数据并为快照分配新空间。更新的数据写入到这个新空间。然后驱动更新快照文件系统元数据指向新的数据。原始数据仍然保留在subvolumes中。
使用Btfs写入和更新大量小文件可能会导致性能降低。

配置Docker使用Btrfs

btrfs存储驱动只在Docker主机的/var/lib/docker挂载为Btrfs文件系统上操作。下面介绍如何在Ubuntu 14.04 LTS上配置Btrfs。

先决条件

如果你已经在Docker主机上使用Docker daemon，并且你想保持现有的镜像，在进行下面的配置前先把镜像push到Docker Hub或者其它地方。
停止Docker daemon，然后确保你在/dev/xvdb有一个闲置的块设备。设备标识符在你的环境中可能不同，你应该在整个过程中替换你自己的值。
下面的步骤也假设你的内核已经正确加载了Btrfs模块。要验证它，使用如下命令：

在Ubuntu 14.04 LTS配置Btrfs

假设你系统已经满足了前面提到的条件，执行如下：
1.安装btrfs-tools包。

2.创建Btrfs存储池。
Btrfs存储池使用mkfs.btrfs命令创建。传递多个设备给mkfs.btrfs命令将在所有这些设备之间创建一个存储池。
这里我们使用在/dev/xvdb的单个设备创建一个存储池。

3.如果Docker主机本地存储区域不存在，先创建。

4.配置系统重启时自动挂载Btrfs文件系统。
a.获取Btrfs文件系统的UUID。

b.在/etc/fstab添加一行来让系统每次启动时自动挂载。

5.挂载新的文件系统并验证

上面输出的最后一行显示/dev/xvdb作为Btrfs挂载在/var/lib/docker。
现在你已经有一个挂载在/var/lib/docker的Btrfs文件系统，docker daemon应该能自动加载btrfs存储驱动了。
1.启动docker daemoon。

启动之后Docker会自动加载Btrfs，不过你可以指定–storage-driver=btrfs或添加DOCKER_OPTS行来强制Docker使用btrfs。
2.使用docker info命令验证

现在docker已经配置使用btrfs存储驱动了。

Btrfs及Docker性能

页缓存(page caching)。Btrfs不支持页缓存共享。意味着n个容器访问同一个文件需要n个副本缓存。因此，Btrfs可能不是PaaS和类似使用场景的最好选择。

小文件写。容器执行大量的小文件写操作(包括Docker主机启动和停止大量容器)会导致Btrfs块利用率低的问题。这可能最终导致docker主机空间很快不足的情况，致命影响docker运行。这是目前使用当前版本的Btrfs的主要缺点。如果你使用btrfs存储驱动，需要使用btrfs filesys来密切监控空间使用情况。不要使用常规的Unix命令如df来查看空间使用情况，因为有可能会显示不正确；推荐始终使用Btrfs原生的命令。

顺序写。Btrfs通过日志技术(journaling technique)将数据写入硬盘。其性能可以提升一半。

碎片(Fragmentation)。碎片是写时拷贝文件系统（如Btrfs）的自然副产品。 许多小的随机写入可以导致这个问题。 它表现为使用SSD硬盘的Docker主机上的CPU峰值和使用机械硬盘的Docker主机上的抖动。 这两者都导致差的性能。
最新版本的Btrfs允许你将autodefrag指定为mount选项。 此模式尝试检测随机写入和碎片整理。 在Docker主机上启用此选项之前，你应该先自己测试下。 一些测试显示此选项对执行大量小型写入的Docker主机（包括启动和停止许多容器的系统）具有负面性能影响。

固态设备（SSD）。 Btrfs具有SSD介质的本机优化。 要启用这些选项，请使用-o ssd mount选项进行挂载。 这些优化包括通过避免诸如在SSD介质上没有用的查找优化等增强的SSD写性能。
Btfs还支持原生的TRIM / Discard。 但是，使用-o discard mount选项进行挂载可能会导致性能问题。 因此，建议你在使用此选项之前先测试下。

使用数据卷(data volumes)。 数据卷提供最佳和最可预测的性能。这是因为他们绕过存储驱动，并且不承担任何通过精简置备和写时拷贝引入的潜在开销。

本文介绍Docker存储驱动的特性。列出Docker支持的存储驱动以及管理它们相关的命令。最后，为你在选择存储驱动时提供数据参考。

可插拔的存储驱动架构

Docker的存储驱动架构设计成可插拔的，这可以让你能根据你的环境和使用场景灵活地选择使用一个存储驱动。每个Docker存储驱动基于Linux文件系统或卷管理器。此外，每个存储驱动器以其自己独特的方式自由地实现镜像数据层和容器数据层的管理。这意味着一些存储驱动在不同的情况下会比其它的驱动会有更好的表现。
一旦你决定了哪个驱动对于你是最好的，你可以在Docker启动时设置为这个驱动。Docker daemon只能运行一个存储驱动，之后所有由docker daemon创建的容器都使用同样的存储驱动。下面的表格显示docker支持的存储驱动技术及它们驱动的名称：

技术	存储驱动名称
OverlayFS	overlay或overlay2
AUFS	aufs
Btrfs	btrfs
Device Mapper	devicemapper
VFS	vfs
ZFS	zfs

要找出目前docker daemon使用的是哪个存储驱动，可以使用docker info命令：

info子命令显示出Docker使用的存储驱动是overlay，Backing Filesystem为extfs。extfs值意思是overlay存储驱动在现有的ext文件系统之上操作。Backing Filesystem指的是在/var/lib/docker创建docker主机本地存储区域的文件系统。你能选择使用哪些存储驱动部分取决于你计划在哪个backing filesystem创建docker主机本地存储区域。一些存储驱动能在不同的backing filesystems上操作。不过有些存储驱动需要与存储驱动相同的backing filesystem。例如btrfs存储驱动需要Btrfs backing filesystem。下面的表格列出每个存储驱动以及是否必须匹配主机backing filesystem:

存储驱动	可用的文件系统	禁用的文件系统
overlay	ext4 xfs	btrfs aufs overlay overlay2 zfs eCryptfs
overlay2	ext4 xfs	btrfs aufs overlay overlay2 zfs eCryptfs
aufs	ext4 xfs	btrfs aufs eCryptfs
btrfs	btrfs only	N/A
devicemapper	direct-lvm	N/A
vfs	debugging only	N/A
zfs	zfs only	N/A

你可以在dockerd命令传递–storage-driver=参数来设置存储驱动，或者在/etc/default/docker文件中设置DOCKER_OPTS选项。
下面的命令显示如何使用dockerd命令以及–storage-driver参数来设置存储驱动为devicemapper：

你选择的存储驱动会影响你容器化应用的性能。所以理解不同的存储驱动可用选项并为你的应用选择一个合适的驱动很重要。最后，在本文你会找到帮助你选择一个适合的驱动的建议。

你应该选择哪个存储驱动

有几个因素会影响存储驱动的选择。不过这两个因素要特别注意：

1.没有哪个驱动非常适合每一个使用场景

2.存储驱动在不断改进和发展

考虑到这些因素，以下应该能为你提供一些指导。

稳定性

为了最稳定和良好的docker体验，你应该考虑以下：

使用默认的存储驱动。当docker安装时，它会根据你系统的配置选择一个默认的存储驱动。稳定性是影响选择一个默认的存储驱动的重要因素。更改这个默认驱动可能增加你使用docker的bug。

遵循CS Engine兼容性列表中指定的配置。CS Engine是Docker Engine的商业支持版本。它的代码库与开源Engine相同，不过它有一组受限的支持配置。这些支持的配置使用最稳定和成熟的存储驱动程序。

经验和专长

选择一个你和你团队/组织有使用经验的存储驱动。例如，如果你使用的是RHEL或其下游分支之一，你可能已经具有LVM和Device Mapper的使用经验。如果是这样，你可能希望使用devicemapper驱动。
如果你对任何的存储驱动都没有使用经验，并且你想要一个易于使用的稳定的Docker体验，你应该考虑使用docker安装时设置的默认驱动。

面向未来

许多用户认为docker未来存储驱动是OverlayFS。不过，它还不太成熟，对于已经成熟的驱动如aufs和devicemapper不够稳定。由于这个原因，你应该慎重使用OverlayFS驱动，并且作好相对于使用一个更成熟驱动遇到更多bug的准备。
下面的图表列出的每一个存储驱动的优势和劣势。在选择要使用的存储驱动程序时，请考虑下表提供的指导以及上述要点。

Overlay vs Overlay2

OverlayFS有两个使用相同的OverlayFS技术但是不同的实现及硬盘存储的不兼容的存储驱动。由于存储上不兼容，在两者之间切换需要重建所有的镜像。overlay驱动是原始的实现，是Docker 1.11和之前版本的唯一选项。overlay驱动具有已知的inode耗尽问题以及提交性能的限制。overlay2驱动解决了这些问题，不过仅与Linux内核4.0及更高的版本兼容。对于使用4.0之间的内核或已存在overlay graph的用户，推荐继续使用overlay。对于使用至少4.0内核版本的，或所需overlay graph数据的用户，那么可以使用overlay2。

为了更有效地使用存储驱动，你必须理解Docker是如何构建和存储镜像的。然后，你需要对镜像是如何被容器使用作个了解。最后，你需要一段关于镜像和容器共同使用的技术的简洁的介绍。

镜像和数据层

每个Docker镜像引用一个或多个代表文件系统差异的只读数据层。数据层彼此堆叠来组成容器的根文件系统。下面的图表表示Ubuntu 15.04镜像由4个堆叠的数据层组成。

Docker存储驱动负责堆叠这些数据层和提供一个单独的统一视图。
当你创建一个容器，同时也在底层堆栈顶部创建了一个新的，薄的，可写的数据层。这个数据层也称为”容器数据层(container layer)“。所有对运行容器的更改 – 如写新文件，更新文件和删除文件 – 都是写到这个数据层。下面的图表显示基于Ubuntu 15.04镜像的容器。

内容寻址存储

Docker 1.10引入了一个新的内容寻址存储模型。这是一个全新的方法来定位硬盘上的镜像和数据层数据。之前的版本，镜像和数据层通过使用随机生成的UUID来引用。在这个新的模型使用了安全哈希（secure content hash）来代替。
新的模式提高了安全性，提供了一个内置的方式来避免ID冲突，并且在pull,push,load,save后保证数据完整性。同时也通过允许镜像(即使它们不是由相同的Dockerfile构建)自由地共享它们的数据层来获取更好的使用体验。
在使用新模式前需要注意的是：

1.迁移现有的镜像

2.镜像和数据层文件系统结构

那些使用早期Docker版本创建和拉取的镜像，在与新模式一起使用前需要进行迁移。迁移操作涉及计算新的安全checksum，这个操作是在你首次启动新的Docker版本时自动完成的。迁移完成后，所有的镜像都会具有全新的安全ID。
虽然迁移是自动和透明的，但是要使用比较多的计算资源。意味着当你有许多镜像需要计算时要花费比较长的时间。在这期间Docker daemon不会响应其它请求。
Docker为此把迁移工具单独出来，允许你在升级Docker之前先把镜像迁移好。这样可以避免长时间的停机时间。
迁移工具以容器方式运行，可以到这里下载https://github.com/docker/v1.10-migrator/releases。
如果你使用的是默认的docker数据路径，手动迁移命令如下：

如果你用的是devicemapper存储驱动，你需要添加–privileged参数来让容器可以访问存储设备。

迁移示例

下面是在Docker 1.9.1，AUFS存储驱动的环境下使用迁移工具的示例.Docker主机运行在配置为1 vCPU, 1GB RAM以及单独的8G SSD的t2.micro AWS EC2实例。Docker数据目录(/var/lib/docker)占用2GB空间。

Unix time命令放在docker run命令前面来统计其运行时间。正如你所看到了，迁移大小为2GB的7个镜像总体时间将近1分钟。不过这个时间包括了拉取镜像/docker/v1.10-migrator镜像的时间(大约为3.5秒)。同样的操作在一个配置为40 vCPUs, 160GB RAM和一个8GB SSD的m4.10xlarge EC2 instance实例花费的时间少得多：

这个示例表明了迁移操作耗费的时间受机器硬件配置的影响。

容器和数据层

容器和镜像的主要区别是顶部的可写数据层。所有对容器进行文件添加或文件更新的操作都会存储到这个可写数据层。当容器被删除后，这个可写数据层也被删除了。而底层的镜像仍然不变。
由于每个容器有自己的可写容器数据层，并且所有的更改都储存到这个数据层，意味着多个容器可以共享访问同一个底层镜像且有它们自己的数据状态。下面的图表显示多个容器共享一个相同的Ubuntu 15.04镜像。

Docker存储驱动负责激活和管理镜像数据层和可写容器数据层。不同的存储驱动处理这两个数据层的方式有所不同。Docker镜像和容器管理背后两个关键技术是可堆叠镜像数据层和写时拷贝(copy-on-write)。

写时拷贝策略

写时拷贝策略与共享和复制类似。需要相同数据的系统进程共享该数据，而不是各自拥有自己的副本。在某些时候，如果一个进程需要更新或写入数据，操作系统就为该进程拷贝一份数据使用。只有需要写入数据的系统有权限访问数据副本。所有其它进程继续使用原始的数据。
Docker对镜像和容器都使用了写时拷贝技术。写时拷贝策略优化了镜像硬盘占用和容器启动时间的性能。接下来我们来看看写时拷贝技术是如何通过共享和复制影响镜像和容器的。

共享使镜像更小

现在我们来了解镜像数据层和写入拷贝技术。所有的镜像和容器数据层存储在由存储驱动管理的Docker主机本地存储区域内。在基于Linux的Docker主机这个目录是/var/lib/docker/。
当使用docker pull和docker push拉取和推送镜像时,docker客户端将输出镜像数据层报告。下面的命令是从Docker Hub拉取ubuntu:15.04镜像。

从输出中我们看到命令实际上拉取了4个镜像数据层。上面的每一行列出了一个镜像数据层和它的UUID或加密散列。这4个数据层混合组成了ubuntu:15.04 Docker镜像。
每一个数据层都存储在Docker主机本地存储区域内的它们自己的目录。
Docker 1.10之前的版本把数据层存储在与它们ID相同名称的目录中。不过对于使用docker 1.10和之后的版本拉取镜像的情况并非如此。例如，下面的命令显示从Docker Hub拉取一个镜像，并列出Docker 1.9.1的一个目录文件列表。

注意看四个目录是如何与下载的镜像的数据层ID匹配的。现在比较下由docker 1.10完成同样的操作的表现。

我们看到四个目录与镜像数据层ID并不匹配。尽管docker 1.10之前与之后的版本镜像管理有不同之处，不过所有的docker版本仍然能在镜像之间共享数据层。例如，如果你拉取一个与已经拉取下来的镜像拥有一些共同的数据层的镜像，Docker会检查到这个并只拉取本地没有的数据层。在这之后，两个镜像共享一些相同的数据层。
你可以自己做试验来说明。对你刚拉取下来的ubuntu:15.04镜像做一个更改，然后基于这个更改构建一个新的镜像。做这个操作的其中一个方法是使用Dockerfile和docker build命令。
1.在一个空目录创建一个以ubuntu:15.04镜像开始的Dockerfile。

2.添加一个内容为”hello world”在/tmp目录的”newfile”文件。Dockerfile类似如下：

3.保存Dockerfile并关闭文件。
4.在Dockerfile相同目录的终端，执行如下命令：

上面显示新镜像的ID为94e6b7d2c720。
5.执行docker images来检查新的changed-ubuntu镜像是否在Docker主机本地存储区域。

6.执行docker history命令来查看哪些数据层用来创建这个新的changed-ubuntu镜像。
$ docker history changed-ubuntu

docker history命令输出显示新的94e6b7d2c720镜像数据层在顶部。你知道这个数据层是由于Dockerfile中的echo “Hello world” > /tmp/newfile命令添加的。下面的4个镜像数据层与组成ubuntu:15.04的数据层是一样的。
注意到新的changed-ubuntu镜像没有它自己每个数据层的拷贝。从如下图表看到，新的镜像与ubuntu:15.04镜像4个底层数据层共享。

docker history命令也显示了每个镜像数据层的大小。如你所见，94e6b7d2c720数据层只消耗了12字节的空间。意味着我们刚才创建的changed-ubuntu镜像只占用了docker主机12字节的空间 – 94e6b7d2c720数据层以下的所有数据层都以存在docker主机上并与其它镜像共享。
镜像数据层的共享使得docker镜像和容器如此的节省空间。

复制使容器高效

你早先学到了一个容器与镜像的区别是容器多了一个可写数据层。下面的图表显示了基于ubuntu:15.04的容器的数据层：

所有对容器的更改都会存储到这个薄的可写容器数据层。其它的数据层是不能修改的只读的镜像数据层。意味着多个容器能安全地共享一个底层镜像。下面的图表显示多个容器镜像一个ubuntu:15.04镜像。每一个容器有它自己的可写数据层。

当容器内的一个存在的文件被修改时，docker使用存储驱动来完成写时拷贝操作。操作的细节取决于存储驱动程序。对于AUFS和OverlayFS存储驱动，写时拷贝的操作类似如下：

在镜像数据层中搜索要更新的文件。从顶部，每次一个数据层开始搜索。

在找到的第一个文件副本执行复制(copy-up)操作。”copy up“复制文件到容器自己的可写数据层。

在容器的可写数据层修改刚才复制上来的文件。

Btrfs, ZFS和其它驱动处理写时拷贝有所不同。你可以之后阅读这些驱动的详细说明。
一个copy-up操作可能导致明显的性能开销。开销的不同取决于使用的存储驱动。不过，大文件，大量数据层和尝试目录树会影响更显着。幸运的是，操作只发生在第一次修改任何特定文件时。随后对同一个文件的修改不会引起一个copy-up操作，而是对存在于容器数据层的这个文件直接修改。
让我们看看如果我们根据我们之前创建的更改的ubuntu映像启动5个容器会发生什么：
1.从Docker主机上的终端，运行以下docker run命令5次。

这将根据更改的ubuntu映像启动5个容器。 随着每个容器的创建，Docker添加一个可写层，并为其分配一个随机UUID。 这是从docker run命令返回的值。
2.运行docker ps命令以验证5个容器是否正在运行。

上面的输出显示了5个正在运行的容器，它们都共享更改的ubuntu映像。 每个CONTAINER ID在创建每个容器时从UUID派生。
3.列出本地存储区的内容。

Docker的写时拷贝策略不仅减少了容器所消耗的空间量，而且还减少了启动容器所需的时间。 在开始时，Docker只需为每个容器创建可写层。 下图显示了这5个容器共享更改的ubuntu映像的一个只读（RO）副本。

如果Docker在每次启动一个新容器时都必须创建底层映像堆栈的整个副本，那么容器启动时间和磁盘空间将大大增加。

数据卷和存储驱动

当容器被删除时，写入到容器中的未存储在数据卷中的任何数据与容器一起被删除。
数据卷是Docker主机文件系统中直接挂载到容器中的目录或文件。 数据卷不受存储驱动程序控制。 对数据卷的读取和写入绕过存储驱动程序，并以本机主机速度运行。 你可以将任意数量的数据卷装载到容器中。 多个容器还可以共享一个或多个数据卷。
下图显示了运行两个容器的单个Docker主机。 每个容器存在于Docker主机本地存储区（/var/lib/docker/ …）内的自己的地址空间内。 Docker主机上的/data还有一个共享数据卷。 它直接安装在两个容器中。

数据卷驻留在Docker主机上的本地存储区域之外，进一步增强了它们与存储驱动程序控制的独立性。 当容器被删除时，存储在数据卷中的任何数据都会保留在Docker主机上。

使用tar创建一个完整的镜像

一般来说你需要准备一台将在上面打包基础镜像的工作机器，以及不是必要的工具，如Debian的Debootstrap，这个工具也能构建Ubuntu镜像。
创建一个Ubuntu基础镜像很简单：

在Docker GitHub Repo有更多的示例关于创建基础镜像的：

BusyBox

CentOS / Scientific Linux CERN (SLC) on Debian/Ubuntu或on CentOS/RHEL/SLC/etc

Debian / Ubuntu

使用scratch创建一个简单的基础镜像

你可以使用Docker自带的，微小的镜像scratch作为构建容器的起点。scratch镜像与你下一个Dockerfile的指令将作为镜像的第一个数据层。
scratch只能在Dockerfile中引用它，不能推送到docker hub或者运行它：

hello文件可以到这里下载https://github.com/docker-library/hello-world/tree/master/hello-world