docker 存储驱动（一） ---- overlay2

官方的文档请参考：docker overlay stroage

一直很好奇docker是怎么存image的。再这总结一下。

前提

OverlayFS is supported if you meet the following prerequisites:

• The overlay2 driver is supported on Docker CE, and Docker EE 17.06.02-ee5 and up, and is the recommended storage driver.
  Version 4.0 or higher of the Linux kernel, or RHEL or CentOS using version 3.10.0-514 of the kernel or higher. If you use an older kernel, you need to use the overlay driver, which is not recommended.

  • The overlay and overlay2 drivers are supported on xfs backing filesystems, but only with d_type=true enabled.

• Use xfs_info to verify that the ftype option is set to 1. To format an xfs filesystem correctly, use the flag -n ftype=1.
  Warning: Running on XFS without d_type support now causes Docker to skip the attempt to use the overlay or overlay2 driver. Existing installs will continue to run, but produce an error. This is to allow users to migrate their data. In a future version, this will be a fatal error, which will prevent Docker from starting.

• Changing the storage driver makes existing containers and images inaccessible on the local system. Use docker save to save any images you have built or push them to Docker Hub or a private registry before changing the storage driver, so that you do not need to re-create them later.

官网给出了使用overlay2的前提条件。
那么如何看docker的存储驱动呢？

mcong@mcong-Virtual-Machine:~$ docker info|grep "Storage Driver"
Storage Driver: overlay2

docker overlay2 工作机制

Image and container layers on-disk

我们把ubuntu的image作为例子。

root@mcong-Virtual-Machine:/var/lib/docker/overlay2# docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
6abc03819f3e: Pull complete
05731e63f211: Pull complete
0bd67c50d6be: Pull complete
Digest: sha256:f08638ec7ddc90065187e7eabdfac3c96e5ff0f6b2f1762cf31a4f49b53000a5
Status: Downloaded newer image for ubuntu:latest

可以看出，这个image有三层。那么这个image是怎么存储的呢？

root@mcong-Virtual-Machine:/home/mcong# cd /var/lib/docker/overlay2/
root@mcong-Virtual-Machine:/var/lib/docker/overlay2# ls -l
total 16
drwx------ 4 root root 4096 May 21 03:26 071bf84e3c225f0b81340d225832100b04bb015b0a3dcd0fb376e0d88e97f8f3
drwx------ 4 root root 4096 May 21 03:26 0aa86c675bb91414fe320abbe7d04ef1f916f17caaca16f4d3d5ff65f8a3e7d1
drwx------ 3 root root 4096 May 21 03:26 8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859
drwx------ 2 root root 4096 May 21 03:26 l

overlay2这个文件夹里边有四个文件夹，有个怪异的文件叫“l“，就是小写的”L“，这里面都是软连接文件目录的简写标识，这个主要是为了避免mount时候页大小的限制。

root@mcong-Virtual-Machine:/var/lib/docker/overlay2# ls -l l
total 12
lrwxrwxrwx 1 root root 72 May 21 03:26 2AKHZHYWB6NVU54RID3EVEOJRL -> ../071bf84e3c225f0b81340d225832100b04bb015b0a3dcd0fb376e0d88e97f8f3/diff
lrwxrwxrwx 1 root root 72 May 21 03:26 IVKI5UJXVI6PDDFG772SYUG5BF -> ../0aa86c675bb91414fe320abbe7d04ef1f916f17caaca16f4d3d5ff65f8a3e7d1/diff
lrwxrwxrwx 1 root root 72 May 21 03:26 V445NSA64ILRIBFUP5D4NVHC5I -> ../8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859/diff

其他三个文件夹就我我们pull时候下载的3层layer
那么这三个文件是如何组织成一个image的？
首先我们看看8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859这个文件夹

root@mcong-Virtual-Machine:/var/lib/docker/overlay2# ls 8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859
diff  link
root@mcong-Virtual-Machine:/var/lib/docker/overlay2# cat 8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859/link
V445NSA64ILRIBFUP5D4NVHC5I

上边说过‘l“这个目录里边有V445NSA64ILRIBFUP5D4NVHC5I是link到…/8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859/diff， 我们看看这个文件里边有什么：

root@mcong-Virtual-Machine:/var/lib/docker/overlay2# ls 8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859/diff
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

这个就是我们的文件系统，最有可能是我们的base image。
这个文件夹搞明白了，那么其他连个文件夹呢？

