容器标准化之道

本课程内容精选自 DaoCloud Docker Meetup 系列线下活动。本期内容整理自马士淼老师 2 月 25 日在 “New version, New vision” Docker Meetup 中的精彩分享。

马士淼

OCI Maintainer

富士通南大软件技术有限公司软件工程师，目前是 OCI runtime-tools 的 maintainer。从事 Linux 周边的开发工作。热爱开源软件，近几年主要从事 container 相关的开源开发工作。

以下为演讲实录：

今天主要是想和大家分享容器标准化，希望更多对容器化感兴趣的朋友可以参与到 OCI  社区之中。

我来自南京富士通南大软件有限公司，是一名工程师，Libstoragemgmt 的 Maintainer。同时由于工作关系，我对 Docker 接触比较早，目前也是 Docker 的使用者和贡献者。同时，我个人也是开源软件和免费软件的拥趸。

在今天的演讲中，我首先会对 container 的基础知识进行简短的介绍，延伸出目前我们所面临的问题，与大家探讨为什么需要进行容器标准化以及容器标准化的目标。在谈到容器标准化时，不可避免地需要谈及 OCI 社区。我会对 OCI 社区目前的状态，OCI 社区下面的开源项目进行简要地介绍，并且会针对当前面临的现状分享未来的开发计划。

/  关  于  容  器  /

容器技术是最近几年的热门话题，目前越来越多的公司都提出基于容器的解决方案。我个人理解，容器是系统级的轻量化的虚拟化技术。容器技术和虚拟机技术相比，天生有很明显的优势：节省资源。由于没有 guest OS，容器比虚拟机启动的速度更快，同时，占有的资源更少。 从这方面来说，容器比虚拟机，在资源方面有很大的优势。

但是，从我们对容器技术的了解来说，容器技术并不是最新的技术。它有很长的演进历史，从下图可以看到：容器技术可以追溯到 1979 年的很老的 chroot 。但是，容器技术一直没有像最近几年突然之间火爆起来。

➤ 为什么 Docker 带动了容器技术的火爆？

过去的容器技术，例如 Linux container 并不适合在不同主机和不同平台之间进行迁移。同时，它使用起来也不够方便。在这种情况下，催生了 Docker 的出现。

但随着越来越多公司的参与，每个厂商都提出自己的技术解决方案。例如比较热门的 Docker、Rocket/rkt 、OpenVZ/Odin、Hyper 等，他们都有自己的技术标准。没有统一的工业标准，每个厂商各自发展自己的容器标准，不可避免地会形成技术壁垒。这就导致整个容器生态看起来比较碎片化。所以容器标准化是为了更好地解决问题。

➤ 为什么我们需要容器标准化？

对于用户来说，他们不知道采用什么样的标准来选择适合他们的容器技术。不同厂商依赖不同的系统或云平台，导致用户也被迫过度依赖某厂商的云服务。用户想在云平台上进行迁移，会比较困难。

容器标准化，实际上就是为了解决上述问题。容器标准化的目标，就是规范容器技术，引导不同厂商向同一方向发展，同时引导用户选择对自己有利的技术，或提供评价的标准。

/  OCI  技  术  /

谈到容器化的标准化，不可避免的要讨论一下 OCI 技术。OCI 的全称是 Open Container Initiative，这是 2015 年 6 月 22 号发起的开源组织，目前，在 Linux 基金会之下运作。它的主要目的是希望能够为容器和运行格式提供统一的标准。目前大概有 47 个 IT 厂商或者云服务商参与其中。

OCI 社区的主要工作，首先是创建容器运行时的 spec，容器的运行时标准，以及 image 的标准。同时，负责接收管理和提高与这些标准相关的开源项目。同时，OCI 社区也负责与其它标准之间的协调性工作。更多的关于OCI 社区的这种介绍，大家可以去 www.opencontainers.org 官方网站进行了解。

我今天主要会分享 OCI 社区下面几个主要的开源项目，向大家介绍一下目前容器标准化的开源状态。大家现在看到的，是 Docker 运行一个 container 的基本流程。为什么以 Docker 为例？因为 Docker 当时提出的口号是：build ship run。一次编译能够跨平台的创建运行。

从上图中可以看到，Docker 首先需要加载一个 image，image 当中包含了运行所需的根目录，同时接收用户的请求，生成容器运行时的配置文件。根据配置文件用户的请求，以及 root MS 来运行生成容器。 Docker 在没有 OCI 社区之前是一个实时性的容器标准，OCI 社区就借鉴 Docker 的标准，将其规范为从上层运行的基本流程，把它简化为以下几个概念。

如上图所示，容器的执行需要 bundle，bundle 中包含了容器需要的根目录以及容器运行时需要的配置文件，然后通过 runtime，解析 config 配置文件的内容。挂载根目录生成 container，来运行配置文件中需要执行的程序。同时为了便于容器在不同的平台或者架构上进行兼容性地转移，提出了 image 的标准，image 和 bundle 之间可以进行互换。

/ 五  个  开  源  项  目  /

runtime-spec： 容器运行所需要的 runtime 标准，以及了解容器运行时需要的 config 配置文件，需要哪些内容的标准。

image-spec： 负责管理开源的容器镜像的标准。

△ image-spec

runC： 是基于 runtime 的实现，通过 runC 大家可以创建运行删除容器，它是容器的运营工具。

△ runC

runtime-tools： 是我目前贡献比较多的项目，是根据 runtime-spec 的标准来验证。首先验证工作，第一是验证一个 bundle 是否符合 runtime-spec 的要求。其次是验证一个 runtime 是不是兼容 runtime spec。

△ runtime-tools

