Dockerは、今日最も影響力のあるオープンソースプロジェクトであることは間違いありません。なぜDockerはこれほどの成功を収めたのでしょうか？Dockerは仮想マシンに取って代わるのでしょうか？そして、この変革は将来、大きな転換点を迎えて突如として起こるのでしょうか？もしそうなら、それはいつ起こるのでしょうか？

これらの疑問に答えるために、まずはこれまでの開発プロセスを簡単に振り返ってみましょう。そうすることで、現状をより深く理解し、将来を見据えることができるかもしれません。

仮想マシン技術が広く普及する以前は、システム管理者はユーザーにサービスを提供するために物理サーバーを導入するのが一般的でした。このプロセスは煩雑で、完全に自動化できず、数時間、あるいは数日かかることもありました。問題が発生した場合は、データセンターに出向いて物理コンポーネントを交換する必要がありました。

仮想マシンの登場により、DevOps担当者は任意の物理サーバーにハイパーバイザーをインストールし、ユーザーからのリクエストに応じて新しい仮想マシンを直接割り当てることができるようになりました。仮想マシンの導入はもはや数時間ではなく数分で完了し、自動化も可能です。基盤となるハードウェアの違いは減少し、ビジネス指向のソリューションが普及しつつあります。ユーザーが追加のリソースを必要とする場合は、新しい仮想マシンを作成できます。物理ホストに障害が発生した場合、管理者はそのホストでホストされている仮想マシンを別のホストに移行または復元するだけで済みます。よりきめ細かな導入モデルが実現可能になり、運用も容易になりました。

ユーザーはもはや、すべてのプログラムを同じホストマシン上で実行する必要はありません。仮想マシンを使用することで、基盤となるハードウェアの機能を最大限に活用できます。あるユーザーは、ハードウェアリソースの使用率を気にすることなく、ある仮想マシンでデータベース、別の仮想マシンでミドルウェア、そして別の仮想マシンでWebアプリケーションを実行できます。同じ企業内で、あるグループが物理サーバーハードウェアの購入を担当し、別のグループがソフトウェアスタックの構築を担当します。これらの役割は比較的独立しており、互いに干渉することはありません。この2つのチームをつなぐ架け橋となるのが仮想マシンです。ソリューションアーキテクトは、各アプリケーションを異なる仮想マシンに簡単かつ低コストで展開できるため、運用コストを大幅に削減できます。これが、ソフトウェアエンジニアにも高く評価されている理由です。まさにこれこそが、ハイパーバイザー技術がもたらした最も重要なイノベーションです。

何年も経ち、人々は仮想マシン上でビジネスをホスティングすることに慣れてきました。スタートアップ企業はもはやサーバーハードウェアリソースを購入する必要すらなく、AmazonのAWSサービスを購入するだけで済みます。今日では、アプリケーションごとに1台の仮想マシンが、ソフトウェアスタックを展開する標準的な方法となっています。

1990年代以降、アプリケーションのデプロイ方法はほとんど変わっていません。当時から、アプリケーションをデプロイする必要がある場合は、まずLinuxディストリビューションをインストールする必要がありました。その主な目的はハードウェアデバイスを駆動することでした。次に、アプリケーションに必要なdebパッケージまたはrpmパッケージをインストールし、その後で実際に実行したいアプリケーションをインストールして設定する必要がありました。

2013年まで、Dockerは、比較的隔離されたLinuxコンテナ内で非常に効率的に動作するアプリケーションを作成、配布、デプロイするための、シンプルでありながら効果的なツールを提供していました。さらに、幅広いアプリケーション向けに、AppleのApp Storeのようなレジストリの概念も導入しました。わかりやすくするために、ここでは「クラウドアプリケーション」と呼びます。Nginxウェブサーバーのデプロイは「docker pull nginx」と入力するだけで簡単に実行できるようになりました。これは、Ubuntu LTSの海賊版をインストールするよりもはるかに簡単で高速です。

Dockerクラウドアプリケーションは事前設定済みなので、Linuxディストリビューションにバンドルされている不要なパッケージをインストールする必要はなくなりました。実際、Nginx Dockerクラウドアプリケーションは、CanonicalやRed Hatではなく、Nginxコミュニティによって直接提供・配布されています。

Dockerの最も大きなイノベーションは、レジストリを含むクラウドアプリケーション標準の包括的なセットを導入したことです。クラウドアプリケーションの実行に仮想マシンを使用するのではなく、Linuxコンテナを活用します。コンテナ技術自体は長年存在していましたが、限られた範囲でしか普及せず、広く受け入れられていませんでした。優れたパフォーマンスを提供していたものの、仮想マシンに比べて機能が制限されており、分離性も弱かったのです。後発のDockerはLinuxコンテナを一気に普及させましたが、Dockerの成功はコンテナだけによるものではありません。ある意味では偶然の産物だったと言えるでしょう。

では、コンテナ技術自体に内在する問題点は何でしょうか？まず、ホットマイグレーションのサポートはまだごく初期段階で、非ネイティブな作業スタック（Linux上でWindowsを実行したり、Windows上でLinuxを実行したりするなど）では実行できません。さらに、コンテナ技術の主な課題はセキュリティにあります。仮想マシンと比較して、潜在的なリスクがより多く存在します。実際、コンテナコミュニティでは、Docker、CoreOS、その他を問わず、マルチテナントコンテナの導入は一般的に推奨されていません。仮想マシンの時代は、誰がどのように使用するかを気にする必要はありませんでした。しかし、コンテナ技術では、複数の異なるユーザーが所有するコンテナを同じホストマシン上で実行することは推奨されません。AmazonとGoogleはどちらもコンテナホスティングサービスを提供していますが、分離とセキュリティ上の理由から、各コンテナを別々の仮想マシン上で実行しています。このアプローチはあまり効率的ではないように思えるかもしれませんが、間違いなくシンプルで実用的です。

人々は徐々にこのことに気づき始めています（訳注：これがDockerと仮想マシンの組み合わせのポイントです）。今年初めに盛大に立ち上げられたいくつかのプロジェクトは、仮想マシンの利点をDockerに統合しようと試みており、その最も代表的なものがIntelとHyperが立ち上げたClear Linuxプロジェクトです。

これらはすべて、従来の仮想マシンを直接使用してDockerクラウドアプリケーション（Linuxコンテナなし）を実行します。私たちはXenのテストをいくつか実施しました。これらのユースケースでは、ハイパーバイザーを調整することで、他のすべての機能を維持しながら、Linuxコンテナと同等の起動時間を実現しました。IntelのXenに関する同様の取り組みと試みは、Xen Developer Summitで紹介される予定です。このサミットでは、ハイパーバイザーもその成果の一部を発表する予定です。

この新たな方向性は、ユーザーにとってWin-Winのソリューションを提供するように思われます。Dockerの利便性と仮想マシンのセキュリティを完璧に組み合わせたソリューションです。近い将来、Dockerは仮想マシンと競合するのではなく、数あるホスティングプラットフォームの一つとなるかもしれません。