ここにある歴史的な情報は本当に面白かったし、急速に範囲と詳細が広がる記事の良い例だね。企業のIT「セキュリティ」ソフトウェアに対抗するためにVPNのふりをしたのは、かなり意外だった。

Linuxのアプリケーションや依存関係の互換性を簡素化する努力が成功することに楽観的だよ。抽象化に頼るんじゃなくてね。

インターネット上のデータに有用で正確なメタデータを適切に付与して、セマンティックウェブのビジョンを実現する努力が成功することにも楽観的だよ。検索エンジンやLLMに頼るんじゃなくてね。

同意だね。最近、docker composeからprocess composeに切り替えたんだけど、ポートをマッピングしたりボリュームをマウントしたりしなくていいのがすごく楽だよ。実際にDockerから必要だったのはコンテナよりもイメージに関することだったし、nixはその問題をより良く解決してくれる。実行時に邪魔にならないしね。

アプリやサービスを作る視点だけで見るならそうかもしれないけど、コンテナはそれ以上のものを提供してるよ。レジストリを通じて配信を標準化し、ランタイムで管理することで、コンテナオーケストレーターを使うと多くの運用上の悩みが解消されるんだ。VMよりも軽量だから、ハードウェアの利用効率も良くなるしね。

なんでだろうね。僕には「ライブラリを更新して、ネット上での改善にはなったけど、ほとんど後方互換性があるだけ」っていうのは、ソフトウェア開発ではすごく一般的な感覚に思えるんだけど。そんな環境でみんながそれをやってるなら、ソフトウェアを確実にデプロイする唯一の方法は、すべての直接的および間接的な依存関係を正確なバージョンで完全に固定することだよね。Dockerは伝統的なLinuxパッケージマネージャーよりもそれを扱うのがずっと得意なんだ。なんで他のツールが復活すると思う？

> Dockerは、1990年代のダイヤルアップツールSLIRPを再利用して、ネットワークブリッジではなくホストシステムコールを通じてコンテナのネットワークトラフィックを変換することで、企業のファイアウォール制限を回避したんだ。ほんとに魅力的で賢い解決策だね！

Palm Pilotのダイヤルアップツールを使って企業のファイアウォールをすり抜けるのは、ちょっと狂気じみてるけど、実際にうまくいったね。最高のインフラハックは、その瞬間には賢く見えないんだ。誰かがそれを維持しなきゃいけなくなったときに初めて、その賢さが見えてくる。

最近まで、Podmanはコンテナネットワーキングにslirp4netを使ってたんだ。約2年前にPastaに切り替えたけど、これがかなり違った動き方をするんだよね。

SLIRPは元々パームパイロット用じゃなかったと思うよ。リリースされたのは2年前だし。ダイヤルアップのシェルを使ってた時に便利だったんだ。スリップやPPPを使わせてもらえなかったり、追加料金がかかったりしたからね。SLIRPはユーザースペースのプログラムで、ソケットAPIを使ってたから、自分のプログラムを実行して任意の宛先に接続できる限り、実際のPPPアカウントのように接続するダイヤルスクリプトを作れたんだ。ただし、受信接続はできなかったけど（私の知る限り）、だからインターネット上のピアではなかったね。普及するNAT/CGNATの予兆かもしれない。

「私のマシンでは動く」って言い訳を業界標準のアーキテクチャに変えたのから、もう10年経ったね（「それなら、あなたのマシンを本番に出荷しよう」って感じで）。

本当のトリックは、「あなたのマシンを出荷する」っていうのをベストプラクティスのように聞こえさせることだった。そして10年後、今度はAIで「私のノートブックでは動く」って言ってる。結局、「ノートブックをコンテナ化してパイプラインと呼ぶ」ってことになった。抽象化はいつも勝つんだ。実際の問題を解決するのはあまりにも難しいからね。

Linuxのユーザースペースは、ほんとにひどい設計だよ。マジで最悪。Dockerなんて必要ないはずなのに。プログラムを動かすのがこんなに難しいなんておかしいよね。

これは究極の静的リンクだね。もしかしたら、なぜそのアプローチがそんなに魅力的なのかっていう質問をするべきかも。

（この記事の共著者です）Dockerの前はXenで働いてたんだけど、VagrantやPackerを使って巨大なブロックデバイスを組み立てる未来は避けられてよかった… 記事では伝えきれないことだけど、初期のDockerconでは、DockerがIT業界の運営方法に与えた（ポジティブな）影響がすごく感じられたんだ。あの頃は、プロダクションに持っていくのが大変な作業だったし、ファイルシステムをすぐに「出荷」できるようになったのは、みんなの仕事のアプローチに大きな変化をもたらした。多くの人が、サービスをもっと早く構築できて、ユーザーに届けるのに許可を取る必要がなくなったことに感謝してくれたよ。今はコーディングエージェントの登場でまた文化的な大きな変化が起きてるけど、当時のDockerも似たような影響を与えてたと思うし、すごく楽しいコミュニティの雰囲気だったな。今は巨大なハイパースケーラーが支配してるから、ちょっと残念だけど、いい思い出は持ち続けるよ :-)

