コンテナランタイムの内部（runc・OCI仕様）

コンテナ起動は「仕様に沿った組み立て作業」

「コンテナを起動する」という1コマンドの裏では、複数の独立した部品が決められた順序で組み上がっています。その設計図を標準化したのが OCI（Open Container Initiative） の仕様群です。コンテナは独自の実行形式ではなく、名前空間と cgroups というカーネル機能を、仕様どおりに組み合わせて作る 隔離されたプロセス にすぎません。

OCIには大きく2つの仕様があります。イメージ仕様は「持ち運ぶ配布物」を、ランタイム仕様は「展開して動かす実体」を規定します。両者を分けることで、ビルドツール・レジストリ・ランタイムが互いを知らなくても相互運用できます。

イメージ仕様：レイヤと内容アドレス

OCIイメージは複数の レイヤ から成ります。各レイヤはファイルシステムの差分を収めたtarアーカイブで、削除は .wh.<名前> というwhiteoutファイルで表現されます。実行時にはこれらを下から順に重ね、overlayfs などで1枚のrootfsに合成します。レイヤを重ねる方式により、共通の下位レイヤを複数イメージで共有でき、ディスクと転送量を節約できます。

イメージの一貫性を支えるのが 内容アドレス（content-addressable） です。各要素は sha256:... のダイジェストで指され、manifestがlayer群とimage configのダイジェストを列挙し、configがエントリポイントや環境変数を保持します。中身が1バイトでも変わればダイジェストが変わるため、改竄や取り違えを検知できます。なお config.json という名前はイメージ仕様（image config）とランタイム仕様（runtime config）の両方に登場しますが、別物である点に注意してください。

ランタイム仕様：バンドルとconfig.json

high-level側がイメージを展開すると、rootfs/ ディレクトリと config.json を含む バンドル（OCI bundle） ができます。この config.json こそがランタイム仕様の中心で、「どう隔離し、どの権限を与え、何を実行するか」を 宣言的に 記述します。runcはこの宣言を読み、対応するカーネル操作へ翻訳するだけの存在です。

// config.json（抜粋・概念図）
{
  "process": {
    "args": ["/bin/sh"],
    "capabilities": { "bounding": ["CAP_CHOWN", "CAP_NET_BIND_SERVICE"] },
    "noNewPrivileges": true
  },
  "linux": {
    "namespaces": [ { "type": "pid" }, { "type": "mount" }, { "type": "network" } ],
    "resources": { "memory": { "limit": 536870912 } },
    "seccomp": { "defaultAction": "SCMP_ACT_ERRNO" }
  }
}

ランタイムの状態は OCI state（id・status・pid を持つJSON）として表現され、create → start → kill → delete というライフサイクル動詞で操作します。create で隔離環境を準備して停止状態にし、start で初めてユーザープロセスを走らせる二段構えになっているのが要点です。

runcの組み立て手順：順序が安全性を決める

runcが config.json を実体化する流れは、順序が安全性に直結 します。たとえば権限を落とす前にユーザープロセスを起動してはいけません。概略は次のとおりです。

1. 名前空間の作成：clone(2)/unshare(2) に CLONE_NEWPID などのフラグを渡し、必要な名前空間を作る。rootlessでは最初にuser名前空間を作って内側rootを得る。
2. cgroupへの登録：cgroup v2 のサブツリーを作り、新プロセスのPIDを cgroup.procs へ書き込んでCPU・メモリ上限を効かせる。
3. rootfsの切り替え：マウントツリーをprivate化し、pivot_root(2) で新rootへ差し替えてから古いrootを umount し、参照を断つ。
4. マウント整備：/proc・/sys・/dev などをconfig指定どおりにマウントし、必要箇所をread-only化する。
5. 権限の確定：no_new_privs を立て、bounding setからcapabilityを削り、最後にseccompフィルタを取り付ける。
6. execve：上記をすべて適用した状態で、初めてユーザープロセスを execve(2) で起動する。

実装上の難所が、execveの直前に動く小さな補助プロセス init の存在です。clone直後の子プロセスはまだ隔離設定が済んでおらず、親から指示を受けて自分自身に名前空間参加・rootfs切替・権限縮小を適用してからexecveします。runcはこのブートストラップ部分をCで書き直し（nsexec）、Goランタイムがスレッドを起動する前に名前空間を確定させることで、マルチスレッドと setns(2) の相性問題を回避しています。

high-level と low-level の分業

docker run 一発の裏には階層化された分業があります。境界線にOCIランタイム仕様を置くことで、各層を差し替え可能にしているのが設計の妙です。

low-levelランタイムは 使い捨て である点が重要です。runcはコンテナを起動するとexecveで消え、常駐しません。コンテナの親プロセス（PID 1 の見守り役）を務めるのは shim で、これによりhigh-levelデーモンを再起動・更新してもコンテナが道連れに死なずに済みます。shimは終了コードの回収や標準入出力の中継も担います。

まとめ