コンテナをサンドボックスを作るための手段として見るなら納得できるけど、ホストシステムの依存関係を変えずに任意のアプリケーションを簡単に立ち上げる方法として考えると、あんまり意味がないよね。

それがコンテナの始まりの理由なの？依存関係地獄が原因で流行ったような気がするけど、簡単に仮想化できる時代じゃなかったからね。同じサーバー上で必要なソフトウェアのバージョンを全部動かすのは、調整するのが大変だったよ。

コンテナやネームスペースはセキュリティのためのものじゃないんだ。OSレベルでシングルトンオブジェクトを持たないためのもの。もし「仮想化」という言葉がそんなに使われてなければ、そう呼んでたかも。みんなが見落としてる大きな違いがあるんだ。バイパス可能なセキュリティメカニズムは、役に立たないどころか悪い。バイパス可能な仮想化メカニズムは役に立つ。悪意のあるプログラムが本当のルートでないことを検出できても、このプログラム専用の別のルートファイルシステムを持つのは便利なんだ。SEL4について言えば、難しい問題を上位層に任せるからこそ、すごくエレガントなんだよね（偶然にもそれらをもっと難しくしてるけど）。

SEL4は実際にうまく設計されてるから、SEL4上でサブカーネルをプロセスとして比較的簡単に実行できるんだ。ほら、これでK8sもいらなくなるね。K8sは、機械のクラスターをあたかも単一のリソースのように管理するためのものだから、その前の「ボーグ」という名前も納得だよね。私の知る限り、これはSEL4が扱うユースケースじゃないよね？

「カーネルに依存しない」Nvidiaドライバがあれば最高だよね。ベアメタル開発の経験があるけど、OSが提供するもののほとんどは、特定のハードウェアを動かすためのライブラリのセットとして、もっと良い形で提供できるように思うんだよね。それに、すごく良い「ビルド」システムも必要だし。

cgroupsは、確かIBMから出てきたリソース管理フレームワークから来たんだよね。しばらくの間、いくつかのディストリビューションのカーネルに入ったけど、上流には行かなかった。ネームスペースはセキュリティを追加するための試みじゃなくて、バインドマウントのようにインターフェースをもっと柔軟にするための作業から生まれたものなんだ。Unixのセキュリティは基本的に良いもので、ネームスペースがないことはあまり問題じゃないけど、今はあるからね。実際、うまくいってると思う。すべてのアプリは多くのカーネル機能を使っていて、非常に安全で高性能なウェブやその他のサーバーもある。L4システムはLinuxと同じくらいの歴史があって、特にSEL4は20年も続いてる。でも、あまり進展はないから、今のところあまりうまくいってるとは言えないかな。SEL4は重要なことをいくつか成し遂げた素晴らしいプロジェクトだけど、Unixの代替としてクーデターを起こす準備ができてるようには見えないね。

「セキュリティに対する根本的に悪いアプローチを持っている。UnixはVPSプロバイダーのために便利に設計されたわけじゃなく、1台のコンピュータが1つの会社のフロア全体にサービスを提供できるように設計された。セキュリティのアプローチは展開戦略に適している。すべてのOSと同様に、インターネットが現れて、すぐにすべてを台無しにした。」

「Cgroupsとネームスペースは、セキュリティを追加するためにLinuxに追加された。UNIXは根本的にセキュリティに対する悪いアプローチ（共有グローバルネームスペース、ユーザーなど）を持っている。すべてのリソースのネームスペース化（共有グローバルネームスペースへの制限なし）は、実際にはplan9から直接取られたものだ。これによりセキュリティが向上するが、それだけじゃなく、分散コンピューティングのための原則的な基盤も整える。コンテナ化がk8sのような低レベルの層を可能にする様子にこれが見られる - もちろん、実際には最もよく知られている高レベルの適応型展開と管理を考慮に入れずに。」

「SEL4みたいなのが、最終的にはクラウドサーバーのワークロードのためにLinuxの代わりになることを願ってる。9frontやディスクレスLinuxのマイクロVM、Firecracker/Kata-containersスタイルでもいいんじゃない？K8sよりも小さいOSで、ファイルシステムとプロセスの隔離が一緒になってるやつ。シンプルでUnixっぽく。既存のバイナリはそのまま使って、プレーンテキストの設定やリポジトリ、イメージもそのまま。スタックの一番下のレイヤーだけを入れ替えて、便利な時にホストOSに移行すればいい。」

聞いた話では、コンテナは仮想マシンに比べてメモリを少なく使えて、カーネルやCPUをより良く共有できるから、同じサーバーでより多くのアプリケーションを動かせるんだって。これが直接的なコスト削減につながるから、大規模なサーバーファームを持つ大企業は、技術を開発して移行するためにエンジニアにお金を払う価値があるんだよね。セキュリティに関しては、SEL4やコンテナ、VMよりも、各アプリケーションに別々の物理サーバーを用意して、CPUやメモリを全く共有しない方が安全だと思う。そうすれば、物理的にアプリケーション間にセキュリティの境界ができるからね。もちろん、ほとんどのビジネスケースにはそれが高すぎるから、みんな使わないんだよね。SEL4を使うのも同じ問題にぶつかると思う。コンテナに比べてサーバーの利用効率が悪くなるから、ビジネスケースには高くついて魅力的じゃない。コンテナに代わるものを求めるなら、それはもっと安くて安全でなきゃいけないけど、何になるかは分からないな。

