背景

CentOS 7 自身的生命周期截止到 2024 年 6 月 30 日。在 2020 年底，CentOS  社區(qū)宣布修改現(xiàn)有的發(fā)布模式，將 CentOS 從作為 RHEL 的下游改為 CentOS Stream，即 RHEL 的上游，更導(dǎo)致  CentOS8 的生命周期短的可憐，這讓社區(qū)中原本就對(duì) CentOS 不滿的開發(fā)者 / 使用者不滿，從而出現(xiàn)了拋棄 CentOS  轉(zhuǎn)投其他發(fā)行版的情況。

大家選擇使用 CentOS ，雖然都在說穩(wěn)定，但是我理解更看重的是 RedHat 在身后背書，CentOS 作為 RHEL 的下游，所有的軟件版本都是經(jīng)過 RedHat 測(cè)試驗(yàn)證的，且后期維護(hù)也是有 RedHat 的身影在，不擔(dān)心維護(hù)的問題。

CentOS 原有的模式也是有問題的，用戶很難參與到 RHEL 的研發(fā)周期。用戶發(fā)現(xiàn)了 CentOS 某個(gè)版本存在問題，想要給  CentOS 進(jìn)行貢獻(xiàn)，讓 CentOS 下一個(gè)版本修復(fù)該問題。此時(shí)只有一條路，就是貢獻(xiàn)給開源組件自身，但是這樣也只是存在修復(fù)的可能，最終是否可能修復(fù)還是看 RedHat 開發(fā)人員的決定（畢竟 RHEL/CentOS 中存在大量開源組件自身不包含，但是 RHEL/CentOS 通過 rpm spec 中進(jìn)行 Patch 的方式包含的 Patch）。在引入了 CentOS Stream 之后，用戶就可以通過貢獻(xiàn)給 CentOS 社區(qū)，來保證 CentOS 下一個(gè)版本包含該 Patch，至于 RHEL 是否包含，用戶并不關(guān)心，那是 RedHat 關(guān)心的問題。

Fedora 更關(guān)注于上游社區(qū)最新的代碼，包含最豐富的功能，作為先驅(qū)者；CentOS Stream 作為 RHEL 的上游，提供穩(wěn)定可靠的持續(xù)交付版本，保證更多的貢獻(xiàn)者可以參與進(jìn)來；RHEL 給企業(yè)用戶使用，有 RedHat 提供完整的維護(hù)服務(wù)。

在現(xiàn)有的模式下，CentOS Stream 已經(jīng)與原有采用 CentOS 的用戶初衷背離，已有的 CentOS7 用戶需要尋找新的替代品，在國(guó)產(chǎn)化的浪潮下，選擇的方向也發(fā)生了一定的變化。

社區(qū)替代品

Rocky Linux

   ?

   Rocky Linux aims to function as a downstream build as CentOS had done previously, building releases after they have been added to the  upstream vendor, not before.

AlmaLinux

   ?

   AlmaLinux OS is replacing CentOS as the downstream rebuild of RedHat Enterprise Linux.

在 CentOS 宣布策略改變之后，社區(qū)中出現(xiàn)了兩個(gè)替代品，分別是 Rocky Linux 和 AlmaLinux，它倆的目的都是一樣的，作為 RHEL 的下游來構(gòu)建發(fā)布，且發(fā)布模式和發(fā)布周期采用 CentOS 原有模式。

通過 AlmaLinux 官方提供的發(fā)行版比較[1] 可以看到，AlmaLinux 和 Rocky Linux 兩者對(duì)于用戶來說沒什么差別，如果一定要較真，那就是 AlmaLinux 大部分人員是來自 CloudLinux 公司，而 Rocky Linux 是 Greg 公司。

國(guó)產(chǎn)替代品

Anolis OS（阿里巴巴）

   ?

   Anolis OS 8 是 OpenAnolis 社區(qū)推出的完全開源、中立、開放的發(fā)行版，它支持多計(jì)算架構(gòu)，也面向云端場(chǎng)景優(yōu)化，兼容  CentOS 軟件生態(tài)。Anolis OS 8 旨在為廣大開發(fā)者和運(yùn)維人員提供穩(wěn)定、高性能、安全、可靠、開源的操作系統(tǒng)服務(wù)。

