[ITリーダーが知るべきコンテナ技術]

2017年4月7日(金)三木 雄平（レッドハット）

リスト

　Dockerはシンプルなコマンドと「Dockerファイル」という設定ファイルによって、アプリケーションと、そのアプリケーションが依存するミドルウェアやOSのライブラリなどをひとくくりにパッケージ化し、別環境に転送（ロード）して動作させる機能を提供しました。これが「イメージ化」です。開発者が自分のマシンのOS上でイメージ化したアプリケーションを、別のマシン上のOSやクラウド上に送っても実行できる、つまりポータビリティを提供したのです。

　第1回で説明したように、デプロイメントの作業が複雑で人手が必要になっていた原因の根底には、このミドルウェアやOS、ライブラリのバージョンなどの依存関係の構成や設定がありました。この依存関係を丸ごとイメージ化し別環境に持ち込めるようにすることで、デプロイメントにおける設定や設定のためのドキュメントの作成時間を大幅に減らすことに成功したのです。

　DockerはLinuxを想定したコンテナ管理技術のため、OSがLinuxであることが大前提でした。それも前回記載したように、米Microsoftが次期WindowsサーバーではDockerに対応すると発表するなど、Linuxに限定されない技術になっているという点も大きなポイントです。

ハイパーバイザー型仮想化とは発想が異なる

　筆者はいろいろな場所でコンテナについて説明する機会があります。その際、コンテナと多くの企業で利用されているハイパーバイザー型仮想化の違いについて質問を受けることがよくあります。そこで簡単に説明しておきます。

　繰り返しになりますがコンテナ、特にDockerコンテナはアプリケーションをイメージ化して別の環境（サーバーなど）にデプロイメントするための技術です。これに対して仮想化は、インフラを構築するための技術だと言えます（図2）。

図2：コンテナ技術とハイパーバイザー型仮想化技術の比較。左がコンテナ、右が仮想化
拡大画像表示

　確かにハイパーバイザー型の仮想化技術でも、OSの細かな設定やミドルウェアなどを仮想サーバーとして隠蔽（隠ぺい）し、それを丸ごと別の環境（マシン）にデプロイすることは可能です。しかし、このハイパーバイザー型仮想化ではホストOSやライブラリなどを必要とするため、仮想イメージのサイズが大きくなってしまいます。

　対してコンテナでは、OSのカーネルやライブラリのほとんどをデプロイメント先の環境で提供されているものを共通で利用するため、イメージのサイズが小さくて済むメリットがあります。イメージが小さくできれば、システム資源のオーバーヘッドや起動時間、バージョン管理のしやすさなど、様々なメリットが生まれます。アプリケーションを構成するモジュール（部品）をコンテナとして作り、多数のコンテナを組み合わせて1つのアプリケーションを構成する「マイクロサービス・アーキテクチャー」も、メリットの1つです。