アプリケーションを複数のリンクされたDockerコンテナーに分割するか、それらを1つに結合する必要がありますか？
バックグラウンド
私は現在、Dockerコンテナーにデプロイするアプリケーションの構築に取り組んでいます。
コンテナは私のサーバーで実行されます。実行されているDockerイメージの量を増大させることなく、同じサーバーで他のアプリケーションを実行できるようにしたいと考えています。
現在のところ、さまざまなパーツ/コンテナは次のとおりです。
- Nginx（リバースプロキシ、静的リソース）
- ノード（アプリのフロントエンド）
- ノード（アプリバックエンド/ API）
- Mongo（データベース）
考え
私が持っている一般的な考えは、それぞれの異なる部分はコンテナとして実行されるべきだということです。私の懸念は、同じマシンで別のアプリケーションを実行すると、結局、処理できない量のリンクされたイメージでアプリケーションが肥大化することです。
これは、アプリケーションごとに1つのイメージを作成することで解決できます。したがって、前述のサービスは1つのイメージの一部になります。これはそもそもDockerの全体的なセキュリティや目的と矛盾しますか？
明確化
1つのDockerイメージに複数のサービスがあると、Dockerの目的と矛盾しますか？
1つのイメージからサービスを実行すると、コンテナーの全体的なセキュリティ上のメリットはなくなりますか？
Docker自体がこれを明確にしています。 コンテナごとに1つのプロセス を実行することが期待されています。
ただし、リンクされたコンテナを処理するためのツールには、多くの要望が残されています。これらはdocker-compose（かつてはfigとして知られていました）を提供しますが、私の開発者はそれが気の利いたものであり、リンクされたコンテナーを追跡できないことを報告しています。また、拡張性も低く、非常に小さなプロジェクトにのみ適しています。
現在、私が利用できる最善のソリューションは、Googleプロジェクトである Kubernetes だと思います。 Kubernetesは、PaaSプラットフォームである Openshift Origin の最新バージョンのほか、Google Container Engineの基礎でもあります。 Kubernetesを使用している場合は、そのようなプラットフォームに簡単にデプロイできます。
Dockerは、コンテナーごとに1つのプロセスが「正しい」方法であると彼らが信じていることを明確にしていますが、実際に正当化することはありません。私の答えは、場合によります。この特定のケースでは、それらを分割してKubernetesまたはOpenShiftで管理します。なぜなら、それは簡単であり、アプリケーションの各部分を個別にスケーリングする機能を提供するからです。
ただし、アプリケーションを分割する必要があるというのはルールではありません。実行中のコンテナーは、基本的にはclone（）システムコール、cgroups、およびselinuxです。つまり、コンテナーごとに複数のプロセスを実行できます。 Docker、LXC、自社開発、それらが実行されているときは本当に重要ではありません。 LXCはコンテナーごとに複数のプロセスを推奨するため、「コンテナーごとに1つのプロセス」はエンジニアリングではなく哲学であると主張します