非Dockerコンテナ技術もDockerとKubernetesのさらに先へ拡大するコンテナエコシステム

Kubernetesの登場でオーケストレーションに一定の成果を見たDockerのエコシステム。だが、コンテナの世界はさらに進化しようとしている。

[Daniel Robinson，Computer Weekly]

　コンテナはここ数年で大きく進化し、ニッチな技術から最新のクラウドネイティブアプリケーションやサービスの導入に欠かせないプラットフォームになった。コンテナの導入増加に伴い、そのエコシステムも進化を続けている。

Computer Weekly日本語版　8月8日号無料ダウンロード

本記事は、プレミアムコンテンツ「Computer Weekly日本語版　8月8日号」（PDF）掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

• Computer Weekly日本語版　8月8日号：DockerとKubernetesのさらに先

なお、同コンテンツのEPUB版およびKindle（MOBI）版も提供しています。

　コンテナという考え方は、PCのリソースを分割する方法として古くから存在する。これは、仮想マシンの考え方にも似ている。

　仮想化はベアメタルレベルで運用される。これに対しコンテナはOSカーネルから提供され、事実上、個別のアプリケーションやコードモジュールごとに独立した実行環境を提供する。

　Docker社が技術とツールを組み合わせてコンテナに新たな力を与えるまで、企業は仮想マシンの使用を非常に重視していた。だが、こうした技術とツールは、コンテナプラットフォームをアジャイル開発向けの最適な手段へと変貌させている。

　コンテナは仮想マシンよりも軽量かつ迅速に導入できる。これにより、企業はマイクロサービスベースのアーキテクチャを採用し、DevOps構想を導入できるようになった。

　「Docker」が2013年にリリースされて以来、コンテナのエコシステムは急速に拡大している。初期のコンテナ技術には、オーケストレーションや負荷分散など、仮想マシンを中心に成長してきたサポートツールや機能の多くが欠如していた。そのため、開発者はそのギャップを急ピッチで埋めざるを得なかった。それがエコシステムの拡大につながっている。

エコシステムの構築

　オーケストレーションの点では、「Kubernetes」が他を大きく引き離したという認識が広がっている。Kubernetesは、オンサイト導入のコンテナプラットフォームとして導入数を増やしているだけでなく、全ての大手クラウドプロバイダーがオーケストレーション層としてKubernetesを組み込んだコンテナサービスを提供している。

　一方、コンテナランタイム（実際にコンテナを実行するエンジン）など、コンテナを支える基礎テクノロジーや、コンテナイメージの格納と配布用ファイルフォーマットの標準化を進めようとする動きも行われている。

　ランタイムについては、これを監督するためにLinux Foundationの支援下でOpen Container Initiative（OCI）が設立された。また、Docker社は同社独自のテクノロジーに基づくレファレンス実装として、基本機能を備えたランタイム「runC」を公開することによってこれに貢献している。

　続いて、Docker社は独自の用途のためにさらに機能を充実させたランタイム「containerd」にrunCを組み込んだ。その後、同社はKubernetesを監督する団体でもあるCloud Native Computing Foundation（CNCF）にcontainerdを引き渡した。

　Docker社はcontainerdを自社製品にも使用している。containerdはrunCを組み込んでいるため、containerdもOCI仕様に準拠する。

　その後しばらくして、標準コンテナイメージ形式の仕様を作成する作業部会がOCIで編成される。この仕様の作成にはDocker社も協力し、完成したOCIの形式を「Image Manifest V 2」としてDockerのプラットフォームに組み込んでいる。

　結果として、コンテナランタイムとコンテナイメージ両方の新たな標準が策定された。最終的には全てのコンテナランタイムがOCI標準に従うと想定される。つまり、インフラの他の部分もOCIに準拠していれば、コンテナ導入の一環としてさまざまなソースのソフトウェアコンポーネントを比較的簡単に混在させ、適合させることが可能になる。

コンテナセキュリティの難題の解決

　コンテナの利用を考えている企業が行き詰まるのは、コンテナのセキュリティを確保する方法に原因がある。仮想マシンの展開においてハイパーバイザーが行うレベルの分離が、コンテナのインスタンス間に適用されないためだ。

　ホストマシンで実行される全てのコンテナは同じ共有カーネルへの呼び出しを通じてリソースにアクセスする。そのため、脆弱（ぜいじゃく）性が潜んでいると、1つのコンテナ内のコードから他のコンテナにアクセスできる可能性が残る。

　この問題に2つの異なる方法で対処する新たな開発が進んでいる。

続きはComputer Weekly日本語版　8月8日号にて

本記事は抄訳版です。全文は、以下でダウンロード（無料）できます。

• Computer Weekly日本語版　8月8日号：DockerとKubernetesのさらに先

■Computer Weekly日本語版 最近のバックナンバー

Computer Weekly日本語版　7月18日号　トイザらスとAmazon成功の分かれ目

Computer Weekly日本語版　7月4日号　EUの罰金リスクはGDPRだけではない

Computer Weekly日本語版　6月20日号　SSDより速いストレージクラスメモリ