回顾
本文接 探索 runC(上)
前文讲到，newParentProcess() 根据源自 config.json 的配置，最终生成变量 initProcess，这个 initProcess 包含的信息主要有
cmd 记录了要执行的可执行文件名，即 “/proc/self/exe init”，注意不要和容器要执行的 sleep 5 混淆了
cmd.Env 记录了名为 _LIBCONTAINER_FIFOFD=%d 记录的命名管道 exec.fifo 的描述符，名为_LIBCONTAINER_INITPIPE=%d 记录了创建的 SocketPair 的 childPipe 一端的描述符，名为_LIBCONTAINER_INITTYPE=”standard” 记录要创建的容器中的进程是初始进程
initProcess 的 bootstrapData 记录了新的容器要创建哪些类型的 Namespace。
/* libcontainer/container_linux.go */
func (c *linuxContainer) start(process *Process) error {
parent, err := c.newParentProcess(process) /* 1. 创建 parentProcess (已完成) */
err := parent.start(); /* 2. 启动这个 parentProcess */
……
准备工作完成之后，就要调用 start() 方法启动。
注意: 此时 sleep 5 线索存储在变量 parent 中
runC create 的实现原理 (下)
start() 函数实在太长了，因此逐段来看
/* libcontainer/process_linux.go */
func (p *initProcess) start() error {
p.cmd.Start()
p.process.ops = p
io.Copy(p.parentPipe, p.bootstrapData)
…..
}
p.cmd.Start() 启动 cmd 中设置的要执行的可执行文件 /proc/self/exe，参数是 init，这个函数会启动一个新的进程去执行该命令，并且不会阻塞。
io.Copy 将 p.bootstrapData 中的数据通过 p.parentPipe 发送给子进程
/proc/self/exe 正是 runc 程序自己，所以这里相当于是执行 runc init，也就是说，我们输入的是 runc create 命令，隐含着又去创建了一个新的子进程去执行 runc init。为什么要额外重新创建一个进程呢？原因是我们创建的容器很可能需要运行在一些独立的 namespace 中，比如 user namespace, 这是通过 setns() 系统调用完成的，而在 setns man page 中写了下面一段话
A multi‐threaded process may not change user namespace with setns(). It is not permitted to use setns() to reenter the caller’s current user names‐pace
即多线程的进程是不能通过 setns()改变 user namespace 的。而不幸的是 Go runtime 是多线程的。那怎么办呢？所以 setns()必须要在 Go runtime 启动之前就设置好, 这就要用到 cgo 了，在 Go runtime 启动前首先执行嵌入在前面的 C 代码。
具体的做法在 nsenter README 描述 在 runc init 命令的响应在文件 init.go 开头，导入 nsenter 包
/* init.go */
import (
“os”
“runtime”
“github.com/opencontainers/runc/libcontainer”
_ “github.com/opencontainers/runc/libcontainer/nsenter”
“github.com/urfave/cli”
)
而 nsenter 包中开头通过 cgo 嵌入了一段 C 代码, 调用 nsexec()
package nsenter
/*
/* nsenter.go */
#cgo CFLAGS: -Wall
extern void nsexec();
void __attribute__((constructor)) init(void) {
nsexec();
}
*/
import “C”
接下来，轮到 nsexec() 完成为容器创建新的 namespace 的工作了, nsexec() 同样很长，逐段来看
/* libcontainer/nsenter/nsexec.c */
void nsexec(void)
{
int pipenum;
jmp_buf env;
int sync_child_pipe[2], sync_grandchild_pipe[2];
struct nlconfig_t config = {0};
/*
* If we don’t have an init pipe, just return to the go routine.
* We’ll only get an init pipe for start or exec.
*/
pipenum = initpipe();
if (pipenum == -1)
return;
/* Parse all of the netlink configuration. */
nl_parse(pipenum, &config);
……
上面这段 C 代码中，initpipe() 从环境中读取父进程之前设置的 pipe(_LIBCONTAINER_INITPIPE 记录的的文件描述符)，然后调用 nl_parse 从这个管道中读取配置到变量 config，那么谁会往这个管道写配置呢 ? 当然就是 runc create 父进程了。父进程通过这个 pipe，将新建容器的配置发给子进程，这个过程如下图所示:
发送的具体数据在 linuxContainer 的 bootstrapData() 函数中封装成 netlink msg 格式的消息。忽略大部分配置，本文重点关注 namespace 的配置，即要创建哪些类型的 namespace，这些都是源自最初的 config.json 文件。
至此，子进程就从父进程处得到了 namespace 的配置，继续往下，nsexec() 又创建了两个 socketpair, 从注释中了解到，这是为了和它自己的子进程和孙进程进行通信。
void nsexec(void)
{
…..
/* Pipe so we can tell the child when we’ve finished setting up. */
if (socketpair(AF_LOCAL, SOCK_STREAM, 0, sync_child_pipe) < 0) // sync_child_pipe is an out parameter
bail(“failed to setup sync pipe between parent and child”);
/*
* We need a new socketpair to sync with grandchild so we don’t have
* race condition with child.
*/
if (socketpair(AF_LOCAL, SOCK_STREAM, 0, sync_grandchild_pipe) < 0)
bail(“failed to setup sync pipe between parent and grandchild”);
}
然后就该创建 namespace 了，看注释可知这里其实有考虑过三个方案
first clone then clone
first unshare then clone
first clone then unshare
最终采用的是方案 3, 其中缘由由于考虑因素太多，所以准备之后另写一篇文章分析
接下来就是一个大的 switch case 编写的状态机, 大体结构如下，当前进程通过 clone()系统调用创建子进程，子进程又通过 clone()系统调用创建孙进程，而实际的创建 / 加入 namespace 是在子进程完成的
switch (setjmp(env)) {
case JUMP_PARENT:{
…..
clone_parent(&env, JUMP_CHILD);
…..
}
case JUMP_CHILD:{
……
if (config.namespaces)
join_namespaces(config.namespaces);
clone_parent(&env, JUMP_INIT);
……
}
case JUMP_INIT:{
}
本文不准备展开分析这个状态机了，而将这个状态机的流程画在了下面的时序图中，需要注意的是以下几点
namespaces 在 runc init 2 完成创建
runc init 1 和 runc init 2 最终都会执行 exit(0), 但 runc init 3 不会，它会继续执行 runc init 命令的后半部分。因此最终只会剩下 runc create 进程和 runc init 3 进程
再回到 runc create 进程
func (p *initProcess) start() error {
p.cmd.Start()
p.process.ops = p
io.Copy(p.parentPipe, p.bootstrapData);
p.execSetns()
……
再向 runc init 发送了 bootstrapData 数据后，便调用 execSetns() 等待 runc init 1 进程终止，从管道中得到 runc init 3 的进程 pid, 将该进程保存在 p.process.ops
/* libcontainer/process_linux.go */
func (p *initProcess) execSetns() error {
status, err := p.cmd.Process.Wait()
var pid *pid
json.NewDecoder(p.parentPipe).Decode(&pid)
process, err := os.FindProcess(pid.Pid)
p.cmd.Process = process
p.process.ops = p
return nil
}
继续 start()
func (p *initProcess) start() error {
……
p.execSetns()
fds, err := getPipeFds(p.pid())
p.setExternalDescriptors(fds)
p.createNetworkInterfaces()
p.sendConfig()
parseSync(p.parentPipe, func(sync *syncT) error {
switch sync.Type {
case procReady:
…..
writeSync(p.parentPipe, procRun);
sentRun = true
case procHooks:
…..
// Sync with child.
err := writeSync(p.parentPipe, procResume);
sentResume = true
}
return nil
})
……
可以看到，runc create 又开始通过 pipe 进行双向通信了，通信的对端自然就是 runc init 3 进程了，runc init 3 进程在执行完嵌入的 C 代码后 (实际是 runc init 1 执行的，但 runc init 3 也是由 runc init 1 间接 clone() 出来的)，因此将开始运行 Go runtime，开始响应 init 命令
sleep 5 通过 p.sendConfig() 发送给了 runc init 进程
init 命令首先通过 libcontainer.New(“”) 创建了一个 LinuxFactory, 这个方法在上篇文章中分析过，这里不再解释。然后调用 LinuxFactory 的 StartInitialization() 方法。
/* libcontainer/factory_linux.go */
// StartInitialization loads a container by opening the pipe fd from the parent to read the configuration and state
// This is a low level implementation detail of the reexec and should not be consumed externally
func (l *LinuxFactory) StartInitialization() (err error) {
var (
pipefd, fifofd int
envInitPipe = os.Getenv(“_LIBCONTAINER_INITPIPE”)
envFifoFd = os.Getenv(“_LIBCONTAINER_FIFOFD”)
)
// Get the INITPIPE.
pipefd, err = strconv.Atoi(envInitPipe)
var (
pipe = os.NewFile(uintptr(pipefd), “pipe”)
it = initType(os.Getenv(“_LIBCONTAINER_INITTYPE”)) // // “standard” or “setns”
)
// Only init processes have FIFOFD.
fifofd = -1
if it == initStandard {
if fifofd, err = strconv.Atoi(envFifoFd); err != nil {
return fmt.Errorf(“unable to convert _LIBCONTAINER_FIFOFD=%s to int: %s”, envFifoFd, err)
}
}
i, err := newContainerInit(it, pipe, consoleSocket, fifofd)
// If Init succeeds, syscall.Exec will not return, hence none of the defers will be called.
return i.Init() //
}
StartInitialization() 方法尝试从环境中读取一系列_LIBCONTAINER_XXX 变量的值，还有印象吗？这些值全是在 runc create 命令中打开和设置的，也就是说，runc create 通过环境变量，将这些参数传给了子进程 runc init 3
拿到这些环境变量后，runc init 3 调用 newContainerInit 函数
/* libcontainer/init_linux.go */
func newContainerInit(t initType, pipe *os.File, consoleSocket *os.File, fifoFd int) (initer, error) {
var config *initConfig
/* read config from pipe (from runc process) */
son.NewDecoder(pipe).Decode(&config);
populateProcessEnvironment(config.Env);
switch t {
……
case initStandard:
return &linuxStandardInit{
pipe: pipe,
consoleSocket: consoleSocket,
parentPid: unix.Getppid(),
config: config, // <=== config
fifoFd: fifoFd,
}, nil
}
return nil, fmt.Errorf(“unknown init type %q”, t)
}
newContainerInit() 函数首先尝试从 pipe 读取配置存放到变量 config 中，再存储到变量 linuxStandardInit 中返回
runc create runc init 3
| |
p.sendConfig() — config –> NewContainerInit()
sleep 5 线索在 initStandard.config 中
回到 StartInitialization(), 在得到 linuxStandardInit 后，便调用其 Init()方法了
/* init.go */
func (l *LinuxFactory) StartInitialization() (err error) {
……
i, err := newContainerInit(it, pipe, consoleSocket, fifofd)
return i.Init()
}
本文忽略掉 Init() 方法前面的一大堆其他配置，只看其最后
func (l *linuxStandardInit) Init() error {
……
name, err := exec.LookPath(l.config.Args[0])
syscall.Exec(name, l.config.Args[0:], os.Environ())
}
可以看到，这里终于开始执行 用户最初设置的 sleep 5 了