Red Hatの森若です。
この記事は Software Design 2021年3月号 に執筆した「CentOS Stream入門」の原稿から派生させた記事です。
CentOS Streamとは?
CentOS Streamは2019年9月に公開された比較的新しいLinuxディストリビューションです。 その後2020年12月に、CentOS プロジェクトが出荷されたRHELをリビルドしたCentOS Linuxの作成を近い将来やめ、CentOS Streamへシフトする発表を行いました("CentOS Project shifts focus to CentOS Stream")。このアナウンスでCentOS Streamの存在を知ったという方も多いかと思います。今回はこのCentOS Streamを紹介していきます。
CentOS Streamは安定志向のディストリビューションで、将来のRHELに含まれる予定のソフトウェアが各種のテストを通過した場合のみパッケージが更新されます。RHELとの違いはパッケージのリリースタイミングが随時行われるローリングリリースモデルであることです。RHELのようなマイナーリリース(8."2"や8."3"など)は存在しませんし、yumリポジトリには最新のパッケージしか含まれません。
一方メジャーバージョンははっきりと区別されており、CentOS Stream 8をインストールしたらいつのまにかCentOS Stream 9になっていたというようなことは発生しません。逆に考えると、現在のところ8から9へのスムーズなアップグレード方法がありません。
用途に制限はありませんが、Red Hat Enterprise Linux(以下RHEL)をターゲット環境とするソフトウェア開発者がCI環境で利用することを強く意識しています。開発者・利用者からのフィードバックを受けつけ、素早く対応するための窓口となることも期待されています。現在RHELやCentOS Linuxなどを使っている方の内、日常的にパッケージを最新へ更新している方であれば違和感なく利用できると思います。
利用者視点でのCentOS Stream
利用する側から見たCentOS Streamの特徴を見ていきます。
常に機能拡張を含む最新パッケージしか提供されませんから、バージョンや機能セットを固定して維持したい用途には向きません。そのような場合にはRHELが向いています。一方RHELむけのソフトウェア開発を行っている場合や、新規ソフトウェアを利用したい場合には(問題なければ)将来のRHELに含まれるソフトウェアが使えるので便利に使えます。
CentOS Streamに含まれるソフトウェアのセットは、基本的にRHELと同じです。次のリリースで投入予定のバージョンであるほか、Red Hatの商標やCPE等のOS名、リポジトリ設定、パッケージの署名などは違います。
CentOS Streamに「マイナーリリース」はなく、ある時点でバージョンや機能を固定してメンテナンスされることはありません。パッケージの互換性維持の方針はRHELに準じます("Red Hat Enterprise Linux 8: Application Compatibility GUIDE")。
CentOS Streamのライフサイクルは、対応するRHELのフルサポート期間(5年間)が終わるまでの間です。RHEL 8のフルサポート期間は2024年5月末までですから、CentOS Stream 8もそこで廃止され、メンテナンスは終了します。RHELのメジャーバージョンの出荷は3年おきなので、対応するRHELリリース前の期間(RHEL 9以降ではGA前にCentOS Streamが先に公開予定)をのぞいた5年間のライフサイクルのうち、2年間は次のメジャーバージョンと並行して提供されます。
ソフトウェア修正の出荷時期は場合により前後関係が変わります。RebaseやupstreamプロジェクトからのバックポートなどはRHELより早くCentOS Streamへ公開されます。一方パートナとのNDAや、セキュリティ修正のembargo期間など守秘義務がある場合、RHELのパッケージ公開後にCentOS Streamへ公開されます。RHELではerrataが出荷されても、CentOS Streamではrebaseにより対応が不要なケースもありますので、RHELとCentOS Streamのパッケージは1対1に対応しません。
RHELのために開発・整備されている大量のテストを通過したパッケージだけがCentOS Streamとして公開されるので、CentOS Streamにパッケージが登場する時点で安定していると言ってよいと思います。問題を発見した場合には、後述のBugzillaへ報告やパッチを送ることができ、Red Hatのエンジニアにより修正やテスト拡張などの対応が行われます。
このようにCentOS StreamはRHELと深い関係がありますが、Red Hatの製品ではないので、製品としてのサポートや各種認定プログラムなどは存在しません。
RHEL開発をオープンにするCentOS Stream
Red Hatの視点では、CentOS StreamはRHELの開発をオープンにしていく取り組みのひとつです。将来RHELに含まれる修正や機能追加の状況をコミュニティから随時アクセス可能にすることで、変更に対するフィードバックとその対応を容易かつ早くするすることが狙いの一つです。
CentOS Streamの位置づけはRHELのNightlyビルドにあたります。単一ソフトウェアのNightlyビルドとは少し異なり、ここではディストリビューションの最新パッケージ群のセットのことを示しています。Red Hatのエンジニア達が次のマイナーリリースに含めようとしているバージョン変更、機能追加、バグ修正、セキュリティ修正などの内、テストを通過したものが随時追加されていきます。これはCentOS Streamが現れる以前にはRed Hat社内と、ごく一部のパートナーしかアクセスできないものでした。
図1にイメージ図を描いています。Fedora Rawhideではどんどん新バージョンや新機能を統合し、品質保証プロセスを経てFedoraがリリースされます。新しいRHELはFedoraからforkして開発が始まり、CentOS Streamとなります。約1年ほどの開発ののち、新しいメジャーバージョンのRHELとしてリリースされます。
図1 Fedora Rawhide, Fedora, CentOS Stream, RHELの関係図
CentOS Stream以外にも、upstreamの最新kernelとのCIを継続的に行うAlways Ready Kernelや、通常のFedoraリリースとは別にRHELに相当する設定(たとえばFedoraにはbtrfsが含まれますがRHELには含まれません)でパッケージのビルド、CIを行うFedora ELNなどの取り組みを行っています。
問題発生期間の短縮
モデルケースを使って、CentOS Streamが存在しない従来のRHEL開発と、CentOS Streamが組み込まれたRHEL開発を比較してみます。RHELに含まれているソフトウェアを開発するOSSプロジェクト「upstreamプロジェクトA」と、RHELでの動作をサポートする「ISV製品B」が登場します。
図2はCentOS Streamがないときの開発です。わかりやすさのためにRHEL 7という名前にしていますが、リリースタイミングはRHEL 8以降と同じく定期的に行われるように絵を描いていますので実際とは異なります。
- upstreamプロジェクトAにISV製品Bと非互換な変更が行われます。
- 7.1リリース後、upstreamプロジェクトAの更新を取りこみます。
- 非互換な変更を含む7.2がリリースされます。
- ISV製品Bのテスト環境を7.2へ更新し、問題が発見・報告されます。
- 原因調査ののちRed Hatが問題を修正します。このときupstreamプロジェクト A でまず修正を行い、それをRHELへバックポートします(upstream firstポリシー)。
4,5の作業中に7.3がリリースされていたため、7.3のerrataとして出荷されます。
図2 CentOS Streamがないとき
図3はCentOS Streamがあるときの開発です。テスト環境がリリースされたRHELではなくCentOS Streamになっている以外はほぼ同じですが、将来出荷予定の変更が公開されるCentOS Streamをテスト環境として利用することで、RHELでの不具合発生期間が大幅に短縮されます。さらにRHEL出荷前に問題の存在がわかるため「製品BはRHEL 9.2では今のところ動作しない」のようなアナウンスを事前に行えます。
図3 CentOS Streamがあるとき
CentOS Streamの入手・インストール
CentOS StreamはCentOS ProjectのWebサイトから入手できます。 ISOイメージをダウンロードして、インストールします。
図4 CentOS StreamのWebサイト
執筆時点ではVMイメージは散発的なタイミングで公開されています。最新パッケージが必要な場合はこれをもとにパッケージを更新するのがよいでしょう。
執筆時点ではCentOS Streamのコンテナイメージは提供されていません。そのため Red Hat Universal Base Image(以下UBI)をベースとして、CentOS Streamのパッケージと差し替えることでCentOS Streamのコンテナイメージを作成する手順をリスト1 で紹介します。ほとんどのコマンドについて出力を省略しています。
(1) CentOS Stream 8の環境でUBI 8を取得し、作業用のコンテナを作成します。 # yum module install -y container-tools $ podman pull registry.access.redhat.com/ubi8 $ buildah from ubi8 ubi8-working-container (2) CentOS Streamのリポジトリ情報を持つrpmをダウンロードし、コンテナにコピーします。 $ yum download centos-stream-repos centos-gpg-keys $ buildah copy ubi8-working-container centos* /tmp (3) コンテナ内のシェルでパッケージの削除と入れ替えを行います。 $ buildah run ubi8-working-container bash # yum remove -y *subscription* ## RHELとのサブスクリプション共有は不要なので削除する # yum install /tmp/centos-* ## CentOS Streamのリポジトリ設定 # yum --setopt protected_packages= swap redhat-release centos-stream-release ## redhat-releaseをcentos-stream-releaseで置き換える # rm /etc/yum.repos.d/ubi.repo ## UBIのリポジトリを削除する # yum clean all # yum distro-sync -y ## CentOS Streamのパッケージに置き換え # yum clean all # rm /tmp/centos* # exit (4) コンテナからイメージ cs8 を作成し、コンテナを削除します。 $ buildah commit ubi8-working-container cs8 $ buildah delete ubi8-working-container
リスト1 Red Hat UBIをもとにCentOS Streamのコンテナイメージを作成する
CentOS Streamの問題に対応する
CentOS Streamではバグレポートや修正パッチを受けつけており、各コンポーネントを担当しているRed Hatのエンジニアが対応します。Red Hatはupstream firstポリシーでRHELを開発しているため、CentOS StreamやRHELが修正されるだけでなく、upstreamプロジェクトでも問題が解決されることを期待できます。
CentOS Streamでのバグ修正はその時点の最新パッケージだけが対象です。レポート前に最新パッケージで問題が再現することを確認しましょう。
Red Hat Bugzillaへバグレポートや修正パッチを送ると、Red Hatのエンジニアがアサインされ、内容を確認してCentOS Streamでの対応方針を決めます。不明点の確認や、修正により問題が解消されたかの確認もここで行われます。
Red Hat Bugzillaで報告するには、アカウント作成が必要です。Red Hatのアカウントを使うこともできますし、メールアドレスがあれば新規に作成することもできます。
報告するには、トップページから "New" → "Red Hat" → "Red Hat Enterprise Linux 8" とリンクをクリックします。図5のような画面が表示され、Versionの中に8.2, 8.3などのマイナーリリースと並んで "CentOS Stream" という選択肢があります。
図5 Red Hat Bugzilla
バグレポートではなくPull Requestを送ることもできます。詳しい手順はCentOS Wikiに記載がありますが、PRを作成することでRed Hat Bugzillaのチケットが自動的に作成されます。
