后 CentOS 的时代的操作系统漫谈

后 CentOS 时代

可能由于习惯，也可能由于红帽早年在国内推广得力，目前大家生产环境所用的 Linux 操作系统里， CentOS 系列占据了较大的比重。然而众所周知，由于各方面的原因，CentOS Linux 即将退出舞台。CentOS Linux8 诞生仅 1 年即夭折，CentOS Linux7 成为绝唱，后续将只剩下 CentOS Stream 这个鸡肋版本。关于他们的区别，可见下图：

而为什么最好不要在生产环境上去用 CentOS Stream，大体有以下几个理由

（以下所有内容节选自红帽官网 Why choose Red Hat Enterprise Linux over CentOS Stream for production use）

• 偏短的生命周期（5 年），没有自动升级工具

• 更激进的内容更新，可能破坏生产环境的兼容性

• 无差别系统更新，无法只更新安全补丁，补丁不保证安全/可靠。

• 随着持续迭代，难以迁移到其他系统

兼容性

CentOS 的替代方案当然要考虑兼容性，通常我们评估操作系统的兼容性支持会考虑以下几个方面：

1. 硬件架构的兼容性。这里包括 CPU 的指令架构的兼容（x86/arm），网卡，主板等各类硬件的驱动兼容等。硬件兼容是操作系统兼容性中最重要的部分，因为操作系统本来就是与硬件打交道的东西嘛。如果我们需要在物理服务器上安装一个陌生的操作系统，那么务必要提前确认相关硬件的兼容性支持，以规避各种硬件无法识别的问题。然而对于虚拟化环境而言，由于屏蔽了硬件层，通常不太存在这方面的兼容性的问题。

2. 操作系统调用的兼容性。对于跨硬件架构的运行环境，应用程序的移植是一个大问题，因为底层调用可能会有非常大的差异。但在相同的硬件架构下，仅不同的 Linux 发行版之间，大多数情况下不涉及这个问题。因为 Linux 遵循 POSIX 标准，涉及操作系统底层调用的部分，在 POSIX 标准下都是可以兼容执行的（并且还可以兼容大部分 UNIX 操作系统）

3. 依赖软件包的兼容性。这部分是兼容性评估最重要的部分，虽然说软件包依赖总是可以通过自己编译安装的方式搞定，但这一来很麻烦，二来编译环境和参数的差异也可能带来不确定性。我们总是希望通过操作系统自带的包管理器来搞定软件包的依赖，因此这是评估的重点。

4. 脚本/配置的兼容性。不同操作系统发行版的软件包版本，可能存在差异。部分软件可能存在高低版本之间的配置不兼容情况，需要进行重新配置。脚本所依赖的脚本语言，也可能存在版本兼容的问题——例如在 CentOS7 上默认的 python 版本是 2.7，而后续操作系统的内置版本一定是 python3 ，涉及 python 脚本的部分必然要考虑 2/3 的兼容迁移问题。

兼容性的评估应该重点放在脚本/配置和包管理器上。通常来说 shell 脚本对环境一致性要求较高，他的可迁移性较差，需要重点评估。python 脚本则重点需要考虑 python2 -> python3 的迁移问题。包管理器则可能影响一些脚本式安装程序的迁移平滑度，如果存在这类的场景，则尽量应该选择相同的包管理器（yum/dnf）的操作系统方案，比如 ubuntu 在这个场合下可能就不合适。

部分操作系统提供了业务迁移的兼容性评估工具，可以通过工具扫描来评估业务迁移的兼容性风险，这对于关键业务迁移评估非常重要。

尽管部分操作系统（例如 rocky，Anolis 等）提供了原地迁移的脚本工具，但我们还是建议尽量选择新建操作系统重新部署相关业务，再通过调度引流的方式切换业务，并逐步下线老服务器。

但对于大部分应用场景而言，内核版本相近的 Linux 发行版之间，应该都可以实现业务的迁移运行。

社区生态

在评估了兼容性之后，另一个重点是操作系统的可靠，稳定和可持续性。如果选用商业的操作系统，那这些就由供应商去承诺好了。在开源的选项中，这一切都是由社区的生态所决定的。

