一言で言うと、開発環境の構築が簡単にできる上、開発したアプリケーションをクラウド上で動かすことも簡単になるためです。
1台のPCで開発環境を構築する場合、それまでに構築していた環境が原因で新しい環境構築に失敗することがありました。
例えば、2つの環境で共通して使うライブラリがあるものの、環境Aではバージョン2.2が必要なのに対し、環境Bではバージョン1.9が必要となるという場合、2つのライブラリを同じPCに入れて参照先を環境毎に切り替える等の設定が必要となりますが、こうした対応は往々にしてトラブルの原因となっていました。
Docker 登場前にこうした問題を解決する方法としては、次の方法がありました。
- PCを開発環境毎に用意する
- 1台のPCに複数のOSをインストールしてデュアルブートする
- VirtualPCなどの仮想化ソフトを使って複数のゲストOSをインストールする
- Chroot を使って隔離された環境を仮想的に構築する
それぞれの方法の内容と長所・短所は次の通りです。
必要な開発環境の数だけPCを用意するという最もシンプルな方法です。
環境間の影響を完全に排除できるというメリットはありますが、金銭的負担が非常に大きい上、PC管理の手間もかかります。また、KVM を使わない場合、モニターやキーボードやマウスが PC の台数分必要となるのも欠点です。
1台のPCに開発環境の数だけOSをインストールしてデュアルブートできるように設定し、開発環境を切り替えるときは別のOSを起動させるというものです。
開発環境の数だけPCを用意するのに比べると金銭的負担が少なく、モニターなどが1台分で済むのがメリットですが、開発環境を切り替えるたびに OS の再起動が必要となる上、エディタなどの設定もOSの数だけ必要となります。
1台の PC にメインとなる OS （ホスト OS と呼びます）を1つインストールし、その上に VirtualPC などの仮想化ソフトをインストールして複数の OS （ゲスト OS と呼びます）を動かせるようにするというものです。
ゲスト OS は同時に複数起動できるため、開発環境を切り替えるために OS を再起動する必要はなく、また、エディタもホスト OS にインストールすれば OK なので、その点もメリットとなります。
一方、ゲスト OS を稼働せるためにはホスト OS のリソースを一定程度割り当てる必要があるため、一度に起動できるゲスト OS の数には限度がありますし、ホスト OS の動作にも影響が出ます。
Linux カーネルの chroot (change root) を使ってプロセスを隔離するとともに、アクセスできるディレクトリも制限して専用の開発環境を用意してしまうというものです。
仮想化ソフトを使う方法に似ていますが、プロセスを隔離する方法はゲスト OS を動かすよりも少ないリソースで可能なため、ホスト OS にかかる負荷は少なくて済みます。
主な欠点としては、隔離する環境毎に実行に必要なファイルシステムを自分で用意する必要があるというところです。
Linux カーネルの namespace, cgroup, capability, aufs ドライバなどを使ってプロセスなどが隔離された環境を用意して、その環境内でアプリケーションを実行できるようにしたものが Docker のコンテナです。
一見すると chroot を使う方法と似ていますが、chroot では隔離できないもの（名前空間、ネットワークなど）を隔離できます。
さらに、実行に必要なファイルシステムを Docker イメージと呼ぶ単位で扱えて、この Docker イメージが Docker Hub という公開レジストリで用途に応じて多数公開されているため、chroot よりも簡単に環境を構築することができます。同時に、自分が構築した開発環境を Docker イメージとして使いまわしたり公開することもできます。
それにより、開発したアプリケーションをクラウド上に展開することも容易になります。
参考にしたサイトなど