拥抱centosstream

2020年12⽉8⽇，

CentOS项⽬的未来是CentOS Stream，在明年，我们将把重点从重建Red Hat Enterprise Linux（RHEL）的CentOS Linux转移到CentOS Stream，后者紧跟当前RHEL版本发布。作为对RHEL 8的重建，CentOS Linux 8将于2021年底结束。CentOSStream在此⽇期之后继续，作为Red Hat Enterprise Linux的上游（开发）分⽀。⼤多数⼈的反应都是抗拒， 包括我，已经开始准备测试 Ubuntu、Debian 了。仔细思考下来，其实 CentOS切换到Stream应该不会差。因为时代不⼀样了。

那么，什么改变了？

软件开发。

利⽤DevOps的优势，我们⼀直在转向基于平台的开发⽅法。

编程语⾔是由⼯具⽀持的平台

如今，⼈们⽆法在带有编译器的编辑器中进⾏编程。

他们使⽤具有许多集成功能的Github或Gitlab和本地IDE。他们承诺使⽤⼀个VCS（实际上，git在⼀个单⼀的VCS上融合了整个世界），并触发了很多事情。类型检查，重新格式化，测试，还包括代码质量指标和安全扫描程序。

即使在2020年启动⼀种新的编程语⾔也没有过去那样容易。仅凭⼀种语⾔是不够的，因为您不仅需要⼀种语⾔，也许还需要⼀种标准库，⽽且还需要⽀持它的JetBrains产品，SonarQube⽀持，XRay集成，gitlab-ci.yml⽰例等等。基本上，有⼀个庞⼤的基础架构系统旨在⽀持开发，⽽⽆论您从什么开始就需要从⼀开始就适应它。

也就是说，因为我们已经依赖整个⼯具⽣态系统来提⾼开发⼈员的速度，并在整个团队中实施统⼀的标准。那是⼀件好事，它可以帮助我们成为更好的程序员。

Github和Gitlab是开发⼈员之间有关代码的对话⼯具

我们也开始依赖⼯具来实现协作以及关于代码的结构化讨论，因为我们作为程序员不再单独⼯作。Gitlab，Github和类似软件的很⼤⼀部分价值是使开发⼈员之间能够以开发⼈员重视的⽅式进⾏有益的合作。

在这些平台的⽣产端可以提取价值的另⼀部分：我们以可复制的⽅式⾃动⽣成构件。其中还包括了解与这些⼯件有关的事情，例如，产⽣这些⼯件并能够报告这些事情的原因：

依赖关系licenses版本号漏洞

提交每个依赖项修复的频率和时间，放弃软件警报

还有更多的东西。通过这些过程，存储库以及其他要素，只要我们找到⼀种适当管理和发展状态的⽅法，我们就可以部署和回滚成为⾃动化且标准化的过程。

与2010年代⼿⼯定制的部署和回滚程序相⽐，这是⼀个巨⼤的进步。

不变的基础架构和可复制的构建

这另⼀部分是不变的基础架构。

这是⼀个基本思想，即在部署代码后，我们就不再对运⾏代码的基础镜像的状态进⾏操作。从根本上说，这是Puppet及其类似⾓⾊的死亡。取⽽代之的是，我们更改构建过程，⽣成不可变的镜像，然后快速进⾏重建和重新部署。我们部署基础镜像，然后以其他更合适的⽅式提供机密、运⾏时配置和控制配置。诸如Vault之类的东西，诸如Zookeeper之类的共识系统之类的东西或类似的机制都浮现在脑海。在当今所有计算已成为分布式计算的时代，它使我们能够在整个实例队列之间协调变更，以确保整个实例队列之间的⼀致性。

可以将相同的思想应⽤于主机的实际基本操作系统，在该主机中，我们从基本操作系统中完全删除了应⽤程序安装。相反，我们提供了⼀种以虚拟机镜像，容器镜像或⽆服务器功能部署（也包括容器，但按钮较少）的形式安装和卸载应⽤程序安装（包括其依赖项）的机制。结果，⼀切都变成了单⽤户，单租户–⼀个镜像仅包含 Postgres，另⼀个镜像仅包含您的静态镜像Web服务器（由外部可挂载卷提供的镜像），⽽第三个镜像仅包含您的⽣产Python应⽤程序和运⾏时环境。容器中只有⼀件东西，Linux UID 不再具有有⽤的分离功能，⽽其他隔离和分离机制将取代它们：

virtualization,CGroups,Namespaces,Seccomp,

和类似的。⽆论如何，它们可以说更强⼤。

这在伟⼤的论点中也形成了⼀种论点：“ curlbash甚⾄ sudo curlbash还是⼀件坏事吗？”

镜像作为应⽤程序的基础

因此，现在我们可以使⽤整个应⽤程序（具有在运⾏时提供并注⼊的配置）来构建服务，并且可以在环境提供的现有服务之上添加我们⾃⼰的代码中的⼀⼩部分来构建我们⾃⼰的服务。我们获得了Kubernetes的Helm Charts，获得了和Step Functions。我们还获得了Nocode，⽆代码或类似的尝试，仅从服务中构建某些东西⽽没有实际编码。但这⽐这更普遍：

Unifi控制平⾯使⽤多个Java进程和⼀个Mongodb。可以将其打包到⼀个镜像，也可以将其作为舵图提供，也可以将其作为包含多个容器的泊坞窗提供，以实现更好的可伸缩性和维护性。

gitlab Omnibus再次使⽤单个容器，并带有Postgres，Redis和许多内部状态以及Chef，以部署⼤约⼗⼆个组件，但是在K8s上下⽂中还存在针对各个组件的差异部署。

像Jitsi设置之类的东西可以打包到⼀个相对简单的docker-compose.yml中，并且将⾃动从镜像中⾃动组装它们。只要提供Linux内核syscall接⼝，结果就可以在⼏乎所有操作系统的基板上运⾏。

打击康威定律

这样就很重要了：将所有依赖项打包到容器或VM镜像本⾝中，基本操作系统就不再重要了。它使我们能够在每个项⽬的基础上以各⾃的速度前进。

该项⽬将⾃带数据库，缓存，运⾏时和库，⽽不会发⽣版本冲突，也⽆需等待发⾏版对其进⾏升级或完全提供。相反，它允许Distro迁移到Stream：它们最终摆脱了缓慢发展的OSS项⽬，从⽽阻⽌了它们升级本地组件，因为其中⼀个尚不准备就绪。

甚⾄企业中的团队现在也可以按照⾃⼰的速度⾃由移动，因为他们不再需要等待六位利益相关者进⼊积压的技术债务部门。

我认为主要要点是，应⽤程序使⽤与主机使⽤的不同的“不再是完整的操作系统”是正常且正常的。承认两者都可以缩⼩范围和规模，并进⾏优化。这是⼀件好事，将加速发展。

因此，在⼀个将组件及其依赖项打包为单⽤户单租户执⾏单元（虚拟机，容器等）的世界中，CentOS迁移到Streams不仅承认了这⼀变化，⽽且还迫使缓慢的⼀半世界承认并接受它。我说：这是⼀件好事。