2020 年底,红帽宣布 CentOS 8 将在一年后结束生命周期。自此,开发者圈子里围绕这件事情就出现了很多不同的声音,有主张立刻迁移的;有观望不决的;有转而付费版的;也有质疑红帽是不是准备割韭菜的,这件事情的热度与 CentOS 的受喜爱度成正比,以至于这个决定公布一年多了还在被讨论。
- 3.0x
- 2.5x
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.75x
- 0.5x
本期《极客有约》,我们邀请到了红帽首席架构师张家驹和我们聊聊“停更”事件始末以及被称作 CentOS 未来的 CentOS Stream 到底是什么。
InfoQ:红帽当时为什么决定结束 CentOS 8 的生命周期?
张家驹:CentOS 8 的停更实际相当于是把 CentOS 改了一个名字——CentOS Stream ,这类似于好多开源项目在运作过程中也经常改名字。比如红帽 OpenShift 的社区版 origin 现在叫做 OKD。事实上,CentOS Stream 继承了 CentOS 的衣钵,与 CentOS 同源。我们认为这就是一个正常的版本迭代,或者说是社区项目的迭代,没想到在市场上造成了这么大的反响。
InfoQ:为什么红帽没有在决定公布之初做出来回应?
张家驹:2000 年之前,大家对红帽的印象还停留在卖软件安装光盘。2000 年左右,红帽开始做企业级 Linux,至今已经 20 年。在这之中,我们发现企业的诉求主要是稳定,比如需要一个长生命周期的产品。相对闭源,开源之所以有这么多创新很大程度上是因为包袱小,可以快速将创新的想法加进来,达到更完美的实现,这也是微软、英特尔 X86 架构中寄存器等设计看起来没有那么完美的原因,主要是历史包袱较重,更新时需要保证兼容性。
在红帽提出做企业级 Linux 之前,很少有人将 Linux 直接用于企业生产,企业对于安全、稳定等还是有担忧的。红帽提出将 Linux 送进企业生产环境,主要做法就是反向移植,基于社区某一版本拉出一个分支,在该分支上不断优化和工程化改进,如果有一些创新的想法也加进来,类似 SUSE 等做企业级 Linux 的基本都是这样的思路。这让我们的开发模式在很长一段时间内类似瀑布式开发,我们在这个过程中不断地将整个版本做稳定,这是一种传统的开发方式。
2017 年左右,我们认为这个传统的开发方式有点不合时宜,因为这种方式的迭代周期比较慢,现在都讲究 DevOps、微服务,开发周期越来越短,我们也在思考操作系统内核包含其上软件的开发速度有没有可能提升,我们在开发流程中加入了 CI/CD,且每天晚上都对当天的提交用例做自动化测试(Nightly Builds),第二天就发布一个新的版本,我们将这个过程叫做 Stream。
2018 年左右,CentOS Stream 的雏形就已经有了,但并没有在 CentOS 社区里面公布这种流式的开发模式。随着这几年的孵化并综合考虑了各方面因素,我们认为 CentOS Stream 可以更快捷稳定的发布 Linux 版本,所以相对于我们把 CentOS 升级到 CentOS Stream。
在我们看来,CentOS Stream 的稳定性不输于 CentOS,很多人对此有疑问,认为这是给小白鼠用的,其实不然,Fedora 才是 RHEL 的实验场。从正常的逻辑来说,我们也不需要两个实验场。
InfoQ:非瀑布式开发会影响版本的稳定性吗?CentOS Stream 在企业级 Linux 生态系统中的地位是什么?
张家驹:内核确实是比较讲究稳定性的。早些年,Linux 内核的补丁贡献人数较少,相对来讲企业级的 Linux 系统更新不会太快。如今,越来越多的开发者加入 Linux 内核贡献的队伍,为了让新特性进入主流版本的速度更快,我们需要采取更加快速的方式进行开发,否则很难跟上这个节奏,这对红帽来说是一件棘手的事情,我们需要优化流程让其更加快速,从 RHEL 8 开始就逐渐采用这种新的开发模式,至于这种方式是否一定比传统的瀑布式开发更好是一个更大的话题,我们认为通过更优的流程和更高程度的自动化可以实现稳定性。
不管是否推出 CentOS Stream,如今操作系统内核的开发方式都已经是 CI/CD 的方式,红帽的 RHEL 8 和 9 都是按照这种方式做的,稳定性不需要太过担心。
至于 CentOS Stream 在 Linux 生态中的位置,一般来说, Fedora 是中上游,RHEL 是下游,CentOS Stream 是中游。事实上, Fedora 完全从社区里来,红帽做的更多是打包和简单测试,对其稳定性及可靠性方面的工作做得是比较少,遵循滚动更新的方式,每半年发布一个新版本,新版本与旧版本之间保有基本的兼容性,也可能会丢弃一些老版本中不好的地方,这恰恰是企业级开发不能接受的。
RHEL 则是基于 Fedora 某个特定版本拉取分支,逐渐在这个版本上做增强,保证新旧版本之间的兼容性,并保证最终版本的稳定性。CentOS Stream 则与 RHEL 的版本相对应,其 Git 提交记录完全一致,二者通过同样的构建流程、同样的测试用例。简单来说,只有通过全部的测试用例,CentOS Stream 新版本才会发布,这些测试用例与 RHEL 可能重合,也可能不重合,但我们认为只有全部通过才是稳定的,才可以进入下一步,RHEL 也是如此,二者在稳定性上保持一致。
那么,既然二者一致,为什么还区分中游和下游呢?所有在 RHEL 做的改动都会先进到 CentOS Stream 里面,方便社区生态伙伴一起共建,并让所有开发者第一时间享受到最新版本。
InfoQ:CentOS Stream 与 RHEL 版本之间的对应关系是什么?
张家驹:CentOS Stream 8 和 RHEL 8 是对应的,不过 RHEL 可能还有 8.1、8.2、8.3......这其中的区别是 CentOS Stream 永远只对应 RHEL 最新的稳定版。一般来说,我们的更新节奏是每六个月会更新一个小版本,假设当前 RHEL 的最新稳定版是 8.3,那么 CentOS Stream 一定是和该版本对应的。
很多传统企业可能基于闭源软件的认知,觉得新版并不是最稳定的,但其实 CentOS Stream 是最新、最稳定的版本。这其中还有一个问题是对已经将 CentOS Stream 部署在生产环境的企业而言,半年更新一次太过频繁,那应该怎么办?
大部分企业会一直沿用上线之初选择的版本,除非出现安全问题才会想到更换,即便是这种模式,使用 CentOS Stream 同样行得通,企业可以自主选择在需要的时候更新版本。
至于二者的区别,RHEL 会对单个版本提供长系统更新支持,最长可持续两年,以保证旧版本的安全可靠。虽然新版本在安全、稳定以及一些新特性方面的支持更到位,但企业不是一个人的企业,一旦因为更新发生问题很可能结果是不可逆的,所以很多企业在这方面会选择偏保守的方案。
InfoQ:兼容性是有保证的吗?
张家驹:兼容性肯定是有保证的,但用户的应用因为是闭源的,所以我们无法确定其到底调用了内核中的哪些模块,一个大的版本范围,比如 8 这个大版本内肯定是保证兼容的,红帽也做了很多工程上的工作,让社区可以没有包袱的往前冲,红帽在背后提供支持,最长可以到 13 年。
InfoQ:据了解,Facebook、英特尔等厂商已经参与到 CentOS Stream 的社区共建中了,他们主要在做哪些事情?
张家驹:英特尔对开源项目一直是非常拥抱的态度,特别是 Linux 内核相关的,总体代码贡献量超过红帽,Linux 主要基于 X86 架构起家,英特尔在其中有很重要的贡献。Facebook 则主要是做一些满足自身业务发展的特色化服务,并回馈给社区。
对 Linux 发行版厂商而言,我们做的事情更多是为了满足大众的诉求,而互联网厂商基于各自的业务特点对内核有更高要求,往往会通过更改上层应用的方式达到内核与上层应用的高效协同,或者通过设计一些专有硬件的方式提升效率。在 CentOS Stream 发布之后,Facebook 第一时间就进行了切换,并逐渐把自己的一些能力开放出来。
InfoQ:原 CentOS 用户如何切换至 CentOS Stream?
张家驹:简单来说只需要通过两条命令就可以迁移至 CentOS Stream,但不同企业对生产环境、准生产环境、研发测试环境的定义不尽相同,切换时需要结合实际的业务场景来判断。
这是两条核心命令,但企业要进行迁移肯定不是这么简单,数据备份是最基本的,必要时可能需要回退,红帽也公布了非常详细的迁移步骤,有需要可以自行查看。而且从理论上他也不应该有区别的,因为这个东西本身都是一样的,它怎么可能有区别?即使你说定义参数,这不是一个编译系统,编译参数可能会有变化,但是真的会有变化吗?应该没有多大,因为你的代码都是一样的,应该是没有什么区别的,本质上和软件更新没有任何区别,并不会引入更多风险。
从客观角度来看,CentOS Stream 在很多场景均可稳定运行,如果切换过程遇到问题依然可以在红帽的知识库检索答案,只要是 CentOS Stream 中出现的 Patch,RHEL 中肯定也会有。如果是系统 Bug,可以提交一个 Bug report,我们会针对性的解决问题。
InfoQ:CentOS 社区的开发者、项目管理委员会、SIG 组目前主要在做什么样的事情?
张家驹:对这个开源项目而言,社区没有那么复杂,主要是董事会和 SIG 组两部分治理机构,董事会基本都是像红帽这样的独立董事。技术方面的决策则通过 SIG 组的方式进行,红帽的工程师也会参与讨论,在社区里面和大家一起交流。
如果开发者对这些 SIG 组的讨论感兴趣,可以通过 CentOS.org 了解现有的 SIG 组分布,有针对新技术的、也有针对特定行业的,比如汽车行业,也有如何跟社区沟通的 SIG 组。如果大家有更好的想法也欢迎提交申请。
InfoQ:CentOS Stream 为什么不直接从红帽的企业版编译?
张家驹:无论是红帽的企业版还是 CentOS Stream,代码和走过的测试用例都是一样的,无非最终一个包打了红帽企业级产品的签名,我们更想表达的意思是 RHEL 里面所有的内容都可以在 CentOS Stream 里面看到,如果反过来,用户难免觉得红帽是不是自己留了一部分。
InfoQ:对开发者而言,如何选择在红帽的哪个平台开发?哪个平台部署?
张家驹:开发层面,很多发烧友可能习惯采用 Linux Destop;桌面开发可以选择 Fedora,里面的所有包都是最新的;大部分情况下,服务器端开发,CentOS Stream 是很好的选择,因为它不像 Fedora 那么激进,包也很全,又具备 RHEL 的稳定性,更新又足够快,特别是 8 之后的版本,不同语言的库包括容器化应用开发所需的镜像都是存在的,是很省心的选择。当然,这些都是免费的。如果需要红帽提供一些服务,也可以选择我们的企业级版本。
InfoQ:CentOS Stream 未来维护和持续更新方面的规划?
张家驹:CentOS Stream 是一个长期维护更新项目,毕竟 RHEL 也依赖于此,因此 CentOS Stream 会一直存在,大家不用担心生命周期相关的问题。
评论