openEuler（華為）

   ?

   openEuler 是一款開源操作系統(tǒng)。當(dāng)前 openEuler 內(nèi)核源于 Linux，支持鯤鵬及其它多種處理器，能夠充分釋放計(jì)算芯片的潛能，是由全球開源貢獻(xiàn)者構(gòu)建的高效、穩(wěn)定、安全的開源操作系統(tǒng)，適用于數(shù)據(jù)庫(kù)、大數(shù)據(jù)、云計(jì)算、人工智能等應(yīng)用場(chǎng)景。同時(shí)，openEuler 是一個(gè)面向全球的操作系統(tǒng)開源社區(qū)，通過社區(qū)合作，打造創(chuàng)新平臺(tái)，構(gòu)建支持多處理器架構(gòu)、統(tǒng)一和開放的操作系統(tǒng)，推動(dòng)軟硬件應(yīng)用生態(tài)繁榮發(fā)展。

銀河麒麟操作系統(tǒng)

   ?

   銀河麒麟高級(jí)服務(wù)器操作系統(tǒng) V10 是針對(duì)企業(yè)級(jí)關(guān)鍵業(yè)務(wù)，適應(yīng)虛擬化、云計(jì)算、大數(shù)據(jù)、工業(yè)互聯(lián)網(wǎng)時(shí)代對(duì)主機(jī)系統(tǒng)可靠性、安全性、性能、擴(kuò)展性和實(shí)時(shí)性等需求，依據(jù) CMMI5 級(jí)標(biāo)準(zhǔn)研制的提供內(nèi)生本質(zhì)安全、云原生支持、自主平臺(tái)深入優(yōu)化、 高性能、易管理的新一代自主服務(wù)器操作系統(tǒng)

在國(guó)產(chǎn)化浪潮下，如果產(chǎn)品需要滿足信創(chuàng)標(biāo)準(zhǔn)，那么操作系統(tǒng)的選擇需要考慮國(guó)產(chǎn)替代品，目前（個(gè)人了解）符合信創(chuàng)標(biāo)準(zhǔn)的操作系統(tǒng)只有銀河麒麟，openEuler 和 Anolis OS 目前還無(wú)法完全通過信創(chuàng)評(píng)審。在這一系列的替代品中， Rocky Linux, AlmaLinux, Anolis OS 所采用的發(fā)布模式和版本控制方式，都維持 CentOS 原有模式，即 8.1, 8.2, 8.3 發(fā)布方式。openEuler  和銀河麒麟操作系統(tǒng)雖然也采用 RPM 作為包管理器并且大部分組件版本與社區(qū)中的 CentOS 8 相同，但是不能完全等價(jià)，這里需要注意。

比較選擇

如果要滿足信創(chuàng)要求，那么只能選擇銀河麒麟作為替代品；如果從使用角度考慮，選擇 Rocky Linux/AlmaLinux/Anolis OS 是更好的選擇，有良好的社區(qū)支持，版本控制也與 CentOS  保持一致，心智負(fù)擔(dān)更低；如果從國(guó)產(chǎn)硬件支持考慮，openEuler 是不錯(cuò)的選擇。

上述討論的各個(gè)發(fā)行版，當(dāng)前所采用的包管理器均為 RPM，所有軟件均已 RPM 為粒度安裝，在 RPM 之上，會(huì)存在 Yum/DNF 包含  RPM 依賴管理、沖突管理、升降級(jí)等功能的基于 RPM 的包管理器。其中 CentOS 7 系列所采用的基于 RPM 的包管理器是  Yum，其他發(fā)行版當(dāng)前維護(hù)版本所采用的基于 RPM 包管理器是 DNF(Dandified Yum)。

升級(jí)轉(zhuǎn)換

在現(xiàn)有使用了 CentOS 7 的環(huán)境中，需要使用替代品將 CentOS 7 升級(jí)轉(zhuǎn)換為目標(biāo)發(fā)行版。

如果應(yīng)用環(huán)境都是單體應(yīng)用，且可以有下線維護(hù)時(shí)間，進(jìn)行數(shù)據(jù)備份然后完整的重裝 OS  是一個(gè)穩(wěn)妥的選擇。如果應(yīng)用環(huán)境是集群，且大部分應(yīng)用都已經(jīng)容器化了，那么依次進(jìn)行單節(jié)點(diǎn)重裝 OS  需要認(rèn)真測(cè)試驗(yàn)證，不同的發(fā)行版版本的默認(rèn)系統(tǒng)參數(shù)可能存在差異，哪怕上層基礎(chǔ)平臺(tái)保證了版本一致（如  Kubernetes,containerd,runc 的版本一致），也可能導(dǎo)致異常情況。

如果選擇不重裝 OS，原地升級(jí)轉(zhuǎn)換的話有兩種方式：自動(dòng)和手動(dòng)。其中 Rocky Linux/AlmaLinux/Anolis OS 提供自動(dòng)升級(jí)轉(zhuǎn)換方式，openEuler 和銀河麒麟可以采用手動(dòng)轉(zhuǎn)換方式。

