|
オープンソースの詳細については、以下をご覧ください。 51CTO オープンソース基本ソフトウェアコミュニティ https://ost..com CentOSコミュニティはまだ存在するのか？ CentOSプロジェクトはまだ存在するのか？ 多くのCentOSユーザーは今後どうなるのか？ CentOSのアップデートが停止したことで、多くの人が様々な疑問を抱いているのではないでしょうか。今日は、これらの疑問に一つずつお答えします。 CentOS には実際には 2 つのバリエーションがあります。1 つは CentOS Linux と呼ばれ、もう 1 つは CentOS Stream と呼ばれます。 CentOS Linuxは比較的初期に登場し、多くの人がCentOSとして知っているのはCentOS Linuxです。一方、CentOS StreamはRed Hatから2年前にリリースされたもので、基本的にはCentOS Linuxの段階的なアップグレードと置き換えを表しています。 これは、かつてiPhone 4を使っていた人が今はiPhone 5を使っているのと同じようなもので、いわばアップグレードです。アップグレード後、メインの名称もCentOS LinuxからCentOS Streamに変更されました。これについては後ほど説明します。この変更は、オープンソース開発モデルの進化と市場の需要の変化に関連しています。 次に、CentOS LinuxからCentOS Streamへの移行は安定しているのだろうか、といった疑問が皆さんにあると思います。私の答えは、シンプルに「はい、安定しています」です。詳細は後ほど説明しますが、その安定性についても詳しく説明します。 Linuxディストリビューション開発モデルの進化まず、Linuxディストリビューションの開発モデルの進化を見てみましょう。これは、多くのオープンソース開発手法の進化とも言えるかもしれません。Linuxは31年の歴史を持っています。初期のLinuxは、完全に趣味から生まれたものでした。Linus Torvalds氏自身が述べたように、Linuxは楽しさと興味深い理由から作られました。 Linuxのオープンソース開発アプローチは、徐々に多くの人々に受け入れられるようになりました。Linuxが徐々に企業での利用へと移行するにつれ、もはや単なるおもちゃではなくなりました。 Linuxディストリビューションには、コミュニティ版とエンタープライズ版があります。ここでは主に、エンタープライズニーズの出現に伴うLinux開発の主要な段階について解説します。 フェドーラ時代最初の段階は、いわゆるv1.0の段階、つまりFedoraの時代でした。実際、多くの人がFedoraを使っており、Fedoraのデスクトップは非常にクールでした。 Fedora Linuxはなぜ登場したのでしょうか？それは主に2つの相反する理由から生まれました。1つは、エンタープライズグレードのLinuxディストリビューションには十分な安定性が求められ、アップデートの頻度が高すぎることは許されず、アップデートを行った場合でも互換性が非常に高くなければならないという点です。 しかし、イノベーションにおいては、安定性と互換性に重点を置きすぎると負担が大きくなります。イノベーションと安定性のバランスをどのように取れば良いのでしょうか？Red Hatは、当初統合されていたRed Hat LinuxをFedoraとRed Hat Enterprise Linuxに分割しました。 Red Hatだけではありません。SuSEのような他の主要ベンダーも同様のアプローチを採用しています。この区別によって、各ユーザーはどのように選択するのでしょうか？企業ユーザーであれば当然安定版を選び、コミュニティユーザーであればFedoraを使うでしょう。しかし当時、Linux開発は段階によって焦点が異なっていました。当時はLinuxオペレーティングシステム自体、特にグラフィカルデスクトップ機能に重点が置かれていました。 Red Hatは現在デスクトップアプリケーションの開発を行っていませんが、Gnomeへの貢献は依然として大きく、当時Fedoraのモデルは優れており、ユーザーに最新のソフトウェアパッケージを提供していました。当時、デスクトップアプリケーションは既にかなり成熟していましたが、互換性と安定性への懸念からか、Linuxデスクトップは広く普及せず、十分な発展を遂げることはありませんでした。 CentOS Linux時代さらに発展し、世界が徐々にモバイルインターネットへと移行するにつれ、Androidなどの登場によりデスクトップの市場シェア自体が縮小していきました。この点では、WindowsとAppleの存在が際立っていました。そのため、Linuxデスクトップに関しては、Red HatやSuSEなどの大手ディストリビューションベンダーが徐々にデスクトップへの投資を停止していきました。 サーバー側では、クラウドと仮想化へと徐々に移行してきました。この方向性が焦点となりつつある中で、クラウドイノベーションに関するこれまでの議論を踏まえると、仮想化、クラウド、コンテナ、あるいはコンテナベースのイノベーションをすべてFedora上に構築できるでしょうか？エンタープライズレベルのアプリケーションにはRHELを使用するという選択肢もありました。しかし、後にこのアプローチは理想的ではないことが判明しました。なぜでしょうか？それは、安定したカーネルを求めているからです。私たちはオペレーティングシステムを最下層のソフトウェアと捉えており、その最下層のソフトウェアに不具合が生じてほしくないのです。 この時点で、開発基盤となるアーキテクチャとして、RHELとほぼ同等の品質を持つプラットフォームが必要となり、CentOSが誕生しました。しかし、CentOSはコミュニティから生まれたものであり、Red Hatが開発したものではありません。CentOSの登場後、その理念は当時のLinuxの開発動向と非常に合致していたため、Red Hatが買収しました。買収後も、CentOS Linuxは独自の技術路線に沿って開発を続けました。 この時点で、バランスを取る必要もあります。一方では、CentOS Linux は仮想化とクラウドに基づいた革新を実現したい場所であり、他方ではその基盤が十分に安定している必要があります。 先ほど説明した歴史は、上の図に示されています。しかし、CentOSに詳しい方の多くは、左側の部分しか知らないのではないでしょうか。RHEL（Red Hat Enterprise Linux）はFedoraから派生したものであり、FedoraはRHELのテスト環境だったと言えるでしょう。CentOSはRHELをベースにしたダウンストリームフォークであり、RHELとほぼ同一であるため、その安定性は疑う余地がありません。 しかし、多くの人は右側のこの部分に気づいていません。実際、クラウド コンピューティングと仮想化が主要なアプリケーション ワークロードになると、CentOS には RHEL コンポーネントだけでなく、Red Hat の OpenStack Community Edition である RDO も大量に含まれていることがわかります。 CentOSには、LibvirtやoVirtといった多くの仮想化ツールも追加されています。つまり、CentOSにはRed Hat Enterprise Linuxパッケージだけでなく、他の多くのパッケージも含まれています。正直なところ、CentOSのこれらのパッケージの品質はRHELよりも低いと言えるでしょう。これは、RHELは厳格なテストを受けているのに対し、コミュニティ版のRDOなどのコンポーネントはそうではないためです。しかし、RDO自体は、OpenStackのコミュニティ版で厳格なテストを受け、その後Red Hat Enterprise EditionのOpenStackで使用されます。Red Hat Enterprise Editionも厳格なテストを受けています。 CentOSでは、この矢印の方向を見ると、一方ではRHELのような安定したオペレーティングシステムパッケージがあり、他方では、テストの観点から見るとCentOS Linuxではそれほど安定していないクラウド関連のパッケージがあります。実際、これが当時のCentOS Linuxのモデルでした。 CentOS ストリーム時代次に、重要なCentOS Streamフェーズについてお話しします。CentOS Streamフェーズでは、従来の開発手法ではもはや現在の要件に対応できないことがわかりました。これは容易に理解できます。デジタルトランスフォーメーションであれデジタルツインであれ、これまでデジタル化されていなかった多くのものが、今ではデジタル化されています。世界自体が常に変化しているため、それを反映するものも頻繁に変化する必要があります。 この傾向は私たちのソフトウェアにも反映されています。25年前、Linuxのバージョンがリリースされた当時は、貢献者は非常に少なかったため、開発モデルやプロセスはそれほど重要ではありませんでした。しかし今では、1つのバージョンに1,000人以上の貢献者が関わり、膨大な作業量と極めて急速な変更が求められています。このように急速に進化するコミュニティリリース環境において、Red Hatが誰もが利用できる安定したエンタープライズグレードのバージョンを開発したいのであれば、開発プロセスはこのような改善を経なければなりません。 この改善は、ストリームモデルと呼ばれています。ストリームモデルは、従来のウォーターフォール型開発アプローチとは異なります。統合、テスト、検証を最終段階に置くのではなく、開発の進行に合わせてテストを実施することで、すべてのリリースの安定性を確保します。これは、ストリームモデルを独自に開発したからではなく、私たちの変化の激しい環境でストリームモデルが求められているからです。つまり、CentOS Streamは、RHELの安定性と信頼性に優れた継続的デリバリーバージョンです。 CentOS Streamに関するよくある質問2020 年 12 月に公開された CentOS ブログの記事では、特に重要なホット トピックがいくつか取り上げられており、改めて強調したいと思います。 CentOSの将来はどうなるのでしょうか？ CentOS公式サイトのFAQを翻訳の問題で誤解しないようご注意ください。CentOS Linuxユーザーの皆様、ご安心ください。CentOSディストリビューションがまもなく登場します。CentOSディストリビューションとは何でしょうか？ 実は、現在Streamと呼んでいるものです。 Stream の安定性とセキュリティ、そして CVE 脆弱性に対するアップデートやパッチの有無について懸念の声が多く寄せられています。新バージョンを開発する際には、元の品質を維持することを確実にしなければなりません。 2つ目のポイントも重要です。古いCentOS Linuxと全く同じものが欲しい場合は、自分で作ることもできます。その場合、RHELのコードは必ず必要になります。そのコードはどこから来るのでしょうか？git.centos.orgです。RHELのコードは以前もこれからもそこにあります。違いはありません。これは完全にオープンソースです。 もちろん、Red Hatのお客様またはサブスクリプションメンバーの方は、サブスクリプションアカウントから簡単にコードをダウンロードできます。Red Hatとは一切関係がなく、コードを閲覧したいだけの場合は、上記のGitアドレスからコードをダウンロードできます。これはGPLライセンスに完全に準拠しており、誰もがコミュニティの繁栄を尊重し、貢献できることを保証します。私たちのコードはGPLに基づいているため、多くの変更を加えていますが、これらの変更は完全に公開されます。 多くの人が懸念しているもう一つの疑問は、CentOS StreamがRHELのベータ版であるかどうかです。CentOS Streamはベータ版ではないことを明確にしておきたいと思います。なぜベータ版ではないのかについては、後ほど簡単に説明します。 もう1つ重要な質問があります。CentOS Linux 8がCentOS Stream 8に移行されたのですが、どのように移行すればいいのでしょうか？サービスが停止されないとのことですが、パッチの受信を継続するにはどうすればいいのでしょうか？そのためには、以下の2つのコマンドをマシン上で入力する必要があります。 [ root @centos ~] # dnf swap centos-linux-repos centos-stream-repos 入力が終わったら、CentOS LinuxソースからCentOS Streamソースにソースを更新し、すべてのパッケージをダウンロードしてインストールし、置き換えてください。その後、システムは通常通り動作するようになります。 たとえあなたが比較的経験豊富なユーザーであっても、この2つのコマンドをあなたのコンピューターに入力すれば、その後の使用時に違いを感じることはないでしょう。安定性、使いやすさ、機能性は変わりません。 次に、Stream が RHEL と同様に安定している理由について説明します。Fedora の場合、Stream は6ヶ月ごとに新しいバージョンをリリースするため、ローリングアップデートシステムと考えることができます。このローリングアップデートでは、新しい機能がリリースされた際に、古い機能との互換性が必ずしも完璧であるとは限りません。例えば、バージョン29の機能がバージョン30で廃止される可能性があり、これは十分にあり得ます。 しかし、CentOS StreamとRHELの場合はそうではありません。なぜなら、これら2つはFedora 28などの特定のバージョンのFedoraをベースにしているからです。安定したエンタープライズバージョンを作成したい場合は、ブランチを作成します。ただし、この安定バージョンにはいくつかの新機能が追加されます。この追加はバックポートと呼ばれます。バックポートとは、すべてを一度に追加するのではなく、いくつかの新機能とバグ修正が必要なことを意味します。 CentOSでCIを構築する方法次に、CentOS が CI を構築する方法について説明します。CentOS Stream と RHEL は同じコードを使用し、それぞれのシステムでコンパイルおよびテストされています。コンパイルとテストに使用されるツールは同一で、一方はコミュニティ版、もう一方はエンタープライズ版です。名前は異なりますが、内容は同じです。テストケースは異なる場合がありますが、合否基準は同じです。例えば、Stream には 300 件のテストケースがあり、RHEL には 500 件のテストケースがあり、そのうち 200 件が重複している場合、結果として 600 件の個別のテストケースが生成されます。CentOS Stream コードと RHEL コードのどちらを使用しているかに関係なく、600 件のテストケースすべてに合格してから次のステップに進む必要があります。1 つでも不合格になった場合、コードは標準以下とみなされ、やり直しが必要になります。 ゲーティングステップでは主に自動テスト手法が使用され、検証ステップでは主に手動テスト手法が使用されます。可能な限り自動化を図っていますが、すべてを完全に自動化できるわけではありません。特定の環境では、依然として手動による介入が必要となる場合があります。ただし、検証ステップでは、両方のステップが検証成功基準を満たしてからでないと続行できないため、品質保証は同等です。 品質保証について長々と議論した後、多くのテスターは「小さな変更ごとにテストプロセス全体を本当に実行できますか？それをサポートするにはどのようなアーキテクチャを使用していますか？」と疑問に思うかもしれません。したがって、このイベントトリガーメカニズムに基づいて、スペースを時間と交換することで、CI システムはさまざまなテスト環境を同時に実行できます。 したがって、CI プロセス全体が DevOps CI/CD パイプラインの要件を完全に満たし、同時実行性が高く、多くの人がパッチを送信する場合でも、迅速にストリーミングを実行できるようにするための大規模なテストを迅速に実行できるようになります。 ここで、このアプローチはマイクロサービスに似ているのではないか、という疑問を持つ人がいるかもしれません。実際、ある程度似ています。マイクロサービスを実装する際、大規模なシステムを複数の小さなモジュールに分割し、アップデートを容易にします。では、なぜカーネル内でマイクロサービスを実装できないのでしょうか？重要な点は、カーネル、特にLinuxはモノリシックカーネルであるということです。すべてがカーネル内にあり、カーネル全体のコードは依然として大きく統一された集合体です。小さなドライバーがカーネル全体をクラッシュさせる可能性がありますが、マイクロサービスにはそのようなことはありません。 そのため、カーネルへの小さな変更はすべてシステム全体のテストを必要とします。その結果、膨大な量のテストが必要となり、より高度なアーキテクチャがなければ、このタイプのLinuxディストリビューションの開発をサポートすることは不可能です。言い換えれば、CentOS LinuxからCentOS Streamへの移行は必須です。そうしないと、開発ペースが遅れ、安定した比較的新しいバージョンをリリースできなくなります。 オープンソースソフトウェアのサプライチェーンセキュリティ今年のlog4jの脆弱性により、log4jは怪物だと考える人もいるかもしれません。実際には、log4jを選択すること自体に何の問題もありません。問題は、セキュリティ脆弱性が発見された際にどのように対応するかにあります。 このプロセスは、現在のDevSecOpsの理念と非常に似ています。参加時に脆弱性が全く存在しないことを保証することはできません。私たちの目標は、オープンソースソフトウェアのサプライチェーンにセキュリティを提供するクローズドループを構築することです。 アップストリーム段階の最初のステップは、悪意のあるコードの有無をチェックするための選定と識別プロセスです。識別後、悪意のあるコードを選択するための標準化されたプロセスは確立されていますか？選定後は、パッケージ化とテストを行います。最終的な配布プロセスでは、適切な検証方法が用意されていますか？そして最も重要なのは、最終段階、つまりユーザーに提供した後、発生する問題を効果的に解決できるかどうかです。 したがって、オープンソース ソフトウェア サプライ チェーンのセキュリティは、主に技術的な問題であると考えています。 AlmaLinux: 代替案AlmaLinuxとは何でしょうか？最近、多くのプロジェクトがCentOS Linuxに似たものを作成し、RHELのコードを完全に複製しています。AlmaLinuxで使用されているすべてのコンポーネントはオープンソースです。ご興味があれば、CentOS.orgでプロセスを確認し、コードの変更を確認できます。これらの変更はパッケージングとビルドのプロセスをトリガーし、最終的にAlmaLinuxへとつながります。 これは、CentOSが間違いなく廃止されるわけではないことを示しています。もし廃止されるなら、AlmaLinux、RockLinux、その他多くのLinuxディストリビューションといったダウンストリーム版はどこから来るのでしょうか？Red HatのRHELはCentOS Streamをベースとしているからです。Red HatがRHELの開発を中止しない限り、CentOS Streamは存続するでしょう。 CentOS Linux は、Red Hat のエンタープライズ グレードの Linux ディストリビューションではありません。最後に、CentOS Linuxについてお話しましょう。CentOS LinuxはRed HatのエンタープライズグレードLinuxとは大きく異なります。エンタープライズグレードLinuxでは、セキュリティやハードウェア／ソフトウェア認証といった認証は機能性よりも信頼性を重視しており、これらの信頼性はエンタープライズグレードLinuxにも備わっています。率直に言って、CentOSは非常に安定しており、問題が発生したりセキュリティ上の脆弱性が発見されたりしても、いずれパッチが提供されるでしょう。しかしながら、実際にはパッチの入手速度はエンタープライズグレードLinuxに比べて明らかに遅いです。 このアプローチを引き続き使用する場合、Stream に切り替えることはできますか？もちろんです。もちろん、エンタープライズ Linux ディストリビューションの場合、明確なガイドラインや業界標準がある場合は、一般的に Red Hat Enterprise Linux を選択することをお勧めします。 |
