本文我来分享下与咱们(搞容器化 /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 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 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】