Docker镜像竟然也是容器？！Docker 到底为什么这么快！？

• 1、轻量级虚拟化技术
• 2、Docker Imagae 镜像到底是什么？
  • 2.1、小试验：`docker images`为什么删除失败？
  • 2.2、什么是`UnionFS`
  • 2.3、各发行版 UnionFS 的实现
  • 2.4、`AUFS`简介
• 3、参考

Docker 到底为什么这么快！？

两句话回答这个问题：

1. 轻量级虚拟化，性能损耗小
2. AUFS文件系统分层设计，将资源利用率玩到极致

原理冗长，但很有意思，感兴趣请继续。

1、轻量级虚拟化技术

一句话，一张图说明问题。

Docker虚拟化技术是基于容器化，容器化技术的本质其实是基于内核资源调度的再分配！ 并不是什么新技术，只是近年Linux内核更加成熟，在资源调度隔离更成熟，所以容器化技术再被提上议程。

比起传统 KVM,VMware 在磁盘上划分区域，虚拟操作系统的方式，性能不知道提升了多少倍。

虚拟化技术

2、Docker Imagae 镜像到底是什么？

两句话回答问题：

1. 所有父层Image中的数据信息、ID、网络、LXC管理的资源调度、具体的Container配置等，称为 Docker 概念上的 Container 。即 Image 镜像其实也是容器！
2. 要从一个Image启动一个容器，其实是Docker从顺序加载父Image到Base Image的过程. 用户的进程也是运行在Writeable文件系统层。

仓库 -> 镜像 -> 容器 被认为是容器的完整生命周期。从仓库下载镜像，基于镜像创建容器，在容器上运行我们的应用，这是我们绝大多数人对容器和镜像的认知。那么容器和镜像有什么关系，下面这个试验可能会刷新你对容器的认知深度！

2.1、小试验：docker images为什么删除失败？

一句话回答问题：Docker Image 其实也是容器，是基于其运行容器的父容器。删除时会判断是否有子容器依赖

• 试验内容如下：

我们安装一个nginx容器，stop 容器后，尝试直接删除Image 镜像，看看会有什么结果。

• 下载安装nginx容器并启动

[root@O2O-T-K8S-TEST4 ~]# docker run -dt nginx /bin/sh
Unable to find image 'nginx:latest' locally
Trying to pull repository docker.io/library/nginx ...
latest: Pulling from docker.io/library/nginx
123275d6e508: Pull complete
6cd6a943ce27: Pull complete
a50b5ac4a7fb: Pull complete
Digest: sha256:d81f010955749350ef31a119fb94b180fde8b2f157da351ff5667ae037968b28
Status: Downloaded newer image for docker.io/nginx:latest
be89d49cace9294db10b1255ce9f3226f1a7505bdb84596f595dd4c06ffb0232
[root@O2O-T-K8S-TEST4 ~]# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
be89d49cace9        nginx               "/bin/sh"           26 seconds ago      Up 25 seconds       80/tcp              objective_williams

• stop 容器

[root@O2O-T-K8S-TEST4 ~]# docker stop be89d49cace9
be89d49cace9

• 【删除失败】 直接删除 Nginx Image

[root@O2O-T-K8S-TEST4 ~]# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
docker.io/nginx     latest              e791337790a6        3 days ago          127 MB
You have new mail in /var/spool/mail/root
[root@O2O-T-K8S-TEST4 ~]# docker rmi e791337790a6
Error response from daemon: conflict: unable to delete e791337790a6 (must be forced) - image is being used by stopped container be89d49cace9

报错了！Nginx的容器存在，无法删除镜像！ 这是什么呢？还记得我们的容器是STOP状态吗？

• 【删除成功】 先删除容器，再删除Nginx Image

[root@O2O-T-K8S-TEST4 ~]# docker rm be89d49cace9
be89d49cace9
[root@O2O-T-K8S-TEST4 ~]# docker rmi e791337790a6
Untagged: docker.io/nginx:latest
Untagged: docker.io/nginx@sha256:d81f010955749350ef31a119fb94b180fde8b2f157da351ff5667ae037968b28
Deleted: sha256:e791337790a6181d5ce870b3bb16de1a4d5aa3a916e8fba6907f57eb409934cf
Deleted: sha256:615a169a3412634ebf75d5f0f5162290fb6042ba36285bd0ddc9ee123165b95e
Deleted: sha256:bd32d67adcec3dba661c5afebc8a2a5413e68a3283b5ad7df134ed86f00b380a
Deleted: sha256:b60e5c3bcef2f42ec42648b3acf7baf6de1fa780ca16d9180f3b4a3f266fe7bc

这个试验说明Image和Container是有依赖关系的。究其源头，要从Docker的AUFS文件系统说起，而AUFS是UnionFS联合文件系统的一种衍生版本。

哈，很多新名词，莫着急，我们下面会逐步了解

2.2、什么是UnionFS