> 'それなら、あなたのマシンをそのままプロダクションに出荷する' もちろんカーネルは除いてね。特別なカーネル機能やモジュールが必要なワークロードにはどうすればいいの？

この意見はよく見るけど、Dockerがやったことはみんなにビルドを再現可能なプロセスに落とし込むよう促したことだと思う（Dockerfileを通じてね）。「マシンを本番環境に出荷する」って、ボタン一つでマシンを再現できる10行のスクリプトがあれば、そんなに悪くないよ。

ああ、ありがとう… 一人じゃないんだ… ちゃんとしたパッケージングが必要なのに、Dockerfileで管理されたクソみたいなコンテナばっかり見るのに疲れたよ。多くの伝統的なLinuxディストリビューションのような、真剣なパッケージングが必要だよね。

2002年には、なんでウェブサイトをパッケージできないんだろうって思ってた。あの.docのインストール手順は狂ってる！誰かの時間を無駄にしてるよね。そんな問題を考えてたんだ。Dockerがその答えだよ。発明するほどの頭はなかったけどね。もし発明してたら、Microsoft/.NETの人間だったから、octopus deployを発明してたかも。

"docker build"やDockerfileを置き換えようとする試みを何度も見てきたけど、たいていはビルドに対するコントロールを強化したいみたいで、パッケージマネージャーに密接に結びつけることもある。でも、Dockerfileはその柔軟性のおかげで生き残ってる。既知のファイルシステムやディストリビューションから始めて、いくつかのファイルをコピーして、そのファイルシステム内で任意のコマンドを実行するっていうのは、オペレーションがずっとやってきたことをうまく反映してるんだよね。あの柔軟性がどんなに醜くても、しばらくは主流の解決策であり続けると思う。

> Dockerfileはその柔軟性のおかげで生き残ってる でも、シェルコマンド以外の何かに標準化されてたらよかったのに。PuppetとかTerraformとか、もっと宣言的なものが「みんなが自分のDockerfileのトップに‘RUN apt-get upgrade’を載せる」よりもずっと良い代替案になったと思う。レイヤーやステージ、キャッシングの動作はいいけど、実際の実行部分がシェルよりも高い抽象レベルの何かで標準化されてたらよかったな。

Dockerレジストリのようなソリューションが不足してるのが、多くの代替案のボトルネックになってる気がする。個人的にはmkosiが大好きで、コンポーザビリティやデプロイオプションは十分にあるけど、真っさらなOSテンプレートから始めたい人ばかりじゃないのは明らかだよね。

その流れが再現可能なビルドに至るのを妨げる障害がいくつかあるんだ。悪者たちがますます巧妙になっていく中で、ある一方が「このビルドハッシュを信頼してる」と言えて、別の一方も「私たちも」と言えることがますます重要になってくるよね。もし両方の当事者がイメージをビルドする際に異なるハッシュを得たら、それはうまくいかないから、ファイルの修正タイムスタンプ（やその他のリスク）がハッシュ化される限り、それは実現しないだろうね。

NixはDockerコンテナを作るのがめちゃくちゃ得意だよ。

「docker build」を「go build」に置き換えることはほぼできるけど、スクリプト言語（PHPやPythonなど）を使いたい人がいる限り、Dockerは必要悪なんだろうね。

> でも、Dockerfileはその柔軟性のおかげで続いている。裏を返せば、世界はまだすべての言語に対応した言語非依存のビルドツールに落ち着いていない。だから、言語特有のパッケージマネージャーを呼び出すために、いろんなコマンドを実行することになってる。もしみんながNixやBazelみたいなのを使っている別のタイムラインがあったら、docker buildは笑い飛ばされていただろうね。

この記事の補足として書いてた時に気づいた超ランダムな事実（OCamlの経験報告）： 「Docker、Guix、NixOS（安定版）はすべて2013年に初めてリリースされたから、パッケージ好きには素晴らしい年だったんだ。」今は毎週コーディングエージェントのアップデートがあるけど、2013年のように複数の素晴らしいプロジェクトが同時に出てきた年はそれ以降なかったよね？ [1]: https://anil.recoil.org/papers/2025-docker-icfp.pdf

正直なところ、そのリストにはDockerだけがふさわしい気がする。GuixやNixにもユーザーはいるけど、Dockerほどの規模じゃないよね。

