Docker学习笔记（二）——Docker底层技术

1. 基础知识：Linux namespace 的概念

    Linux 内核从版本 2.4.19 开始陆续引入了 namespace 的概念。其目的是将某个特定的全局系统资源（global system resource）通过抽象方法使得namespace 中的进程看起来拥有它们自己的隔离的全局系统资源实例（The purpose of each namespace is to wrap a particular global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. ）。Linux 内核中实现了六种 namespace，按照引入的先后顺序，列表如下：

namespace	引入的相关内核版本	被隔离的全局系统资源	在容器语境下的隔离效果
Mount namespaces	Linux 2.4.19	文件系统挂接点	每个容器能看到不同的文件系统层次结构
UTS namespaces	Linux 2.6.19	nodename 和 domainname	每个容器可以有自己的 hostname 和 domainame
IPC namespaces	Linux 2.6.19	特定的进程间通信资源，包括System V IPC 和  POSIX message queues	每个容器有其自己的 System V IPC 和 POSIX 消息队列文件系统，因此，只有在同一个 IPC namespace 的进程之间才能互相通信
PID namespaces	Linux 2.6.24	进程 ID 数字空间 （process ID number space）	每个 PID namespace 中的进程可以有其独立的 PID； 每个容器可以有其 PID 为 1 的root 进程；也使得容器可以在不同的 host 之间迁移，因为 namespace 中的进程 ID 和 host 无关了。这也使得容器中的每个进程有两个PID：容器中的 PID 和 host 上的 PID。
Network namespaces	始于Linux 2.6.24 完成于 Linux 2.6.29	网络相关的系统资源	每个容器用有其独立的网络设备，IP 地址，IP 路由表，/proc/net 目录，端口号等等。这也使得一个 host 上多个容器内的同一个应用都绑定到各自容器的 80 端口上。
User namespaces	始于 Linux 2.6.23 完成于 Linux 3.8)	用户和组 ID 空间	在 user namespace 中的进程的用户和组 ID 可以和在 host 上不同； 每个 container 可以有不同的 user 和 group id；一个 host 上的非特权用户可以成为 user namespace 中的特权用户；

Linux namespace 的概念说简单也简单说复杂也复杂。简单来说，我们只要知道，处于某个 namespace 中的进程，能看到独立的它自己的隔离的某些特定系统资源；复杂来说，可以去看看 Linux 内核中实现 namespace 的原理，网络上也有大量的文档供参考，这里不再赘述。

2. Docker 容器使用 linux namespace 做运行环境隔离

当 Docker 创建一个容器时，它会创建新的以上六种 namespace 的实例，然后把容器中的所有进程放到这些 namespace 之中，使得Docker 容器中的进程只能看到隔离的系统资源。 

2.1 PID namespace

我们能看到同一个进程，在容器内外的 PID 是不同的：

• 在容器内 PID 是 1，PPID 是 0。
• 在容器外 PID 是 2198， PPID 是 2179 即 docker-containerd-shim 进程.
• pid namespace 通过将 host 上 PID 映射为容器内的 PID， 使得容器内的进程看起来有个独立的 PID 空间。

2.2 UTS namespace

类似地，容器可以有自己的 hostname 和 domainname：

root@onfocus:/home/lee# hostname
onfocus
root@devstack:/home/lee# docker exec -it web hostname
8b7dd09fbcae

2.3 user namespace

2.3.1 Linux 内核中的 user namespace

 

老版本中，Linux 内核里面只有一个数据结构负责处理用户和组。内核从3.8 版本开始实现了 user namespace。通过在 clone() 系统调用中使用 CLONE_NEWUSER 标志，一个单独的 user namespace 就会被创建出来。在新的 user namespace 中，有一个虚拟的用户和用户组的集合。这些用户和用户组，从 uid/gid 0 开始，被映射到该 namespace 之外的 非 root 用户。

 

在现在的linux内核中，管理员可以创建成千上万的用户。这些用户可以被映射到每个 user namespace 中。通过使用 user namespace 功能，不同的容器可以有完全不同的 uid 和 gid 数字。容器 A 中的 User 500 可能被映射到容器外的 User 1500，而容器 B 中的 user 500 可能被映射到容器外的用户 2500.

 

为什么需要这么做呢？因为在容器中，提供 root 访问权限有其特殊用途。想象一下，容器 A 中的 root 用户 （uid 0） 被映射到宿主机上的 uid 1000，容器B 中的 root 被映射到 uid 2000.类似网络端口映射，这允许管理员在容器中创建 root 用户，而不需要在宿主机上创建。 

2.3.2 Docker 对 user namespace 的支持

在 Docker 1.10 版本之前，Docker 是不支持 user namespace。也就是说，默认地，容器内的进程的运行用户就是 host 上的 root 用户，这样的话，当 host 上的文件或者目录作为 volume 被映射到容器以后，容器内的进程其实是有 root 的几乎所有权限去修改这些 host 上的目录的，这会有很大的安全问题。

