自動ニュース作成G
レッドハットが「RHEL 10」で“イミュータブル”なアプローチを採用した背景
https://japan.zdnet.com/article/35233831/
2025-06-08 10:26:42
＞2010年代に入って、イミュータブル（システムのコア部分を変更できない）Linuxディストリビューションという概念が具体化し始めた。〜これは、コアシステムファイルが読み取り専用としてロックされており、個々のパッケージ単位ではなく、全体を（つまり、アトミックに）更新できるディストリビューションのことだ。
ちょうどその後でIT分野から引退したのでそんな用語は初耳だった。
＞あるパッケージを変更する必要があるとしよう。従来の方法を使えば簡単だが、イミュータブルなシステムでは、システムを再起動しなければならない。このことは、高可用性システムには大きな負担となるかもしれない。＜ それはそうだな。面倒そうだ
・問い合わせ受ける側からするとラクになるんだろうけど、セキュリティパッチ当てるたびにシステム再起動ってこと？
・#1そういうことよね。昔、汎用大型機のOS開発してた時に無停止で適用可能なパッチを作れ（或いは適用指示書に可不可を明記せよ）と指示があって頭を抱えたことはある。unix系は当たり前にやってたのでスゲーなとは思ってた。ちなみに当時はセキュリティパッチという区分は無くてバグパッチと機能パッチの２種類だった
・#2 何がネックなのか分からんが、ファイルシステム（iノード）のお陰かね。ファイルディスクリプタ毎にファイルを参照した時点のレビジョンが保持されるんで普通にやれば普通に出来る。静的ライブラリは問題無さそうだが何も考えずにやったら動的ライブラリは破綻するかな。
・カーネルが静的ってことは、少し前のBSDや初期のLinuxのようなシステム再構成での再ビルドに戻しただけでは。#3が知ったかなのは理解した。FSは全然関係無い。せめてカーネルモジュールのioctl系と間違えてくれ。動的ライブラリも基本的にはソフトウェア(OSでは無い)の再起動が必要。予め計画してれば動的なロードを制御できるが別の話
・現在の主流はクラウドで、VMかDockerが戦場だったりするのでメインターゲットはそのあたり。現在のカーネルパッチとかはバイナリではなく(多くはソースの一部更新ですらない)、ソースやバイナリを丸ごと送って入れ換えるとか再ビルドするとかそんな感じ。OS部分も含めて複数(仮想)ハードで統一されてると、大量のコンテナ環境の土台部分の管理が非常に楽になるのではと思う
・稼働中のパッチ当は、少し前なら可用性システムで、待機系を更新して現用系と入れ換え、問題なければ待機中の現用系にも適用みたいな感じだった。今だとVMやコンテナの数を維持しつつ、裏で必要数を更新して一気に切り替える感じだと思う(バージョンの混在を避けるため)。イミュータブルだと基盤の整合性を取りやすくなるが更新時にOSの再起動が必要とか？
・#4 どう関係無いのか書かないから何について語っているにか分からんが、コアシステムだからカーネル限定ではないんじゃないの？パッチはファイルの入れ替えで対応する訳でファイルシステムが関係しないなんて事はない。
・#6 貴方こそ勘違いしている。「待機系を更新して現用系と入れ換え」の話ではないと思うぞ。サービスを中断しない話かね。それこそ全く関係ない。
・#3 が #2 にレスってるが、#2 ってシステムを停止せずにパッチを当てる話だよね。そこにファイルシステムとかiノードとか、たまたま自分が知ってる単語並べてみたかったと思うんだが、かすりもしなくて見てて恥ずかしい。高可用性システムすら扱ったことないなら黙ってれば？