CentOS社区还存在？CentOS项目还存在吗？很多CentOS用户会去哪里？随着CentOS更新的暂停，您可能会有这样那样的疑问。今天，我就以上问题一一解答。CentOS实际上有两个变种，一个叫CentOSLinux，另一个叫CentOSStream。CentOSLinux出现的比较早，大家熟知的CentOS就是CentOSLinux。CentOSStream是两年前由RedHat推出的。推出CentOSStream后，相当于逐步升级CentOSLinux。这就好比，你以前用的是iphone4，现在是iphone5，相当于升级了。更替之后，主要的名字也发生了一些变化——从CentOSLinux变成了CentOSStream，这个我后面会讲到，这个变化本身与开源开发模式的演进和市场需求的变化有关。接下来相信大家还会有其他疑惑，比如CentOSLinux转CentOSStream是否稳定？先一句话回答，稳定。具体有多稳定，待会儿再详细介绍给大家。Linux发行版开发模式的演进我们先来看看Linux发行版开发模式的演进，这可能也是很多开源开发方式的演进。Linux已经走过了31个年头。在早期，Linux完全是出于兴趣爱好。那时候的Linux就像LinusTorvalds自己说的，Linux是为了好玩和好玩而生的。渐渐地，Linux这种开源的开发方式被更多人所接受。随着Linux逐渐走向企业级，Linux逐渐不是玩具。Linux发行版有社区版和企业版。我们主要讲一下在满足企业需求之后Linux发展的主要阶段。Fedora时代的第一个阶段就是所谓的v1.0阶段，也就是Fedora时代。其实很多人也用过Fedora，Fedora的桌面还是很酷的。为什么那个时候会出现FedoraLinux？主要看两个原因，这两个原因还是有些相反的。一是如果你要做企业级的Linux，系统需要足够稳定，也就是说你的更新可能不会太频繁。就算你更新了，也要保证你的兼容性特别好。但对于创新来说，如果过多考虑稳定性和兼容性，创新的包袱会更重。如何平衡创新与稳定的关系？RedHat将其最初统一的RedhatLinux分为Fedora和RedhatEnterpriseLinux。不仅是RedHat，像SuSE这样的其他主流厂商也是如此。这样区分了两者之后，对于不同的用户该如何选择呢？如果我们是企业用户，当然选择稳定版。对于社区用户，您使用Fedora。但是我当时在做Linux开发的时候，不同的阶段都有自己的侧重点。当时我更多的是关注Linux操作系统本身，尤其是图形化桌面的一些功能。其实RedHat虽然不再做桌面了，但是它在Gnome中的贡献还是很大的。当时，Fedora是一个很好的模型，它给了你一些最新的包。那时候的桌面其实已经很成熟了，但可能主要还是兼容性和稳定性的问题。毕竟很少有人使用Linux桌面，所以还没有得到充分的发展。CentOSLinux时代进一步发展，因为逐渐走向移动互联网，出现Android之类的东西，自己桌面的份额越来越小。这方面有Windows和Apple，所以对于Linux桌面，后来各大发行厂商逐渐放弃了对桌面的投入，比如RedHat，SuSE。在服务器端，我们正在逐步走向云化和虚拟化。这个方向成为关注的焦点之后，如果继续我们之前讲的在云上的创新，是不是可以在Fedora的基础上做虚拟化、云化、容器化或者容器方面的创新？企业级使用RHEL。后来发现这个方法其实不太好，为什么呢？因为我们希望有一个稳定的内核，我们认为操作系统是最底层的软件，我们不希望最底层的软件出故障。这时候大家就需要一个和RHEL差不多质量的东西作为它的底层来做上面的一些开发。这时，CentOS应运而生。但是出现在社区中的是CentOS，而不是RedHat做的CentOS。CentOS出现后，它的理念其实很符合当时Linux的发展趋势，所以RedHat收购了CentOS。收购后，CentOSLinux继续按照原来的技术方向发展。这时候，也存在平衡问题。一方面，CentOSLinux是我们想做的基于虚拟化和云的创新；另一方面，它的基础必须足够稳固。所以我刚才讲的那段历史就是上图所示。但是相信我们很多朋友可能都知道CentOS，而且可能只知道左边的部分——我们知道RHELRedHatEnterpriseLinux是从Fedora来的，Fedora是RHEL的试验场。CentOS是基于RHEL的下游复制品，与RHEL相差无几，稳定性毋庸置疑。但是右边的部分很多人不理解——其实当云和虚拟化成为主要的应用负载时，我们会发现CentOS里面的东西不仅仅是RHEL里面的东西，很多东西都是来自Something关于RDO，它是RedHat的OpenStack社区版。虚拟化的东西很多，像Libvirt，oVirt，CentOS也加入了类似的东西。所以坦白说，CentOS不仅仅是RedHatEnterpriseLinux软件包，它还包括许多其他软件包。坦白说，CentOS中其他包的质量应该不如RHEL，因为RHEL是经过严格测试的，社区版的RDO之类的东西并没有经过严格测试。但是对于RDO来说，OpenStack的社区版经过严格的测试之后，生成了OpenStack的RedHatEnterpriseEdition，经过了严格的测试。所以在CentOS中，我们看这个箭头的方向。一方面有RHEL中稳定的操作系统包，同时也有云相关的包，从各方面测试都不太稳定。在CentOSLinux中，其实这就是那个时代的CentOSLinux模型。CentOSStream时代接下来可能要说说最关键的CentOSStream阶段。在CentOSStream阶段，我们发现过去的开发方式已经不能满足现在的要求了。这个或许很好理解：无论是数字化转型还是数字孪生，很多东西以前没有数字化，现在已经数字化了。.世界本身是经常变化的，所以反映它的事物也需要经常变化。这种趋势反映在我们的软件中。25年前Linux发布一个版本的时候，很少有人做出贡献，所以我们采用什么样的开发模式和开发流程可能并不重要。但是现在一个版本有上千人投稿，投稿量巨大，所以它的变化非常快。在这个瞬息万变的社区版本中，如果红帽还想做一个非常稳定的企业级版本供大家使用，那么你的研发过程就必须要做出这样的改进。这种改进就是所谓的Stream模式。Stream模式不同于传统的所谓瀑布式开发。它没有把集成、测试、验证的步骤放在最后一步，而是随着开发的进行而进行测试，可以保证每个发布的版本都是稳定的版本。这是因为我们的快节奏需要Stream模式，而不是我们有Stream模式。所以简而言之，CentOSStream是一个稳定可靠的RHEL持续交付版本。CentOS博客上有一篇文章是2020年12月发表的CentOSStream的几个热点问题，里面有几个特别重要的热点问题，我再给大家强调一下。CentOS的未来是什么样的？CentOS官网给出的一个FAQ，我不想因为翻译而给它造成任何误解。如果您是CentOSLinux用户，请不要担心，将来会有CentOSDistribution等着您。什么是CentOS发行版？其实就是我们现在的Stream。大家关心的是Stream稳定不稳定，安全不安全，CVE漏洞有没有更新和补丁。我们做这个新版本的时候，一定要保证它原来的质量。第二点也比较重要。如果你还想要一个一模一样的旧版CentOSLinux，你可以自己动手。如果你自己做，你必须有一个RHEL代码。代码从何而来？git.centos.org。RHEL代码在前，RHEL代码在后，没有区别，这个其实是完全开放的。当然，如果您是RedHat客户或订阅者，您可以轻松地在您的订阅帐户中下载您的代码。上面说的代码下载的git地址，意思就是你跟RedHat没有关系，我只是想看看你的代码，没关系。其实这也完全符合GPL协议，大家共同遵守，共同繁荣这个社区。由于我们是基于GPL的代码，虽然我们做了很多更改，但这些更改将被完全公开。还有一个大家比较关心的问题。CentOSStream还不如RHEL的beta测试版吗？我们已经明确CentOSStream不是beta版，后面我会简单说明为什么不是beta版。还有一个比较关键的问题，因为CentOSLinux8现在已经转换成CentOSStream8了，那么怎么转换呢？你说服务还没停，那我怎么继续打补丁呢？然后你在你的机器上输入这两行命令：[root@centos~]#dnfswapcentos-linux-reposcentos-stream-repos[root@centos~]#dnfdistro-sync输入后，重新更新它的源，从CentOSLinux的源码到CentOSStream的源码，然后下载安装所有的包，然后替换掉，然后你的系统还是可以用的。即使你是一个比较有经验的用户，如果我在你的电脑上输入这两个命令，接下来使用它们，你也不会察觉。也就是它的稳定性、使用方法、功能都和以前一样。接下来说说为什么Stream和RHEL一样稳定。对于Fedora，我们可以将其视为滚动更新，因为我们每六个月会发布一个新版本。这里所谓的rollingupdate就是我推出了一个新东西，和老东西的兼容性不是特别好。比如我们在29有一个函数，可能在30就舍弃了，这是完全有可能的。但是对于CentOSStream和RHEL就不行了，因为这两个东西都是基于特定版本的Fedora，比如Fedora28，我想做一个稳定的企业版，就拉了一个分支出来。但一些新功能将被添加到这个稳定版本中。此添加称为Backport。向后移植意味着我需要一些新功能和错误修复，而不是一次性添加所有内容。CentOS如何搭建CI接下来我们说说CentOS是如何搭建CI的。CentOSStream和RHEL，一样的代码，进入两个编译和测试系统，编译和测试过程使用的工具是一样的，无非一个是社区版，一个是企业版，只不过名字是不同，但其内容是相同的。这里的测试用例可能不同，但是测试用例是否通过的标准是一样的。比如Stream有300个测试用例，RHEL有500个测试用例，中间有200个测试用例重叠。事实上，一共有600个测试用例没有重复。这600个测试用例，不管你是带着CentOSStream的代码过来的，还是带着RHEL的代码来的，这600个测试用例必须完全通过，才能往下走。其中一个失败了，大家等等，这段代码质量不达标，回去重做。Gating步骤主要是一些自动化测试方法，Verification步骤主要是一些人工测试方法。能自动化的都尽量自动化，但不能说全自动化。其中一些特定于特定环境，一些可能需要手动完成。但在这一步Verification中，双方必须满足Verification的成功标准才能进行下一步，因此其质量保证是相同的。说了这么多关于质量保证，相信很多做测试的朋友可能会说，每做一个小改动，都要经过完整的测试过程。你能挺过去吗？你用什么样的结构来支持它？所以，它也是基于这种事件触发的机制。以空间换取时间，CI系统将完全并发的搭建多个不同的测试环境。所以整个CI流程完全满足DevOpsCI/CDpipeline，可以快速的做大规模的测试，保证在并发比较多，很多人提交patch的时候，我可以快速实现Stream方法。说到这里，不知道大家有没有这样的疑问。这个方法是不是类似于微服务？它实际上有点像那样。如果我们做微服务，为了方便更新，我们把一个大的分成几个小的模块。为什么我们不能在内核中做微服务？我觉得很重要，因为内核，尤其是Linux，是一个宏内核，一切都在内核里面，整个内核的代码其实就是一个大疙瘩。一个小的驱动程序实际上可能会导致整个内核崩溃，这在微服务中实际上是不存在的。正因为如此，每次在内核中做一个小改动，都必须进行测试。在这种情况下，测试量是非常大的，所以如果你没有先进的架构，是无法支持这种Linux发行版的开发的。也就是说，你必须要从CentOSLinux到CentOSStream做这么一步的改变，因为如果你不做这样的改变，那么你的开发节奏就跟不上了，你就无法生产了一个稳定且相对较新的版本。开源软件供应链安全因为今年的log4j漏洞，有些人可能认为log4j是洪水猛兽。其实大家选择log4j是没有问题的。问题是当我们发现安全漏洞时如何处理。我们会发现这个过程和现在的DevSecOps概念非常相似。我们不能保证你进来就没有漏洞，我们的目的是打造一个闭环，保证开源软件供应链的安全。第一步，我们必须在UpStream阶段进行选择和识别。是否有一些恶意代码组件？筛选之后，有没有一个标准化的流程可以帮助我们选择；选型后，我们打包测试；最后，你们在传播过程中有没有一些好的验证方法？尤其是最关键的是，我们上一步把这个东西给了用户，但是当我们遇到问题的时候，能不能有效的去解决呢？因此，我们认为开源软件的供应链安全其实主要是技术问题。AlmaLinux：什么是AlmaLinux替代品？现在很多像CentOSLinux做的东西，都是完全基于RHEL的代码来做fork的。整个过程用到什么组件，AlmaLinux里面的东西都是开源的。如果你有兴趣，可以看看这个过程，看看CentOS.org上代码的变化。对于其中的任何变化，它可以触发它的打包和构建过程，并最终产生它的AlmaLinux。从这一点也可以看出，CentOS绝对不能停。如果停止了，那么这些下游版本，如AlmaLinux、RockLinux和许多其他Linux是从哪里来的？因为RedHat的RHEL是基于CentOSStream的，除非RedHat停止做RHEL，否则CentOSStream会一直存在。CentOSLinux不是RedHatEnterpriseLinux最后，让我们谈谈CentOSLinux，它与RedHatEnterpriseLinux有很大的不同。对于企业级Linux所需要的安全认证、软硬件认证，在企业级保障中，保障多于功能，企业级Linux才有这样的保障。坦白说，CentOS确实很稳定。如果有问题，一旦出现安全漏洞，我会找到补丁。总有一天我会找到一个补丁。但实际上，你打补丁的速度肯定没有企业级Linux快。如果你继续使用这种方式，你可以切换到Stream吗？这是完全可能的。当然，其实对于企业级Linux，如果有明确的规定，比如一些行业标准，还是建议选择RedHat的企业级Linux。