举例：

• 启动一个容器： docker run -d -v /bin:/host/bin --name web34 training/webapp python app.py
• 此时进程的用户在容器内和外都是root，它在容器内可以对 host 上的 /bin 目录做任意修改

而 Docker 1.10 中引入的 user namespace 就可以让容器有一个 “假”的  root 用户，它在容器内是 root，它被映射到容器外一个非 root 用户。也就是说，user namespace 实现了 host users 和 container users 之间的映射。

启用步骤：

1. 修改 /etc/default/docker 文件，添加行  DOCKER_OPTS="--userns-remap=default"
2. 重启 docker 服务，此时 dockerd 进程为 /usr/bin/dockerd --userns-remap=default --raw-logs
3. 然后创建一个容器：docker run -d -v /bin:/host/bin --name web35 training/webapp python app.py
4. 查看进程在容器内外的用户：

root@onfocus:/home/lee# ps -ef | grep python
231072    1726  1686  0 01:44 ?        00:00:00 python app.py

root@onfocus:/home/lee# docker exec web35 ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 17:44 ?        00:00:00 python app.py

• 查看文件/etc/subuid 和 /etc/subgid，可以看到 dockermap 用户在host 上的 uid 和 gid 都是 231072：

 

root@onfocus:/home/lee# cat /etc/subuid
lee:100000:65536
stack:165536:65536
dockremap:231072:65536

root@onfocus:/home/lee# cat /etc/subgid
lee:100000:65536
stack:165536:65536
dockremap:231072:65536

• 再看文件/proc/1726/uid_map，它表示了容器内外用户的映射关系，即将host 上的 231072 用户映射为容器内的 0 （即root）用户。

root@onfocus:/home/lee# cat /proc/1726/uid_map
         0     231072      65536

•  现在，我们试图在容器内修改 host 上的 /bin 文件夹，就会提示权限不足了：

root@80993d821f7b:/host/bin# touch test2
touch: cannot touch 'test2': Permission denied

这说明通过使用 user namespace，使得容器内的进程运行在非 root 用户，我们就成功地限制了容器内进程的权限。

正是/proc//uid_map 和 /proc//gid_map 这两个文件， 把容器中的uid和真实系统的uid给映射在一起。这两个文件的格式为：

ID-inside-ns ID-outside-ns length 

其中：  

• 第一个字段ID-inside-ns表示在容器显示的UID或GID，
• 第二个字段ID-outside-ns表示容器外映射的真实的UID或GID。
• 第三个字段表示映射的范围，一般填1，表示一一对应。

举个例子, 0 1000 256这条配置就表示父user namespace中的1000~1256映射到新user namespace中的0~256。

 比如，把真实的uid=1000映射成容器内的uid=0：

把namespace内部从0开始的uid映射到外部从0开始的uid，其最大范围是无符号32位整形：

上面的截图中正是后面这种情形，也就是容器中的 uid 和宿主机上的 uid 是从0开始一一对应着映射的。 

备注：linux user namespace 非常复杂，应该是所有 namespace 中最复杂的一个。这里只是一个简单介绍，还进一步理解，还需要阅读更多材料，比如https://lwn.net/Articles/532593/

2.4 network namespace

  默认情况下，当 docker 实例被创建出来后，使用 ip netns  命令无法看到容器实例对应的 network namespace。这是因为 ip netns 命令是从 /var/run/netns 文件夹中读取内容的。

步骤：

1. 找到容器的主进程 ID

root@onfocus:/home/lee# docker inspect --format '{{.State.Pid}}' web5
2704

2. 创建  /var/run/netns 目录以及符号连接

root@onfocus:/home/lee# mkdir /var/run/netns
root@onfocus:/home/lee# ln -s /proc/2704/ns/net /var/run/netns/web5

3. 此时可以使用 ip netns 命令了

root@onfocus:/home/lee# ip netns
web5
root@onfocus:/home/lee# ip netns exec web5 ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
  valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
  valid_lft forever preferred_lft forever
15: eth0:  mtu 1500 qdisc noqueue state UP group default
  link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
  inet 172.17.0.3/16 scope global eth0
  valid_lft forever preferred_lft forever
  inet6 fe80::42:acff:fe11:3/64 scope link
  valid_lft forever preferred_lft forever

其他的几个 namespace，比如 network，mnt 等，比较简单，这里就不多说了。总之，Docker 守护进程为每个容器都创建了六种namespace 的实例，使得容器中的进程都处于一种隔离的运行环境之中：

root@devstack:/proc/1726/ns# ls -l
total 0
lrwxrwxrwx 1 231072 231072 0 Sep 18 01:45 ipc -> ipc:[4026532210]
lrwxrwxrwx 1 231072 231072 0 Sep 18 01:45 mnt -> mnt:[4026532208]
lrwxrwxrwx 1 231072 231072 0 Sep 18 01:44 net -> net:[4026532213]
lrwxrwxrwx 1 231072 231072 0 Sep 18 01:45 pid -> pid:[4026532211]
lrwxrwxrwx 1 231072 231072 0 Sep 18 01:45 user -> user:[4026532207]
lrwxrwxrwx 1 231072 231072 0 Sep 18 01:45 uts -> uts:[4026532209] 

