深入理解Docker容器引擎runC执行框架

深入理解Docker容器引擎runC执行框架

1 简介

根据官方的定义:runC是一个根据OCI标准创建并运行容器的CLI tool。

Docker就是基于runC创建的,简单地说,runC是Docker中最为核心的部分,容器的创建,运行,销毁等等操作最终都将通过调用runC完成。下面我们将演示如何使用runC,以最精简的方式创建并运行一个容器。

1.1 利用runC运行busybox容器

下载并编译runC

创建容器的根文件系统

利用runC的spec命令创建默认的配置文件config.json,其中包含了创建一个容器所需的所有配置信息

利用runC运行busybox容器

可以看到,容器成功运行,此时我们打开另一个终端观察容器的运行状态

事实上,runc run是一个复合命令,它包含了容器的创建runc create,启动runc start以及在退出之后对容器进行的销毁runc delete,从演示的角度看它是最为直观的。但是如果想要深入理解runC内部的实现机制,将容器的创建,启动,销毁三个步骤分开,显然会让整个过程的分析更为简单和易于接受

下面我们就将结合源码,对整个容器技术最为核心的部分进行探究—— 容器是如何创建并启动的

2 源码分析

首先,我们来对runC的整体代码结构做一个宏观的把控:

可以看到在runC的顶层目录中,有着一系列形如create.go, start.go, run.go…的go文件,它们和runC的子命令,例如runc create...runc start...runc run是一致的。 另外,在顶层目录中还有一个名为libcontainer的子目录。对于Docker项目的发展历史有所了解的同学应该都知道,libcontainer曾经是Docker中最为核心的包,容器的创建,删除等一系列工作,最终都是交由它来完成的。

这样一来,runC的代码结构就非常清晰了。我们知道,runC是符合OCI标准的容器运行时。不难猜出,它本质上是对libcontainer的一层薄薄的封装。它会先读取符合OCI标准的容器配置,再将其转换成与libcontainer兼容的格式,最后将转换后的配置交由libcontainer来完成具体的工作。

2.1 容器创建

create.go的工作主要分为如下两部分:

  1. 将容器配置从config.json文件加载到内存中,保存在一个类型为*specs.Spec (Spec即为OCI标准的容器配置在内存中的表现形式)的结构体中
  2. 调用startContainer()完成容器的创建工作,值得注意的是runc run , runc create以及runc restore最终都将调用该函数,只是第三个参数不同而已,对于runc create,该参数为CT_ACT_CREATE,表示首次创建容器。接下来程序的执行路径将因该参数的不同而有所不同。

startContainer的工作由如下三部分组成:

  1. 从参数中获取容器的id,例如对于命令runc create abc ,则获取的id即为abc
  2. 调用createContainer ,根据spec中Container相关的内容,调用libcontainer 创建容器对象,且容器的状态设置为Stopped。此时的容器仅仅只是一个内存中的数据结构,并没有与之对应的进程
  3. 创建runner对象并调用相应的run方法,该对象会将spec中的Process转换成libcontainer兼容的模式,并对容器的IO进行配置

run方法的工作同样由三部分组成:

  1. 将OCI标准的进程配置specs.Process转换为符合libcontainer格式的进程配置libcontainer.Process
  2. 调用setupIO对进程的IO进行配置,因为IO涉及的内容较为复杂,会在另外的文章中详细叙述
  3. 根据startContainer配置参数的不同,调用不同的方法,分别进行容器的创建,运行或者恢复,本文我们只讨论CT_ACT_CREATE这种情况

到此为止,我们已经将OCI格式的配置,不管是Container还是Process都转换成了libcontainer要求的格式。接着我们将深入libcontainer,真正完成容器实例的创建工作。

Start方法仅仅只是对start的一个封装并且会在容器状态为Stopped时(即新建容器时),创建一个路径为/run/runc/$ID/exec.fifo的管道文件,它的作用我们会在后文中详细描述。

