OCI とは？コンテナの背後にあるオープン標準

Open Container Initiative（OCI）は、コンテナイメージと runtime のオープン標準を定義します。あるツールで build したイメージが別のツールで動くのは、そのためです。

コンテナが移植可能なのは、業界が共通のフォーマットに合意したからにほかなりません。Linux Foundation 傘下のプロジェクトである OCI が、それらの仕様を維持しています。それらは、「Docker イメージ」が実は「OCI イメージ」を意味する理由であり - そして Podman、containerd、BuildKit、Kubernetes がすべて同じ artifact を build・実行できる理由です。

3つの仕様

• Image spec - コンテナイメージのフォーマット（layer、manifest、config）。
• Runtime spec - 展開されたイメージからコンテナをどう実行するか。
• Distribution spec - イメージを push・pull するための registry API。

標準化が重要な理由

OCI 以前は、イメージと runtime のフォーマットがベンダーごとに断片化する恐れがありました。標準があることで、異なるチームが作った build ツールと runtime が相互運用します - 1つのベンダーの stack にロックインされません。

日常的な言葉での OCI

人が「Docker イメージ」「container registry」「container runtime」と言うとき、その根底にある取り決めは OCI 仕様です。Docker が概念を普及させ、OCI がそれらを誰もが実装するオープン標準にしました。

コンテナを超えて

OCI の distribution spec は今や、コンテナイメージ以上のものを保存するのに使われています - Helm chart、SBOM、その他の artifact が同じ registry プロトコルに乗り、registry を汎用の artifact store にしています。

CI が恩恵を受ける理由

OCI の移植性により、適したツール（Docker、buildx、Buildah）で build し、OCI に対応するどこでも実行できます。マネージド runner は標準の OCI イメージを素早く build して任意の OCI registry に push し、一時的な失敗を retry するため、標準的な pipeline がそのまま機能します。

重要なポイント

• OCI は、コンテナのイメージ、runtime、registry のフォーマットを標準化します。
• これらの標準こそが、イメージがツールやベンダー間で移植可能である理由です。
• distribution spec は今やイメージだけでなく、chart や他の artifact も保存します。

関連ガイド