Docker 底层原理浅析

鹅厂程序员 作者： vitovzhong，腾讯 TEG 应用开发工程师 2020-11-16 投诉

阅读数：25734

容器的实质是进程，与宿主机上的其他进程是共用一个内核，但与直接在宿主机执行的进程不同，容器进程运行在属于自己的独立的命名空间。命名空间隔离了进程间的资源，使得 a,b 进程可以看到 S 资源，而 c 进程看不到。

1. 演进

对于统一开发、测试、生产环境的渴望，要远远早于 docker 的出现。我们先来了解一下在 docker 之前出现过哪些解决方案。

1.1 vagrant

Vagarant 是笔者最早接触到的一个解决环境配置不统一的技术方案。它使用 Ruby 语言编写，由 HashCorp 公司在 2010 年 1 月发布。Vagrant 的底层是虚拟机，最开始选用的是 virtualbox。一个个已经配置好的虚拟机被称作 box。用户可自由在虚拟机内部的安装依赖库和软件服务，并将 box 发布。通过简单的命令，就能够拉取 box，将环境搭建起来。

如果需要运行多个服务，也可以通过编写 vagrantfile，将相互依赖的服务一起运行，颇有如今 docker-compose 的味道。

1.2 LXC (LinuX Container)

在 2008 年，Linux 2.6.24 将 cgroups 特性合入了主干。Linux Container 是 Canonical 公司基于 namespace 和 cgroups 等技术，瞄准容器世界而开发的一个项目，目标就是要创造出运行在 Linux 系统中，并且隔离性良好的容器环境。当然它最早也就见于 Ubuntu 操作系统上。

2013 年，在 PyCon 大会上 Docker 正式面世。当时的 Docker 是在 Ubuntu 12.04 上开发实现的，只是基于 LXC 之上的一个工具，屏蔽掉了 LXC 的使用细节（类似于 vagrant 屏蔽了底层虚拟机），让用户可以一句 docker run 命令行便创建出自己的容器环境。

2. 技术发展

容器技术是操作系统层面的虚拟化技术，可以概括为使用 Linux 内核的 cgroup，namespace 等技术，对进程进行的封装隔离。早在 Docker 之前，Linux 就已经提供了今天的 Docker 所使用的那些基础技术。Docker 一夜之间火爆全球，但技术上的积累并不是瞬间完成的。我们摘取其中几个关键技术节点进行介绍。

2.1 Chroot

软件主要分为系统软件和应用软件，而容器中运行的程序并非系统软件。容器中的进程实质上是运行在宿主机上，与宿主机上的其他进程共用一个内核。而每个应用软件运行都需要有必要的环境，包括一些 lib 库依赖之类的。所以，为了避免不同应用程序的 lib 库依赖冲突，很自然地我们会想是否可以把他们进行隔离，让他们看到的库是不一样的。基于这个朴素的想法，1979 年， chroot 系统调用首次问世。来举个例子感受一下。在 devcloud 上申请的云主机，现在我的 home 目录下准备好了一个 alpine 系统的 rootfs，如下：

在该目录下执行：

然后将/etc/os-release 打印出来，就看到是”Alpine Linux”，说明新运行的 bash 跟 devcloud 主机上的 rootfs 隔离了。

2.2 Namespace

简单来说 namespace 是由 Linux 内核提供的，用于进程间资源隔离的一种技术，使得 a,b 进程可以看到 S 资源；而 c 进程看不到。它是在 2002 年 Linux 2.4.19 开始加入内核的特性，到 2013 年 Linux 3.8 中 user namespace 的引入，对于我们现在所熟知的容器所需的全部 namespace 就都实现了。

Linux 提供了多种 namespace，用于对多种不同资源进行隔离。容器的实质是进程，但与直接在宿主机执行的进程不同，容器进程运行在属于自己的独立的命名空间。因此容器可以拥有自己的 root 文件系统、自己的网络配置、自己的进程空间，甚至自己的用户 ID 空间。

还是来看一个简单的例子，让我们有个感性认识，namespace 到底是啥，在哪里能直观的看到。在 devcloud 云主机上，执行：ls-l /proc/self/ns 看到的就是当前系统所支持的 namespace。

