Docker镜像管理

Docker镜像管理

• 一、镜像的概念
• 二、镜像详解
  • 2.1 UnionFS(联合文件系统)
  • 2.2 基于联合文件系统的镜像分层
  • 2.3 基于Dockerfile文件的镜像分层
  • 2.4 Docker镜像为什么分层？
• 三、容器读写层的工作原理
  • 3.1 写时复制(copy on write)
  • 3.2 用时配置
• 四、存储驱动
  • 4.1 AUFS
  • 4.2 OverlayFS
  • 4.3 Device mapper
  • 4.4 Btrfs
  • 4.5 ZFS
• 五、存储驱动的对比及适应场景
  • 5.1 AUFS VS Overlay
  • 5.2 Overlay VS Device mapper
  • 5.3 Device mapper VS Btrfs Driver VS ZFS
  • 5.4 在IO性能上

---

一、镜像的概念

Docker镜像是一种轻量级，可执行的独立软件包，用来打包软件运行环境和基于运行环境开发的程序，它包含运行某个程序所需要所有内容，包括代码、库文件、环境变量和配置文件。

简单来说Docker镜像就好比是一个模板，可以通过这个模板来创建容器服务；一个镜像可以创建多个容器（程序运行在容器中）。

Docker镜像的获取方式：

• 从公有仓库下载
• 他人拷贝给你
• 自己制作docker镜像（DockerFile）

二、镜像详解

2.1 UnionFS(联合文件系统)

UnionFS（联合文件系统）是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层一层的叠加，同时可以将不同的文件系统挂载到同一个虚拟文件系统下。UnionFS（联合文件系统）是Docker镜像的基础，镜像可以通过分层来进行继承，基于基础镜像可以制作各种应用镜像。

UnionFS（联合文件系统）特性：一次同时加载多个文件系统，但从外面看起来，只能看到一个文件系统，联合加载会把各层文件系统叠加起来，这样最终的文件系统会包含所有底层的文件和目录。

2.2 基于联合文件系统的镜像分层

Docker的镜像实际上由一层一层的文件系统组成，使用层级的文件系统UnionFS。

典型的Linux文件系统由bootfs和rootfs两部分组成。

• bootfs(boot file system)主要包含bootloader和kernel， bootloader主要是引导加载kernel，Linux刚启动时会加载bootfs文件系统，在Docker镜像的最底层是bootfs。这一层与我们典型的Linux/Unix系统是一样的，包含boot加载器和内核。当boot加载完成之后整个内核就都在内存中了，此时内存的使用权已由bootfs转交给内核，此时系统也会卸载bootfs。
• rootfs (root file system) ，在bootfs之上。包含的就是典型Linux系统中的/dev, /proc, /bin, /etc等标准目录和文件。rootfs就是各种不同的操作系统发行版，比如：Centos、Ubuntu等等。

这里也解释了为什么虚拟机占用空间非常大通常以G为单位，为什么docker这里才几十上百M？

• 对于一个精简的OS，rootfs可以很小，只需要包括最基本的命令、工具和程序库就可以了，因为底层直接用Host的kernel，自己只需要提供rootfs就行了。由此可见对于不同的linux发行版, bootfs基本是一致的, rootfs会有差别, 因此不同的发行版可以公用bootfs。

基于联合文件系统的镜像分层优缺点：

优点：

• 便于镜像的修改。
• 有助于共享资源。具有相同环境的应用程序的镜像共享同一个环境镜像，不需要每个镜像都创建一个底层环境，运行时也只需要加载同一个底层环境。

不足：

• 会导致镜像的层数越来越多，而联合文件系统所允许的层数是有限的。
• 当需要修改大文件时，以文件为粒度的写时拷贝需要复制整个大文件进行修改，会影响操作效率。
• 一些上层的镜像都基于相同的底层基础镜像，一旦基础镜像需要修改，而基于它的上层镜像如果是通过容器生成的，则维护工作量会变得相当大。
• 镜像的使用者无法对镜像进行审计，存在一定的安全隐患。

