OCI文書を読むときは、imageに何が含まれるか、registryがどう転送するか、runtimeがどうcontainerを起動するかを分けます。Open Container InitiativeはImage、Distribution、Runtimeの各Specificationを別々に公開しています。OCI概要は全体の流れを示し、containerdのcontent-flow説明はregistryから実行用filesystemまでを追っています。

三つの仕様は別の境界を扱う

  • Image Specificationはmanifest、config、layerなどimageデータの構造を扱います。
  • Distribution Specificationはimageやartifactを検索・upload・downloadするregistry APIの相互運用規約です。registry製品の内部設計すべてを定めるものではありません。
  • Runtime Specificationは準備済みfilesystem bundleと設定からcontainer processを生成・実行する方法を扱います。

imageのpullにはDistributionとImageの観点が、ローカルprocessの起動にはRuntimeの観点が関係します。OCI準拠だけで製品のscheduler、network、完全な権限policyまで決まるわけではありません。

tagから実行filesystemまでを追う

example/app:stableのような名前は便利ですが、実体の解決が必要です。containerdの説明では、registryはmanifest単体または複数platformのmanifestを指すindexを返すことがあります。indexなら対象OSとCPU architectureに合うmanifestを選び、digestを使ってconfigとlayerを取得します。layerを順に展開してsnapshotを作り、containerで書き込み可能なfilesystemを準備します。

「imageを実行する」までには複数の境界があります。同じtagでもhostごとに別platformのmanifestが選ばれることがあります。registryからのpull成功は、unpackやprocess起動の成功を意味しません。障害時はresolved digestとplatform、layer展開、runtime起動を別々に確認します。

runtime仕様とdaemonを区別する

OCI Runtime Specificationはlow-levelのbundleと実行設定を記述します。containerdのような上位projectはimage転送やstorage、lifecycleを調整し、その後OCI互換runtimeを呼び出す構成を取れます。標準interfaceとdaemonを区別すると、image処理、実行準備、process起動のどこで失敗したかを絞れます。

Windows containerが常にHyper-V分離とは限らない

OCI runtime仕様にはWindows専用設定があります。Windows設定文書はWindows Host Compute Service APIの利用を説明します。optionalなhyperv項目を設定するとHyper-V isolationが必須となり、省略するとWindows Server containerとして実行すると定義されています。したがってWindows containerをすべてLinux VMと説明するのは誤りです。host OS、runtime、deployment設定を併せて確認してください。

障害調査の順番

registryの問題ならDistribution APIと応答、platform不一致やlayer不足ならimage index・manifest・digest、process起動失敗ならruntime bundle・host固有設定・実行engineを確認します。層を分けると「OCIが壊れた」という曖昧な診断を検証できる原因に変えられます。

参考資料