3. Docker run 命令中 namespace 中相关参数

Docker run 命令有几个参数和 namespace 相关：

• --ipc string IPC namespace to use
• --pid string PID namespace to use
• --userns string User namespace to use
• --uts string UTS namespace to use

3.1 --userns

--userns：指定容器使用的 user namespace

• 'host': 使用 Docker host user namespace
• '': 使用由 `--userns-remap‘ 指定的 Docker deamon user namespace

你可以在启用了 user namespace 的情况下，强制某个容器运行在 host user namespace 之中：

root@onfocus:/proc/2835# docker run -d -v /bin:/host/bin --name web37 --userns host training/webapp python app.py
9c61e9a233abef7badefa364b683123742420c58d7a06520f14b26a547a9476c
root@onfocus:/proc/2835# ps -ef | grep python
root      2962  2930  1 02:17 ?        00:00:00 python app.py

否则默认的话，就会运行在特定的 user namespace 之中了。

3.2 --pid

同样的，可以指定容器使用 Docker host pid namespace，这样，在容器中的进程，可以看到 host 上的所有进程。注意此时不能启用 user namespace。

 

3.3 --uts

同样地，可以使容器使用 Docker host uts namespace。此时，最明显的是，容器的 hostname 和 Docker hostname 是相同的。

扩展阅读：

• http://lwn.net/Articles/531114/
• Docker基础技术：Linux Namespace（上）
• Docker基础技术：Linux Namespace（下）
• https://github.com/crosbymichael/dockercon-2016/blob/master/Creating%20Containerd.pdf
• https://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf
• https://blog.yadutaf.fr/2016/04/14/docker-for-your-users-introducing-user-namespace/
• https://success.docker.com/Datacenter/Apply/Introduction_to_User_Namespaces_in_Docker_Engine
• https://segmentfault.com/a/1190000006913195
• https://www.cnblogs.com/sammyliu/p/5878973.html

上前面讲到 Docker 容器使用 linux namespace 来隔离其运行环境，使得容器中的进程看起来就像爱一个独立环境中运行一样。但是，光有运行环境隔离还不够，因为这些进程还是可以不受限制地使用系统资源，比如网络、磁盘、CPU以及内存 等。关于其目的，一方面，是为了防止它占用了太多的资源而影响到其它进程；另一方面，在系统资源耗尽的时候，linux 内核会触发 OOM，这会让一些被杀掉的进程成了无辜的替死鬼。因此，为了让容器中的进程更加可控，Docker 使用 Linux cgroups 来限制容器中的进程允许使用的系统资源。 

4. 基础知识：Linux control groups 

4.1 概念

  Linux Cgroup 可​​​让​​​您​​​为​​​系​​​统​​​中​​​所​​​运​​​行​​​任​​​务​​​（进​​​程​​​）的​​​用​​​户​​​定​​​义​​​组​​​群​​​分​​​配​​​资​​​源​​​ — 比​​​如​​​ CPU 时​​​间​​​、​​​系​​​统​​​内​​​存​​​、​​​网​​​络​​​带​​​宽​​​或​​​者​​​这​​​些​​​资​​​源​​​的​​​组​​​合​​​。​​​您​​​可​​​以​​​监​​​控​​​您​​​配​​​置​​​的​​​ cgroup，拒​​​绝​​​ cgroup 访​​​问​​​某​​​些​​​资​​​源​​​，甚​​​至​​​在​​​运​​​行​​​的​​​系​​​统​​​中​​​动​​​态​​​配​​​置​​​您​​​的​​​ cgroup。所以，可以将 controll groups 理解为 controller （system resource） （for） （process）groups，也就是是说它以一组进程为目标进行系统资源分配和控制。

  它主要提供了如下功能： 

• Resource limitation: 限制资源使用，比如内存使用上限以及文件系统的缓存限制。
• Prioritization: 优先级控制，比如：CPU利用和磁盘IO吞吐。
• Accounting: 一些审计或一些统计，主要目的是为了计费。
• Control: 挂起进程，恢复执行进程。

使​​​用​​​ cgroup，系​​​统​​​管​​​理​​​员​​​可​​​更​​​具​​​体​​​地​​​控​​​制​​​对​​​系​​​统​​​资​​​源​​​的​​​分​​​配​​​、​​​优​​​先​​​顺​​​序​​​、​​​拒​​​绝​​​、​​​管​​​理​​​和​​​监​​​控​​​。​​​可​​​更​​​好​​​地​​​根​​​据​​​任​​​务​​​和​​​用​​​户​​​分​​​配​​​硬​​​件​​​资​​​源​​​，提​​​高​​​总​​​体​​​效​​​率​​​。

在实践中，系统管理员一般会利用CGroup做下面这些事（有点像为某个虚拟机分配资源似的）：

• 隔离一个进程集合（比如：nginx的所有进程），并限制他们所消费的资源，比如绑定CPU的核。
• 为这组进程分配其足够使用的内存
• 为这组进程分配相应的网络带宽和磁盘存储限制
• 限制访问某些设备（通过设置设备的白名单）

查看 linux 内核中是否启用了 cgroup：

我们看到 /sys/fs/cgroup 目录中有若干个子目录，我们可以认为这些都是受 cgroups 控制的资源以及这些资源的信息。

• blkio — 这​​​个​​​子​​​系​​​统​​​为​​​块​​​设​​​备​​​设​​​定​​​输​​​入​​​/输​​​出​​​限​​​制​​​，比​​​如​​​物​​​理​​​设​​​备​​​（磁​​​盘​​​，固​​​态​​​硬​​​盘​​​，USB 等​​​等​​​）。
• cpu — 这​​​个​​​子​​​系​​​统​​​使​​​用​​​调​​​度​​​程​​​序​​​提​​​供​​​对​​​ CPU 的​​​ cgroup 任​​​务​​​访​​​问​​​。​​​
• cpuacct — 这​​​个​​​子​​​系​​​统​​​自​​​动​​​生​​​成​​​ cgroup 中​​​任​​​务​​​所​​​使​​​用​​​的​​​ CPU 报​​​告​​​。​​​
• cpuset — 这​​​个​​​子​​​系​​​统​​​为​​​ cgroup 中​​​的​​​任​​​务​​​分​​​配​​​独​​​立​​​ CPU（在​​​多​​​核​​​系​​​统​​​）和​​​内​​​存​​​节​​​点​​​。​​​
• devices — 这​​​个​​​子​​​系​​​统​​​可​​​允​​​许​​​或​​​者​​​拒​​​绝​​​ cgroup 中​​​的​​​任​​​务​​​访​​​问​​​设​​​备​​​。​​​
• freezer — 这​​​个​​​子​​​系​​​统​​​挂​​​起​​​或​​​者​​​恢​​​复​​​ cgroup 中​​​的​​​任​​​务​​​。​​​
• memory — 这​​​个​​​子​​​系​​​统​​​设​​​定​​​ cgroup 中​​​任​​​务​​​使​​​用​​​的​​​内​​​存​​​限​​​制​​​，并​​​自​​​动​​​生​​​成​​​​​内​​​存​​​资​​​源使用​​​报​​​告​​​。​​​
• net_cls — 这​​​个​​​子​​​系​​​统​​​使​​​用​​​等​​​级​​​识​​​别​​​符​​​（classid）标​​​记​​​网​​​络​​​数​​​据​​​包​​​，可​​​允​​​许​​​ Linux 流​​​量​​​控​​​制​​​程​​​序​​​（tc）识​​​别​​​从​​​具​​​体​​​ cgroup 中​​​生​​​成​​​的​​​数​​​据​​​包​​​。​​​
• net_prio — 这个子系统用来设计网络流量的优先级
• hugetlb — 这个子系统主要针对于HugeTLB系统进行限制，这是一个大页文件系统。

4.2 实验

4.2.1 通过 cgroups 限制进程的 CPU

写一段最简单的 C 程序：

int main(void)
{
    int i = 0;
    for(;;) i++;
    return 0;
}

编译，运行，发现它占用的 CPU 几乎到了 100%：

top - 22:43:02 up  1:14,  3 users,  load average: 0.24, 0.06, 0.06  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 2304 root      20   0    4188    356    276 R 99.6  0.0   0:11.77 hello

接下来我们做如下操作：

root@onfocus:/home/lee/c# mkdir /sys/fs/cgroup/cpu/hello
root@onfocus:/home/lee/c# cd /sys/fs/cgroup/cpu/hello
root@onfocus:/sys/fs/cgroup/cpu/hello# ls
cgroup.clone_children  cgroup.procs       cpu.cfs_quota_us  cpu.stat           tasks
cgroup.event_control   cpu.cfs_period_us  cpu.shares        notify_on_release
root@onfocus:/sys/fs/cgroup/cpu/hello# cat cpu.cfs_quota_us
-1
root@onfocus:/sys/fs/cgroup/cpu/hello# echo 20000 > cpu.cfs_quota_us
root@onfocus:/sys/fs/cgroup/cpu/hello# cat cpu.cfs_quota_us
20000
root@onfocus:/sys/fs/cgroup/cpu/hello# echo 2428 > tasks

然后再来看看这个进程的 CPU 占用情况：

 PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 2428 root      20   0    4188    356    276 R 19.9  0.0   0:46.03 hello

它占用的 CPU 几乎就是 20%，也就是我们预设的阈值。这说明我们通过上面的步骤，成功地将这个进程运行所占用的 CPU 资源限制在某个阈值之内了。

如果此时再启动另一个 hello 进程并将其 id 加入 tasks 文件，则两个进程会共享设定的 CPU 限制：

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 2428 root      20   0    4188    356    276 R 10.0  0.0 285:39.54 hello
12526 root      20   0    4188    356    276 R 10.0  0.0   0:25.09 hello

4.2.2 通过 cgroups 限制进程的 Memory

同样地，我们针对它占用的内存做如下操作：

root@onfocus:/sys/fs/cgroup/memory# mkdir hello
root@onfocus:/sys/fs/cgroup/memory# cd hello/
root@onfocus:/sys/fs/cgroup/memory/hello# cat memory.limit_in_bytes
18446744073709551615
root@onfocus:/sys/fs/cgroup/memory/hello# echo 64k > memory.limit_in_bytes
root@onfocus:/sys/fs/cgroup/memory/hello# echo 2428 > tasks
root@onfocus:/sys/fs/cgroup/memory/hello#

上面的步骤会把进程 2428 所占用的内存阈值设置为 64K。超过的话，它会被杀掉。

4.2.3 限制进程的 I/O

运行命令：

sudo dd if=/dev/sda1 of=/dev/null

通过 iotop 命令看 IO （此时磁盘在快速转动），此时其写速度为 242M/s：

 TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2555 be/4 root      242.60 M/s    0.00 B/s  0.00 % 61.66 % dd if=/dev/sda1 of=/dev/null

接着做下面的操作：

root@onfocus:/home/lee# mkdir /sys/fs/cgroup/blkio/io
root@onfocus:/home/lee# cd /sys/fs/cgroup/blkio/io
root@onfocus:/sys/fs/cgroup/blkio/io# ls -l /dev/sda1
brw-rw---- 1 root disk 8, 1 Sep 18 21:46 /dev/sda1
root@onfocus:/sys/fs/cgroup/blkio/io# echo '8:0 1048576'  > /sys/fs/cgroup/blkio/io/blkio.throttle.read_bps_device
root@onfocus:/sys/fs/cgroup/blkio/io# echo 2725 > /sys/fs/cgroup/blkio/io/tasks

结果，这个进程的IO 速度就被限制在 1Mb/s 之内了：

 TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2555 be/4 root      990.44 K/s    0.00 B/s  0.00 % 96.29 % dd if=/dev/sda1 of=/dev/null

4.3 术语

cgroups 的术语包括：

• 任务（Tasks）：就是系统的一个进程。
• 控制组（Control Group）：一组按照某种标准划分的进程，比如官方文档中的Professor和Student，或是WWW和System之类的，其表示了某进程组。Cgroups中的资源控制都是以控制组为单位实现。一个进程可以加入到某个控制组。而资源的限制是定义在这个组上，就像上面示例中我用的 hello 一样。简单点说，cgroup的呈现就是一个目录带一系列的可配置文件。
• 层级（Hierarchy）：控制组可以组织成hierarchical的形式，既一颗控制组的树（目录结构）。控制组树上的子节点继承父结点的属性。简单点说，hierarchy就是在一个或多个子系统上的cgroups目录树。
• 子系统（Subsystem）：一个子系统就是一个资源控制器，比如CPU子系统就是控制CPU时间分配的一个控制器。子系统必须附加到一个层级上才能起作用，一个子系统附加到某个层级以后，这个层级上的所有控制族群都受到这个子系统的控制。Cgroup的子系统可以有很多，也在不断增加中。

4.4 Docker run 命令中 cgroups 相关命令

block IO:
      --blkio-weight value          Block IO (relative weight), between 10 and 1000
      --blkio-weight-device value   Block IO weight (relative device weight) (default [])
      --cgroup-parent string        Optional parent cgroup for the container
CPU:
      --cpu-percent int             CPU percent (Windows only)
      --cpu-period int              Limit CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int               Limit CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int              CPU shares (relative weight)
      --cpuset-cpus string          CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string          MEMs in which to allow execution (0-3, 0,1)
Device:    
      --device value                Add a host device to the container (default [])
      --device-read-bps value       Limit read rate (bytes per second) from a device (default [])
      --device-read-iops value      Limit read rate (IO per second) from a device (default [])
      --device-write-bps value      Limit write rate (bytes per second) to a device (default [])
      --device-write-iops value     Limit write rate (IO per second) to a device (default [])
Memory:      
      --kernel-memory string        Kernel memory limit
  -m, --memory string               Memory limit
      --memory-reservation string   Memory soft limit
      --memory-swap string          Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --memory-swappiness int       Tune container memory swappiness (0 to 100) (default -1)

扩展阅读：

• Docker基础技术：Linux CGroup
• http://blog.csdn.net/qinyushuang/article/details/46611709
• http://www.funtoo.org/Traffic_Control
• https://docs.docker.com/engine/admin/resource_constraints/

5. AUFS基础知识

5.1 Linux 的 rootfs 和 bootfs

  一个典型的 Linux 系统要能运行的话，它至少需要两个文件系统：

• boot file system （bootfs）：包含 boot loader 和 kernel。用户不会修改这个文件系统。实际上，在启动（boot）过程完成后，整个内核都会被加载进内存，此时 bootfs 会被卸载掉从而释放出所占用的内存。同时也可以看出，对于同样内核版本的不同的 Linux 发行版的 bootfs 都是一致的。
• root file system （rootfs）：包含典型的目录结构，包括 /dev, /proc, /bin, /etc, /lib, /usr, and /tmp 等再加上要运行用户应用所需要的所有配置文件，二进制文件和库文件。这个文件系统在不同的Linux 发行版中是不同的。而且用户可以对这个文件进行修改。

Linux 系统在启动时，roofs 首先会被挂载为只读模式，然后在启动完成后被修改为读写模式，随后它们就可以被修改了。

5.2 AUFS

 AUFS 是一种 Union File System（联合文件系统），又叫 Another UnionFS，后来叫Alternative UnionFS，再后来叫成高大上的 Advance UnionFS。所谓 UnionFS，就是把不同物理位置的目录合并mount到同一个目录中。UnionFS的一个最主要的应用是，把一张CD/DVD和一个硬盘目录给联合 mount在一起，然后，你就可以对这个只读的CD/DVD上的文件进行修改（当然，修改的文件存于硬盘上的目录里）。

 举个例子，假设在 Ubuntu 系统上现有如下目录结构：

tree
.
├── fruits
│   ├── apple
│   └── tomato
└── vegetables
    ├── carrots
    └── tomato

# 创建一个mount目录
$ mkdir mnt
 
# 把水果目录和蔬菜目录union mount到 ./mnt目录中
$ sudo mount -t aufs -o dirs=./fruits:./vegetables none ./mnt
 
#  查看./mnt目录
$ tree ./mnt
./mnt
├── apple
├── carrots
└── tomato

我们可以看到在./mnt目录下有三个文件，苹果apple、胡萝卜carrots和蕃茄tomato。水果和蔬菜的目录被union到了./mnt目录下了。

我们来修改一下其中的文件内容：

$ echo mnt > ./mnt/apple
$ cat ./mnt/apple
mnt
$ cat ./fruits/apple
mnt

上面的示例，我们可以看到./mnt/apple的内容改了，./fruits/apple的内容也改了。

$ echo mnt_carrots > ./mnt/carrots
$ cat ./vegetables/carrots
 
$ cat ./fruits/carrots
mnt_carrots

关于 AUFS 的几个特点：

• AUFS 是一种联合文件系统，它把若干目录按照顺序和权限 mount 为一个目录并呈现出来
• 默认情况下，只有第一层（第一个目录）是可写的，其余层是只读的。
• 增加文件：默认情况下，新增的文件都会被放在最上面的可写层中。
• 删除文件：因为底下各层都是只读的，当需要删除这些层中的文件时，AUFS 使用 whiteout 机制，它的实现是通过在上层的可写的目录下建立对应的whiteout隐藏文件来实现的。
• 修改文件：AUFS 利用其 CoW （copy-on-write）特性来修改只读层中的文件。AUFS 工作在文件层面，因此，只要有对只读层中的文件做修改，不管修改数据的量的多少，在第一次修改时，文件都会被拷贝到可写层然后再被修改。
• 节省空间：AUFS 的 CoW 特性能够允许在多个容器之间共享分层，从而减少物理空间占用。
• 查找文件：AUFS 的查找性能在层数非常多时会出现下降，层数越多，查找性能越低，因此，在制作 Docker 镜像时要注意层数不要太多。
• 性能：AUFS 的 CoW 特性在写入大型文件时第一次会出现延迟。

 详情请转至Docker基础技术：AUFS

6. OverlayFS介绍

　　OverlayFS是一种堆叠文件系统，它依赖并建立在其它的文件系统之上（例如ext4fs和xfs等等），并不直接参与磁盘空间结构的划分，仅仅将原来底层文件系统中不同的目录进行“合并”，然后向用户呈现，这也就是联合挂载技术，对比于AUFS，OverlayFS速度更快，实现更简单。 而Linux 内核为Docker提供的OverlayFS驱动有两种：overlay和overlay2。而overlay2是相对于overlay的一种改进，在inode利用率方面比overlay更有效。但是overlay有环境需求：docker版本17.06.02+，宿主机文件系统需要是ext4或xfs格式。

联合挂载

　　 overlayfs通过三个目录：lower目录、upper目录、以及work目录实现，其中lower目录可以是多个，work目录为工作基础目录，挂载后内容会被清空，且在使用过程中其内容用户不可见，最后联合挂载完成给用户呈现的统一视图称为为merged目录。以下使用mount将演示其如何工作的。

 使用mount命令挂载overlayfs语法如下：

mount -t overlay overlay -o lowerdir=lower1:lower2:lower3,upperdir=upper,workdir=work merged_dir

创建三个目录A、B、C,以及worker目录：

然后使用mount联合挂载到/tmp/test 下：

然后我们再去查看/tmp/test目录，你会发现目录A、B、C被合并到了一起,并且相同文件名的文件会进行“覆盖”，这里覆盖并不是真正的覆盖，而是当合并时候目录中两个文件名称都相同时，merged层目录会显示离它最近层的文件：

同时我们还可以通过mount命令查看其挂载的选项：

以上这样的方式也就是联合挂载技术。

8. Docker中的overlay驱动

　　介绍了overlay驱动原理以后再来看Docker中的overlay存储驱动，以下是来自docker官网关于overlay的工作原理图：

在上述图中可以看到三个层结构，即：lowerdir、uperdir、merged，其中lowerdir是只读的image layer，其实就是rootfs，对比我们上述演示的目录A和B，我们知道image layer可以分很多层，所以对应的lowerdir是可以有多个目录。而upperdir则是在lowerdir之上的一层，这层是读写层，在启动一个容器时候会进行创建，所有的对容器数据更改都发生在这里层，对比示例中的C。最后merged目录是容器的挂载点，也就是给用户暴露的统一视角，对比示例中的/tmp/test。而这些目录层都保存在了/var/lib/docker/overlay2/或者/var/lib/docker/overlay/(如果使用overlay)。

演示

启动一个容器

查看其overlay挂载点,可以发现其挂载的merged目录、lowerdir、upperdir以及workdir：

overlay2的lowerdir可以有多个，并且是软连接方式挂载，后续我们会进行说明。 

如何工作

 

当容器中发生数据修改时候overlayfs存储驱动又是如何进行工作的？以下将阐述其读写过程：

 

读：

• 如果文件在容器层（upperdir），直接读取文件；
• 如果文件不在容器层（upperdir），则从镜像层（lowerdir）读取；

修改：

• 首次写入： 如果在upperdir中不存在，overlay和overlay2执行copy_up操作，把文件从lowdir拷贝到upperdir，由于overlayfs是文件级别的（即使文件只有很少的一点修改，也会产生的copy_up的行为），后续对同一文件的在此写入操作将对已经复制到容器的文件的副本进行操作。这也就是常常说的写时复制（copy-on-write）
• 删除文件和目录： 当文件在容器被删除时，在容器层（upperdir）创建whiteout文件，镜像层(lowerdir)的文件是不会被删除的，因为他们是只读的，但without文件会阻止他们显示，当目录在容器内被删除时，在容器层（upperdir）一个不透明的目录，这个和上面whiteout原理一样，阻止用户继续访问，即便镜像层仍然存在。 

 

注意事项

1. copy_up操作只发生在文件首次写入，以后都是只修改副本,
2. overlayfs只适用两层目录，,相比于比AUFS，查找搜索都更快。
3. 容器层的文件删除只是一个“障眼法”，是靠whiteout文件将其遮挡,image层并没有删除，这也就是为什么使用docker commit 提交保存的镜像会越来越大，无论在容器层怎么删除数据，image层都不会改变。 

overlay2镜像存储结构

从仓库pull一个ubuntu镜像，结果显示总共拉取了4层镜像如下：

此时4层被存储在了/var/lib/docker/overlay2/目录下：

这里面多了一个l目录包含了所有层的软连接，短链接使用短名称，避免mount时候参数达到页面大小限制（演示中mount命令查看时候的短目录）：

处于底层的镜像目录包含了一个diff和一个link文件，diff目录存放了当前层的镜像内容，而link文件则是与之对应的短名称：

在这之上的镜像还多了work目录和lower文件，lower文件用于记录父层的短名称，work目录用于联合挂载指定的工作目录。而这些目录和镜像的关系是怎么组织在的一起呢？答案是通过元数据关联。元数据分为image元数据和layer元数据。 

image元数据

　　镜像元数据存储在了/var/lib/docker/image//imagedb/content/sha256/目录下，名称是以镜像ID命名的文件，镜像ID可通过docker images查看，这些文件以json的形式保存了该镜像的rootfs信息、镜像创建时间、构建历史信息、所用容器、包括启动的Entrypoint和CMD等等。例如ubuntu镜像的id为47b19964fb50:

查看其对应的元数据(使用vim :%!python -m json.tool格式化成json) 截取了其rootfs的构成：

上面的 diff_id 对应的的是一个镜像层，其排列也是有顺序的，从上到下依次表示镜像层的最低层到最顶层：

diff_id如何关联进行层？具体说来，docker 利用 rootfs 中的每个diff_id 和历史信息计算出与之对应的内容寻址的索引(chainID) ，而chaiID则关联了layer层，进而关联到每一个镜像层的镜像文件。

layer元数据

 

　　layer 对应镜像层的概念，在 docker 1.10 版本以前，镜像通过一个 graph 结构管理，每一个镜像层都拥有元数据，记录了该层的构建信息以及父镜像层 ID，而最上面的镜像层会多记录一些信息作为整个镜像的元数据。graph 则根据镜像 ID(即最上层的镜像层 ID) 和每个镜像层记录的父镜像层 ID 维护了一个树状的镜像层结构。

　　在 docker 1.10 版本后，镜像元数据管理巨大的改变之一就是简化了镜像层的元数据，镜像层只包含一个具体的镜像层文件包。用户在 docker 宿主机上下载了某个镜像层之后，docker 会在宿主机上基于镜像层文件包和 image 元数据构建本地的 layer 元数据，包括 diff、parent、size 等。而当 docker 将在宿主机上产生的新的镜像层上传到 registry 时，与新镜像层相关的宿主机上的元数据也不会与镜像层一块打包上传。

　　Docker 中定义了 Layer 和 RWLayer 两种接口，分别用来定义只读层和可读写层的一些操作，又定义了 roLayer 和 mountedLayer，分别实现了上述两种接口。其中，roLayer 用于描述不可改变的镜像层，mountedLayer 用于描述可读写的容器层。具体来说，roLayer 存储的内容主要有索引该镜像层的 chainID、该镜像层的校验码 diffID、父镜像层 parent、storage_driver 存储当前镜像层文件的 cacheID、该镜像层的 size 等内容。这些元数据被保存在 /var/lib/docker/image//layerdb/sha256// 文件夹下。如下： 

每个chainID目录下会存在三个文件cache-id、diff、zize：

cache-id文件：

docker随机生成的uuid，内容是保存镜像层的目录索引，也就是/var/lib/docker/overlay2/中的目录，这就是为什么通过chainID能找到对应的layer目录。以chainID为d801a12f6af7beff367268f99607376584d8b2da656dcd8656973b7ad9779ab4 对应的目录为 130ea10d6f0ebfafc8ca260992c8d0bef63a1b5ca3a7d51a5cd1b1031d23efd5,也就保存在/var/lib/docker/overlay2/130ea10d6f0ebfafc8ca260992c8d0bef63a1b5ca3a7d51a5cd1b1031d23efd5

 

 

diff文件：

保存了镜像元数据中的diff_id（与元数据中的diff_ids中的uuid对应）

size文件：

保存了镜像层的大小

 

在 layer 的所有属性中，diffID 采用 SHA256 算法，基于镜像层文件包的内容计算得到。而 chainID 是基于内容存储的索引，它是根据当前层与所有祖先镜像层 diffID 计算出来的，具体算如下：

• 如果该镜像层是最底层(没有父镜像层)，该层的 diffID 便是 chainID。
• 该镜像层的 chainID 计算公式为 chainID(n)=SHA256(chain(n-1) diffID(n))，也就是根据父镜像层的 chainID 加上一个空格和当前层的 diffID，再计算 SHA256 校验码。 

 

mountedLayer 信息存储的可读init层以及容器挂载点信息包括：容器 init 层ID（init-id）、联合挂载使用的ID（mount-id）以及容器层的父层镜像的 chainID(parent)。相关文件位于/var/lib/docker/image//layerdb/mounts// 目录下。

如下启动一个id为3c96960b3127的容器: 

  查看其对应的mountedLayer三个文件：

可以看到initID是在mountID后加了一个-init，同时initID就是存储在/var/lib/docker/overlay2/的目录名称：

查看mountID还可以直接通过mount命令查看对应挂载的mountID，对应着/var/lib/docker/overlay2/目录，这也是overlayfs呈现的merged目录:

在容器中创建了一文件：

此时到宿主的merged目录就能看到对应的文件：

 

关于init层

　　init层是以一个uuid+-init结尾表示，夹在只读层和读写层之间，作用是专门存放/etc/hosts、/etc/resolv.conf等信息，需要这一层的原因是当容器启动时候，这些本该属于image层的文件或目录，比如hostname，用户需要修改，但是image层又不允许修改，所以启动时候通过单独挂载一层init层，通过修改init层中的文件达到修改这些文件目的。而这些修改往往只读当前容器生效，而在docker commit提交为镜像时候，并不会将init层提交。该层文件存放的目录为/var/lib/docker/overlay2//diff 

通过以上的内容介绍，一个容器完整的层应由三个部分组成，如下图：

1. 镜像层：也称为rootfs，提供容器启动的文件系统 
2. init层： 用于修改容器中一些文件如/etc/hostname、/etc/resolv.conf等
3. 容器层：使用联合挂载统一给用户提供的可读写目录。 

以overlayfs作为存储驱动的的镜像存储原理其中每层的镜像数据保存在/var/lib/docker/overlay2//diff目录下，init层数据保存了在 /var/lib/docker/overlay2//diff目录下，最后统一视图（容器层）数据在 /var/lib/docker/overlay2//diff目录下，docker通过image元数据和layer元数据利用内容寻址（chainID）将这些目录组织起来构成容器所运行的文件系统。

 

参考：

《use overlayfs driver 》

《Docker 镜像之存储管理》

https://www.cnblogs.com/wdliu/p/10483252.html