本文我来分享下与我们（搞容器化/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/opencontainers/runc 也就是现在大家看到的 runc 了。
发布历程
我们来看看 runc 版本发布的历程，以便了解它为何长跑 5 年。
| runc version | release time | runtime-spec version | 备注 |
|---|---|---|---|
| runc v1.0-rc1 | 2016.06.04 | v1.0.0-rc1 | |
| runc v1.0-rc2 | 2016.10.01 | v1.0.0-rc2-38-g1c7c27d | |
| runc v1.0-rc3 | 2017.03.22 | v1.0.0-rc5 | |
| runc v1.0-rc4 | 2017.08.09 | v1.0.0 | runtime-spec 首次发布 v1.0 |
| runc v1.0-rc5 | 2018.02.27 | v1.0.0 | 首次计划作为最后一个 rc 版本 |
| runc v1.0-rc6 | 2018.11.21 | v1.0.1-49-g5684b8a | 计划是 1.0 之前的最后一个功能版本，包含了一些规范合规性的修正 |
| runc v1.0-rc7 | 2019.03.28 | v1.0.1-59-g29686db | 修复 CVE-2019-5736 |
| runc v1.0-rc8 | 2019.04.26 | v1.0.1-59-g29686db | 修复 v1.0.0-rc7 |
| runc v1.0-rc9 | 2019.10.05 | v1.0.1-59-g29686db | 修复 CVE-2019-16884 |
| runc v1.0-rc10 | 2020.01.23 | v1.0.1-59-g29686db | 修复 CVE-2019-19921 |
| runc v1.0-rc90 | 2020.05.12 | v1.0.1-59-g29686db | 与 runc v1.0-rc10 相同，是为了修正 version scheme |
| runc v1.0-rc91 | 2020.07.02 | v1.0.2-8-g237cc4f | 开始支持 cgroup v2 ；一些规范性的问题得到解决 |
| runc v1.0-rc92 | 2020.08.06 | v1.0.2-23-g4d89ac9 | 修复我在 runc v1.0-rc91 中发现的 bug |
| runc v1.0-rc93 | 2021.02.04 | v1.0.2-35-ge6143ca | cgroup v2 得到稳定支持， |
| runc v1.0-rc94 | 2021.05.10 | v1.0.2-57-g1c3f411 | 修复 runc v1.0-rc93 中的 regressions |
| runc v1.0-rc95 | 2021.05.19 | v1.0.2-57-g1c3f411 | 修复 CVE-2021-30465 |
| runc v1.0 | 2021.06.22 | v1.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 这些版本中还有一大批比较耗费时间和精力的工作，包括添加测试，以及性能优化等，作为底层的基础软件，性能优化对于上层的应用/平台而言影响重大。
有趣的是 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/opencontainers/runc/releases/tag/v1.0.0
欢迎订阅我的文章公众号【MoeLove】
