OCI 仕様 - OCI spec
OCI はコンテナのイメージ・実行・配布形式を標準化する業界団体。Image Spec / Runtime Spec / Distribution Spec の 3 本柱で、Docker・Podman・containerd などが同じ成果物を扱える。
概念図
構文
bash
OCI の 3 仕様
OCI は 2015 年に Docker 社の寄贈をきっかけに設立された Linux Foundation 配下のプロジェクトで、次の 3 つの仕様を策定・保守しています。
| 仕様 | 対象 | 中身 |
|---|---|---|
| Image Spec | イメージ形式 | レイヤー（tar + gzip）、マニフェスト、コンフィグ（env・cmd・user 等）の JSON フォーマット |
| Runtime Spec | 実行時の仕様 | ルートファイルシステムと config.json（namespace・cgroups・capabilities 等）からコンテナを起動する手順 |
| Distribution Spec | レジストリ API | push / pull / manifest / blob の HTTP API（旧 Docker Registry V2） |
これらはそれぞれ独立した GitHub リポジトリ（opencontainers/image-spec 等）で管理されています。
仕様が揃うと何が嬉しいか
3 つの仕様があることで、ツール間で成果物を自由に持ち運べます。
例えば Docker でビルドしたイメージを GitHub Container Registry（GHCR）にプッシュし、本番では Podman で pull して Kubernetes の containerd が起動する、という構成が破綻なく成立します。
また、イメージに関する新機能（マルチアーキテクチャのマニフェストリスト、sigstore による署名、SBOM の添付など）も、仕様として標準化されることで特定ベンダーへのロックインを避けられます。
実装との対応（Docker / Podman / containerd）
主要な実装はそれぞれ OCI の各層を担っています。
| コンポーネント | カバーする層 | 役割 |
|---|---|---|
| Docker Engine | 全層 | CLI + デーモン + ビルダー。内部で containerd と runc を使う |
| Podman | 全層 | daemonless な Docker 互換 CLI。runc / crun を利用 |
| containerd | Image + Runtime | Kubernetes の CRI 実装として広く使われる高水準ランタイム |
| runc | Runtime Spec | 実際に namespace・cgroups を組んで init プロセスを起動する低水準ランタイム |
| CRI-O | Image + Runtime | Kubernetes 専用の高水準ランタイム。軽量な実装方針 |
| Harbor / Distribution / GHCR / ECR | Distribution Spec | レジストリサーバ |
「Docker」という 1 つの塊に見えていても、内部はこの層構造に分かれているため、部分ごとに別の実装に差し替えられます。
関連トピック
linux namespaces- Linux Namespaces はプロセスごとに「見える世界」を分離する仕組み。PID・Mount・Network・UTS・IPC・User・cgroup の 7 種があり、コンテナのプロセス隔離の中核を担う。 cgroups- cgroups（Control Groups）はプロセス群の CPU・メモリ・IO などのリソース使用量を制限・計測する Linux カーネルの仕組み。namespace と対になってコンテナの基盤を成す。 container vs VM- コンテナと VM はどちらもワークロードを隔離する技術だが、カーネル共有の有無で性能・密度・隔離強度が大きく変わる。用途ごとに使い分ける。 Firecracker / gVisor / Kata- Firecracker・gVisor・Kata Containers はコンテナの軽さと VM の強い隔離を両立させるための技術。AWS Lambda など、信頼できないコードを大量に安全に動かす場面で使われる。