自動(dòng)流程

自動(dòng)升級(jí)轉(zhuǎn)換依賴于 Leapp[2]，Leapp 由 Redhat 員工開發(fā)的開源工具，Leapp 自身只是一個(gè)工作流框架，其中包含 Actor、Model、Message、Workflow  等概念，具體組件關(guān)系圖如下，其中 workerflow 包含多個(gè) phase，每個(gè) phase 含有 3 個(gè)  stage：Before，Main，After，每個(gè) stage 中包含多個(gè) Actors，其中 Actors 之間沒有嚴(yán)格的順序，而是靠  Message 通信，Message 遵循 Model 的定義，如果 ActorA 依賴了 ActorB 產(chǎn)生的 MessageB，那么  ActorA 會(huì)在 ActorB 之后執(zhí)行，沒有 MessageB 依賴的 ActorC 會(huì)按照加載順序執(zhí)行，沒有嚴(yán)格順序依賴。

目前 Leapp 主要使用場(chǎng)景是用于 RedHat 系發(fā)行版升級(jí)、不同發(fā)行版之間的升級(jí)切換等。

在完整的升級(jí)流程中，使用統(tǒng)一定義的 Workflow，不同階段（如預(yù)升級(jí)、升級(jí)、Firstboot）都是調(diào)用的同一個(gè) Workflow，只是根據(jù)指定的不同的 Tag、參數(shù)來決定執(zhí)行的 Phase 不同。

•  預(yù)升級(jí)（preupgrade），進(jìn)行環(huán)境信息的收集與檢查，將檢查結(jié)果以報(bào)告的形式提供給用戶，這里進(jìn)行的信息收集及檢查項(xiàng)數(shù)量很大，包含了很多細(xì)節(jié)，除了包含一些基礎(chǔ)組件的檢查：CPU 架構(gòu)、openssh 配置變更、PAM 模塊變更、Driver 支持、NTP 變更等之外，還包含一些第三方應(yīng)用的檢查：SAP  HANA、Memcached、寶塔等。
  
•  升級(jí)（upgrade），升級(jí)的主要?jiǎng)幼?，與預(yù)檢查使用的是相同 Workflow。
  

•   configuration_phase
  
•   FactsCollection
  
•   Checks
  
•   TargetTransactionFactsCollection，生成臨時(shí) minimal 環(huán)境，包含完整的目標(biāo)版本的運(yùn)行環(huán)境，用于使用目標(biāo)版本的工具棧，比如 DNF、RPM 高級(jí)特性等，該環(huán)境還會(huì)用來生成下一步驟所需的 initramfs image
  
•   TargetTransactionCheck，通過上述生成的 minimal 環(huán)境，使用其中的 dnf 工具，dnf rhel-upgrade check 來檢查當(dāng)前節(jié)點(diǎn)是否可以進(jìn)行升級(jí)
  
•   Reports
  
•   Download，升級(jí)所需軟件包下載步驟， dnf rhel-upgrade download
  
•   InterimPreparation，生成下一步驟所需的 initramfs，在前述步驟中的 minimal 環(huán)境中安裝 dracut 相關(guān)工具包，使用 dracut[3] 生成 initramfs image，生成完成后調(diào)整系統(tǒng)啟動(dòng)項(xiàng)，將其置為第一個(gè)啟動(dòng)項(xiàng)
  

•  臨時(shí)環(huán)境升級(jí)（Interim Upgrade），真正執(zhí)行 RPM 升級(jí)的步驟，與預(yù)檢查使用的是相同的 Workflow
  

•   在系統(tǒng) reboot 后，系統(tǒng)引導(dǎo)到前置步驟生成的 initramfs 中，系統(tǒng)正常引導(dǎo)，dracut hook 中，增加了兩個(gè) hook，分別是 85sys-upgrade-redhat[4] 和 90sys-upgrade[5]， 其中 85 是真正執(zhí)行節(jié)點(diǎn)軟件包升級(jí)的動(dòng)作 (leapp upgrade –resume），90 配置 systemd upgrade unit （與重啟相關(guān)）
  
•  InitRamStart，移除啟動(dòng)項(xiàng)設(shè)置
  
•  LateTests
  
•  Preparation
  
•  RPMUpgrade，dnf rhel-upgrade upgrade 升級(jí) RPM
  
•  Applications
  
•  ThirdPartyApplications
  
•  Finalization
  

•  升級(jí)后動(dòng)作（Firstboot），系統(tǒng)升級(jí)完成會(huì)，會(huì)自動(dòng) reboot 進(jìn)入到目標(biāo)版本系統(tǒng)中，此時(shí)會(huì)執(zhí)行 Firstboot 階段，在執(zhí)行完成后，系統(tǒng)升級(jí)完成
  

•  FirstBoot，執(zhí)行清理動(dòng)作，修改部分配置（NM）等
  

完整升級(jí)流程共執(zhí)行 4 次 Workflow，其中采用臨時(shí)環(huán)境執(zhí)行升級(jí)動(dòng)作的目的是：升級(jí)動(dòng)作執(zhí)行工具鏈?zhǔn)悄繕?biāo)環(huán)境對(duì)應(yīng)版本的工具鏈。