ほぼその通りだね。Javaみたいに一貫した孤立した依存関係管理を持つシステムは、OSレベルのコンテナソリューションを必要としなかった。アプリケーションサーバーを通じてユーザースペースのコンテナ管理はあったけどね。

その通りなんだけど、Pythonだけじゃないんだよね。ほとんどのLinuxアプリは、ファイルシステムに散らばっていて、絶対パスへのハードコーディングされた参照があって、依存関係も自分で用意しないといけない。要するに、Linuxの世界はアプリを配布しにくくするように設計されてるんだよね。

確かに、彼らは自分たちのアプリにDockerを使ってたけど、dotCloud自体もPaaSだったから、Herokuやそれに似たサービスと競争しようとしてたんだよね。ビルドパックがあったからね。問題は、ビルドパックがあまり柔軟じゃなくて、自分の言語やランタイム、スタックに合ったビルドパックがないと機能しないことだったんだ。

基本的にはその通りだね。でも、もっと一般的な問題は、エンジニアたちがアプリとその依存関係を簡単に配布・実行できるパッケージにまとめる能力を失っちゃったことだと思う。Javaが.jarファイルを主流にした頃（要は、マニフェスト付きで全部をzipするだけ）、他の世界は静的リンクのやり方を完全に忘れちゃったし、今はみんなが高度にスケジュールされたマルチスレッドOSを使ってる。長い間の「解決策」は、単一アプリの仮想マシンを立ち上げることだったけど、それは重い解決策で、アプリに使える全体のシステムリソースを減らしちゃって、すごく非効率な解決法になってた。現代のクラウドはこの段階で生まれたから、今のクラウドシステムの基本的な原則の一つがVMなんだよね。コンテナは依存関係の配布問題とリソースの割り当て問題を同時に「解決」したんだ。

PyinstallerはDockerより前に登場したんだ。特定の言語がパッケージングできないってわけじゃなくて、どんな言語やアーキテクチャでもアプリケーションを実行するための統一されたインターフェースが必要なんだ。だからK8sみたいなプラットフォームはPythonや他の言語について何も知らなくても、自動的に将来の言語もサポートできるんだよ。

君の言ってることには100%同意だけど、君が言ってるのはDockerがデプロイメントのワークフローを変えたってことかもしれないね、開発のワークフローじゃなくて（ただ、devcontainersのおかげでその境界は曖昧だけど）。Justinは数ヶ月前にDockerを辞めたばかりで、彼のCTOとしての長い経歴がこの記事の意見の大半に影響を与えているのは明らかだと思う。デプロイメントに関する視点や他の意見は、彼が大企業の顧客と交わした会話を反映しているように思える。個人開発者が頻繁に開発環境を切り替えるワークフローとは違うんじゃないかな。

これがHWが安すぎると起こることだね。

だからDockerとレイヤーが存在するんだ。コンテナはそれらよりも10年以上前からあったんだよ。

「今日のエンジニア」と言ってるけど、「2001年のエンジニア」のこと？sbuild[0]、コンテナ内でdebパッケージをビルドするためのツールが作られたのはその頃だよ。毎回クリーンなコンテナから始まるっていう点でかなり革新的だったし、ユーザーのマシンに変な依存関係がインストールされていても、信頼性のある方法でdebをビルドできたんだ。（当時はschrootコンテナで、dockerはまだ存在していなかったことに注意）[0] https://metadata.ftp-master.debian.org/changelogs//main/s/sb...

そう、それが理由だよ。コンテナは、他の方法ではできないOS環境の多くをパッケージ化する手段なんだ。

そうだね。「じゃあ、どうやってこれをデプロイして、運用して、維持するの？」っていうのが、ベンダーとの数週間の会議だったのを覚えてる。ひどい「人間が読める」ドキュメントについて話し合ったり（あればだけど）。そういう会議は今でも時々あるけど、「クラウド」*aaSやコンテナのおかげで、そういうのはかなり減ったよね。

プログラミングの授業を受けるためにデスクトップコンピュータにOracleをインストールしたのを覚えてる… インストールがクラッシュしたら（結構よくあることだった）、コンピュータを完全にフォーマットしてやり直す方が簡単だった。データベースが壊れた？多分、全部フォーマットして最初からインストールする方が楽だね。

BSD Jailのおかげで「なんでこれがLinuxにはないんだろう？」って感じが生まれたと思う。

私の知る限り、最初に登場したのはHerbert Pötzlらによるlinux-vserver.orgの「ctx」カーネルパッチプロジェクトだった。 https://web.archive.org/web/20250307173707/http://linux-vser... （残念ながら、ドメインは最近期限切れになったみたい）当時はそれをたくさん使ってたよ、カーネルネームスペースが上流に行く前や、dockerが登場する前にね。