2.3 基于Dockerfile文件的镜像分层

为克服镜像分层方式的不足，Docker推荐选择Dockerfile文件逐层构建镜像。

大多数Docker镜像都是在其他镜像的基础上逐层建立起来的。Dockerfile文件在构建镜像时每一层都由镜像的Dockerfile指令所决定。除了最后一层，每层都是只读的。

FROM centos:7
RUN yum -y install vim
CMD ["/bin/bash"]

2.4 Docker镜像为什么分层？

镜像分层最大的一个好处就是共享资源。

比如说有多个镜像都从相同的底层镜像构建而来，那么Docker Host只需保存一份底层镜像；同时运行时内存中也只需加载一份底层镜像，就可以为所有容器服务了；而且镜像的每一层都可以被共享。

三、容器读写层的工作原理

在容器启动时为当前容器单独挂载。每一个容器在运行时，都会基于当前镜像在其最上层挂载一个读写层。而用户针对容器的所有操作都在读写层中完成。一旦容器销毁，这个读写层也随之销毁
容器=镜像+读写层
而我们针对这个读写层的操作，主要基于两种方式：写时复制和用时分配

3.1 写时复制(copy on write)

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

3.2 用时配置

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

四、存储驱动

docker提供了多种存储驱动来实现不同的方式存储镜像，常用的有五种存储驱动：

AUFS、OverlayFS、Device mapper、Btrfs、ZFS

4.1 AUFS

AUFS（AnotherUnionFS）是一种Union FS，是文件级的存储驱动。AUFS是一个能透明覆盖一个或多个现有文件系统的层状文件系统，把多层合并成文件系统的单层表示。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种文件系统可以一层一层地叠加修改文件。无论底下有多少层都是只读的，只有最上层的文件系统是可写的。当需要修改一个文件时，AUFS创建该文件的一个副本，使用CoW将文件从只读层复制到可写层进行修改，结果也保存在可写层。在Docker中，底下的只读层就是image，可写层就是Container。

AUFS文件系统据说有3W行代码，而ext4文件系统却只有4000-5000行左右代码，这些代码是要被整合进内核的，后来AUFS申请要被合并进内核代码的时候，linuz觉得它这代码太过臃肿，于是拒绝了。因此AUFS这个文件系统一直以来就不是linux内核中自有的文件系统，想用AUFS这个文件系统的话，必须自己向内核打补丁并去编译使用它，但redhat系列的操作系统一向以稳定著称，不会干这种出格的事，所以在redhat系列操作系统中使用AUFS并无可能。而ubuntu上的docker默认使用的就是AUFS。

结构如下图：

4.2 OverlayFS

Overlay是Linux内核3.18后支持的，也是一种Union FS，和AUFS的多层不同的是Overlay只有两层：一个upper文件系统和一个lower文件系统，分别代表Docker的镜像层和容器层。当需要修改一个文件时，使用CoW将文件从只读的lower复制到可写的upper进行修改，结果也保存在upper层。在Docker中，底下的只读层就是image，可写层就是Container。目前最新的OverlayFS为Overlay2。

结构如下图：

4.3 Device mapper

	Device mapper是Linux内核2.6.9后支持的，提供的一种从逻辑设备到物理设备的映射框架机制，在该机制下，用户可以很方便的根据自己的需要制定实现存储资源的管理策略。前面讲的AUFS和OverlayFS都是文件级存储，而Device mapper是块级存储，所有的操作都是直接对块进行操作，而不是文件。Device mapper驱动会先在块设备上创建一个资源池，然后在资源池上创建一个带有文件系统的基本设备，所有镜像都是这个基本设备的快照，而容器则是镜像的快照。所以在容器里看到文件系统是资源池上基本设备的文件系统的快照，并不有为容器分配空间。当要写入一个新文件时，在容器的镜像内为其分配新的块并写入数据，这个叫用时分配。当要修改已有文件时，再使用CoW为容器快照分配块空间，将要修改的数据复制到在容器快照中新的块里再进行修改。Device mapper 驱动默认会创建一个100G的文件包含镜像和容器。每一个容器被限制在10G大小的卷内，可以自己配置调整。

