2018年08月09日 08時00分 公開
特集/連載

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

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

[Daniel Robinson,Computer Weekly]

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

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

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

なお、同コンテンツの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つの異なる方法で対処する新たな開発が進んでいる。

この記事を読んだ人にお薦めの関連記事

注目テーマ

ITmedia マーケティング新着記事

news011.jpg

今どきシニア、半数が帰省してくる子や孫の交通費を負担――あおぞら銀行調べ
あおぞら銀行は、55〜74歳の男女約2000人を対象に「シニアのリアル調査」を実施し、結果...

news040.jpg

AIが業務要件に合わせてテキスト解析、データセクションがサービス提供
データセクションは、顧客の抱える課題や要望に合わせてカスタマイズ可能なAIテキスト解...

news015.jpg

バーチャルYouTuberが半年で4000人以上に――ユーザーローカル調べ
ユーザーローカルはCyberVと協力し、バーチャルYouTuberの市場成長ついて分析しました。