docker系列—聊一聊存储驱动

首先了解Docker镜像的分层

镜像的分层特性

在说docker的文件系统之前，我们需要先想清楚一个问题。我们知道docker的启动是依赖于image，docker在启动之前，需要先拉取image，然后启动。多个容器可以使用同一个image启动。那么问题来了：这些个容器是共用一个image，还是各自将这个image复制了一份，然后各自独立运行呢？

我们假设每个容器都复制了一份这个image，然后各自独立运行，那么就意味着，启动多少个容器，就需要复制多少个image，毫无疑问这是对空间的一种巨大浪费。事实上，在容器的设计当中，通过同一个Image启动的容器，全部都共享这个image，而并不复制。那么问题又随之而来：既然所有的容器都共用这一个image，那么岂不是我在任意一个容器中所做的修改，在其他容器中都可见？如果我一个容器要将一个配置文件修改成A，而另一个容器同样要将这个文件修改成B，两个容器岂不是会产生冲突？

我们把上面的问题放一放，先来看下面一个拉取镜像的示例：​​
​​​​
上面的示例是从docker官方镜像仓库拉取一个nginx:latest镜像，可以看到在拉取镜像时，是一层一层的拉取的。事实上镜像也是这么一层一层的存储在磁盘上的。通常一个应用镜像包含多层，如下：

我们首先需要明确一点，镜像是只读的。每一层都只读。在上图上，我们可以看到，在内核之上，最底层首先是一个基础镜像层，这里是一个ubuntu的基础镜像，因为镜像的只读特性，如果我们想要在这个ubuntu的基础镜像上安装一个emacs编辑器，则只能在基础镜像之上，在构建一层新的镜像层。同样的道理，如果想要在当前的emacs镜像层之上添加一个apache，则只能在其上再构建一个新的镜像层。而这即是镜像的分层特性。

容器读写层的工作原理

我们刚刚在说镜像的分层特性的时候说到镜像是只读的。而事实上当我们使用镜像启动一个容器的时候，我们其实是可以在容器里随意读写的，从结果上看，似乎与镜像的只读特性相悖。

我们继续看上面的图，其实可以看到在镜像的最上层，还有一个读写层。而这个读写层，即在容器启动时为当前容器单独挂载。每一个容器在运行时，都会基于当前镜像在其最上层挂载一个读写层。而用户针对容器的所有操作都在读写层中完成。一旦容器销毁，这个读写层也随之销毁。

知识点： 容器=镜像+读写层

而我们针对这个读写层的操作，主要基于两种方式：写时复制和用时分配。

写时复制

所有驱动都用到的技术——写时复制（CoW）。CoW就是copy-on-write，表示只在需要写时才去复制，这个是针对已有文件的修改场景。比如基于一个image启动多个Container，如果为每个Container都去分配一个image一样的文件系统，那么将会占用大量的磁盘空间。而CoW技术可以让所有的容器共享image的文件系统，所有数据都从image中读取，只有对文件修改时（在构建镜像或运行容器时），才从image里把要写的文件复制到可写层进行修改。所以无论有多少个容器共享同一个image，所做的写操作都是对从image中复制到自己的文件系统中的复本上进行，并不会修改image的源文件，且多个容器操作同一个文件，会在每个容器的文件系统里生成一个复本，每个容器修改的都是自己的复本，相互隔离，相互不影响。使用CoW可以有效的提高磁盘的利用率。

用时配置

用时分配是用在原本没有这个文件的场景，只有在要新写入一个文件时才分配空间，这样可以提高存储资源的利用率。比如启动一个容器，并不会为这个容器预分配一些磁盘空间，而是当有新文件写入时，才按需分配新空间。

Docker支持以下存储驱动程序

1. OverlayFS
2. AUFS
3. device mapper
4. Btrfs
5. ZFS
6. VFS

选择合适的存储驱动

• 对于当前支持的所有Linux发行版，overlay2是首选的存储驱动程序，并且不需要额外的配置。
• aufs是Docker 18.06和更老版本的首选存储驱动程序，当运行在Ubuntu 14.04的内核3.13上时，它不支持overlay2。。
• devicemapper支持，但direct-lvm对于生产环境是必需的，虽然loopback-lvm零配置，但是性能很差。devicemapper是CentOS和RHEL的推荐存储驱动程序，因为它们的内核版本不支持overlay2。但是，当前版本的CentOS和RHEL现在支持overlay2，这是推荐的驱动程序。
• 如果btrfs和zfs驱动程序是后备文件系统（安装了Docker的主机的文件系统），则使用它们。这些文件系统允许使用高级选项，例如创建“快照”，但需要更多的维护和设置。这些中的每一个都依赖于正确配置的后备文件系统。
• vfs存储驱动程序用于测试目的，以及无法使用写时复制文件系统的情况。此存储驱动程序的性能很差，通常不建议在生产中使用。

¹）overlay存储驱动程序已在Docker Engine-Enterprise 18.09中弃用，并将在以后的版本中删除。建议将overlay存储驱动程序的用户迁移到overlay2。

²）devicemapper存储驱动程序已在Docker Engine 18.09中弃用，并将在以后的版本中删除。建议将devicemapper存储驱动程序的用户迁移到overlay2。

如果可能，建议使用overlay2作为存储驱动程序。第一次安装Docker时，默认使用的是overlay2。以前，aufs在可用时是默认使用的，但现在不再是这样了。如果您希望在新的安装上使用aufs，那么需要显式地配置它，并且可能需要安装额外的包，比如linux-image-extra。

在使用的现有安装中aufs，它仍然被使用。