OverlayFS是文件级存储，Device mapper是块级存储，当文件特别大而修改的内容很小，Overlay不管修改的内容大小都会复制整个文件，对大文件进行修改显然要比小文件要消耗更多的时间，而块级无论是大文件还是小文件都只复制需要修改的块，并不是整个文件，在这种场景下，显然device mapper要快一些。因为块级的是直接访问逻辑盘，适合IO密集的场景。而对于程序内部复杂，大并发但少IO的场景，Overlay的性能相对要强一些。

结构如下图：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XnuvSWEv-1660381988186)(https://qny.helloyf.fun/blog/docker14.jpg)]

4.4 Btrfs

Btrfs被称为下一代写时复制文件系统，并入Linux内核，也是文件级级存储，但可以像Device mapper一直接操作底层设备。Btrfs把文件系统的一部分配置为一个完整的子文件系统，称之为subvolume 。那么采用 subvolume，一个大的文件系统可以被划分为多个子文件系统，这些子文件系统共享底层的设备空间，在需要磁盘空间时便从底层设备中分配，类似应用程序调用 malloc()分配内存一样。为了灵活利用设备空间，Btrfs 将磁盘空间划分为多个chunk 。每个chunk可以使用不同的磁盘空间分配策略。比如某些chunk只存放metadata，某些chunk只存放数据。这种模型有很多优点，比如Btrfs支持动态添加设备。用户在系统中增加新的磁盘之后，可以使用Btrfs的命令将该设备添加到文件系统中。Btrfs把一个大的文件系统当成一个资源池，配置成多个完整的子文件系统，还可以往资源池里加新的子文件系统，而基础镜像则是子文件系统的快照，每个子镜像和容器都有自己的快照，这些快照则都是subvolume的快照。

结构如下图：

当写入一个新文件时，为在容器的快照里为其分配一个新的数据块，文件写在这个空间里，这个叫用时分配。而当要修改已有文件时，使用CoW复制分配一个新的原始数据和快照，在这个新分配的空间变更数据，结束再更新相关的数据结构指向新子文件系统和快照，原来的原始数据和快照没有指针指向，则被覆盖。

4.5 ZFS

ZFS 文件系统是一个革命性的全新的文件系统，它从根本上改变了文件系统的管理方式，ZFS 完全抛弃了“卷管理”，不再创建虚拟的卷，而是把所有设备集中到一个存储池中来进行管理，用“存储池”的概念来管理物理存储空间。过去，文件系统都是构建在物理设备之上的。为了管理这些物理设备，并为数据提供冗余，“卷管理”的概念提供了一个单设备的映像。而ZFS创建在虚拟的，被称为“zpools”的存储池之上。每个存储池由若干虚拟设备（virtual devices，vdevs）组成。这些虚拟设备可以是原始磁盘，也可能是一个RAID1镜像设备，或是非标准RAID等级的多磁盘组。于是zpool上的文件系统可以使用这些虚拟设备的总存储容量。

在Docker里ZFS的使用。首先从zpool里分配一个ZFS文件系统给镜像的基础层，而其他镜像层则是这个ZFS文件系统快照的克隆，快照是只读的，而克隆是可写的，当容器启动时则在镜像的最顶层生成一个可写层。

结构如下图：

当要写一个新文件时，使用按需分配，一个新的数据快从zpool里生成，新的数据写入这个块，而这个新空间存于容器(ZFS的克隆)里。

当要修改一个已存在的文件时，使用写时复制，分配一个新空间并把原始数据复制到新空间完成修改。

五、存储驱动的对比及适应场景

存储驱动	特点	优点	缺点	适用场景
AUFS	联合文件系统、未并入内核主线、文件级存储	作为docker的第一个存储驱动，已经有很长的历史，比较稳定，且在大量的生产中实践过，有较强的社区支持	有多层，在做写时复制操作时，如果文件比较大且存在比较低的层，可能会慢一些	大并发但少IO的场景
overlayFS	联合文件系统、并入内核主线、文件级存储	只有两层	不管修改的内容大小都会复制整个文件，对大文件进行修改显示要比小文件消耗更多的时间	大并发但少IO的场景
Devicemapper	并入内核主线、块级存储	块级无论是大文件还是小文件都只复制需要修改的块，并不是整个文件	不支持共享存储，当有多个容器读同一个文件时，需要生成多个复本，在很多容器启停的情况下可能会导致磁盘溢出	适合io密集的场景
Btrfs	并入linux内核、文件级存储	可以像devicemapper一样直接操作底层设备，支持动态添加设备	不支持共享存储，当有多个容器读同一个文件时，需要生成多个复本	不适合在高密度容器的paas平台上使用
ZFS	把所有设备集中到一个存储池中来进行管理	支持多个容器共享一个缓存块，适合内存大的环境	COW使用碎片化问题更加严重，文件在硬盘上的物理地址会变的不再连续，顺序读会变的性能比较差	适合paas和高密度的场景

5.1 AUFS VS Overlay

AUFS和Overlay都是联合文件系统，但AUFS有多层，而Overlay只有两层，所以在做写时复制操作时，如果文件比较大且存在比较低的层，则AUSF可能会慢一些。而且Overlay并入了linux kernel mainline，AUFS没有，所以可能会比AUFS快。但Overlay还太年轻，要谨慎在生产使用。而AUFS做为docker的第一个存储驱动，已经有很长的历史，比较的稳定，且在大量的生产中实践过，有较强的社区支持。目前开源的DC/OS指定使用Overlay

5.2 Overlay VS Device mapper

Overlay是文件级存储，Device mapper是块级存储，当文件特别大而修改的内容很小，Overlay不管修改的内容大小都会复制整个文件，对大文件进行修改显示要比小文件要消耗更多的时间，而块级无论是大文件还是小文件都只复制需要修改的块，并不是整个文件，在这种场景下，显然device mapper要快一些。因为块级的是直接访问逻辑盘，适合IO密集的场景。而对于程序内部复杂，大并发但少IO的场景，Overlay的性能相对要强一些。

5.3 Device mapper VS Btrfs Driver VS ZFS

Device mapper和Btrfs都是直接对块操作，都不支持共享存储，表示当有多个容器读同一个文件时，需要生活多个复本，所以这种存储驱动不适合在高密度容器的PaaS平台上使用。而且在很多容器启停的情况下可能会导致磁盘溢出，造成主机不能工作。Device mapper不建议在生产使用。Btrfs在docker build可以很高效。
​ ZFS最初是为拥有大量内存的Salaris服务器设计的，所在在使用时对内存会有影响，适合内存大的环境。ZFS的COW使碎片化问题更加严重，对于顺序写生成的大文件，如果以后随机的对其中的一部分进行了更改，那么这个文件在硬盘上的物理地址就变得不再连续，未来的顺序读会变得性能比较差。ZFS支持多个容器共享一个缓存块，适合PaaS和高密度的用户场景

5.4 在IO性能上

AUFS在读的方面性能相比Overlay要差一些，但在写的方面性能比Overlay要好
device mapper在512M以上文件的读写性能都非常的差，但在512M以下的文件读写性能都比较好
btrfs在512M以上的文件读写性能都非常好，但在512M以下的文件读写性能相比其他的存储驱动都比较差
ZFS整体的读写性能相比其他的存储驱动都要差一些