データベースをドッキング（コンテナ化）することは理にかなっていますか？
Webサーバー、アプリサーバー、ロードバランサーなどのステートレスサービスをドッキングすることのメリットを理解できます。これらのサービスをマシンのクラスターで実行している場合は、オーバーヘッドを抑えてこれらのコンテナーを簡単に移動できます。データベースのコンテナ化の目的は何ですか？データベースは、特定のハードディスクで永続的なデータボリュームに接続されます。状態のため、実際にデータベースコンテナーを移動することは簡単ではなく、効率的でもありません。では、なぜデータベースをドッキングすることがなぜ役立つのか、だれでもわかるでしょうか。
「では、だれでもデータベースのドッキングがなぜ役立つのか、誰にもわかるでしょうか？」
いい質問キート。データベースをコンテナ化する主な理由の1つは、ステートレスパーツだけでなく、開発、ステージング、本番環境にわたって、アプリ全体で同じ一貫した環境を使用できるようにすることです。一貫性のある環境はDockerの約束の1つですが、データベースがこのモデルの外にある場合、テストでは説明できない大きな違いがあります。また、データベースとアプリの他の部分をコンテナ化することで、ホスティングプロバイダー間でアプリ全体を移動できる可能性が高くなります（AWSからGoogle Computeなど）。たとえば、Amazon RDSを使用する場合、ウェブノードをGoogleに移動できても、データベースを移動することはできません。つまり、クラウドプロバイダーに大きく依存しています。
データサービスをコンテナ化するもう1つの理由はパフォーマンスです。これは、サービスプロバイダー（サービス提供としてのすべてのデータベース- rackspace cloud databases -コンテナーで実行）などに特に当てはまります。コンテナーを使用すると、仮想化を使用しては不可能なサービスを保証できるためです。物理マシンごとに1つのデータベースを実行することは、経済的に現実的ではありません。おそらくデータベースホスティングサービスを実行していない可能性がありますが、ベアメタルで実行していてVMの代わりにコンテナーをプロセス分離に使用したい場合、これは同様の意味になります。 VMでdbを実行する際の既知のI/Oヒットにより、データベースのパフォーマンスが向上します。
データベースをコンテナ化する必要があると言っているわけではありませんが、これらが理にかなっている理由の一部です。
完全な開示、私はclusterhqで働いています。その新しいプロジェクトはMark O'connorが彼の回答で述べたものです。 Flockerと呼ばれるオープンソースプロジェクトがあり、ホスト間でのデータベースとそのボリュームの移行がはるかに簡単になるため、上記で述べた利点が、質問で指摘された欠点を完全に上回っていません。
効率性についてのあなたのコメントに同意するかどうかわかりません...データベースコンテナーをネイティブにインストールするよりもダウンロードして実行する方がはるかに簡単です。 Dockerのドキュメントでは、ステートフルコンテナーとそのデータを明確に論理的に分離する方法について説明しています。
しかし...データを移植するための何らかのメカニズムがない限り、ステートフルコンテナーはそのホストサーバーに関連付けられることは間違いありません。
明白な解決策の1つは、データベースを実行している可能性のあるすべてのホストに共有ストレージボリュームをマウントすることです。
次の記事では、ビットトレントのようなクライアントを使用してホスト間でデータコンテナーを複製する非常に革新的なソリューションについて説明します。
最後に、flockerと呼ばれる新しいプロジェクトが、ステートフルコンテナーとそれに関連付けられたZFSボリュームの両方を管理することにより、この問題を解決しようとしています。
これは良いスレッドであり、SQL Serverのクローン作成における最近の進歩により、クローンでのコンテナーの使用に追加の機能が追加されるでしょう。これは、大規模なデータセットでの問題のいくつかに対処します。完全な開示として、Windocksで働いており、データベースのクローン作成が統合されたSQL Serverコンテナーを備えた2.0をリリースしました。