コンテナwith app + DB

Question

私はドッカーでいくつかのテストを行ってきましたが、これまでのところ、2つのコンテナでDBとアプリケーションを分離するのが良い方法と考えられています。

2つの容器を持つことは管理が面倒であるように見えますが、実際にはその価値はわかりません。 私はアプリケーションごとに自己持続可能なコンテナを持つという考えが好きですが。

Answer 1

1つの理由は、データストレージとアプリケーションの分離です。両方を自分のコンテナに入れたら、それらを独立して更新することができます。私の経験では、これは一般的なプロセスです。通常、アプリケーションは基礎となるデータベースよりも速く進化するためです。

これにより、異なる場所でコンテナを実行することができ、操作上の制約になる可能性があります。または、異なるアプリケーションで同じデータベースイメージから複数のコンテナを実行することもできます。

多くの場合、同じデータベース（またはキャッシュインスタンスまたはHTTPバックエンド）に接続された1つのインスタンスから複数のインスタンスにUIを拡大縮小することもできます。これはdocker best practicesで簡単に説明しています。

また、1つのコンテナで複数のプロセスを実行したいとのご理解もあります。それで、最近、s6のような非常に多くのミニマリストのinitシステム/監督者が登場しました。私はフロントエンドのためのnginx、データベース、おそらくredisのインスタンスのような、いくつかのことを必要とするアプリケーションのデモにこれを好む。しかし、基本的にはdocker-compose fileと書いて、デモを複数のコンテナで実行することもできます。

Answer 2

「データベース」とは何か、データベースアプリケーションかコンテンツかによって異なります。

後者は簡単ですが、アプリケーションの存続期間外にコンテンツを永続化する必要があります。このコンベンションでは、アプリケーションとのリンクを簡略化する「データ」コンテナ（例えば、Docker Engineのcreateコマンド--volumes-fromパラメータを使用）を使用することがありました。 Docker 1.9には、「データ」コンテナの概念を置き換えた新しいボリュームAPIがあります。しかし、オーバーレイファイルシステムにデータを保存することは決してありません（永続性だけでなく、パフォーマンスのために）。

データベースアプリケーションを指している場合は、実際にはマイクロサービスの群衆との半宗教的な議論に入ります。 Dockerは単一プロセスを実行するように構築されています。それは12要素のアプリのために作られています。マイクロサービスのために作られています。コンテナ内で複数のプロセスを実行することは間違いありませんが、これらのプロセスの管理/監視（例えばスーパーバイザなどのinitプロセスの使用）、ログ処理などの複雑さを考慮する必要があります。

私は両方を配達しました。コンテナの配備を管理している場合（たとえば、アプリケーションをホストしている場合）、複数のコンテナを使用することは実際にはあまり効果がありません。これにより、Dockerの抽象レイヤーをネットワークおよび永続ストレージに使用できます。また、アプリケーションの規模を拡張する際に最大限のポータビリティを提供します（複数のサーバー間でコンボイやFlockerボリュームドライバやオーバーレイネットワークを使用してコンテナをホストすることも考えられます）。配布用の製品を開発している場合は、単一のDocker Repository（1つのImageを含む）を提供する方が便利です。これにより、展開を通じて顧客を導くサポートコストが最小限に抑えられます。