IDP構築のポイント（1）：コンテナランタイム
以下の図はIDPをKubernetesで構築した例だ。プラットフォームエンジニアは開発者と協議して、必要な要求を適用してプラットフォームを提供する。開発者はこのプラットフォームを活用して、アプリケーションをコンテナ化するだけで良い。
「なぜコンテナがIDPの構築に適しているかと言えば、先に挙げたプラットフォームエンジニアリングの3つの目標と、コンテナのメリットがマッチしているからである」と語るのは、続いて登壇した同社の岡田雄真氏だ。
「なかでも、デプロイが頻発するような開発環境においては、コンテナの『Quick Deployment（迅速なデプロイ）』や『Portability（可搬性）』『Consistency（一貫性）』といった特徴が効いてくる。また、バーチャルマシンと比較しても、コンテナはゲストOSのカーネルを必要としない分、オーバーヘッドが軽くなり、迅速に起動できるメリットがある」（岡田氏）
次に、コンテナの内部構造について話が及んだ。
コンテナを構築・操作する際に内部で実行されているソフトウェアを「コンテナランタイム」という。コンテナランタイムには、高レベルと低レベルがあり、それぞれ次のような役割がある。
- 高レベルコンテナランタイム：コンテナイメージの取得や、コンテナネットワークやストレージの管理を行う。（代表例：CRI-O・containerd・Docker・libpod）
- 低レベルコンテナランタイム：高レベルランタイムからの指示を受け、コンテナの作成や削除を実行する。（代表例：runc・kata-runtime・gVisor）
まず、Kubernetesのようなコンテナオーケストレーションシステムと、高レベルコンテナランタイムがやりとりをする。その際のインターフェースとなるのが「CRI（Container Runtime Interface）」というKubernetes向けに標準化された規格である。
次に、「OCI（Open Container Initiative）」というコンテナ技術の標準仕様を策定する団体が定めた規格に則り、高レベルコンテナランタイムが低レベルコンテナランタイムとやりとりを行う。
そして最後に、低レベルコンテナランタイムが実際にコンテナの操作を行う。
「Dockerがリリースされた当時は、『コンテナ＝Docker』と評されるほど、Dockerは支配的なポジションを築いていた。しかしDockerはCRIに対応しておらず、Kubelet（Kubernetesのノード管理エージェント）がDockerエンジンとやりとりするには、Docker Shimという中間レイヤーが必要だった。他にもいくつかの課題もあり、Docker依存を解消するために進化してきたコンテナランタイムもある。このようにコンテナランタイムが進化すると、実運用ベースでの切り替えが発生することがあるため、プラットフォームエンジニアはトレンドをきちんと押さえておくことが重要だ」（岡田氏）