自動(dòng)實(shí)現(xiàn)方式

項(xiàng)目地址列表：

•  https://github.com/oamg/leapp
  
•  https://github.com/oamg/leapp-repository
  
•  https://github.com/AlmaLinux/leapp-data
  

其中 leapp 是框架自身，leapp-repository 是 Leapp 的應(yīng)用實(shí)現(xiàn)，也就是升級(jí)中所執(zhí)行的 Actor  實(shí)現(xiàn)，leapp-data 是升級(jí)中所用到的基礎(chǔ)配置信息。不同發(fā)行版會(huì)維護(hù)自己的 leapp-repository，比如 Anolis OS  就維護(hù)了自己的 Git 倉(cāng)庫(kù)（在 Gitee 上），并針對(duì)性的增加了自己的檢查項(xiàng)。在 Leapp  的架構(gòu)中，因?yàn)樽罱K的應(yīng)用會(huì)以獨(dú)立的插架形式安裝，所以 Python 的 syspath  可能會(huì)發(fā)生變化，在查看代碼的時(shí)候需要對(duì)應(yīng)的修改一下路徑地址。以 NTP 檢查為例：

NTP 檢查的 Actor 實(shí)現(xiàn)：

from leapp.actors import Actor
from leapp.libraries.actor.checkntp import check_ntp
from leapp.models import InstalledRedHatSignedRPM, NtpMigrationDecision, Report
from leapp.tags import ChecksPhaseTag, IPUWorkflowTag
class CheckNtp(Actor):
   """
   Check if ntp and/or ntpdate configuration needs to be migrated.
   """
   name = 'check_ntp'
   consumes = (InstalledRedHatSignedRPM,)
   produces = (Report, NtpMigrationDecision)
   tags = (ChecksPhaseTag, IPUWorkflowTag)
   def process(self):
       installed_packages = set()
       signed_rpms = self.consume(InstalledRedHatSignedRPM)
       for rpm_pkgs in signed_rpms:
           for pkg in rpm_pkgs.items:
               installed_packages.add(pkg.name)
       self.produce(check_ntp(installed_packages))

Actor 中調(diào)用的 check_ntp 函數(shù)實(shí)現(xiàn)：

# Check services from the ntp packages for migration
def check_ntp(installed_packages):
   service_data = [('ntpd', 'ntp', '/etc/ntp.conf'),
                   ('ntpdate', 'ntpdate', '/etc/ntp/step-tickers'),
                   ('ntp-wait', 'ntp-perl', None)]
   migrate_services = []
   migrate_configs = []
   for service, package, main_config in service_data:
       if package in installed_packages and \
               check_service('{}.service'.format(service)) and \
               (not main_config or is_file(main_config)):
           migrate_services.append(service)
           if main_config:
               migrate_configs.append(service)
   if migrate_configs:
       reporting.create_report([
           reporting.Title('{} configuration will be migrated'.format(' and '.join(migrate_configs))),
           reporting.Summary('{} service(s) detected to be enabled and active'.format(', '.join(migrate_services))),
           reporting.Severity(reporting.Severity.LOW),
           reporting.Groups([reporting.Groups.SERVICES, reporting.Groups.TIME_MANAGEMENT]),
       ] + related)
       # Save configuration files that will be renamed in the upgrade
       config_tgz64 = get_tgz64(files)
   else:
       api.current_logger().info('ntpd/ntpdate configuration will not be migrated')
       migrate_services = []
       config_tgz64 = ''
   return NtpMigrationDecision(migrate_services=migrate_services, config_tgz64=config_tgz64)

手動(dòng)流程

