头图

开源项目的 5 年长跑,runc v1.0 终于正式发布!

张晋涛
English
本文我来分享下与我们(搞容器化/K8S 从业者)息息相关的一个基础项目 runc 是如何自 2016 年发布了 v1.0.0-rc1 到现在历经 5 年长跑,从 rc1 一直到 rc95 ,如今终于正式发布 v1.0 版本的过程,及这中间的故事。

大家好,我是张晋涛。

在 2018 年 11 月底时,我写了一篇文章 《runc 1.0-rc6 发布之际》 , 那应该是我第一次公开介绍 runc。如果你还不了解 runc 是什么,以及如何使用它,请参考我那篇文章。本文中不再对其概念和用法等进行说明。

在 2019 年 3 月底时,我写了另一篇文章 《runc 1.0-rc7 发布之际》,介绍 runc 1.0-rc7 发布的原因,及那个版本中最主要的修复 CVE-2019-5736 。其中也介绍了关于 runc/Docker 等对于 Linux 内核兼容性的问题,感兴趣的小伙伴可以看看。

关注我的朋友们,应该也在 K8S 生态周报 中多次看到过我对 runc 的介绍,包括其特性及安全漏洞等方面。

在 2015 年 6 月, Docker ,CoreOS 和其他一些公司共同成立了 OCI (开放容器计划) 组织,其最主要的内容有两个:

  • 容器运行时规范
  • 容器镜像规范

Docker 将其运行时捐赠给了 OCI ,作为容器运行时规范的基础实现,托管在了 https://github.com/opencontai... 也就是现在大家看到的 runc 了。

发布历程

我们来看看 runc 版本发布的历程,以便了解它为何长跑 5 年。

runc versionrelease timeruntime-spec version备注
runc v1.0-rc12016.06.04v1.0.0-rc1
runc v1.0-rc22016.10.01v1.0.0-rc2-38-g1c7c27d
runc v1.0-rc32017.03.22v1.0.0-rc5
runc v1.0-rc42017.08.09v1.0.0runtime-spec 首次发布 v1.0
runc v1.0-rc52018.02.27v1.0.0首次计划作为最后一个 rc 版本
runc v1.0-rc62018.11.21v1.0.1-49-g5684b8a计划是 1.0 之前的最后一个功能版本,包含了一些规范合规性的修正
runc v1.0-rc72019.03.28v1.0.1-59-g29686db修复 CVE-2019-5736
runc v1.0-rc82019.04.26v1.0.1-59-g29686db修复 v1.0.0-rc7
runc v1.0-rc92019.10.05v1.0.1-59-g29686db修复 CVE-2019-16884
runc v1.0-rc102020.01.23v1.0.1-59-g29686db修复 CVE-2019-19921
runc v1.0-rc902020.05.12v1.0.1-59-g29686db与 runc v1.0-rc10 相同,是为了修正 version scheme
runc v1.0-rc912020.07.02v1.0.2-8-g237cc4f开始支持 cgroup v2 ;一些规范性的问题得到解决
runc v1.0-rc922020.08.06v1.0.2-23-g4d89ac9修复我在 runc v1.0-rc91 中发现的 bug
runc v1.0-rc932021.02.04v1.0.2-35-ge6143cacgroup v2 得到稳定支持,
runc v1.0-rc942021.05.10v1.0.2-57-g1c3f411修复 runc v1.0-rc93 中的 regressions
runc v1.0-rc952021.05.19v1.0.2-57-g1c3f411修复 CVE-2021-30465
runc v1.02021.06.22v1.0.2-57-g1c3f411

我在上面的表格中,专门增加了一列 runtime-spec version ,表示 OCI 组织中的容器运行时规范的版本。我们来总结下这个发布进程:

  • 在 runc v1.0-rc5 之前,runc 其实也没打算发布正式版,毕竟标准还没正式完成呢,实现也不可能先出稳定版;
  • runc v1.0-rc7 , rc 9 ~ rc 10 均是为了修正严重的安全问题;
  • runc v1.0-rc90 纯粹是解决 version scheme 的问题;
  • runc v1.0-rc91~rc93 主要功能点是在 cgroup v2 的支持,以及一些跟规范集成的问题;
  • runc v1.0-93 之后,其实就基本控制代码冻结了,直到 runc v1.0-rc95 修复了一个安全漏洞;
  • 目前主要的几个仓库也都已经测试了跟 runc 代码仓库中最新代码的集成,相关的问题也已经修复。

从这里看到的三个主要耗时的点如下:

  • runtime-spec 尚未正式发布 v1.0 版本;
  • 修复安全漏洞和自身的 bug ;
  • 完成新特性的耗时;

规范未发布 v1.0 耗时的部分这里就不多说了,这也是个依赖项,对于大多数的项目/软件开发都会有类似的情况,只能去推动规范的发布了;

至于特性,bug 和安全漏洞等的耗时,这其实跟 runc 项目的功能和其定位有关。runc 偏底层了一些,这就需要有更多相关领域的知识来支撑。就拿我在 runc v1.0-rc 91 中发现的那个bug 来说,对 Linux 内核源码不太了解的人,确实会花费比较多时间的。

- switch {
- case mode&unix.S_IFBLK == unix.S_IFBLK:
+ switch mode & unix.S_IFMT {
+ case unix.S_IFBLK:
    devType = configs.BlockDevice
- case mode&unix.S_IFCHR == unix.S_IFCHR:
+ case unix.S_IFCHR:
    devType = configs.CharDevice
- case mode&unix.S_IFIFO == unix.S_IFIFO:
+ case unix.S_IFIFO:
    devType = configs.FifoDevice
default:
    return nil, ErrNotADevice

有趣的是 runc v1.0 版本 Release 的标题是 "A wizard is never late, nor is he early, he arrives precisely when he means to." 这大概也很符合 runc 的发布历程了吧 :)

但无论如何,runc 经过 5 年长跑,终于发布了 v1.0 版本!感谢每一个为之付出过的小伙伴!

欢迎大家下载更新! https://github.com/opencontai...


欢迎订阅我的文章公众号【MoeLove】

TheMoeLove

阅读 8.6k

K8S生态
Container, Docker, Go, Kubernetes, Python, Vim; 微信公众号: MoeLove
1.2k 声望
14.3k 粉丝
0 条评论
你知道吗?

1.2k 声望
14.3k 粉丝
宣传栏