コンテナの話を聞くずっと前から、Intelが「0コスト」のハードウェアレベルの仮想化をサポートしているって話を聞いてたのを覚えてる。確か、主に仮想マシン（VMWareのやつ）を速くするためだったと思う。サーバー分野でのIntelの大きな市場差別化要因だったんだ。VirtualBoxでいくつかの機能をオンにする必要があったのをぼんやり覚えてる。それを使うと、サポートしているCPUならパフォーマンスが大幅に向上したんだ。

もっと前の1999年に、FreeBSDやSolarisがコンテナを手に入れる前に、HP-UX Vaultのコンセプトに出会ったんだ。残念ながら、HPeはHP-UXのドキュメントのほとんどをインターネットから削除しちゃったから、指摘するのが難しい。でも、HP-UX 10.24リリースのデジタルトレースはまだ残ってる。>「これはHP-UXのバーチャルボールトリリースで、強化されたセキュリティ機能を提供します。バーチャルボールトは、各ファイルにコンパートメントが割り当てられ、プロセスは適切なコンパートメント内のファイルにしかアクセスできないコンパートメント化されたオペレーティングシステムです。他のほとんどのUNIXシステムとは異なり、スーパーユーザー（またはroot）は正しい手続きを踏まない限り、システムに完全にアクセスできません。」 https://en.wikipedia.org/wiki/HP-UX フォーラムのディスカッションもあるよ。 https://community.hpe.com/t5/operating-system-hp-ux/hp-virtu... 今、HP-UX VaultのPDFが戻ってきたら最高だね。

それは二言だね。「決定論的」ってのはどう？

rpmやdebパッケージを作ってみたことある？

（mkdirについての注意：mkdir -pは、ディレクトリが既に存在していても成功するよ）

ソフトウェアに関して言えば、根本的な悪はお金じゃなくて状態だと思う。状態の変化を制限するためにできることは、バグを防ぐために価値がある。コンテナはこれに最適で、特に「システム管理者」が個別のアプリケーションサーバーにSSH（またはこの場合はRDP）で入って、適切な自動化を使わずに手動でアプリを更新する羽目になったことがある人にはね。

コンテナは状態管理を大幅に減らしてくれる。しかも、Podmanを使ってルート権限なしでコンテナをビルド/実行すれば、状態管理を減らし、不要な権限昇格を避けられるよ。

数年前、これがまさに同僚たちをコンテナに興味を持たせるきっかけだった。プロダクションのやり方に変更を求めることは一切なかった。ただ、自分のワークステーションで開発やテストのためにランタイム環境を管理するためにコンテナを使い始めただけ。それを見た同僚たちが、従来のVMベースの管理方法に比べてどれだけ手間が減ったかに気づき始めた。すぐに、同じようにセットアップする手伝いを頼まれるようになって、最終的にはCIパイプラインもコンテナ化した。でも、プロダクションでのやり方は変えなかった。OpsはVM+Ansibleのセットアップに満足していたし、「コンテナ万歳」以上の理由でそれをいじる必要はなかったからね。今にして思えば、Devcontainersの導入によって、開発におけるコンテナの利点が大きく損なわれた気がする。少なくとも私の視点からすると、開発におけるコンテナの本当の価値は、タイピングするアプリケーションのランタイム環境と、テストを行うランタイム環境との結合が緩やかになることだったんだ。だけど、Devcontainersはその二つを再び密結合にするように設計されている。

いつでも「apt-get install」できるよ。特定のパッケージのバージョンを確実に固定することはできないと思うけど、そうするとコンテナの前と同じように問題が起きるよね。

たぶん、単一のサーバーに単一のアプリがずっとそのままってことはあまりないからかな。全体的には状況が改善されて、個人的にはLinuxの方がWindowsよりもいいと思うけど… .NetやJavaのアプリをいくつかインストールして、複数のフレームワークバージョンでうまく動かすのは最悪だよね。依存関係がもっと複雑だったらなおさら。Windowsコンテナ用のDocker自体も、依存関係の問題で本当にイライラする経験だったし、最初からあまり良いアイデアだとは思ってなかった。それがLinux用のDockerを薄めてしまったと思う。Dockerやコンテナ、Composeは、データベースやキャッシュなどの依存関係があるアプリケーションなら結構使いやすいよね。TLS証明書の設定や終了をアプリサーバーから分けたり、大規模なオーケストレーションオプションにスケールアップしたりする選択肢もあるし… でも、私は自宅のラボや自分のサーバーでComposeを超えたことはまだないけど。コンテナやボリュームを使うことで、バックアップや復元のためにデータストレージやアプリケーションの設定をより良く配置できるし、Composeや設定の隣に置けるんだ。実際、compose-down、rsync、DNS変更、そして新しいサーバーでcompose up -dを使ってアプリをサーバー間で移行できたこともある。全体的に見て、かなり良い感じだよ。