Dockerコンテナの中身が進化！標準化や堅牢性の実現へ | 東京エレクトロンデバイス

積極的な標準化策が生んだOCIとCRIという重要な標準

Dockerコンテナの基本となる技術は、Dockerの登場以前から「コンテナ型仮想化」として知られており、いくつかの実装も存在していました。しかし、そのコンテナ型仮想化が広く普及したのは、Docker社による「Dockerコンテナの実装」が登場したおかげであることは誰の目にも明らかです。

当初、Dockerコンテナはその名の通り、Docker社による独自のコンテナ型仮想化の実装でしたが、オープンソースとして公開されたことや、同社が（おそらく創業者であるソロモン・ハイクス氏の意向により）Dockerコンテナの標準化に積極的だったこともあり、Dockerコンテナの標準化は比較的早期に実現されています。

Dockerコンテナが広く注目され始めたのは2013年頃であり、2014年に「Docker 1.0」が登場。その翌年の2015年にはDocker社とGoogle、Red Hat、VMware、Amazon Web Services（AWS）らが、Dockerコンテナ関連の標準化を目指して「Open Container Project」を発足させました。団体の名称はその後「Open Container Initiative」（OCI）に改められ、2017年に最初の標準である「OCI 1.0」が発表されました。

余談ですが、現時点で一般に「Dockerコンテナ」と呼ばれる実装は、すでにDocker社による実装だけではなく、他社の実装も含めて広くOCIの標準に基づくコンテナ型仮想化の実装を含むことになるため、本来なら「Dockerコンテナ」というよりも「OCIコンテナ」と呼ぶ方が正しいように思われます。

しかし現実には、OCIコンテナという呼び方はあまり一般的ではないため、Docker社以外の実装であってもDockerコンテナの一種もしくは派生物的な意味も込めて「Dockerコンテナ」と呼ばれているのが現状です。本記事でも同様の意味で「Dockerコンテナ」という用語を使っています。

さて標準仕様として策定されたOCIは、コンテナランタイムの標準仕様である「Runtime Specification」と、コンテナイメージフォーマットの標準仕様である「Format Specification」の2つから構成されます。OCI Runtime Specificationの仕様を満たしている実装であれば、どの実装であっても置き換えて使うことができるし、OCI Format Specificationを満たしているコンテナイメージであれば、同じくあらゆるDockerコンテナのランタイムから読み込んで実行することができるということになります。

もう1つ、Dockerコンテナ関連で重要な標準が、2017年にKubernetesの開発チームによって策定されています。それがKubernetesとDockerコンテナのランタイムの間で使われるAPIである「CRI」（Kubernetes Container Runtime Interface）です。このCRIに沿っていれば、KubernetesからDockerコンテナのランタイムを呼び出すことができます。

OCIとCRIは、現在でもDockerコンテナ関連の重要な標準です。そして、こうした標準仕様の登場により、Dockerコンテナは新たな発展を始めたのです。

標準化でさらに発展する「Dockerコンテナのエコシステム」

標準仕様とAPIが策定されたことで、Docker社以外からもDockerコンテナのランタイムが登場するようになり、ユーザーはさまざまなランタイムの選択肢を得られるようになりました。

その代表的な例として、ここではGoogleの「gVisor」とAWSの「Firecracker」を挙げておきます。

このOSのユーザー空間を分割するというDockerコンテナの特徴は、ある弱点も生み出しています。それは分離レベルが低いという点です。分離レベルが低いと、同一ホスト上で複数のコンテナが動作しているとき、あるコンテナがクラッシュした場合、隣りにあるコンテナがその巻き添えを食らう可能性があります。あるいは同一マシンのあるコンテナがCPUやメモリを大量に使用する重い処理を開始した場合、別のコンテナがそのあおりを受けて処理が遅くなるといったことが起こり得ます。

この分離レベルが低いという従来のDockerコンテナの弱点を、それぞれのアプローチで解決したのがGoogleのgVisorとAWSのFirecrackerです。

それぞれのアプローチを手短に解説すると、AWSのFirecrackerでは分離レベルの高い従来のハイパーバイザー型の仮想マシンの仕組みを徹底的に軽量化したmicroVMという技術を用いつつ、Dockerコンテナの標準仕様にも対応することによって、「高い分離レベルを実現したうえで軽量」という特長をDockerコンテナに持たせることに成功しました。

一方、GoogleのgVisorでは従来のコンテナ型仮想化の仕組みを改良して、カーネルをクラッシュさせそうなシステムコールを安全に処理できるゲストカーネル機能をコンテナランタイムに持たせることで、「クラッシュしにくく安全」というコンテナランタイムを実現しました。

目的に合わせてDockerコンテナを使いこなす時代へ

このように標準仕様が策定されたことで、それぞれに特長を備えたさまざまなDockerコンテナの実装が登場するようになりました。

本家のDocker社も先日、より分離レベルの高いコンテナランタイム「Sysbox」の開発元であるNestybox社の買収を発表したばかりです。今後もさまざまな特長を持つコンテナランタイムが登場してくることでしょう。

標準仕様に対応したコンテナランタイムは自在に入れ替えて使うことができます。そのため、例えば開発環境向けには分離レベルがそれほど高くなくてもいいので「より軽量なもの」を、本番環境向けには「セキュアな高い分離レベルのもの」を選んで利用するといった、環境と目的ごとにDockerコンテナを使いこなすことが当たり前になっていくのではないかと思われます。