Docker - 05 libcontainer

2022-10-31

libcontainer已经被docker捐给OCI,并包装成runc:
runc

以下内容基于runc 1.0.3版本展开

OCI Bundle

OCI Bundle是指满足OCI标准的一系列文件，这些文件包含了运行容器所需要的所有数据，它们存放在一个共同的目录，该目录包含以下两项：

config.json文件包含容器运行的配置数据
root目录为container的root filesystem

整理流程

在runc中所有二级命令都有单独的go文件，通过packege cli中的App命令模版统一调用

创建容器

runc create -b /mycontainer test

create.go

Action: func(context *cli.Context) error {
       // 入参检查
 if err := checkArgs(context, 1, exactArgs); err != nil {
  return err
 }
       //保存pid文件
 if err := revisePidFile(context); err != nil {
  return err
 }
       //加载config.json到spec数据结构
 spec, err := setupSpec(context)
 if err != nil {
  return err
 }
       //创建容器
 status, err := startContainer(context, spec, CT_ACT_CREATE, nil)
 if err != nil {
  return err
 }
 // exit with the container's exit status so any external supervisor is
 // notified of the exit with the correct exit status.
 os.Exit(status)
 return nil
},

utils_linux.go/createContainer/CreateLibcontainerConfig将Spec等相关配置信息转存到Config数据结构,为后续工厂执行操作提供入参
加载Factory接口，其中LinuxFactory将作为一种实现
- 创建root目录 root用户执行是/run/runc
- 创建LinuxFactory数据结构
调用Factory的Create()方法，返回Container接口创建逻辑容器,其中linuxContainer将作为其中一种实现
- 验证容器id合法性
- 验证config合法性
- 通过SecureJoinVFS创建容器的root目录 ${root}/containerid
- 返回Container对象

创建runner在r.run(spec.Process)中执行container.Start(process)创建物理容器Container主要包含了容器配置、控制等信息，是对不同操作系统下容器实现的抽象,目前在linux平台相当于执行func (c *linuxContainer) Start(process *Process) error

在容器root目录下创建exec.fifo

执行内置函数func (c *linuxContainer) start(process *Process) (retErr error)

创建parentProcess,参与物理容器创建过程的Process一共有两个实例

第一个叫Process，用于物理容器内进程的配置和IO的管理，前面在runner run创建的Process就是指它,该实例主要来自spec.Process

另一个叫ParentProcess，负责从物理容器外部处理物理容器启动工作，与Container对象直接进行交互。启动工作完成后，ParentProcess负责执行等待、发信号、获得容器内进程pid等管理工作,initProcess是ParentProcess的一个实现

type parentProcess interface {
 // pid returns the pid for the running process.
 pid() int

 // start starts the process execution.
 start() error

 // send a SIGKILL to the process and wait for the exit.
 terminate() error

 // wait waits on the process returning the process state.
 wait() (*os.ProcessState, error)

 // startTime returns the process start time.
 startTime() (uint64, error)

 signal(os.Signal) error

 externalDescriptors() []string

 setExternalDescriptors(fds []string)

 forwardChildLogs() chan error
}

type initProcess struct {
 cmd             *exec.Cmd
 messageSockPair filePair
 logFilePair     filePair
 config          *initConfig
 manager         cgroups.Manager
 intelRdtManager intelrdt.Manager
 container       *linuxContainer
 fds             []string
 process         *Process
 bootstrapData   io.Reader
 sharePidns      bool
}

调用parentProcess的forwardChildLogs通过管道不断获取容器内的日志

调用parentProcess的start，其实就是执行func (p *initProcess) start() (retErr error)

执行err := p.cmd.Start()会执行runc init命令,但是这个子进程会阻塞在nsenter的func init()，直到通过nsenter让父进程把需要用到相关ns的信息写入socketpair后才执行后面的函数
1
2
3
4
if _, err := io.Copy(p.messageSockPair.parent, p.bootstrapData); err != nil {
return newSystemErrorWithCause(err, "copying bootstrap data to pipe")
}
err = <-waitInit
向子进程发送initConfig,init进行容器初始化,创建网络、路由表、rootfs等
通过messageSockPair.parent进行一系列消息交互,init向父进程发送procReady,等待父进程发送procRun,代表init可以进行execv

最后init会以只写方式打开exec.fifo,这里会阻塞直到另一个进程以读方式打开管道。然后写一个字符0,去执行后续的execv

fd, err := unix.Open("/proc/self/fd/"+strconv.Itoa(l.fifoFd), unix.O_WRONLY|unix.O_CLOEXEC, 0)
if err != nil {
	return newSystemErrorWithCause(err, "open exec fifo")
}

if _, err := unix.Write(fd, []byte("0")); err != nil {
	return newSystemErrorWithCause(err, "write 0 exec fifo")
}

最终runc init进程将分离并作为容器内的init一直执行,容器的状态变为created
容器的状态会保存在/run/runc/${containerid}/state.json

运行容器

runc start test

基于/run/runc/${containerid}/state.json加载container结构
start就是执行container的exec接口,将对应容器的exec.fifo以读方式打开,这样init就不会阻塞,去执行exec的命令,后面使用select读取fifo内容(字符0)
读取到字符0后handleFifoResult(result)将删除exec.fifo文件

func (c *linuxContainer) exec() error {
	path := filepath.Join(c.root, execFifoFilename)
	pid := c.initProcess.pid()
	blockingFifoOpenCh := awaitFifoOpen(path)
	for {
		select {
		case result := <-blockingFifoOpenCh:
			return handleFifoResult(result)

		case <-time.After(time.Millisecond * 100):
			stat, err := system.Stat(pid)
			if err != nil || stat.State == system.Zombie {
				// could be because process started, ran, and completed between our 100ms timeout and our system.Stat() check.
				// see if the fifo exists and has data (with a non-blocking open, which will succeed if the writing process is complete).
				if err := handleFifoResult(fifoOpen(path, false)); err != nil {
					return errors.New("container process is already dead")
				}
				return nil
			}
		}
	}
}

runc exec

exec时创建的parentProcess对应实例就不是initProcess而是setnsProcess,并且在执行data, err := c.bootstrapData(0, state.NamespacePaths)时不需要任何cloneFlags,只需要setns相关进程对应ns路径

然后执行setnsProcess的start(),去执行/proc/self/exe init, 将在main之前调用nsexec.c的nsexec去setns

执行完main之前命名空间切换操作将来到setns_init_linux.go中的Init，根据父进程传入的initConfig执行容器tty、能力、Seccomp等配置 ,最后执行execv