<h2>OCI 和容器标准</h2>    <p>容器技术随着 docker 的出现炙手可热，所有的技术公司都积极拥抱容器，促进了 docker 容器的繁荣发展。 <strong>容器</strong> 一词虽然口口相传，但却没有统一的定义，这不仅是个技术概念的问题，也给整个社区带来一个阴影：容器技术的标准到底是什么？由谁来决定？</p>    <p>很多人可能觉得 docker 已经成为了容器的事实标准，那我们以它作为标准问题就解决了。事情并没有那么简单，首先是否表示容器完全等同于 docker，不允许存在其他的容器运行时（比如 coreOS 推出的 rkt）；其次容器上层抽象（容器集群调度，比如 kubernetes、mesos 等）和 docker 紧密耦合，docker 接口的变化将会导致它们无法使用。</p>    <p>总的来说，如果容器以 docker 作为标准，那么 docker 接口的变化将导致社区中所有相关工具都要更新，不然就无法使用；如果没有标准，这将导致容器实现的碎片化，出现大量的冲突和冗余。这两种情况都是社区不愿意看到的事情，OCI（Open Container Initiative） 就是在这个背景下出现的，它的使命就是推动容器标准化，容器能运行在任何的硬件和系统上，相关的组件也不必绑定在任何的容器运行时上。</p>    <p>官网上对 OCI 的说明如下：</p>    <p>An open governance structure for the express purpose of creating open industry standards around container formats and runtime. – Open Containers Official Site</p>    <p>OCI 由 docker、coreos 以及其他容器相关公司创建于 2015 年，目前主要有两个标准文档： <a href="/misc/goto?guid=4959009934197537878" rel="nofollow,noindex">容器运行时标准</a> （runtime spec）和 <a href="/misc/goto?guid=4959009934197537878" rel="nofollow,noindex">容器镜像标准</a> （image spec）。</p>    <p>这两个协议通过 OCI runtime filesytem bundle 的标准格式连接在一起，OCI 镜像可以通过工具转换成 bundle，然后 OCI 容器引擎能够识别这个 bundle 来运行容器。</p>    <p><img src="https://simg.open-open.com/show/f563abb212868b38bf6ed4704ab546e5.jpg"></p>    <p>下面，我们来介绍这两个 OCI 标准。因为标准本身细节很多，而且还在不断维护和更新，如果不是容器的实现者，没有必须对每个细节都掌握。所以我以介绍概要为主，给大家有个主观的认知。</p>    <h3>image spec</h3>    <p>OCI 容器镜像主要包括几块内容：</p>    <ul>     <li><a href="/misc/goto?guid=4959755319444463292" rel="nofollow,noindex">文件系统</a> ：以 layer 保存的文件系统，每个 layer 保存了和上层之间变化的部分，layer 应该保存哪些文件，怎么表示增加、修改和删除的文件等</li>     <li><a href="/misc/goto?guid=4959755319532703459" rel="nofollow,noindex">config 文件</a> ：保存了文件系统的层级信息（每个层级的 hash 值，以及历史信息），以及容器运行时需要的一些信息（比如环境变量、工作目录、命令参数、mount 列表），指定了镜像在某个特定平台和系统的配置。比较接近我们使用 docker inspect <image_id> 看到的内容</li>     <li><a href="/misc/goto?guid=4959755319630855781" rel="nofollow,noindex">manifest 文件</a> ：镜像的 config 文件索引，有哪些 layer，额外的 annotation 信息，manifest 文件中保存了很多和当前平台有关的信息</li>     <li><a href="/misc/goto?guid=4959755319708644378" rel="nofollow,noindex">index 文件</a> ：可选的文件，指向不同平台的 manifest 文件，这个文件能保证一个镜像可以跨平台使用，每个平台拥有不同的 manifest 文件，使用 index 作为索引</li>    </ul>    <h3>runtime spec</h3>    <p>OCI 对容器 runtime 的标准主要是指定容器的运行状态，和 runtime 需要提供的命令。下图可以是容器状态转换图：</p>    <p><img src="https://simg.open-open.com/show/7a1701c06a955a46f8ddb5ce32ea89bf.jpg"></p>    <ul>     <li>init 状态：这个是我自己添加的状态，并不在标准中，表示没有容器存在的初始状态</li>     <li>creating：使用 create 命令创建容器，这个过程称为创建中</li>     <li>created：容器创建出来，但是还没有运行，表示镜像和配置没有错误，容器能够运行在当前平台</li>     <li>running：容器的运行状态，里面的进程处于 up 状态，正在执行用户设定的任务</li>     <li>stopped：容器运行完成，或者运行出错，或者 stop 命令之后，容器处于暂停状态。这个状态，容器还有很多信息保存在平台中，并没有完全被删除</li>    </ul>    <h2>runc</h2>    <p>runc 是 docker 捐赠给 OCI 的一个符合标准的 runtime 实现，目前 docker 引擎内部也是基于 runc 构建的。这部分我们就分析 runc 这个项目，加深对 OCI 的理解。</p>    <h3>使用 runc 运行 busybox 容器</h3>    <p>先来准备一个工作目录，下面所有的操作都是在这个目录下执行的，比如 mycontainer ：</p>    <pre>  <code class="language-go"># mkdir mycontainer</code></pre>    <p>接下来，准备容器镜像的文件系统，我们选择从 docker 镜像中提取：</p>    <pre>  <code class="language-go"># mkdir rootfs  # docker export $(docker create busybox) | tar -C rootfs -xvf -  # ls rootfs   bin  dev  etc  home  proc  root  sys  tmp  usr  var</code></pre>    <p>有了 rootfs 之后，我们还要按照 OCI 标准有一个配置文件 config.json 说明如何运行容器，包括要运行的命令、权限、环境变量等等内容， runc 提供了一个命令可以自动帮我们生成：</p>    <pre>  <code class="language-go"># runc spec  # ls  config.json  rootfs</code></pre>    <p>这样就构成了一个 <a href="/misc/goto?guid=4959755319792883758" rel="nofollow,noindex">OCI runtime bundle</a> 的内容，这个 bundle 非常简单，就上面两个内容：config.json 文件和 rootfs 文件系统。 config.json 里面的内容很长，这里就不贴出来了，我们也不会对其进行修改，直接使用这个默认生成的文件。有了这些信息，runc 就能知道怎么怎么运行容器了，我们先来看看简单的方法 runc run （这个命令需要 root 权限），这个命令类似于 docker run ，它会创建并启动一个容器：</p>    <pre>  <code class="language-go">➜  runc run simplebusybox  / # ls  bin   dev   etc   home  proc  root  sys   tmp   usr   var  / # hostname  runc  / # whoami  root  / # pwd  /  / # ip addr  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000      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  / # ps aux  PID   USER     TIME   COMMAND      1 root       0:00 sh     11 root       0:00 ps aux</code></pre>    <p>最后一个参数是容器的名字，需要在主机上保证唯一性。运行之后直接进入到了容器的 sh 交互界面，和通过 docker run 看到的效果非常类似。但是这个容器并没有配置网络方面的内容，只是有一个默认的 lo 接口，因此无法和外部通信，但其他功能都正常。</p>    <p>此时，另开一个终端，可以查看运行的容器信息：</p>    <pre>  <code class="language-go">➜ runc list  ID              PID         STATUS      BUNDLE                                    CREATED                          OWNER  simplebusybox   18073       running     /home/cizixs/Workspace/runc/mycontainer   2017-11-02T06:54:52.023379345Z   root</code></pre>    <p>目前，在我的机器上，runc 会把容器的运行信息保存在 /run/runc 目录下：</p>    <pre>  <code class="language-go">➜ tree /run/runc/                       /run/runc/  └── simplebusybox      └── state.json    1 directory, 1 file</code></pre>    <p>除了 run 命令之外，我们也能通过create、start、stop、kill 等命令对容器状态进行更精准的控制。继续实验，因为接下来要在后台模式运行容器，所以需要对 config.json 进行修改。改动有两处，把 terminal 的值改成 false ，修改 args 命令行参数为 sleep 20 ：</p>    <pre>  <code class="language-go">"process": {    "terminal": false,    "user": {     "uid": 0,     "gid": 0    },    "args": [     "sleep", "20"    ],          ...  }</code></pre>    <p>接着，用 runc 子命令来控制容器的运行，实现各个容器状态的转换：</p>    <pre>  <code class="language-go">// 使用 create 创建出容器，此时容器并没有运行，只是准备好了所有的运行环境  // 通过 list 命令可以查看此时容器的状态为 `created`  ➜  runc create mycontainerid  ➜  runc list  ID              PID         STATUS      BUNDLE                                    CREATED                          OWNER  mycontainerid   15871       created     /home/cizixs/Workspace/runc/mycontainer   2017-11-02T08:05:50.658423519Z   root      // 运行容器，此时容器会在后台运行，状态变成了 `running`  ➜  runc start mycontainerid  ➜  runc list  ID              PID         STATUS      BUNDLE                                    CREATED                          OWNER  mycontainerid   15871       running     /home/cizixs/Workspace/runc/mycontainer   2017-11-02T08:05:50.658423519Z   root    // 等待一段时间（20s）容器退出后，可以看到容器状态变成了 `stopped`  ➜  runc list  ID              PID         STATUS      BUNDLE                                    CREATED                          OWNER  mycontainerid   0           stopped     /home/cizixs/Workspace/runc/mycontainer   2017-11-02T08:05:50.658423519Z   root    // 删除容器，容器的信息就不存在了  ➜  runc delete mycontainerid  ➜  runc list  ID          PID         STATUS      BUNDLE      CREATED     OWNER</code></pre>    <p>把以上命令分开来虽然让事情变得复杂了，但是也有很多好处。可以类比 unix 系统 fork-exec 模式，在两者动作之间，用户可以做很多工作。比如把 create 和 start 分开，在创建出来容器之后，可以使用插件为容器配置多主机网络，或者准备存储设置等。</p>    <h3>runc 代码实现</h3>    <p>看完了 runc 命令演示，这部分来深入分析 runc 的代码实现。要想理解 runc 是怎么创建 linux 容器的，需要熟悉namespace 和cgroup、 go 语言 、常见的系统调用。</p>    <p>分析的代码对应的 commit id 如下，这个代码是非常接近 v1.0.0 版本的：</p>    <pre>  <code class="language-go">➜  runc git:(master) git rev-parse HEAD  0232e38342a8d230c2745b67c17050b2be70c6bc</code></pre>    <p>runc 的代码结构如下（略去了部分内容）：</p>    <pre>  <code class="language-go">➜  runc git:(master) tree -L 1 -F --dirsfirst                    .  ├── contrib/  ├── libcontainer/  ├── man/  ├── script/  ├── tests/  ├── vendor/  ├── checkpoint.go  ├── create.go  ├── delete.go  ├── Dockerfile  ├── events.go  ├── exec.go  ├── init.go  ├── kill.go  ├── LICENSE  ├── list.go  ├── main.go  ├── Makefile  ├── notify_socket.go  ├── pause.go  ├── PRINCIPLES.md  ├── ps.go  ├── README.md  ├── restore.go  ├── rlimit_linux.go  ├── run.go  ├── signalmap.go  ├── signalmap_mipsx.go  ├── signals.go  ├── spec.go  ├── start.go  ├── state.go  ├── tty.go  ├── update.go  ├── utils.go  └── utils_linux.go</code></pre>    <p>main.go 是入口文件，根目录下很多 .go 文件是对应的命令（比如 run.go 对应 runc run 命令的实现），其他是一些功能性文件。</p>    <p>最核心的目录是 libcontainer ，它是启动容器进程的最终执行者， runc 可以理解为对 libcontainer 的封装，以符合 OCI 的方式读取配置和文件，调用 libcontainer 完成真正的工作。如果熟悉 docker 的话，可能会知道 libcontainer 本来是 docker 引擎的核心代码，用以取代之前 lxc driver。</p>    <p>我们会追寻 runc run 命令的执行过程，看看代码的调用和实现。</p>    <p>main.go 使用 github.com/urfave/cli 库进行命令行解析，主要的思路是先声明各种参数解析、命令执行函数，运行的时候 cli 会解析命令行传过来的参数，把它们变成定义好的变量，调用指定的命令来运行。</p>    <pre>  <code class="language-go">func main() {      app := cli.NewApp()      app.Name = "runc"      ...            app.Commands = []cli.Command{    checkpointCommand,    createCommand,    deleteCommand,    eventsCommand,    execCommand,    initCommand,    killCommand,    listCommand,    pauseCommand,    psCommand,    restoreCommand,    resumeCommand,    runCommand,    specCommand,    startCommand,    stateCommand,    updateCommand,   }   ...      if err := app.Run(os.Args); err != nil {    fatal(err)   }  }</code></pre>    <p>从上面可以看到命令函数列表，也就是 runc 支持的所有命令，命令行会实现命令的转发，我们关心的 runCommand 定义在 run.go 文件，它的执行逻辑是：</p>    <pre>  <code class="language-go">Action: func(context *cli.Context) error {   if err := checkArgs(context, 1, exactArgs); err != nil {    return err   }   if err := revisePidFile(context); err != nil {    return err   }   spec, err := setupSpec(context)      status, err := startContainer(context, spec, CT_ACT_RUN, nil)   if err == nil {    os.Exit(status)   }   return err  },</code></pre>    <p>可以看到整个过程分为了四步：</p>    <ol>     <li>检查参数个数是否符合要求</li>     <li>如果指定了 pid-file，把路径转换为绝对路径</li>     <li>根据配置读取 config.json 文件中的内容，转换成 spec 结构对象</li>     <li>然后根据配置启动容器</li>    </ol>    <p>其中 spec 的定义在 github.com/opencontainers/runtime-spec/specs-go/config.go#Spec ，其实就是对应了 OCI bundle 中 config.json 的字段，最重要的内容在 startContainer 函数中：</p>    <p>utils_linux.go#startContainer</p>    <pre>  <code class="language-go">func startContainer(context *cli.Context, spec *specs.Spec, action CtAct, criuOpts *libcontainer.CriuOpts) (int, error) {   id := context.Args().First()   if id == "" {    return -1, errEmptyID   }   ......     container, err := createContainer(context, id, spec)   if err != nil {    return -1, err   }   ......     r := &runner{    enableSubreaper: !context.Bool("no-subreaper"),    shouldDestroy:   true,    container:       container,    listenFDs:       listenFDs,    notifySocket:    notifySocket,    consoleSocket:   context.String("console-socket"),    detach:          context.Bool("detach"),    pidFile:         context.String("pid-file"),    preserveFDs:     context.Int("preserve-fds"),    action:          action,    criuOpts:        criuOpts,   }   return r.run(spec.Process)  }</code></pre>    <p>这个函数的内容也不多，主要分成两部分：</p>    <ol>     <li>调用 createContainer 创建出来容器，这个容器只是一个逻辑上的概念，保存了 namespace、cgroups、mounts、capabilities 等所有 Linux 容器需要的配置</li>     <li>然后创建 runner 对象，调用 r.run 运行容器。这才是运行最终容器进程的地方，它会启动一个新进程，把进程放到配置的 namespaces 中，设置好 cgroups 参数以及其他内容</li>    </ol>    <p>我们先来看 utils_linux.go#createContainer ：</p>    <pre>  <code class="language-go">func createContainer(context *cli.Context, id string, spec *specs.Spec) (libcontainer.Container, error) {   config, err := specconv.CreateLibcontainerConfig(&specconv.CreateOpts{    CgroupName:       id,    UseSystemdCgroup: context.GlobalBool("systemd-cgroup"),    NoPivotRoot:      context.Bool("no-pivot"),    NoNewKeyring:     context.Bool("no-new-keyring"),    Spec:             spec,    Rootless:         isRootless(),   })   ....     factory, err := loadFactory(context)   ....   return factory.Create(id, config)  }</code></pre>    <p>它最终会返回一个 libcontainer.Container 对象，上面提到，这并不是一个运行的容器，而是逻辑上的容器概念，包含了 linux 上运行一个容器需要的所有配置信息。</p>    <p>函数的内容分为两部分：</p>    <ol>     <li>创建 config 对象，这个配置对象的定义在 libcontainer/configs/config.go#Config ，包含了容器运行需要的所有参数。 specconv.CreateLibcontainerConfig 这一个函数就是把 spec 转换成 libcontainer 内部的 config 对象。这个 config 对象是平台无关的，从逻辑上定义了容器应该是什么样的配置</li>     <li>通过 libcontainer 提供的 factory，创建满足 libcontainer.Container 接口的对象</li>    </ol>    <p>libcontainer.Container 是个接口，定义在 libcontainer/container_linux.go 文件中：</p>    <pre>  <code class="language-go">type Container interface {   BaseContainer     // 下面这些接口是平台相关的，也就是 linux 平台提供的特殊功能     // 使用 criu 把容器状态保存到磁盘   Checkpoint(criuOpts *CriuOpts) error     // 利用 criu 从磁盘中重新 load 容器   Restore(process *Process, criuOpts *CriuOpts) error     // 暂停容器的执行   Pause() error     // 继续容器的执行   Resume() error     // 返回一个 channel，可以从里面读取容器的 OOM 事件   NotifyOOM() (<-chan struct{}, error)     // 返回一个  channel，可以从里面读取容器内存压力事件   NotifyMemoryPressure(level PressureLevel) (<-chan struct{}, error)  }</code></pre>    <p>里面包含了 Linux 平台特有的功能，基础容器接口为 BaseContainer ，定义在 libcontainer/container.go 文件中，它定义了容器通用的方法：</p>    <pre>  <code class="language-go">type BaseContainer interface {   // 返回容器 ID   ID() string     // 返回容器运行状态   Status() (Status, error)     // 返回容器详细状态信息   State() (*State, error)     // 返回容器的配置   Config() configs.Config     // 返回运行在容器里所有进程的 PID   Processes() ([]int, error)     // 返回容器的统计信息，主要是网络接口信息和 cgroup 中能收集的统计数据   Stats() (*Stats, error)     // 设置容器的配置内容，可以动态调整容器   Set(config configs.Config) error     // 在容器中启动一个进程   Start(process *Process) (err error)     // 运行容器   Run(process *Process) (err error)     // 销毁容器，就是删除容器   Destroy() error     // 给容器的 init 进程发送信号   Signal(s os.Signal, all bool) error     // 告诉容器在 init 结束后执行用户进程   Exec() error  }</code></pre>    <p>可以看到，上面是容器应该支持的命令，包含了查询状态和创建、销毁、运行等。</p>    <p>这里使用 factory 模式是为了支持不同平台的容器，每个平台实现自己的 factory ，根据运行平台调用不同的实现就行。不过 runc 目前只支持 linux 平台，所以我们看 libcontainer/factory_linux.go 中的实现：</p>    <pre>  <code class="language-go">func New(root string, options ...func(*LinuxFactory) error) (Factory, error) {   if root != "" {    if err := os.MkdirAll(root, 0700); err != nil {     return nil, newGenericError(err, SystemError)    }   }   l := &LinuxFactory{    Root:      root,    InitPath:  "/proc/self/exe",    InitArgs:  []string{os.Args[0], "init"},    Validator: validate.New(),    CriuPath:  "criu",   }   Cgroupfs(l)   for _, opt := range options {    if opt == nil {     continue    }    if err := opt(l); err != nil {     return nil, err    }   }   return l, nil  }    func (l *LinuxFactory) Create(id string, config *configs.Config) (Container, error) {   ......   containerRoot := filepath.Join(l.Root, id)   if err := os.MkdirAll(containerRoot, 0711); err != nil {    return nil, newGenericError(err, SystemError)   }      ......         c := &linuxContainer{    id:            id,    root:          containerRoot,    config:        config,    initPath:      l.InitPath,    initArgs:      l.InitArgs,    criuPath:      l.CriuPath,    newuidmapPath: l.NewuidmapPath,    newgidmapPath: l.NewgidmapPath,    cgroupManager: l.NewCgroupsManager(config.Cgroups, nil),   }   ......   c.state = &stoppedState{c: c}   return c, nil  }</code></pre>    <p>New 创建了一个 linux 平台的 factory，从 LinuxFactory 的 fields 可以看到，它里面保存了和 linux 平台相关的信息。</p>    <p>Create 返回的是 linuxContainer 对象，它是 libcontainer.Container 接口的实现。有了 libcontainer.Container 对象之后，回到 utils_linux.go#Runner 中看它是如何运行容器的：</p>    <pre>  <code class="language-go">func (r *runner) run(config *specs.Process) (int, error) {        // 根据 OCI specs.Process 生成 libcontainer.Process 对象      // 如果出错，运行 destroy 清理产生的中间文件   process, err := newProcess(*config)   if err != nil {    r.destroy()    return -1, err   }         ......   var (    detach = r.detach || (r.action == CT_ACT_CREATE)   )   handler := newSignalHandler(r.enableSubreaper, r.notifySocket)      // 根据是否进入到容器终端来配置 tty，标准输入、标准输出和标准错误输出   tty, err := setupIO(process, rootuid, rootgid, config.Terminal, detach, r.consoleSocket)   defer tty.Close()     switch r.action {   case CT_ACT_CREATE:    err = r.container.Start(process)   case CT_ACT_RESTORE:    err = r.container.Restore(process, r.criuOpts)   case CT_ACT_RUN:    err = r.container.Run(process)   default:    panic("Unknown action")   }     ......   status, err := handler.forward(process, tty, detach)   if detach {    return 0, nil   }   r.destroy()   return status, err  }</code></pre>    <p>runner 是一层封装，主要工作是配置容器的 IO，根据命令去调用响应的方法。 newProcess(*config) 将 OCI spec 中的 process 对象转换成 libcontainer 中的 process，process 的定义在 libcontainer/process.go#Process ，包括进程的命令、参数、环境变量、用户、标准输入输出等。</p>    <p>有了 process ，下一步就是运行这个进程 r.container.Run(process) ， Run 会调用内部的 libcontainer/container_linux.go#start() 方法：</p>    <pre>  <code class="language-go">func (c *linuxContainer) start(process *Process, isInit bool) error {   parent, err := c.newParentProcess(process, isInit)     if err := parent.start(); err != nil {    return newSystemErrorWithCause(err, "starting container process")   }     c.created = time.Now().UTC()   if isInit {          ......     for i, hook := range c.config.Hooks.Poststart {     if err := hook.Run(s); err != nil {      return newSystemErrorWithCausef(err, "running poststart hook %d", i)     }    }   }    return nil  }</code></pre>    <p>运行容器进程，在容器进程完全起来之前，需要利用父进程和容器进程进行通信，因此这里封装了一个 paerentProcess 的概念，</p>    <pre>  <code class="language-go">func (c *linuxContainer) newParentProcess(p *Process, doInit bool) (parentProcess, error) {   parentPipe, childPipe, err := utils.NewSockPair("init")   cmd, err := c.commandTemplate(p, childPipe)      ......   return c.newInitProcess(p, cmd, parentPipe, childPipe)  }</code></pre>    <p>parentPipe 和 childPipe 就是父进程和创建出来的容器 init 进程通信的管道，这个管道用于在 init 容器进程启动之后做一些配置工作，非常重要，后面会看到它们的使用。</p>    <p>最终创建的 parentProcess 是 libcontainer/process_linux.go#initProcess 对象，</p>    <pre>  <code class="language-go">type initProcess struct {   cmd             *exec.Cmd   parentPipe      *os.File   childPipe       *os.File   config          *initConfig   manager         cgroups.Manager   intelRdtManager intelrdt.Manager   container       *linuxContainer   fds             []string   process         *Process   bootstrapData   io.Reader   sharePidns      bool  }</code></pre>    <ul>     <li>cmd 是 init 程序，也就是说启动的容器子进程是 runc init ，后面我们会说明它的作用</li>     <li>paerentPipe 和 childPipe 是父子进程通信的管道</li>     <li>bootstrapDta 中保存了容器 init 初始化需要的数据</li>     <li>process 会保存容器 init 进程，用于父进程获取容器进程信息和与之交互</li>    </ul>    <p>有了 parentProcess ，接下来它的 start() 方法会被调用：</p>    <pre>  <code class="language-go">func (p *initProcess) start() error {   defer p.parentPipe.Close()   err := p.cmd.Start()   p.process.ops = p   p.childPipe.Close()        // 把容器 pid 加入到 cgroup 中   if err := p.manager.Apply(p.pid()); err != nil {    return newSystemErrorWithCause(err, "applying cgroup configuration for process")   }         // 给容器进程发送初始化需要的数据   if _, err := io.Copy(p.parentPipe, p.bootstrapData); err != nil {    return newSystemErrorWithCause(err, "copying bootstrap data to pipe")   }            // 等待容器进程完成 namespace 的配置   if err := p.execSetns(); err != nil {    return newSystemErrorWithCause(err, "running exec setns process for init")   }     // 创建网络 interface   if err := p.createNetworkInterfaces(); err != nil {    return newSystemErrorWithCause(err, "creating network interfaces")   }      // 给容器进程发送进程配置信息   if err := p.sendConfig(); err != nil {    return newSystemErrorWithCause(err, "sending config to init process")   }         // 和容器进程进行同步      // 容器 init 进程已经准备好环境，准备运行容器中的用户进程      // 所以这里会运行 prestart 的钩子函数   ierr := parseSync(p.parentPipe, func(sync *syncT) error {    ......    return nil   })     // Must be done after Shutdown so the child will exit and we can wait for it.   if ierr != nil {    p.wait()    return ierr   }   return nil  }</code></pre>    <p>这里可以看到管道的用处：父进程把 bootstrapData 发送给子进程，子进程根据这些数据配置 namespace、cgroups，apparmor 等参数；等待子进程完成配置，进行同步。</p>    <p>容器子进程会做哪些事情呢？用同样的方法，可以找到 runc init 程序运行的逻辑代码在 libcontainer/standard_init_linux.go#Init() ，它做的事情包括：</p>    <ol>     <li>配置 namespace</li>     <li>配置网络和路由规则</li>     <li>准备 rootfs</li>     <li>配置 console</li>     <li>配置 hostname</li>     <li>配置 apparmor profile</li>     <li>配置 sysctl 参数</li>     <li>初始化 seccomp 配置</li>     <li>配置 user namespace</li>    </ol>    <p>上面这些就是 linux 容器的大部分配置，完成这些之后，它就调用 Exec 执行用户程序：</p>    <pre>  <code class="language-go">if err := syscall.Exec(name, l.config.Args[0:], os.Environ()); err != nil {   return newSystemErrorWithCause(err, "exec user process")  }</code></pre>    <p>NOTE：其实，init 在执行自身的逻辑之前，会被 libcontainer/nsenter 劫持，nsenter 是 C 语言编写的代码，目的是为容器配置 namespace，它会从 init pipe 中读取 namespace 的信息，调用setns 把当前进程加入到指定的 namespace 中。</p>    <p>之后，它会调用 clone 创建一个新的进程，初始化完成之后，把子进程的进程号发送到管道中，nsenter 完成任务退出，子进程会返回，让 init 接管，对容器进行初始化。</p>    <p>至此，容器的所有内容都 ok，而且容器里的用户进程也启动了。</p>    <p><img src="https://simg.open-open.com/show/1d4299676a1a901181c51b950cc9c0e7.jpg"></p>    <p>runc 的代码调用关系如上图所示，可以在新页面打开查看大图。主要逻辑分成三块：</p>    <ul>     <li>最上面的红色是命令行封装，这是根据 OCI 标准实现的接口，它能读取 OCI 标准的容器 bundle，并实现了 OCI 指定 run、start、create 等命令</li>     <li>中间的紫色部分就是 libcontainer，它是 runc 的核心内容，是对 linux namespace、cgroups 技术的封装</li>     <li>右下角的绿色部分是真正的创建容器子进程的部分</li>    </ul>    <h2>参考资料</h2>    <ul>     <li><a href="/misc/goto?guid=4959755319875587770" rel="nofollow,noindex">OCI FAQ page</a></li>     <li><a href="/misc/goto?guid=4958970357236840690" rel="nofollow,noindex">OCI标准和runC原理解读</a></li>     <li><a href="/misc/goto?guid=4958875851697412256" rel="nofollow,noindex">Docker背后的容器管理——Libcontainer深度解析</a></li>    </ul>    <p> </p>    <p>来自：http://cizixs.com/2017/11/05/oci-and-runc</p>    <p> </p>