「Linux」が登場するずっと前、筆者は「UNIX」システムの管理者として働いていた。当時は、システムの更新や新しいパッケージのインストールが必要になるたびに、ソースコードをダウンロードして「tarball」アーカイブを解凍し、コンパイルしてインストールしていた。これは本当に面倒な作業だった。
1989年に「UNIX System V Release 4」（SVR4）が登場し、最初のパッケージ管理システムである「pkgadd」と「pkgrm」「pkginfo」が利用可能になったことで、状況は改善された。IBMやSun Microsystemsといった企業がそれぞれ独自のプロプライエタリー版をリリースしたことにより、システム管理者としての仕事は大幅に楽になった。具体的には、前者は「AIX」とそのシステム管理インターフェースツール（SMIT）、後者は「Solaris 2.0」をリリースした。
一方、386（486）ATクローン向けの（フリーの）OSの開発に取り組んでいることを1991年に明かしたLinus Torvalds氏は、Linuxが多くの人々に受け入れられ、真剣に扱われていることにを喜んでいた（同氏は当時、Linuxは単なる趣味であり、「GNU」みたいに大規模でプロフェッショナルなものにはならないと語っていた）。
パッケージマネージャーの進化
SVR4のパッケージマネージャーに触発されて、ビジネスサーバーでLinuxをUNIXのライバルにすることを目指した最初のディストリビューション群がこのアイデアを採用した。1993～1994年頃には、Linux専用のパッケージマネージャーが登場し始めていた。Rik Faithの「Package Management System」は、あまり知られていないLinuxディストリビューション「BOGUS」でその先駆けとなった。BOGUSが大きな意味を持っているのは、より重要な「Red Hat Package Manager」（RPM）が1994年に開発されるきっかけとなったからだ。ほぼ同時期に、「Debian Linux」の生みの親であるIan Murdock氏はDebianパッケージマネージャー（dpkg） を構築した。
これらのパッケージマネージャーには、基本的な依存関係追跡機能が含まれていた。依存関係の自動解決が当たり前になったのは、1990年代後半にDebianの「apt」やRed Hatの「yum」といった高度なツールが登場してからのことだ。その頃から、ほぼ全てのユーザーはパッケージマネージャーを使って、OSのパッチやプログラムをインストールしたり、管理したりするようになった。
2010年代に入って、イミュータブル（システムのコア部分を変更できない）Linuxディストリビューションという概念が具体化し始めた。「Docker」の台頭を受けてコンテナーが普及したことで、最小限のLinuxディストリビューションへの関心が高まった。これは、コアシステムファイルが読み取り専用としてロックされており、個々のパッケージ単位ではなく、全体を（つまり、アトミックに）更新できるディストリビューションのことだ。
イミュータブルなLinuxディストリビューションでは、個々の問題にパッチを適用するのではなく、再起動時に全ての問題に同時にパッチを適用する。これには、システムアップデートも含まれる。つまり、全てが単一のトランザクションとして更新される。何か問題が発生した場合は、古いイメージをリブートするだけで、簡単に正常なシステムに戻せる。余計な手間はかからない。
このアーキテクチャーアプローチは、不正な変更を防いで、システム破損のリスクを軽減することで、システムのセキュリティと安定性を大幅に向上させる。多くの主要なLinuxディストリビューションでは断片的な更新が実行されるが、イミュータブルなLinuxディストリビューションでは全てが一度に更新される。
コンテナーの台頭に加えて、セキュリティと信頼性も、プラットフォーム設計のこうした変化を促した。読み取り専用のコアを持つサーバーは、マルウェアや偶発的な設定ミス、不正な変更に対する防御力が高くなる。コンテナー化は重要な機能である。アプリケーションをコアシステムから分離したり、アプリケーション同士を分離したりすることで、攻撃対象領域をより小さくするからだ。さらに、イミュータブルなディストリビューションは、同じイメージを実行する全てのサーバーに一貫性と予測可能性を提供して、大規模な展開の管理を容易にすることで、メンテナンスを簡素化する。
最初の主要なイミュータブルLinuxは2013年に登場した「CoreOS」だ。大規模なコンテナー実行のために特別に設計されたOSで、コアOSは読み取り専用となっていた。更新はアトミックに適用され、新しいイメージとして展開される。そのおかげで、CoreOSはクラウドネイティブ環境や「Kubernetes」クラスターに最適なOSとなった。
抜け目のないRed Hatは2018年、CoreOSをわずか2億5000万ドルで買収した。CoreOSをベースとして、Red Hatは3つの重要なLinuxディストリビューションを開発した。
1つ目は、ミニマリズムと自動アトミック更新を実現するために構築された「Fedora CoreOS」である。このディストリビューションは、コンテナーホスティングやKubernetesクラスターに最適だ。「rpm-ostree」を使用してイミュータブルなベースを管理し、追加のパッケージやコンテナー化されたワークロードもサポートする。
次に登場したのは、「Fedora Workstation」のイミュータブル版である「Fedora Silverblue」だ。Silverblueはデスクトップにイミュータビリティーをもたらした。アプリケーション管理に「Flatpak」、アトミック更新に「OSTree」を使用する。
「RHEL 10」はイミュータブルなアプローチを採用
最後に登場したのは、「Red Hat Enterprise Linux 10」（RHEL 10）だ。そう、Red Hatの主力OSであるRHEL 10は、主要なエンタープライズLinuxディストリビューションとして初めてイミュータブルなアプローチを採用した。
なぜ、イミュータブルを選択したのだろうか。2025年5月にボストンで開催された「Red Hat Summit」で、RHELのプロダクトマーケティング担当シニアディレクターのChris Wells氏は以下のように説明した。
システムの更新やアップグレードが最大の悩みの種だという話を多くの管理者から聞かされた。彼らはそれが必要であることを理解しているし、実行することを望んでもいる。ただ、なぜこんなに大変なのかと疑問に思っている。考えてみると、システムにパッチを適用する現在の方法の起源は、20年前のUNIXの世界にまで遡る。これは伝統的なやり方だ。UNIX/Linuxの世界では、小さなソフトウェアパッケージが使われており、パッケージは全て互いに結びついている。ユーザーはパッケージとその依存関係を更新して、うまくいくことを祈るだけだ。
われわれは、もっと良い方法があるのではないかと考えた。そして、「OS層をコンテナー化したらどうなるだろうか。それを本番システムに導入したらどうなるだろうか。次に新しいシステムを構築するとき、従来のやり方、つまりパッケージモードで実行するのではなく、アプリケーション層とOS層の両方をコンテナー化して、それをイメージとして提供したらどうなるだろうか」と想像した。突然、そのイメージが現実のものとなり、何らかの問題が発生した場合に、システムに展開できるようになった。以前のようにロールバックするのではなく、元のイメージに戻すだけで済む。なぜなら、先ほども述べたように、全てがイミュータブルになるからだ。
イミュータブルLinuxの有用性に気づいた企業は、Red Hatだけではない。「Ubuntu」や「SUSE Linux Enterprise Server」（SLES）ほどの知名度はないものの、「Flatcar Container Linux」や「openSUSE MicroOS」「Ubuntu Core」「Talos Linux」など、ビジネスに特化したイミュータブルLinuxディストリビューションが多数存在する。「Chainguard OS」のようなセキュリティファーストのイミュータブルディストリビューションもある。
ただし、トレードオフもある。従来のパッケージ管理に慣れたシステム管理者は、新しいワークフローに適応することを余儀なくされる。また、一部のカスタマイズには回避策が必要になる。例えば、あるパッケージを変更する必要があるとしよう。従来の方法を使えば簡単だが、イミュータブルなシステムでは、システムを再起動しなければならない。このことは、高可用性システムには大きな負担となるかもしれない。
それでも、今後、イミュータブルLinuxは欠点を補って余りある価値を持つようになるとRed Hatは確信している。Red Hatはずっと前からエンタープライズLinux市場の中心にいる。同社の抜本的な変革は成功する可能性が高いのではないだろうか。
提供：wellesenterprises/Getty Images
この記事は海外Ziff Davis発の記事を朝日インタラクティブが日本向けに編集したものです。
