ディスカッション (11件)
Dockerが登場してから早いもので10年が経ちました。今や開発現場では当たり前となったコンテナ技術ですが、この10年間で私たちのデプロイや環境構築の常識は一変しました。Dockerが歩んできた軌跡を振り返り、エンジニアとしてその進化を噛み締めてみましょう。
ここに書いてある歴史的な話はマジで面白い。記事のスコープと詳細がどんどん広がっていく素晴らしい例だね。VPNのふりをして企業のIT「セキュリティ」ソフトに対抗したやり方は、かなり予想外だった。
Linuxアプリや依存関係の互換性を、抽象化で誤魔化すんじゃなくて、もっとシンプルにする取り組みが成功することを期待してるよ。
Dockerは、もともとPalm Pilot用だった1990年代のダイアルアップツール「SLIRP」を再利用した。ネットワークブリッジの代わりにホストのシステムコール経由でコンテナの通信を変換することで、企業のファイアウォール制限を回避したんだ。
純粋に魅力的で、賢い解決策だね!
「自分のマシンでは動く」っていう言い訳を業界標準のアーキテクチャ(「じゃあ、お前のマシンをそのまま本番環境に送っちゃおうぜ」)に変えてから、もう丸10年か。
「docker build」やDockerfileを置き換えようとする試みは山ほど見てきた。ビルドをより厳密に制御しようとしたり、特定のパッケージマネージャーにガチガチに紐付けようとしたりね。でもDockerfileが生き残ってきたのは、その柔軟性のおかげ。既知のファイルシステムやディストリビューションから始めて、ファイルをコピーして、その中で任意のコマンドを実行する。これが長年運用チームがやってきたこととうまく重なったんだ。その柔軟性がどれだけ不恰好だとしても、まだ当分はこれが主流であり続けると思うよ。
この記事の関連記事(OCamlの体験レポート)を書いてた時に気づいた、めちゃくちゃランダムな事実なんだけど:
「Docker、Guix、NixOS(安定版)はすべて2013年に初リリースされており、パッケージング愛好家にとっては豊作の年だった。」
今は毎週のようにコーディングAIエージェントのアップデートがあるけど、2013年みたいに素晴らしいプロジェクトが同時にいくつも登場した年って他にもあったっけ?
20年以上ガチなネットワーク周りの仕事はしてないし、この記事にあるような複雑な環境も経験ないから、ネットワークの話はほとんど理解できなかった。
MacでDocker動かす時にやりたいのは、コンテナにMac本体とは別のIPアドレスを持たせて、Mac上のアプリからそれが見えるようにすることなんだ。ポートマッピングなしでね。コンテナの80番ポートでWebサーバーが動いてるなら、127.0.0.1:2000とかじゃなくて「コンテナのIP:80」でアクセスしたい。
LinuxならDockerのブリッジネットワークを使えばいけると思うんだけど、Macだとハイパーバイザー上で動いてるLinux VMにブリッジされちゃうんだよね。
これ、公式に推奨されてるサポート済みのやり方ってあるのかな?
しばらくはLinux VMでWireGuardを動かしてMacとトンネルを作って、Linux VM側でフォワーディングを有効にしてた。結構長くうまく動いてたんだけど、なぜか止まっちゃって原因もわからず。で、また動くようになったり、止まったり。
その後、もっと自動化されてるこれ[2]に切り替えた。これもWireGuardを使ってる。しばらくは良かったんだけど、Dockerのアップデートでたまに壊れる問題が出てきた。
Mac版Dockerにこういう機能が最初から組み込まれてたら最高なんだけどな。
Dockerが2013年のPyCon US Santa Claraでデビューしたのを覚えてるから、「10年」っていう計算はちょっと違う気がしたんだ。
で、数年前に自分が書いたHNのコメントを見つけたら、やっぱりそうだった:
「[...] あの日のことは鮮明に覚えてる。同じライトニングトークのセッションで、Solomon HykesがまだdotCloudにいた頃にDockerをPythonコミュニティに紹介したんだ。これが、この件に関する最古の公開・記録された技術トークだと思う:」
YouTubeリンク: https://youtu.be/1vui-LupKJI?t=1579
注:1579秒から。26分19秒だね。
まあ、細かい話だけど。だいたい13年前か。このライトニングトークはコンピュータの歴史の一部として見ると面白いよ。
(追記:論文を読み進めたら、脚注にこのYouTubeのプレゼンかそのコピーが引用されてた。で、2013年のリリースについても言及されてる。もしかしたら、このタイトルでACMに論文が提出されてから出版されるまで数年のラグがあったのかも。これもまた、重箱の隅をつつくような話だけどね!)
今や何にでもMLやAIが詰め込まれるようになって、イメージサイズが爆増したよね。torchを依存関係に入れるだけで数GBになっちゃう。30MBのイメージを目指してた頃が懐かしいよ。
みんなも同じ感じ? それとも自分たちのやり方が何か間違ってるのかな。
当時は、2026年(※原文ママ)の自分たちのjupyter/MLイメージが22GBにもなるなんて予想もしてなかった。もっとマシな方法があるはずだよね。