拥抱centos stream


2020年12月8日，​​CentOS项目将重点转移到CentOS Stream​​


CentOS项目的未来是CentOS Stream，在明年，我们将把重点从重建Red Hat Enterprise Linux（RHEL）的CentOS Linux转移到CentOS Stream，后者紧跟当前RHEL版本发布。作为对RHEL 8的重建，CentOS Linux 8将于2021年底结束。CentOS Stream在此日期之后继续，作为Red Hat Enterprise Linux的上游（开发）分支。


大多数人的反应都是抗拒， 包括我，已经开始准备测试 Ubuntu、Debian 了。

拥抱 centos stream_git

仔细思考下来，其实 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，获得了​​The Serverless Sea Change​​和Step Functions。我们还获得了Nocode，无代码或类似的尝试，仅从服务中构建某些东西而没有实际编码。

但这比这更普遍：


  • Unifi控制平面使用多个Java进程和一个Mongodb。可以将其打包到一个镜像，也可以将其作为舵图提供，也可以将其作为包含多个容器的泊坞窗提供，以实现更好的可伸缩性和维护性。
  • gitlab Omnibus再次使用单个容器，并带有Postgres，Redis和许多内部状态以及Chef，以部署大约十二个组件，但是在K8s上下文中还存在针对各个组件的差异部署。
  • 像Jitsi设置之类的东西可以打包到一个相对简单的docker-compose.yml中，并且将自动从镜像中自动组装它们。只要提供Linux内核syscall接口，结果就可以在几乎所有操作系统的基板上运行。

打击康威定律

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

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

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

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

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

我说：这是一件好事。