「Dao」课堂|马士淼:分享容器标准化之道

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

014121 (1)

马士淼

OCI Maintainer

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

以下为演讲实录:

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

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

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

/  关  于  容  器  /

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

屏幕快照 2017-03-14 下午7.08.50

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

屏幕快照 2017-03-14 下午7.10.16

➤ 为什么 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。一次编译能够跨平台的创建运行。

屏幕快照 2017-03-14 下午7.16.31

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

屏幕快照 2017-03-14 下午7.17.25

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

/ 五  个  开  源  项  目  /

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

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

屏幕快照 2017-03-14 下午7.21.14

△ image-spec

 

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

屏幕快照 2017-03-14 下午7.22.11

△ runC

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

屏幕快照 2017-03-14 下午7.20.03

△ runtime-tools

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

屏幕快照 2017-03-14 下午7.19.32

△ 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 一样,实现在跨平台的验证工作。

今天的分享就到这里,谢谢大家!

文章太长?或者想身临其境感受现场氛围,点击这里,一键观看视频回放!

Leave a Reply

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