Webアプリに個別のDockerコンテナーを使用する必要がありますか？
複雑なWebアプリケーションに個別のDockerコンテナーを使用する必要がありますか、それとも必要なすべてのサービスを1つのコンテナーに入れることができますか？アプリを多くのコンテナーに分割する必要がある理由を誰かに説明してもらえますか（たとえば、php-fpmコンテナ、mysqlコンテナ、mongoコンテナ）1つのコンテナにすべてのものをインストールして起動する機能がある場合はどうなりますか？
Dockerを使用する際に考慮すべきことは、Dockerが内部でどのように機能するかです。 Dockerは、PID 1を、DockerfileのCMD（および少し複雑なENTRYPOINT）ディレクティブで指定したコマンドに置き換えます。 PID 1は通常、initシステムが存在する場所です（sysvinit、runit、systemdなど）。あなたのコンテナは、そこで開始されたプロセスによって生きたり死んだりします。プロセスが停止すると、コンテナも停止します。 Stdout and stderr そのプロセスの場合コンテナ内は、docker logs myContainerと入力したときにホストマシンに表示されるものです。ちなみに、これが、サービスを開始してcronジョブ（通常はinitシステムによって実行されること）を実行するためにフープを飛び越える必要がある理由です。これは、特定の方法で物事を行う動機を理解する上で非常に重要です。
今、あなたはあなたがやりたいことを何でもすることができます。これを行うための「正しい」方法については多くの意見がありますが、それをすべて捨てて、やりたいことを行うことができます。したがって、これらすべてのサービスを1つのコンテナーで実行する方法を理解できます。しかし、dockerがPID1をDockerfilesのCMD（およびENTRYPOINT）で指定したコマンドに置き換える方法がわかったので、アプリをそれぞれのアプリで実行し続けるのが賢明だと思うかもしれません。独自のコンテナを作成し、 コンテナリンク を介して相互に動作させます。 （Update-2017年4月27日：コンテナリンクは非推奨になり、通常のole コンテナネットワーク になりました。堅牢で、別々のアプリケーションコンテナを同じネットワークに参加させるだけで、相互に通信できるようになります）。
決定に少し助けが必要な場合は、私自身の経験から、アプリを個々のコンテナーに分割してからそれらをリンクすると、はるかにクリーンで保守が容易になることがわかります。ちょうど今、HHVMからWordpressインストールを構築しており、Wordpressインストールを1つのコンテナーに入れて、NginxとHHVM/php-fpmをインストールしています。 MariaDBは別のコンテナーに格納されます。将来的には、これにより、MariaDBデータの直前に代わりのWordpressインストールを、ほとんど手間をかけずにドロップできるようになります。アプリごとにコンテナー化する価値があります。幸運を！
Webアプリケーションを多くのコンテナーに分割する場合、アプリケーションをデプロイするときにすべてのサービスを再起動する必要はありません。従来のように、Webレイヤーを更新するときにmysqlサーバーを再起動しません。
また、アプリケーションをスケーリングする場合は、アプリケーションを個別のコンテナーに分割すると簡単になります。次に、ボトルネックを解決するために必要なアプリケーションの部分をスケーリングするだけです。
コンテナごとに1つのプロセスのみを実行する必要があると言う人もいます。他の人は、コンテナごとに1つのアプリケーションを言うでしょう。これらのアドバイスは、 マイクロサービス の原則に基づいています。
マイクロサービスがすべての場合に適切なソリューションであるとは思わないので、その理由だけで盲目的にそれらのアドバイスに従うことはしません。ケースの1つのコンテナに複数のプロセスを含めることが理にかなっている場合は、そうしてください。 （ スーパーバイザー および Phusion baseimage を参照）
ただし、コンテナを分離する別の理由もあります。ほとんどの場合、作業が少なくて済みます。
Docker Hub には、すぐに使用できるDockerイメージがたくさんあります。必要なものを引っ張るだけです。
あなたがしなければならないことはそれからです：
- それらのDockerイメージのドキュメントを読んでください（設定する環境変数など）
docker-compose.ymlこれらのコンテナの操作を容易にするファイル
Webアプリを単一のコンテナーに入れ、データベースなどのサポートサービスを別のコンテナーに入れる方がおそらく良いでしょう。ローリング更新または再起動を行う必要がある場合にこれを行うことにより、アプリケーションノードが個別に再起動している間、データベースをオンラインに保つことができるため、ダウンタイムが発生しません。 Redisなどでキャッシュしている場合、これも同じ理由で役立ちます。また、ノードをより簡単に追加して、疎結合方式でスケーリングすることもできます。また、特定の目的により適した方法でコンテナを管理することもできます。あなたが説明しているアプリケーションのタイプについては、単一のコンテナーですべてのサービスを実行するための引数はほとんどありません。
それはあなたがあなたのアプリケーションのために持っているビジョンとロードマップに依存します。この場合、Dockerコンテナーでは、アプリケーションのすべてのコンポーネントを1つの層に配置することは、すべての卵を1つのバスケットに配置することに似ています。
アプリケーションでセキュリティが必要な場合は常に、パフォーマンス関連の問題を解決し、これら3つのコンポーネントを独自のコンテナーに分離することが理想的なソリューションです。言うまでもなく、このコンテナ間の分業にはある程度のコストがかかり、通信やセキュリティなどのためにこれらのコンテナを相互に接続することに関連します。