Union File System,简称UnionFS ,是一种为 Linux, FressBSD和NetBSD操作系统设计的，把多个文件系统联合挂载到一个挂载点的文件系统技术。

敲黑板，下面讲的每句话，每个字都特别重要！特别重要！特别重要！

其核心技术是：它使用branch把不同文件系统的文件和目录“透明”覆盖，形成一个单一的文件系统。外部对该文件系统执行写操作时，系统并未真正改变readonly权限的的系统，而是写入到有read-write权限的系统，即原来的文件没有改变。

联合文件系统，是Docker镜像技术的基础，一种轻量级的高性能分层文件系统，支持将文件系统中的修改进行提交和层层叠加。该特性有利于镜像通过分层实现继承，同时支持将不同目录挂载到同一虚拟文件系统下。

即Docker镜像分为基础镜像和父镜像，没有父镜像的统称为基础镜像。

用户基于基础镜像制作不同的应用镜像。这些应用镜像共享同一个基础镜像，提高存储效率。

用户针对镜像的操作，通常会在新建镜像层进行，其基础镜像并不会改变。使用PhotoShop的同学会更容易理解，很像新建图层。

AUFS是UnionFS的一种。

Docker目前支持的联合文件系统包括AUFS、Btrfs、VSF、DeviceMapper、overlay、overlay2。

2.3、各发行版 UnionFS 的实现

Linux各发行版实现的UnionFS各不相同，所以Docker在不同linux发行版中使用的也不同。通过docker info可以查看docker使用的是哪种UnionFS:

CentOS, Storage Driver: overlay2
debain, Storage Driver: aufs

2.4、AUFS简介

如下内容摘自 COOLSHELL AUFS又叫Another UnionFS，后来叫Alternative UnionFS，后来可能觉得不够霸气，叫成Advance UnionFS。是个叫Junjiro Okajima（岡島順治郎）在2006年开发的，AUFS完全重写了早期的UnionFS 1.x，其主要目的是为了可靠性和性能，并且引入了一些新的功能，比如可写分支的负载均衡。AUFS在使用上全兼容UnionFS，而且比之前的UnionFS在稳定性和性能上都要好很多，后来的UnionFS 2.x开始抄AUFS中的功能。但是他居然没有进到Linux主干里，就是因为Linus不让，基本上是因为代码量比较多，而且写得烂（相对于只有3000行的union mount和10000行的UnionFS，以及其它平均下来只有6000行代码左右的VFS，AUFS居然有30000行代码），所以，岡島不断地改进代码质量，不断地提交，不断地被Linus拒掉，所以，到今天AUFS都还进不了Linux主干（今天你可以看到AUFS的代码其实还好了，比起OpenSSL好N倍，要么就是Linus对代码的质量要求非常高，要么就是Linus就是不喜欢AUFS）。

Docker使用AUFS就是一种联合文件系统。简单讲**“支持将不同目录挂载到同一虚拟文件系统下的文件系统”**。其思想也是借鉴 Linux 启动。

Linux的启动到运行需要两个文件系统: BootFS 和 RootFS.

• BootFS

BootFS主要包括BootLoader和Kernel。BootLoader主要引导加载Kernel，当Boot成功后，Kernel被加载到内存中BootFS就被Umount了。

• RootFS

RootFS包含了典型Linux中的/dev、/proc、/bin等标准目录和文件。

不同的Linux发行版，BootFS基本一致，但RootFS可能会有差异。

Linux启动后，先将RootFS置为Readonly,检查结束后切换为Readwrite供用户使用。

Docker也是利用该技术，Union Mount在Readonly的RootFS系统上挂载Readwrite文件系统。并且向上叠加，使一组Readonly和Readwrite的结构构成一个Container的运行目录。每层被称为一个文件系统Layer。

• 镜像

敲黑板了哦！镜像究竟是什么，埋伏了这么多，这里终于经神龙现身了！！

AUFS的特性，使得每个针对Readonly层文件/目录的修改都只会存在于上层的Writeable层中，这样不存在竞争，且多个Container可以共享Readonly文件系统层 。在 Docker 中，将Readonly层称为镜像层.

对于Container整体而言，整个RootFS是read-write，但事实上所有修改都写入的是上层的writeable 层, image 并不保存用户状态。

通常,上层的image依赖下层的image, 因此， Docker 通常把下层的image称为父镜像， 没有父镜像的image称为Base Image.

• 容器的启动

因此，要从一个Image启动一个容器，其实是Docker从顺序加载 父Image到Base Image的过程. 用户的进程也是运行在Writeable文件系统层。

所有父层Image中的数据信息、ID、网络、LXC管理的资源调度、具体的Container配置等，称为 Docker 概念上的 Container .

讲到这里，终于结束了。那么你已经懂了吧？^^

3、参考

https://docs.docker.com/storage/storagedriver/overlayfs-driver/ https://coolshell.cn/articles/17061.html