對(duì)于 Linux 發(fā)行版來說，整體是由無(wú)數(shù)個(gè) RPM 組成的，最終系統(tǒng)中看到的最小粒度就是 RPM，我們可以通過 RPM  的升級(jí)來完成整體的發(fā)行版的升級(jí)變更。但是對(duì)于部分 RPM 來說，RPM 之間的依賴阻礙了我們無(wú)法通過依次升級(jí)部分 RPM  的方式來完成完整的升級(jí)替換，其中一些關(guān)鍵組件，如 glibc、glib2、openssl  等等都是強(qiáng)依賴的，我們必須要找到一個(gè)方式來完成整體的升級(jí)。在 Yum 中，存在 distribution-synchronization 命令用來同步當(dāng)前 OS 中所有的 RPM 到目標(biāo) Repository 中的版本，但是用 Yum 可能會(huì)存在無(wú)法識(shí)別 rpmlib  的情況。RPM 作為基礎(chǔ)包管理器，自身會(huì)存在部分高級(jí)特性以 rpmlib 的依賴形式提供，如果當(dāng)前系統(tǒng)的包管理器無(wú)法識(shí)別  rpmlib，那么就會(huì)在同步過程中出現(xiàn)無(wú)法解決的依賴沖突。

舉例：目標(biāo) RPM 為 dnf-4.2.23-6.oe1.noarch.rpm ，升級(jí)提示依賴  rpmlib(RichDependencies) <= 4.12.0-1 沖突。這是因?yàn)?dnf-4.2.23 這個(gè) RPM  在構(gòu)建的階段，所使用的 rpm 環(huán)境（可能是在 openEuler 20.03 或更高版本）比當(dāng)前 OS 的 RPM 版本（CentOS  7）高，所以當(dāng)前 rpm 無(wú)法滿足這個(gè)依賴條件。

我們可以使用 DNF 的 distro-sync 并配合部分的 RPM 修改，來完成手動(dòng)升級(jí)轉(zhuǎn)換。流程如下：

•  將當(dāng)前 CentOS7 升級(jí)到 CentOS 7.x 系列最新版本；
•  停止節(jié)點(diǎn)上運(yùn)行的所有應(yīng)用
  
•  配置 CentOS7 Repository ，安裝 DNF（DNF 依賴于 glib2 的執(zhí)行版本，但是未在 spec 中聲明，需要單獨(dú)升級(jí) glib2）
  
•  移除 Yum 管理器，防止與 DNF 產(chǎn)生沖突
  
•  配置目標(biāo)發(fā)行版 Repository
  
•  使用 dnf distro-sync 進(jìn)行升級(jí)轉(zhuǎn)換
  
•  使用 dnf remove 移除無(wú)用 RPM
  
•  重啟主機(jī)生效
  

手動(dòng)實(shí)現(xiàn)方式

當(dāng)前 CentOS7 包管理器是 Yum，在目標(biāo)版本中包管理器是 DNF，在通過 Yum 安裝 DNF ，在保證 Yum(DNF) Repository 配置是目標(biāo)版本的前提下，使用 dnf distro-sync 命令來進(jìn)行 RPM 的升級(jí)和同步，該命令會(huì)將當(dāng)前 OS 已經(jīng)安裝的 RPM 與 Yum Repository 中的 RPM 進(jìn)行匹配。RPM 版本匹配存在以下幾種情況：

•  當(dāng)前 RPM 版本低于目標(biāo) Repository 中包含的 RPM 版本，則會(huì)升級(jí)；
  
•  當(dāng)前 RPM 版本高于目標(biāo) Repository 中包含的 RPM 版本，則會(huì)降級(jí)；
  
•  當(dāng)前 RPM 被目標(biāo) Repository 中包含的 RPM 所替代（指定 Obsolete），則會(huì)安裝新 RPM，原有 RPM 被卸載（替代）；
  
•  當(dāng)前 RPM 版本與目標(biāo) Repository 中包含的 RPM 版本相同，但 dist 等其他 RPM 元數(shù)據(jù)不同，則會(huì)重新安裝；
  
•  當(dāng)前 RPM 是被其他 RPM 依賴引入的，但是其他 RPM 已經(jīng)被替代，則該 RPM 會(huì)被卸載；
  
•  當(dāng)前 RPM 在目標(biāo) Repository 中不包含，則不會(huì)進(jìn)行處理；
  

總結(jié)

通過自動(dòng)或者手動(dòng)的方式，我們可以原地將 CentOS 7 升級(jí)轉(zhuǎn)換為我們想要的目標(biāo)發(fā)行版。社區(qū)的 Rocky Linux/AlmaLinux/Anolis OS  可以采用自動(dòng)的方式完成 ，國(guó)產(chǎn)非等價(jià)替代的 openEuler 可以采用控制 Repository 的方式手動(dòng)完成，減少發(fā)行版變更帶來的工作量。