runc（ランシー）

2025年11月5日

runc（ランシー）

英語表記: runc

概要

runcは、コンテナ技術（Docker, Podman）の根幹を支える、軽量でポータブルなコマンドラインインターフェース（CLI）ツールです。これは、コンテナの実行に関する業界標準であるOCI (Open Container Initiative) ランタイム仕様のリファレンス実装として開発されました。高レベルのコンテナ管理ツール（Dockerやcontainerdなど）が、実際にコンテナという隔離された環境をホストOS上に生成・実行する際、その現場の実行役として機能しています。

runcの最大の使命は、コンテナ技術（Docker, Podman）の文脈において、どのコンテナエンジンを使っても、標準化された方法でコンテナが起動されることを保証することにあります。

詳細解説

runcは、階層構造における「コンテナ技術」の中の「コンテナランタイム」の中でも、特に「低レベルランタイム」に分類されます。これは、コンテナの実行環境を直接OSカーネルの機能を使って構築する、非常に重要な役割を担っています。

runcの目的と背景

コンテナ技術が爆発的に普及する中で、異なるベンダーやツール間でコンテナの動作に互換性を持たせることが急務となりました。そこで、Linux Foundationの下でOCIが設立され、コンテナの「イメージフォーマット」と「ランタイム動作」の標準仕様が策定されました。runcは、このOCIランタイム仕様を完全に満たすためにDocker社（当時）によって開発され、後に独立したプロジェクトとして寄贈されました。

この標準化のおかげで、私たちは「ランタイム比較」を行う際に、runcを基準点として考えることができます。DockerやPodmanといったユーザーが直接触れるツールは、コンテナのライフサイクル管理やネットワーク設定、イメージのプルなどの高レベルな操作を担当しますが、最終的に「コンテナプロセスを起動する」という最も根源的な作業はruncに委ねられるのです。

主要な動作原理とコンポーネント

runcがコンテナを実行するプロセスは、非常にシンプルかつ強力です。

OCI設定ファイルの読み込み: runcは、コンテナの実行に必要なすべての情報が記述されたconfig.jsonという設定ファイルを受け取ります。このファイルには、コンテナ内で実行するコマンド、環境変数、マウントするボリューム、そして何よりも重要な分離設定（CgroupsとNamespacesの設定）が含まれています。
OSカーネル機能の活用: runcは、受け取った設定に基づき、Linuxカーネルが提供するCgroups (Control Groups) とNamespacesという二大分離技術を駆使します。
- Namespaces: プロセスID、ネットワーク、ユーザー、ファイルシステムなど、OSリソースをコンテナごとに論理的に分離し、隔離された環境を作り出します。
- Cgroups: CPU、メモリ、I/Oなどの物理リソースの使用量を制限し、ホストOSや他のコンテナへの影響を防ぎます。
コンテナプロセスの起動: これらの分離と制限が設定された後、runcは指定されたルートファイルシステム内で、コンテナのメインプロセスを起動します。

runcは、コンテナ技術（Docker, Podman）の安定性と移植性を確保するための、目に見えない土台と言えるでしょう。この低レベルな標準化があるからこそ、私たちは複雑なことを気にせずにコンテナを利用できるのです。

runcと高レベルランタイムの関係

コンテナ技術のスタックは、しばしば三層構造で説明されます。

最上位層（ユーザーインターフェース）: Docker CLI, Podman CLIなど。ユーザーが直接操作します。
中間層（高レベルランタイム）: containerd, CRI-Oなど。コンテナイメージの管理、ネットワーク、ストレージ管理、そして低レベルランタイムの呼び出しを担当します。
最下層（低レベルランタイム）: runc。実際にOSカーネルと対話し、コンテナプロセスを生成します。

runcは中間層のツールによって呼び出されるため、コンテナランタイムの「ランタイム比較」を行う際、runcは「最も標準的で、最も直接的にOSに依存する実行基盤」として比較のベンチマークとなります。

具体例・活用シーン

runcは通常、ユーザーが直接操作するツールではありませんが、その役割を理解することは、コンテナ技術の全体像を把握する上で非常に役立ちます。

1. 現場の熟練職人という比喩

runcの役割を理解するために、コンテナ技術を「都市開発プロジェクト」に例えてみましょう。

DockerやPodman（現場監督）: 顧客（ユーザー）からの要望を聞き、プロジェクト全体を管理します。彼らは「この場所にウェブサーバーを、あの場所にデータベースを」と指示を出します。
containerdやCRI-O（設計士）: 現場監督の指示に基づき、詳細な設計図（OCIの設定ファイル）を作成し、必要な資材（コンテナイメージ）を手配します。
runc（現場の熟練職人）: 設計士が作成した設計図（config.json）を受け取り、実際に建物を建てる（コンテナを起動する）唯一の存在です。runcは、OSカーネルという「土地」の上で、Namespacesという「壁」とCgroupsという「資源制限」を施し、隔離された部屋（コンテナ）を迅速に作り上げます。

現場監督（Docker）が変わっても、設計士（containerd）が変わっても、熟練職人（runc）がOCIという共通の建築基準に従って作業するため、完成するコンテナは常に標準的な品質を保つのです。これが、コンテナ技術（Docker, Podman）が持つポータビリティの秘密であり、ランタイム比較の際にruncが「標準」として扱われる理由です。

2. トラブルシューティングでの活用

普段はruncの存在を意識しませんが、コンテナの実行時に低レベルな問題（例：Cgroupsの制限超過、カーネルレベルの分離問題）が発生した場合、runcの動作を理解していると原因究明が容易になります。

例えば、containerd経由でコンテナが起動しない場合、ユーザーは直接runcを実行し、OCI設定ファイルを与えてみることで、問題が中間層（containerd）にあるのか、それとも実行基盤（runcとOSカーネル）にあるのかを切り分けることができます。これは、コンテナ技術の深い理解を必要とする、応用的な活用シーンです。