- サーバー配布とプロセス分離の問題の歴史をたどり、FreeBSD jails が現代のコンテナ概念を業界より10年早く実装していたことに光を当てる記事
- 2000年にFreeBSD 4.0に導入された jails は
chroot を拡張し、ファイルシステム・ネットワーク・プロセスの完全な分離をカーネルネイティブ機能として提供
- Linuxは2008年のLXC、2013年のDockerを通じてコンテナに到達したが、その過程で namespace・cgroups・OCI など複雑な抽象化レイヤー が積み重なった
- Dockerがうまく解決したのはアプリケーションのパッケージングと配布（shipping）の問題であり、jails は分離に優れる一方で ネイティブな配布標準が存在しない 点が弱み
- 続編では jails ベースのインフラ構築、ZFSスナップショット、Ansibleによるプロビジョニングなど実運用の方法を扱う予定
初期のサーバー配布の問題
- 数十年前、サーバーに何かを配布する標準的な方法は Total Commander、FileZilla、FAR Manager などで FTP経由で手動でファイルをコピー することであり、上級ユーザーは
scp や rsync を使っていたが本質は同じだった
- 1人で作業するプロジェクトではミスは大きな問題ではなかったが、数十件のクライアントプロジェクト を管理する場合は致命的だった
- 一般的なバックエンド構成では、複数のWebサイトが同じ Apache Webサーバーのインスタンス を共有し、同じライフサイクルを持っていたため、Apacheが落ちるとすべて落ちた
- トラフィック急増時に1つのサイトがすべてのリソースを消費すると、同じサーバー上の 他のサイトが静かに窒息する 問題が発生した
- システム管理者はシェルスクリプトで自動化を試みたが、バージョン管理やロールバックのための 標準的な方法は存在せず、プロジェクトフォルダー名に連番やタイムスタンプを付ける慣行が使われていた
解決すべき2つの中核問題
- 配布（Deployment）: 安定したデリバリー、ヒューマンエラーの防止、バージョン管理とロールバックの実装、あらゆるビジネスケースをカバーする汎用ソリューションが必要
- プロセス分離（Process Isolation）: アプリとシステム間の相互保護、1つのアプリの要件が他のアプリを密かに壊す状況の防止、依存関係の衝突解決が必要
- 配布問題を解決しようとする試みは、現代の CI/CDパイプライン、パッケージング標準、バージョン管理システムへと進化したが、分離問題の歴史は相対的にあまり知られていない
chroot から仮想マシンまで
- 1979年にBell UNIXが導入した
chroot は、プロセスに ファイルシステムの分離されたビュー を提供し、サブツリーの外へアクセスできなくする原始的だが有用なアイデアだった
- 限界: 分離されるのはファイルシステムだけであり、ネットワーク・他のプロセス・システムリソースには依然として干渉でき、脱出も可能
- 最初の本格的なエンタープライズ向けの答えは 仮想マシン（VM） で、VMwareが1990年代後半に主流化した
- 各アプリケーションに完全に分離されたOS環境を提供したが、すべてのVMが完全なOSを含むため 相当なオーバーヘッド と分単位の起動時間というコストの問題があった
FreeBSD Jailsの誕生
- 2000年、Windows ServerでもLinuxでもない FreeBSD で静かな革命が起きた
- FreeBSDはLinuxとは根本的に異なる形で、Linuxがカーネルだけを提供し、GNUユーザーランド・パッケージエコシステム・ディストリビューションごとの選択肢が組み合わされるのに対し、FreeBSDはカーネル・ユーザーランド・基本ツール・ライブラリを1つの完全なOSとして 一緒に開発・バージョン管理・テストしている
- この一貫した基盤の上に構築されたソリューションが jails であり、Poul-Henning Kamp と Robert Watson が発表し、FreeBSD 4.0（2000年3月）にネイティブなカーネル機能として搭載された
- 各 jail は独自の ファイルシステムビュー、ネットワークスタック、プロセス空間 を持ち、ホストシステムは見えない
- ホストカーネルを共有するため、ほぼゼロに近いオーバーヘッド とほぼ瞬時の起動時間を実現
- FreeBSDは現在コンテナと呼ばれているものの 実用的実装を業界より10年早く 本番環境で達成していた
分離技術のタイムライン
- 分離問題の実際の進化経路は、分離のない共有サーバー → 重いが分離された仮想マシン → 軽量で分離されたコンテナ だった
- FreeBSDは2000年に第3段階へ到達し、Linuxは 2008年のLXC で到達、Dockerは2013年に登場した
- Dockerが革命的だと称賛されていたとき、FreeBSD jails はすでに 13年間成熟し、実戦で検証済みの状態 だった
Linuxが勝利した理由
- 技術的優位性はエコシステム戦争での勝利を保証しなかった
- Linuxは 迅速な意思決定、GPLライセンスのバイラル効果、Red HatとIBMの強力なエンタープライズ支援 によって勝利した
- その後、Google、Facebook、Amazon が大規模データセンター向けのツールを開発し、業界全体の方向性を定めた
- Linuxは「商用ライセンスを買えない人のための無料OS」から 「サーバー向けの唯一の選択肢」 へと変貌した
Linuxコンテナエコシステムの複雑さ
- Linuxエンジニアたちは分離と配布の問題を解決するため、namespace、cgroups、seccomp などのカーネルプリミティブを構築し、その上に LXC（2008）→ OCI/runc（2015）→ Docker/Podman（2013/2018）→ Docker Hub など 複雑な抽象化レイヤー を積み上げた
- その結果、クラウドベースでベンダーロックインされたインフラのための 過剰にエンジニアリングされたリーキーアブストラクションの塊 が形成された
- 今日では、大規模システムでアプリケーションを運用するには Docker でコンテナ化し、Kubernetes でオーケストレーションすることが 暗黙のデフォルト として定着しており、複数の選択肢の1つではなく当然の選択として提示されている
Dockerの貢献とJailsの弱点
- Dockerがうまく解決したのは shippingの問題 だった。アプリケーションをすべての依存関係とともにパッケージ化し、レジストリを通じて配布し、どのマシンでも同じように動かせる 汎用標準 を提供した
- OCIイメージフォーマット が実質的な業界標準として定着した
- Jailsは分離問題を見事に解決する一方で、shipping に対する ネイティブなソリューションが存在せず、これが Docker エコシステムに比べて jails エコシステムが未成熟に感じられる主な理由となっている
- コミュニティもこのギャップを認識しており、一部のツール（cbsd、bastille、pot、appjail など）が現代のコンテナエコシステムを模倣しようとしており、FreeBSDネイティブのプリミティブを活用する 別のアプローチ も存在する
続編予告
- 次のパートでは、FreeBSDベースのインフラの簡潔さと優雅さ、jails の基礎からその動作原理、jailマネージャーによるボイラープレート削減、Ansibleを使ったプロビジョニングと配布、ZFSスナップショット の強力さ、そしてこれらすべてを組み合わせて Hypha のための堅牢でスケーラブルなインフラを構築する方法を扱う予定
1件のコメント
Hacker Newsのコメント
技術的優位性だけではエコシステム戦争には勝てなかった
90年代半ば、Linuxは素早い意思決定、GPLライセンスの拡散性、Red HatとIBMの企業支援のおかげで成長した
私は1994年にLinuxをインストールしたが、FreeBSDコミュニティでは私の3,500ドルのPCは「たいしたことない」と見なされた
IDEインターフェースにバグがあったが、Linuxは数日で回避策を出し、BSD側はSCSI機器を買えと言うだけだった
当時大学生だった私はお金がなく、結局Linuxが現実的な選択だった
後になってFreeBSDをまた使ってみたが、すでにLinuxが私に必要なことをすべて満たしていた
関連するバグは CMD640のWiki記事 にまとまっている
それでもFreeBSDはシステムの一貫性がより高く、サウンドやイベントAPIのような中核コンポーネントが安定して維持されている点が気に入っている
最新ハードウェアのドライバー対応は依然としてLinuxのほうが上だが、FreeBSDがあまりに「Linux化」しないでほしい
実際、現代の*nixならどちらでもほとんど何でもできる。今では性能より嗜好と慣れの問題だ
一方BSDはAT&Tとの訴訟のため企業に敬遠され、その間にLinuxが市場を支配した
今でもFreeBSDを擁護する文章は出てくるが、90年代に固まった流れを覆すのは難しい
それでもハードウェア対応には今でも改善の余地が大きいと思う
この記事は興味深かった
Linuxのnamespaces, cgroups, seccompのようなカーネルプリミティブが最終的に複雑な抽象化エコシステムを生んだ、という評価には同意しない
Linuxが成功したから複雑になったのであって、設計が失敗していたからではない
もしBSDが主流だったとしても、同じように「過剰設計」なエコシステムが生まれていただろう
コンテナは結局軽量VMにすぎないので、むしろ本物のVMを使うほうがよいと思う
Dockerが人気なのは再利用性とエコシステムのおかげであって、セキュリティ分離のためではなかった
FreeBSDのjailはシンプルでエレガントだが、LinuxのOCIコンテナのほうがはるかに使いやすい
コンテナはカーネルの独立した機能ではなく、複数の名前空間、マウント、プロセス分離を組み合わせた幻想だ
Linuxの設計は意図的なものであり、cgroupsやseccompはコンテナ以外にもsystemdやflatpakなどで広く使われている
「家畜 vs ペット」の哲学はVMやオーケストレーションのレベルで適用できる
jailsのほうが優れているという話は現実感がない
Dockerが勝った理由は技術的な分離ではなくエコシステムだった
Dockerfile、public registry、composeのようなツールのおかげで、30秒で実行可能な環境を作れた
FreeBSD jailは技術的には優れていたが、参入障壁が高かった
最近ではコンテナスタックの複雑さから、シンプルなjailやVMへ戻ろうとする動きも見られる
しかし競争というより、それぞれ役割が違うだけだ
FreeBSDにはこうした概念がなく、イメージシステムも不足している
FreeBSDがDockerのようにUXとエコシステムに投資していれば、ユーザー層は数倍に増えていただろう
2005年ごろ、会社全体をFreeBSD上で動かして運用していた
しかし時間がたつにつれて、Linuxが個人用途でも業務でもすべてを支配するようになった
今ではDockerも十分悪くなく、戻る論理的な理由がない
しかしマルチコアCPU時代への対応が遅れ、LinuxやWindowsに押された
今では性能は回復したが、ドライバー不足と開発者数の限界のため、依然として不利だ
私はGPUやCUDAが必要なところではLinuxを、安定したサーバーにはFreeBSDを使っている
FreeBSDのUXのほうが一貫しているが、現実的にはLinuxが「幸福な道筋」になってしまった
FreeBSDを紹介する記事はいつでも歓迎だ
FreeBSDが2000年にjailを導入したが、LinuxにはすでにOpenVZやVServerのような類似技術があった
結局2000年代後半にLXCが登場して、「FreeBSDが先行していた」という認識が生まれた
コンテナとVMの分離実装方式を技術的に説明した記事があるのか気になる
単に「同じカーネルだから弱い」というレベルではなく、実際の実装の詳細を知りたい
最近はsystemd-oomdのような機能のせいで、FreeBSDに戻りたいと思うことがある
昔はターミナルで複数のプロセスを立ち上げたままログを残しつつ開発していたが、
今ではsystemdがcgroup単位でプロセスを丸ごと殺すため、作業が消えてしまう
こうした非互換なシステム変更は開発フローを壊し、プロセス分離のために毎回systemd-runやDockerを使わなければならない状況がもどかしい
Linux成功の核心はGPLの伝播性とネットワーク効果だった
ユーザーがLinuxを標準と見なすようになり、ハードウェアメーカーも自然にLinux向けドライバーを出すようになった
カーネルの柔軟性のおかげで、オープンソースのドライバーエコシステムは爆発的に成長した