「Dockerは奇妙」自作コンテナランタイムで学んだ5つの事実
原題: Docker is weird
なぜ重要か
コンテナ技術の内部構造を平易に解説した本記事は、DockerやKubernetesを業務で使う開発者・SREがセキュリティと設計トレードオフを正しく理解する上で参考になる。
個人開発者がブログ「Code and Cake」で、自作コンテナランタイム制作中に発見したDockerの内部構造を公開した。コンテナの実体がプロセスであること、imageがフォルダであること、GoがDockerの実装言語として抱える設計上の制約など、5つの具体的な技術的知見をまとめている。
ブログ「Code and Cake」を運営する開発者が2026年10月22日、自作コンテナランタイムを制作する過程で発見したDockerの技術的な特性を公開した。
まず指摘されたのは「コンテナはプロセスに過ぎない」という点。VMとは異なり、コンテナはホストのLinuxカーネルが動かす通常のプロセスであり、/proc配下から確認できる。さらに「コンテナ」という単一のLinux機能は存在せず、実態はNamespace（可視範囲の隔離）、cgroups（リソース制限）、ネットワーク仮想化など5つのカーネル機能の組み合わせだ。
Imageの構造についても明快に説明している。Imageは単なるフォルダであり、Dockerはそのフォルダをchroot（またはpivot_root）でプロセスの新しいルートディレクトリとして設定するだけだ。
DockerのコンテナランタイムruncがGoで書かれている点についても問題を挙げた。Goのランタイムはネイティブでマルチスレッドだが、コンテナランタイムが必要とする多くのLinux syscallはシングルスレッド環境で実行しなければならない。そのためruncはGoランタイムの初期化前に実行されるCモジュールを持つ。またGoにはforkが存在せず、runcは/proc/self/exeを特殊な引数付きでexecすることでforkを近似的に実現している。
最後に権限の問題。Linuxカーネルの多くのAPIがroot権限を要求するため、Dockerデーモンは基本的にrootで動作する。rootlessモードでは、同等の機能を提供するためにネットワークスタック全体をユーザー空間で再実装しなければならないという課題がある。