值得注意的是start方法的第二个参数对容器的状态进行了判断。事实上,命令runc createrunc exec的代码的执行路径是类似的,它俩共享了大部分的代码。因此,这里我们需要对容器的状态进行判断,如果容器的状态为Stopped说明接下来应当进行容器的创建,否则应当在已有容器中exec一个新进程。

start方法的工作也可以分为如下三部分:

  1. 调用newParentProcess创建parentProcess 对象
  2. 调用parentProcessstart方法,它真正完成容器进程的创建以及初始化工作
  3. 如果isInit参数为true,则说明执行的命令为runc create,更新容器状态为Created,并且如果定义了hooks(回调函数),则还需要执行PostStart类型的hook函数。否则,如果执行的命令为runc exec,则更新容器状态为Running

newParentProcess首先创建了一个名为init的管道,它一方面会在创建容器时给容器的初始化进程传输容器的配置信息,另一方面它也会用于runC和容器进程之间的同步。

之后,它会调用commandTemplate创建容器初始化进程的运行模板,如下所示:

从上面的代码中我们可以看出,环境变量也是runC进程和容器初始化进程之间进行交互的一种重要方式。上文中的init 管道的信息就是通过环境变量的方式从runC传递给容器初始化进程的。

到这里,我们脑海中可能会浮现出另一个问题:c.initPath应该就是容器初始化进程的二进制文件的路径,那么它是一个独立于runC的二进制文件么?它又是放在哪的呢?事实上,c.initPath在上文初始化Container对象时会被初始化为/proc/self/exe,而c.initArgs被设置为init ,因此我们创建子进程的过程其实相当于执行了runc init这条命令。

如果执行的命令为runc create,还需要将前文提到的exec.fifo这个管道同样以环境变量的形式传递到容器初始化进程中。最后,调用newInitProcess将所有配置都填充至结构体initProcess中。

initProcess结构的start方法真正完成了容器进程的创建,并通过init管道协助其完成初始化工作。该方法首先调用p.cmd.Start()创建一个独立的进程,执行命令runc init。接着通过init管道将容器配置p.bootstrapData写入管道中。然后再调用parseSync()函数,通过init管道与容器初始化进程进行同步,待其初始化完成之后,执行PreStart Hook等一些回调操作。最后,关闭init管道,容器创建完成。

runC端在创建容器时所做的工作我们已经基本了解了,下面我们来看看runc init,也就是容器初始化进程具体完成了哪些工作。

作为容器的初始化进程,必须先通过init管道获取配置才能进行下一步的工作。显然,我们首先要做的就是从环境变量中获取与runC进程进行交互的管道的信息,包括init管道。对于runc create还有管道exec.fifo,即上方代码中的fifofd。紧接着,调用函数newContainerInit,创建用于初始化的接口对象initer,该函数的代码如下:

该函数的作用非常明显,从init管道中读取容器配置,解析至initConfig中。对于runc create,创建linuxStandardInit结构,将各种配置信息写入其中。最后,调用该结构的Init方法真正对容器进行初始化。

Init方法真正完成了对容器的初始化工作,它会对容器的网络,路由,hostname等一系列属性进行配置。这些工作一般都是直接通过系统调用设置完成的,因此我们就不再细述了。接下来我们将重点描述容器初始化进程和其父进程,也就是runC进程的同步过程。

我们都知道,每个容器都有自己的根文件系统,到目前为止我们依然还是宿主机文件系统的视角,那么文件系统根目录的切换是在哪里进行的呢?答案是显然的,prepareRootfs

prepareRootfs先对容器的Mounts和Dev等信息进行配置,之后再调用syncParentHooks,通过init管道向runC进程发送procHooks信号。runC进程接收到procHooks信号之后,执行容器的PreStart Hook回调函数,再通过init管道给容器初始化进程发送信号procResume,通知其继续执行。可见容器的PreStart Hook是在根目录尚未切换之前执行完成的。最终,调用chroot函数,切换根目录。至此,容器的文件系统切换完毕。

在文件系统准备完成之后,Init方法还会对Console, hostname等属性进行配置。当一切就绪之后,调用syncParentReady通过init管道通知runC进程,获取响应之后,关闭init管道,同步结束,准备开始执行用户指定的容器进程。