Linux 作为 GPL 协议下的开源操作系统内核，发行版本多如牛毛，然而大家熟知的版本却一个手数的过来。生态良好，积累的大量用户的社区，他天然的就拥有自我完善持续迭代的能力，并在庞大的用户基数下不断的验证系统的可靠性。

简单来讲，用的人越多越好。

因此如果不看重包管理器的一致性，那么 ubuntu 是一个久经考验的发行版。如果考虑包管理器的一致性，那么 CentOS 创始人背书，社区日益完善的 rocky 和有着 Oracle 支持的 Oracle Linux，都是很好的选择。

国产化的选择

Github 封禁伊朗开发者的事情告诉我们，开源毕竟也是分国界的。国产化的运行环境替代，即便暂时不应用在生产，也是值得去做一些测试和体验的。

对于开源的国产操作系统而言，有两个生态较好的国产开源项目可供参考：

1. 由阿里发起的 Anolis ，与 CentOS 生命周期一致（类似 rocky），提供 centos2anolis 的直接迁移工具。目前最新的版本是 Anolis 8.6 ，Linux Kernel 版本 4.19 —— 对标 RHEL 8.6， 。

2. 由华为发起，开放原子开源基金会 孵化的 OpenEuler ，采取相对独立的生命周期管理（有点像 ubuntu），但使用与 CentOS 一致的 rpm 包管理生态。目前最新版本是 openEuler 22.03 LTS , Linux Kernel 版本 5.10。

我们在 OpenEuler 上做了一些简单的尝试，并计划进一步迁移更多的业务到国产化的操作系统上。

迁移 Shibboleth IdP 至 OpenEuler

作为尝鲜也为了测试，我们在一些相对边缘的业务开启了国产化操作系统的迁移。首先尝试的是提供 SAML2.0 认证协议支持的 Shibboleth-IdP 服务。

Shibboleth-IdP 是一个 Java 应用，除了 jdk 以外所依赖的只有 nginx，mysql 等非常主流的软件。而我们已知 nginx，openjdk，mariadb 都是在 OpenEuler 的内置软件包仓库中，确定兼容支持的。因此这个业务的迁移完全无需做兼容性测试，我们可以确定他一定是可以 100%兼容的。

类似 Java 这样有虚拟机运行时语言开发的业务迁移都非常简单，runtime 屏蔽了大部分的操作系统底层细节，大体上只要把新操作系统下各类的相关环境准备好。然后把原服务器上的内容打包拷过来就完事了。

操作系统

我们选用 openEuler-22.03-LTS 来作为迁移的目标操作系统，挂载镜像安装，非常熟悉的界面。

环境安装

参照 IdP4升级方案 ，分别安装好 java, tomcat, nginx 等相关环境。注意在 OpenEuler 中，官方的 repo 里已经内置 nginx，因此安装 nginx 时就不需要去 nginx.org 拉 repo 了。直接 dnf install nginx 即可。

如果我们的 IdP 服务器采取了数据库存储 eptID 的方案，那么我们还需要安装数据库。参照 eptID配置 中相关文档，安装数据库。

上海教育认证的文档建议安装 MySQL5.7，这主要是因为 CentOS7 自带的 MariaDB 版本太低了。在 OpenEuler 22.03 中的 MariaDB 版本是 10.5，这个相当于对标 RHEL 9 了，建议直接装 MariaDB 就好。

业务迁移

在环境准备好以后，迁移业务本身确实只需要拷过来就好了。我们在老服务器上对 /opt/shibboleth-idp 打一个包，然后拷到新服务器上解压到同目录即可。

无感知切割

得益于 Shibboleth-IdP 的前通道技术架构，我们可以让我们新旧服务的切割过程对用户完全无感。简单来说测试的时候修改本地 host 到新服务器上进行测试，测试完成后：

1. 如果是直接发布到服务器上的模式，修改生产环境 DNS 完成迁移。

2. 如果服务器前面还有代理或者负载均衡，修改 proxy 的后端服务器池，增加新服务器并移除老服务器完成迁移。

详见 IdP4无感知迁移上线

结束语

不出意外的话，CentOS 的时代再过 2 年就将彻底拉下帷幕了。后 CentOS 的时代群雄崛起，也给了国产操作系统非常好的机会。Anolis 和 OpenEuler 都是国产开源的佼佼者，既然都是要更换操作系统，为什么不尝试一下国内的开源方案呢？

以上