接着我们使用 unshare 命令，运行一个 bash，让它不使用当前的 pid namespace：

然后运行: ps -a 看看当前 pid namespace 下的进程都有哪些：

在新起的 bash 上执行：ls -l /proc/self/ns，发现当前 bash 的 pid namespace 与之前是不相同的。

既然 docker 就是基于内核的 namespace 特性来实现的，那么我们可以简单来认证一下，执行指令：

运行一个简单的 alpine 容器，让它与主机共用同一个 pid namespace。然后在容器内部执行指令 ps -a 会发现进程数量与 devcloud 机器上的一样；执行指令 ls -l /proc/self/ns/ 同样会看到容器内部的 pid namespace 与 devcloud 机器上的也是一样。

2.3 cgroups

cgroups 是 namespace 的一种，是为了实现虚拟化而采取的资源管理机制，决定哪些分配给容器的资源可被我们管理，分配容器使用资源的多少。容器内的进程是运行在一个隔离的环境里，使用起来，就好像是在一个独立于宿主的系统下操作一样。这种特性使得容器封装的应用比直接在宿主运行更加安全。例如可以设定一个 memory 使用上限，一旦进程组（容器）使用的内存达到限额再申请内存，就会出发 OOM（out of memory），这样就不会因为某个进程消耗的内存过大而影响到其他进程的运行。

还是来看个例子感受一下。在 devcloud 机器上运行一个 apline 容器，限制只能使用前 2 个 CPU 且只能使用 1.5 个核：

然后再开启一个新的终端，先看看系统上有哪些资源是我们可以控制的：

最左边一侧就是可以设置的资源了。接着我们需要找到这些控制资源分配的信息都放在哪个目录下：

然后我们找到刚刚运行的 alpine 镜像的 cgroups 配置：

这样，把二者拼接起来，就可以看到这个容器的资源配置了。我们先来验证 cpu 的用量是否是 1.5 个核：

输出 100000，可以认为是单位，然后再看配额：

输出 150000，与单位相除正好是设置的 1.5 个核，接着验证是否使用的是前两个核心：

输出 0-1。

目前来看，容器的资源配置都是按照我们设定的来分配的，但实际真能在 CPU0-CPU1 上限制使用 1.5 个核吗？我们先看一下当前 CPU 的用量：

因为没有在 alpine 中运行程序，所以 CPU 用量为 0，我们现在回到最开始执行 docker 指令的 alpine 终端，执行一个死循环：

再来观察当前的 CPU 用量：

接近 1，但为啥不是 1.5？因为刚刚运行的死循环只能跑在一个核上，所以我们再打开一个终端，进入到 alpine 镜像中，同样执行死循环的指令，看到 CPU 用量稳定在了 1.5，说明资源的使用量确实是限制住了的。

现在我们对 docker 容器实现了进程间资源隔离的黑科技有了一定认识。如果单单就隔离性来说，vagrant 也已经做到了。那么为什么是 docker 火爆全球？是因为它允许用户将容器环境打包成为一个镜像进行分发，而且镜像是分层增量构建的，这可以大大降低用户使用的门槛。

3. 存储

Image 是 Docker 部署的基本单位，它包含了程序文件，以及这个程序依赖的资源的环境。Docker Image 是以一个 mount 点挂载到容器内部的。容器可以近似理解为镜像的运行时实例，默认情况下也算是在镜像层的基础上增加了一个可写层。所以，一般情况下如果你在容器内做出的修改，均包含在这个可写层中。

3.1 联合文件系统（UFS）

Union File System 从字面意思上来理解就是“联合文件系统”。它将多个物理位置不同的文件目录联合起来，挂载到某一个目录下，形成一个抽象的文件系统。

如上图，从右侧以 UFS 的视角来看，lowerdir 和 upperdir 是两个不同的目录，UFS 将二者合并起来，得到 merged 层展示给调用方。从左侧的 docker 角度来理解，lowerdir 就是镜像，upperdir 就相当于是容器默认的可写层。在运行的容器中修改了文件，可以使用 docker commit 指令保存成为一个新镜像。

3.2 Docker 镜像的存储管理

有了 UFS 的分层概念，我们就很好理解这样的一个简单 Dockerfile：