[和訳]コンテナは仮想マシンではない #docker

本稿は Containers are not VMs (2016/3/24) の和訳です。

かなりの時間をDockerで過ごしていますが、コミュニティメンバーと話していて、皆Dockerについて知識の差はありますが、ある共通の課題 を感じました。Dockerを初めて触れるときの自然な反応として、Dockerを仮想マシンという枠組みでとらえようとする点です。Dockerのコンテナが「軽量の仮想マシン」と表現されているのを何度も聞きました。

私も初めにDockerを使ったときはまったく同じ捉え方をしたので気持ちはわかります。Dockerも仮想マシンも同じ性質をもつ技術ですから、容易に関連付けられます。両者ともアプリケーションを実行するために、独立した環境を提供するような仕様です。さらに、両者とも、その環境はホスト間を移動できるバイナリ形式のアーティファクトです。他にも類似点はあるかもしれませんが、個人的にはこの二つが大きな類似点だと思います。
鍵となるのは、両者の基盤のアーキテクチャが本質的に異なる点です。私が使っている例えは、（私をよく知っているなら私が例え話が好きなのはご存知ですね）一軒家(仮想マシン)とアパート(コンテナ)との違いです。

一軒家（仮想マシン）は完全に自己完結型で、部外者から守られています。また、各建物は水道管、熱、電気などそれ自体のインフラを所有しています。しかも多くの場合一軒家は最低でも寝室、リビング、風呂、キッチンがあります。「スタジオハウス」はまだ見たことがありませんが、もし最も小さい家を買うとしても、結局自分が必要としている以上のものを買うことになるかもしれません。それが一軒家の建て方だからです。（物知りな皆さんへ。マイクロハウスという新しいトレンドは私の例えと合わないので扱いません。）

アパート（コンテナ）も部外者からは守ってくれますが、インフラ周りを共有した建築です。アパートの建物（Dockerホスト）は水道管、熱、電気などを共有します。そのうえ、アパートにはスタジオから複数の寝室つきのペントハウスまで様々なサイズがあります。そして、必要なものだけを借りています。最後に、一軒家と同じようにアパートも鍵をかけられる玄関があり、部外者が入れないようになっています。
コンテナの場合、Dockerホストの基盤リソースを共有し、アプリケーションの実行に必要なイメージを構築できます。基礎から始まり、必要なものを足していきます。仮想マシンは正反対の建て方です。完全なオペレーションシステムを開始し、依存するアプリケーションを開始し、場合によってはいらないものを削除するかもしれません。
皆さんの多くが「ああ、わかりました。両者は違うのですね」と言っていることでしょう。しかしそう言ったとしても、まだ現在の仮想マシンの考え方やプロセスを、コンテナに適用しようとするでしょう。

・コンテナはどのようにバックアップするのか？
・実行中のコンテナのパッチ管理はどうすればよいのか？
・アプリケーションサーバーはどこで稼働するのか？

私が瞬間的にひらめいたのは、Dockerとは仮想化技術ではなく、アプリケーションのデリバリー技術なのです。仮想マシン中心の世界では、抽象概念の単位とはアプリケーションコードだけではありません。しばしばステートフルなデータを保管するモノリシックな仮想マシンです。仮想マシンはかつて物理サーバーにあったすべてを単一のバイナリに詰め込み、移動できるようにしました。しかし、それでもまだ同じです。コンテナが抽象化するのはアプリケーションです。より正確に言えば、アプリケーションをまとめる手助けとなるサービスです。

コンテナの場合、通常は多くのサービス（それぞれを単一のコンテナとして表す）がアプリケーションを構成します。アプリケーションはより小さい構成要素に分解することができるため、プロダクション 環境（実運用）で管理する方法がまったく変わります。
では、どのようにコンテナをバックアップするのでしょうか。バックアップは行いません。データはコンテナの中には無いからです。データがあるのは名前を付けて定義したボリュームの中にあり、複数のコンテナ間で共有します。バックアップするのはデータボリュームでありコンテナのことは忘れてください。最適なことに、コンテナは完全にステートレスで不変です。
確かにパッチは依然として世界の一部ではありますが、コンテナの実行には適用しません。現実には、実行中のコンテナにパッチを適用してから、パッチを適用していないイメージに基づいて新しいコンテナを起動すると、まずいことになります。理想的にはDockerイメージをアップデートし、実行中のコンテナを停止し、新しいコンテナを起動してください。なぜならコンテナはたちまち起動するため、このやり方のほうが手軽なのです。

アプリケーションサーバーはコンテナ内で動くサービスに変換されます。確かにマイクロサービスベースのアプリケーションは、コンテナ化されていないサービスに接続する必要があります。しかし、ほとんどの場合、コードを実行するスタンドアロンサーバーは、少ないオーバーヘッドで同じ機能を提供する一つ以上のコンテナに取って代わられます（そしてよりよい水平スケールを提供します）。
「でも仮想マシンは慣例的にはリフトとシフト（訳者注：以降方式の１つ）でしたよね。既存のアプリケーションをどうすればよいのでしょうか？」

コンテナで巨大なモノリシックのアプリを実行する方法をよく聞かれます。マイクロサービスアーキテクチャに移行する有効な手段はたくさんあります。既存のモノリシックなアプリを仮想マシンからコンテナに移動することから始めます。しかしこれは、その方法の最終ゴールではなく、最初のステップと考えるべきでしょう。
あなたの組織がどのようにDockerを活用できるか考えるにあたって、仮想マシン中心の考え方からは離れて、Dockerはただの「軽量の仮想マシン」ではないことを実感してください。これはアプリケーション中心の手法であり、あなたが選んだインフラ上で高性能かつスケーラブルなアプリケーションをもたらします。

Dockerに関してさらに学ぶには

・Docker初心者は、10分のオンラインチュートリアルをご覧ください。
・画像、自動構築などを無料のDocker Hubアカウントでシェアしてみましょう。
・Docker 1.10リリースノートを読んでみましょう。
・Docker Weeklyを購読してみましょう。
・次に予定されているDockerオンラインMeetupに登録してみましょう。
・次に予定されているDocker Meetupに参加してみましょう。
・DockerCon 2016に登録してみましょう。
・DockerCon EU 2015のビデオを見てみましょう。
・Dockerコミュニティへの貢献を始めましょう。