20年以上も真剣なネットワーキングのことをやってないし、この記事のような複雑な環境ではやったことがないから、ネットワーキングの部分はほとんど理解できなかったよ。MacでDockerコンテナを動かすときにやりたいのは、コンテナがMacのIPアドレスとは別のIPアドレスを持つことなんだ。ポートマッピングなしで、コンテナがポート80でウェブサーバーを持ってたら、container_ip:80でアクセスしたいんだ。127.0.0.1:2000みたいな、コンテナのポート80にマッピングされるのは嫌だ。LinuxではDockerのブリッジネットワークを使ってたから、それでいけると思うけど、Macではハイパーバイザーの下で動いているLinux VMにブリッジするだけなんだ。これをやるための公式に推奨されている方法はあるのかな？しばらくはLinux VMでWireGuardを動かして、Macとのトンネルを作ってたんだけど、Linux VMでフォワーディングを有効にしてたんだ。それはしばらくうまくいってたけど、突然止まってしまって、理由がわからなかった。その後また動いたり、また止まったりした。今はこれを使ってるけど、これもWireGuardを使ってるけど、もっと自動化された方法なんだ。しばらくはうまくいってたけど、Dockerのアップデートで壊れることもあった。MacのDockerにこれみたいなのが組み込まれてたらいいのに。[1] https://news.ycombinator.com/item?id=33665178 [2] https://github.com/chipmk/docker-mac-net-connect

（この記事の共著者でDockerエンジニアです）WireGuardはこういう機能を作るにはいい基盤だと思うよ。Docker Desktop用のTailscale拡張を試してみるといいかも。これがすべての設定をやってくれるはずだよ。詳細はhttps://hub.docker.com/extensions/tailscale/docker-extensionを見てね。ところで、ポートマッピングを避けようとしてるのは、ポートが動的で事前に知られていないから？もしそうなら、コンテナを--net=hostで実行して、Docker Desktopの設定でリソース/ネットワークに移動してホストネットワーキングを有効にしてみて。これで、コンテナ内のアプリケーションがポートでリッスンすると自動的にトンネルが設定されるよ。リンクありがとう、これから掘り下げてみるね！

Mac環境は持ってないけど、開発目的でちょっと調べたことがあって、Macでのコンテナ用のオープンソースソリューションとしてColimaプロジェクトをおすすめするよ。試してみた？

「10年」の計算が間違ってる気がする。2013年にPyCon USサンタクララでDockerがデビューしたのを覚えてるから。数年前に書いたHNのコメントを見つけたら、これを確認できたんだ：「[...] あの日のことははっきり覚えてる。なぜなら、同じライトニングトークのセッションで、ソロモン・ハイクスがPythonコミュニティにDockerを紹介していたから。これがそのテーマに関する最初の公開された技術トークだと思う。」YouTubeリンク: https://youtu.be/1vui-LupKJI?t=1579 注: t=1579から始まる、26:19だよ。ちょっと細かいことを言ってるけど、約13年前のことだね。このライトニングトークはコンピュータの歴史として面白いよ。（編集: 論文を掘り下げてたら、彼らがこのYouTubeのプレゼンテーションを引用してるのを見つけた。2013年のリリースにも言及してるし。論文がこのタイトルでACMに提出されてから出版されるまでに数年の遅れがあったのかも。やっぱり細かいことを言ってるね！）

そうだね、2014年だった。shykesがDockerを発表したとき、HNにいたよ。LXCやjuju charms、Vagrantみたいな代替手段にうんざりしてたから、まさに神の恵みだった。2013年の発表はこちらだよね：https://news.ycombinator.com/item?id=5408002

下のコメントからだけど、これは時間を遡るってことを伝えるための短いタイトルって感じで、時計を合わせるためのものじゃないよ。記事は少し前にCACMに提出したんだ。レビューには時間がかかるし、「Dockerコンテナの12年」ってタイトルはあんまり雰囲気が合わなかったんだ。（CACMのレビュアーたちが記事をかなり改善してくれたから、あの時間は無駄じゃなかったよ！）

MLやAIがあらゆるものに押し込まれている今、イメージのサイズが膨れ上がってる。torchを依存関係に持つだけで数ギガバイトになるよね。30MBのイメージを目指してた頃が懐かしい。他の人もそう感じてるのかな？もしかして、何か間違ってるのかも。

ISOから動いてる不変のAlpine Linuxがあって、いくつかのDockerコンテナ（主にRubyとPHP）を含んでるんだ。全部で約750MBだよ。

> 開発者なら、私たちの目標はDockerを目に見えない存在にすることだよ。目に見えないだけじゃなくて、いなくなってほしい。Kubernetesがあれば、k3sやそれに似たものでローカルに使っても、コンテナを実行するためには使われないからね。でも、OCIイメージを作るためにはよく使われてる。Podmanがその隙間を埋めてくれるよ。Containerfile形式は同じ構文だけど、Dockerビルドよりもシンプルで、今はearthly.devに似たビルドオーケストレーション機能も提供してるから、別々に保つ方がいいと思う。