不过在找到了用户指定的容器程序在容器文件系统的执行路径之后,初始化进程又打开了我们之前多次提到的exec.fifo这个管道,并且往里面写入了一个字节,之后才执行Exec系统调用,切换到用户程序。既然exec.fifo是一个管道,那么我们在这一端写入之后,就必须有消费者在另外一端进行读取,否则写进程就会一直处于阻塞状态。

事实上,此处对exec.fifo管道的写阻塞正是runc createrunc start执行流的分界点。容器的创建工作,在容器初始化进程往exec.fifo管道进行写操作的那一刻,就全部结束了。

2.2 容器启动

相对于容器的创建,容器的启动就非常简单了

当我们执行runc start命令时,我们首先会获取相应容器的状态。显然,只有状态为Created的容器才是合法的,此时需要调用容器的Exec方法。

Exec方法仅仅只是对exec的简单封装。而exec方法的工作很简单,找到exec.fifo管道的路径,打开它,并调用readFromExecFifo从管道中将容器初始化进程从另一端写入的字节读出。一旦管道中的数据被读出,容器内的初始化进程将不再被阻塞,紧接着将完成Exec系统调用,容器初始化进程将被切换为用户指定的程序。到此为止,一个容器真正启动成功。

可是这一路分析下来,似乎并没有对容器的namespace进行配置的操作?事实上,子进程runc init的执行流在进入Go语言的运行时之前,会被包/runc/libcontainer/nsenter劫持,先去执行一段C代码。这段C代码同样会从init管道中读取容器的配置,主要是namespace的路径,clone flag等等,并根据这些配置,调用setns系统调用,将容器进程加入到合适的namespace中。之后再进入Go的运行时,完成上文所述的各种初始化操作。

3 总结

简而言之,runC创建容器的过程如下图所示:
runc
1. runc create命令加载文件config.json中容器的配置并转化为与libcontainer兼容的模式
2. libcontainer根据配置创建Container以及ParentProcess对象
3. Parentproces创建runc init子进程,中间会被/runc/libcontainer/nsenter劫持,使runc init子进程位于容器配置指定的各个namespace内
4. ParentProcessinit管道将容器配置信息传输给runc init进程,runc init再据此进行容器的初始化操作。初始化完成之后,再向另一个管道exec.fifo进行写操作,进入阻塞状态
5. 执行runc start命令,从管道exec.fifo中读取上一个步骤写入的字节。runc init进程不再阻塞,执行Exec系统调用,切换至用户指定的容器进程,容器真正创建并启动完成

注:

  1. 文中源码对应的runC版本为v1.0.0-rc5,commit:4fc53a81fb7c994640722ac585fa9ca548971871
  2. 文中引用的代码因文章效果做了部分删减,详细的源码注释参见我的Github

参考文献

Zengzeng Yao

作者介绍:姚增增,浙江大学SEL实验室的在读研究生。多年来从事云原生相关的技术领域,对容器技术、编排技术、操作系统内核有着深入的研究。目前是Kubernetes社区的资深contributor,PouchContainer的maintainer,主导并推进了PouchContainer容器技术中CRI接口的设计与实现。

浙江大学SEL实验室是本网站上所有页面设计、页面内容的著作权人,对该网站所载的作品,包括但不限于网站所载的文字、数据、图形、照片、有声文件、动画文件、音视频资料等拥有完整的版权,受著作权法保护。严禁任何媒体、网站、个人或组织以任何形式或出于任何目的在未经本实验室书面授权的情況下抄袭、转载、摘编、修改本网站內容,或链接、转帖或以其他方式复制用于商业目的或发行,或稍作修改后在其它网站上使用,前述行为均将构成对本网站版权之侵犯,本网站將依法追究其法律责任。
本网站与他人另有协议授权下载的或法律另有规定的,在下载使用时必须注明“稿件来源:浙江大学SEL实验室”。

Leave a Reply

Your email address will not be published. Required fields are marked *