root@mcong-Virtual-Machine:/var/lib/docker/overlay2# cat 0aa86c675bb91414fe320abbe7d04ef1f916f17caaca16f4d3d5ff65f8a3e7d1/lower
l/2AKHZHYWB6NVU54RID3EVEOJRL:l/V445NSA64ILRIBFUP5D4NVHC5I

这就表明了这个文件应该是顶层的layer，它的lower包含其他两个layer。
我们再去最后一个文件夹看看：

root@mcong-Virtual-Machine:/var/lib/docker/overlay2# cat 071bf84e3c225f0b81340d225832100b04bb015b0a3dcd0fb376e0d88e97f8f3/lower
l/V445NSA64ILRIBFUP5D4NVHC5I

这个应该就是中间层。

还有一个问题：这两层有什么东西呢。
东西都是存在diff这个目录下。

那么我们跑一下这个container会有什么效果？

root@mcong-Virtual-Machine:~# docker run -ti ubuntu bash

root@mcong-Virtual-Machine:/var/lib/docker/overlay2# ls
071bf84e3c225f0b81340d225832100b04bb015b0a3dcd0fb376e0d88e97f8f3
0aa86c675bb91414fe320abbe7d04ef1f916f17caaca16f4d3d5ff65f8a3e7d1
8ea06311f7fa82211f09765c9880b1bf1b947ac21bb98b99f6a573ce69b55859
b22e19f8a8a698ee8b5c210285517cb141a8e5a248f864a5b87924eee227a3e1
b22e19f8a8a698ee8b5c210285517cb141a8e5a248f864a5b87924eee227a3e1-init

这里多了两个目录。
先看不带init的目录：

root@mcong-Virtual-Machine:/var/lib/docker/overlay2/b22e19f8a8a698ee8b5c210285517cb141a8e5a248f864a5b87924eee227a3e1# ls
diff  link  lower  merged  work

这里会多一个merged目录，这个目录就是我们再container里边看到的目录结构。diff目录存放了container里边多/少的
为了测试， 我再container中创建了/home/aaa.test并且删掉bin目录下sleep和sync两个文件。
我们再去目录里看看

root@mcong-Virtual-Machine:/var/lib/docker/overlay2/b22e19f8a8a698ee8b5c210285517cb141a8e5a248f864a5b87924eee227a3e1/diff/bin# ls -l
total 0
c--------- 1 root root 0, 0 May 21 04:03 sleep
c--------- 1 root root 0, 0 May 21 04:03 sync

可以看出diff里边这两个文件已经mark成删除了。

root@mcong-Virtual-Machine:/var/lib/docker/overlay2/b22e19f8a8a698ee8b5c210285517cb141a8e5a248f864a5b87924eee227a3e1/diff/home# ls -l
total 0
-rw-r--r-- 1 root root 0 May 21 04:00 aaa.test

aaa.test已经存在。

这里如果启动容器还有一点需要介绍，你会看到多了一个”读写层-init”，这个只读层，它的目的是为了初始化容器配置信息，譬如hostname等信息

How the overlay driver works

官网的图片很生动， 就是原来diff目录叫upperdir。官网还没有更新。
OverlayFS将单个Linux主机上的两个目录合并成一个目录。这些目录被称为层，统一过程被称为联合挂载。OverlayFS关联的底层目录称为lower，合并过后统一视图称为merged。

下图是一个docker镜像和docke容器的分层图，docker镜像是lower，docker容器是diff。而统一的视图层是merged层

文件操作

那么当我们读写文件的时候各层是怎样合作的呢？

• 读

  如果该文件在容器层不存在：文件不存在diff中，则从lower中读取
  只在容器层存在： 文件只存在diff中，则直接从容器中读取改文件
  文件同事存在容器曾和镜像层：容器层diff会覆盖镜像层lowdir中的文件

• 修改

  首次写入： 改文件在diff中不存在，在overlay和overlay2中，执行copy_up操作，把文件从lowdir拷贝到diff。然后所以的更改都是在容器层内修改副本的操作，由于overlayfs是文件级别的，不是块级别的，这就意味着即使文件只有很少的一点修改，也会产生的copy_up的行为，不过有两点需要注意：

  1. copy_up操作只发生在文件首次写入，以后都是只修改副本
  2. overlayfs只适用两层，因此性能很好，查找搜索都更快

• 删除文件和目录： 当文件在容器被删除时，在容器层（diff）创建whiteout文件，镜像层的文件是不会被删除的，因为他们是只读的，但without文件会阻止他们展现，当目录在容器内被删除时，在容器层（diff）一个不透明的目录，这个和上面whiteout原理一样，阻止用户继续访问，即便镜像层仍然存在
  最后画个图：