Sollte ich eine Anwendung in mehrere verknüpfte Docker-Container aufteilen oder zu einem kombinieren?

Hintergrund

Ich arbeite derzeit an der Erstellung einer Anwendung, die ich in Docker-Containern bereitstellen möchte.

Die Container werden auf einem meiner Server ausgeführt. Ich möchte die Möglichkeit haben, andere Anwendungen auf demselben Server auszuführen, ohne die Anzahl der ausgeführten Docker-Images zu erhöhen.

Die verschiedenen Teile / Behälter sind ab sofort:

• Nginx (Reverse Proxy, statische Ressourcen)
• Knoten (App-Frontend)
• Knoten (App-Backend / API)
• Mongo (Datenbank)

Gedanken

Die allgemeine Idee, die ich habe, ist, dass jedes einzelne Teil als Container ausgeführt werden sollte. Ich mache mir Sorgen, dass ich, wenn ich eine andere Anwendung auf demselben Computer ausführen würde, diese mit einer nicht handhabbaren Menge verknüpfter Bilder aufblähen würde.

Dies könnte gelöst werden, indem für jede Anwendung ein Bild erstellt wird. Damit werden die oben genannten Dienste Teil eines Bildes. Widerspricht dies in erster Linie der allgemeinen Sicherheit oder dem allgemeinen Zweck von Docker?

Klärung

Widerspricht das Vorhandensein mehrerer Dienste in einem Docker-Image dem Zweck von Docker?

Werden die allgemeinen Sicherheitsvorteile von Containern entfernt, wenn die Dienste von einem Image ausgeführt werden?

Docker selbst macht dies deutlich: Es wird erwartet, dass Sie einen einzelnen Prozess pro Container ausführen .

Ihre Werkzeuge für den Umgang mit verknüpften Containern lassen jedoch zu wünschen übrig. Sie bieten Docker-Compose an (früher bekannt als Abb.), Aber meine Entwickler berichten, dass es pingelig ist und gelegentlich den Überblick über verknüpfte Container verliert. Es lässt sich auch nicht gut skalieren und ist wirklich nur für sehr kleine Projekte geeignet.

Im Moment denke ich, dass die beste verfügbare Lösung Kubernetes ist , ein Google-Projekt. Kubernetes ist auch die Basis für die neueste Version von Openshift Origin , einer PaaS-Plattform, sowie für Google Container Engine und wahrscheinlich auch für andere Dinge. Wenn Sie Kubernetes verwenden, können Sie diese problemlos auf solchen Plattformen bereitstellen.

Docker macht deutlich, dass ein Prozess pro Container der "richtige" Weg ist, gibt aber niemals wirklich Rechtfertigung. Meine Antwort ist, es kommt darauf an. In diesem speziellen Fall würde ich sie auflösen und mit Kubernetes oder OpenShift verwalten, da dies trivial ist und Sie die Möglichkeit haben, jeden Teil Ihrer Anwendung unabhängig zu skalieren.

Ich würde nicht sagen, dass es eine Regel ist, dass Sie Ihre Anwendung aufteilen müssen. Laufende Container sind im Wesentlichen der Systemaufruf clone (), cgroups und selinux, was bedeutet, dass Sie absolut mehr als einen Prozess pro Container ausführen können. Docker, LXC, hausgemacht, es ist wirklich egal, wann sie laufen. LXC unterstützt mehrere Prozesse pro Container, daher würde ich argumentieren, dass "ein Prozess pro Container" Philosophie und kein Engineering ist

http://rhelblog.redhat.com/2016/03/16/container-tidbits-when-should-i-break-my-application-into-multiple-containers/