image-tools： 和 runtime-tools 的功能比较相似，也是验证性工具。因为 OCI 社区的目的不仅仅是定义这种容器的开源工业标准，同时希望能够提供验证的程序，帮助大家能够通过 OCI 的这种程序，让更多人了解和接受，这是符合开放性标准的 runtime。

△ image-tools

/ 目  前  社  区  状  态  /

Runtime-spec 从以下几个方面对标准进行了规范。runtime-spec 定义一个 bundle 应该包含哪些内容，比如说要有 container config 配置文件。同时对容器的生命周期以及 runtime 应该做哪些操作，进行了标准化的规范；对容器运行所需要的配置文件当中，需要包含哪些配置项进行规范。

目前，runtime-spec 对于 Linux, Solaris, Windows 三个平台都进行了支持。同时，提供了 specs-go package，方便大家可以通过调用包来完成符合 runtime spec 的编写和创建，同时提供了 json schema 的应用包，帮助大家验证自己的config 是不是符合 runtime-spec 的要求。目前已经发行了 9 个版本，最新版本是 v1.0.0-rc4 版本。在 1 到 2 个月内，1.0 版本即将通过。

Image-spec 对容器的镜像的 layout 和镜像的配置、货品清单进行了规范。通过标准对容器镜像的标准化，我们规范容器镜像的基准格式，和镜像包中应该包含哪些内容。这样，镜像可以在不同云平台和不同云厂商之间兼容性地运行，不会过度依赖某个厂商的平台或架构。image-spec 也提供了 specs-go package 和 json schema 的验证包。

目前 image-spec 发布了 10 个版本，最新的 v1.0.0-rc5 版本。目前还有很大一部分工作需要做。也欢迎对 image container 感兴趣的各位朋友多多参与。

Runc 是基于 runtime-spec 的一个实现，目前支持容器的创建删除等基本操作。而且，runC 在 Docker，Kubernetes，亚马逊云服务等平台已经获得支持。执行 Docker，底层是 runC 进行容器的创建和状态查询。目前，runC 也已经发布了 14 个版本，也是出现 RC 版本的状态。以我对 runC 的了解来说，目前主要面临的问题是底层仅仅支持 cgroupsv1 ，而对某些系统上已使用的 cgroupv2 目前还不支持。

➤ runtime-tools 三大功能

目前，runtime-tools 主要有以下 3 个功能。

• 第一个功能是帮助用户生成 container 运行时的配置文件。社区认为，container 配置文件是一个 json 文件，里面包含了很多项目。如果用户自己进行编写的话，首先需要自己学习 runtime-spec，要对 Linux 配置项特别熟悉，还要会写 json。这会比较困难。我们希望自己提供 json 命令行工具和一个接口，用户只需要根据命令行参数，可以自动生成 runtime config 配置文件。
• 另外，我们目前也提供了对 OCI bundle 的验证。因为在 OCI 运行里面 bundle 是必须的，image 只是存储不是运营所需要的。我们希望在支持 OCI 标准的云厂商中，能够支持用户上传自己的 bundle 包。这样以来，我们首先对用户的 bundle 进行检证，检验它是否能够在符合 OCI 标准的 runtime 上正常运行。目前已经完成了大概有 70% 的验证工作，只剩下 30% 需要验证的项目还没有进行。
• 第三种功能是对 runtime 进行验证，这也是 runtime-tool 的主要方向。我们希望提供验证机制，帮助用户分辨一个 runtime 是否符合 OCI 标准。Runtime-tools 的验证目前分为两部分：一个是内部的验证，runtime test，一个是外部的 cgroup 和 lifecycle 的验证。内部的验证工作，目前已经完成。但是，cgroups 和 lifecycle 的验证目前还没有完成。我们正在对 runtime-tools 外部验证进行改造，希望实现自动化验证结果。

➤ image tools 主要功能

• 对 image 的验证，基本开发功能已经完成。对于 image 的验证，主要工作也比较简单，因为 image spec 的要求，image 每一层需要有一个哈希值，配置文件同时有哈希值，这为我们的验证提供了很方便的途径。image-validation 也是根据文件的配置项当中的哈希值来验证是否被篡改，所以说目前工作量不是很大的情况下，基本验证工作已经完成了。
• 另外的功能，是帮助用户把一个 image unpack 成一个 bundle，提供帮助用户 image 转换成 bundle 的过程、功能。具体每一个项目的进度，大家可以在 github 上进行查看。

/ 社 区 开 源 项 目 未 来 计 划  /

对于 runtime-spec 和 image-spec，目前关注的不是太多，所以说我们目前只是期望 v1.0 能够尽快发布，重点参与对一些 json schema 的验证包修正。

对于 runC，我们目前的工作重点是，对于 runC 支持的 cgroupv2 的开发。同时，需要完成对 runtime-spec 要求的一些配置，目前 runC 还不支持这部分的开发，希望尽快提升 runC的品质。

对于 runtime-tools，我们未来的计划，完成对于 Linux cgroups 配置的验证，以及对 runtime validation 的改造。还有一个重点，完成这种验证结果输出的可能性。目前的可能性比较差。将来还计划完成 runtime 的兼容性工作。目前 runtime-tools 过度依赖于底层的 go 源包。目前仅仅完成的工作，比如说在 Linux 系统上，验证面向 Linux 的 bundle。我们希望将来在 Linux 平台能够对不同的，比如说面向 Windows 的包，完成这种验证工作。

Image tools 主要的问题，是目前它的功能都是分散的，我们希望它能像 runtime-tools，对其做统一的改造。同时也希望 image tools 也能像 runtime-tools 一样，实现在跨平台的验证工作。