Containerisierung für Hosting-Stack

[lgweb]

Hallo,

ich betreibe seit einer Weile (primär privat) ein relativ klassisches Stack aus Mailserver (Postfix, Dovecot und diverse Helferlein), Webhosting (nginx mit PHP-FPM) sowie einen MySQL-Dämonen auf Debian, mittlerweile auf mehreren vServern.

Im immer fortwährenden Trend von Containerisierung, ganz speziell mit dem gehypten Docker, habe ich mich mit der Sache auch einmal auseinandergesetzt und bin nun etwas hin- und hergerissen, ob sich ein Umstieg auf eine beliebige Containerlösung für mich lohnt. Wie bereits gesagt betreibe ich mehrere vServer (bei mehreren Providern) mit nahezu identischem Stack (Unterschiede liegen in installieren PHP-Modulen, das würde sich aber angleichen lassen) und administriere die primär per Parallel-SSH. Die Configs haben sich bewährt.

Der Haken ist natürlich, dass soweit erst einmal alle Dienste nicht voneinander abgeschirmt sind. Sockets wiederum sind mit entsprechenden Berechtigungen versehen, sodass eben nur der betreffende User auf seine PHP-FPM-Instanz zugreifen kann, aber zentrale Services (speziell MySQL), die von Diensten (Postfix-User) wie Endnutzersoftware (zig CMS-Installationen) genutzt werden, sind natürlich alle auf einer Ebene zugange.

Wo ich einfach mal euren Rat oder eure Meinung brauche: Wie sinnvoll würdet ihr eine Containerisierung einer solchen Umgebung finden? Meine Überlegung wäre gewesen, den kompletten Mailstack in einen Container (bzw. mehrere, um dem Konzept "ein Service pro Container" Rechnung zu tragen) zu schieben, dann jeweils jeden PHP-FPM-Prozess in einen Container zu schieben (...was dann vermutlich einen Übergang von Sockets auf TCP mit sich zieht?), einen Reverse-Proxy davor zu schalten und so eben nach und nach alles zu dockern, wobei ich hier ein bisschen Angst vor sinnlosem Overhead habe. Ist der Sicherheitsgewinn dabei so hoch, dass eine Ausführung unter verschiedenen Systemnutzern nicht mehr mithalten kann? Abgesehen von irgendwelchen Sicherheitslücken kann ich das nicht so recht glauben. Speziell MySQL wird oft und gern so beschrieben, dass man sich pro Service einen MySQL-Container anlegt, diesen dann mit dem benötigenden Container linkt und somit möglicherweise wahnsinnig viele MySQL-Container. Sollte man hier diesen starken Overhead, den ich da vermute, wirklich akzeptieren? Bisher lege ich einfach mehrere Datenbanken und Nutzer mit generierten Passwörtern an.

Die nächste Thematik ist die Aktualisierung der enthaltenen Software. Bisher bin ich da eigentlich ziemlich hinterher; was über die Debian-Repos reinkommt, läuft bei mir. Mit Docker müsste ich ja bei jedem Update die Images ersetzen bzw. gar neu bauen, wenn ich eigene benötige - und bin darauf angewiesen, dass der Entwickler des Images sozusagen als zusätzliches Layer auch die Aktualisierung verteilt, nachdem sie vom "Upstream" kommt. Führt das nicht zu immensem Mehraufwand?

Es würde mich freuen, hier ein paar Meinungen zu hören, ohne, dass ich einen Glaubenskrieg vom Zaun brechen möchte. Ich habe selbst schon ein bisschen mit Docker zu tun gehabt, aber eher in Entwicklungsumgebungen, vor allem im Bereich der Continous Integration. Dort würde ich die Sinnhaftigkeit nie in Frage stellen, aber für die Produktivanwendung würde ich mir gern weitere Meinungen einholen.

Beste Grüße
Lukas

 

[elias5000]

Die Antwort ist mal wieder: Es kommt drauf an.

Docker ist Linux Namespaces in Steroids. Aus $Gründen ist Docker nicht geeignet um eine Privilege Separation zwischen Containern vollständig sicherzustellen. Daraus ergibt sich, dass du nicht Container auf Servern zusammen laufen lassen solltest, deren Payload du nicht auch ohne Containerisierung auf dem selben System haben wollen würdest.

Containerisierung ist hauptsächlich geeignet für Sachen, die kurzlebig sind und die man durch verschiedene Lifecycle states auf verschiedenen Systemen schleusen will. Z.B. eine Application, die man in einer Cloud laufen lassen will und die man durch CI/CD-Pipelines laufen lässt. Da gehört eine ganze Menge Infrastruktur dazu. Das lohnt sich in erster Linie für Services, die man selbst entwickelt und die ein Sliding-Release-Modell haben.

Für einen Mailserver ist das weniger was. Auch nicht für den DB-Server. Eher schon für aktiv entwickelte Web-Applications. Aber auch da ist ein unterschied zu machen und es kommt drauf an.

Ich persönlich habe einige wenige Dinge in Containern laufen, für die sich das anbietet. Der Rest läuft nativ. Alleine schon, weil ich den Overhead an Ressourcen scheue.
In meiner Eigenschaft als SRE für ein größeres Technologieunternehmen, in der ich diverse Services in Cloud-Infrastrukturen installiere, sieht das dann schon wieder anders aus.

Wenn du ein schickes Projekt suchst um deine Administration zu verbessern, dann schau dir lieber Config Management (mit Puppet oder Chef) an. Das dürfte für deine Umgebung mehr Mehrwert bieten.

 

[IP-Projects.de]

Ergänzend dazu - Docker und andere Container sind nett für Entwickler. Die Entwickler klicken sich Ihre Instanz auf dem Desktop zusammen und rollen diese dann einfach per "1-Klick" aus ohne dass diese einen Systemadministrator im ersten Moment benötigen. Das bedeutet, es gibt keinen Unterschied mehr von einer Lokalen Entwicklungsumgebung zum vServer / Dedicated Server. Gerade was die Versionierung angeht bedeutet das - was lokal läuft läuft auch im Internet.

Negativer beigeschmack ist, dass Personen die von Systemwartung, Administration und Konfiguration keine Ahnung haben auf einmal Systemadministrator spielen können und das natürlich für Botnetze ein gefundenes Fressen ist wenn hier nicht aufgepasst wird.

Für dich konkret der offensichtlich Ahnung davon hat, was er tut und wie man einen Server administriert bringt das in meinen Augen keinerlei Vorteile wenn nicht sogar durch den genannten Overhead noch Nachteile.

Konkret kann ich dir sagen, dass viele Firmen der Branche wie z.B. Zalando mit Docker arbeiten und darüber Ihre Shopaktualisierungen ausrollen, man kann damit sehr nette Sachen machen wie mal 30 Server auf einer neuen Shopversion laufen lassen und 30 auf der Alten und mittels A/B Testing dann die beiden Versionen gegeneinander laufen lassen mit Hilfe von vorgeschalteten Loadbalancern .... das ist aber eher Entwicklerspierei Wenn du also den Bedarf hättest, die Selbe Serverkonfiguration in verschiedenen Rechenzentren zu betreiben ohne überall alles neu installieren zu müssen, hättest du mit Docker sicher einen Zeit Vorteil, nicht aber bei individuellen Setups.

 

[lgweb]

Aus $Gründen ist Docker nicht geeignet um eine Privilege Separation zwischen Containern vollständig sicherzustellen. Daraus ergibt sich, dass du nicht Container auf Servern zusammen laufen lassen solltest, deren Payload du nicht auch ohne Containerisierung auf dem selben System haben wollen würdest.

Alles klar, das hat mir erstmal den Zahn gezogen, dass ich daraus einen sinnvollen Sicherheitsgewinn ziehe. Definitiv gut zu wissen; ich hab mich zur Thematik "Privilege Separation" da gerade nochmal quer rein gelesen, da ist ja Docker wirklich wenig ideal, wenn unprivilegierte Container quasi gar nicht möglich sind.

Da gehört eine ganze Menge Infrastruktur dazu. Das lohnt sich in erster Linie für Services, die man selbst entwickelt und die ein Sliding-Release-Modell haben.

Genau für sowas setze ich Docker derzeit ein, aber eher als "Konsument" auf meiner Bastelmaschine und in VMs, um mal schnell eine bestimmte Softwareversion ranzuholen. Diese "Leichtigkeit", die immer gern assoziiert wird (drei Commands, und der Container läuft) scheint ja auch ein Problem zu sein, wie IP-Projects schon andeutete. "DevOps" scheint also doch Hype-Charakter zu haben.

Für einen Mailserver ist das weniger was. Auch nicht für den DB-Server. Eher schon für aktiv entwickelte Web-Applications. Aber auch da ist ein unterschied zu machen und es kommt drauf an.

Das war eben ja auch mein unbestätigtes Gefühl, und das hat sich nun bestätigt - vielen Dank für die Ausführungen

Wenn du ein schickes Projekt suchst um deine Administration zu verbessern, dann schau dir lieber Config Management (mit Puppet oder Chef) an. Das dürfte für deine Umgebung mehr Mehrwert bieten.

Danke für den Tipp - von den beiden habe ich gehört, liegt auf der Liste "Dinge die zu tun sind, wenn ich mal frei habe und nichts anderes zu tun" - momentan gehts mit Parallel-SSH und diversen selbst entwickelten Shellskripten noch relativ gut, aber eines solche Tools (kannst du ein bestimmtes derer empfehlen? Ansible ist mir auch ab und zu über den Weg gelaufen) wird definitiv eine sinnvolle Lösung sein.

Negativer beigeschmack ist, dass Personen die von Systemwartung, Administration und Konfiguration keine Ahnung haben auf einmal Systemadministrator spielen können und das natürlich für Botnetze ein gefundenes Fressen ist wenn hier nicht aufgepasst wird.

Das hatte ich ja oben schon erwähnt, somit erkläre ich mir etwas den Hype darum, der mich etwas mit in den Strudel gerissen hat. Docker kam aus allen Richtungen, und genau da stellt sich dann die Frage, ob das seine Berechtigung hat. Scheinbar wird in dieser Richtung dann doch sehr übertrieben, denn viele Gedanken und Artikel dazu gehen über reines Softwaredeployment hinaus.

bringt das in meinen Augen keinerlei Vorteile wenn nicht sogar durch den genannten Overhead noch Nachteile.

Alles klar, ich danke Dir für deine Ausführungen!

Euch beiden, die ja was davon verstehen, danke ich vielmals für die Beschreibungen. Sehr angenehm und fundiert, dazu Informationen zu erhalten! Ich werde Docker vorerst nicht im produktiven Hosting einsetzen, da die Separierung mein Interesse gewesen wäre, was ja aber Docker eher nicht bringt und auch ansonsten eher am Sinn von Docker vorbei gewesen wäre - off-label-use kann ja auch mal schnell daneben gehen, wenn sich der Kurs weiter in die eigentlich Richtung dreht.

Soweit,
Lukas

 

[elias5000]

[...] aber eines solche Tools (kannst du ein bestimmtes derer empfehlen? Ansible ist mir auch ab und zu über den Weg gelaufen) wird definitiv eine sinnvolle Lösung sein.

Da ich selber viel damit arbeite, finde ich Puppet gut. Das hat eine deklarative DSL, in der man die Config beschreibt. Puppet stellt dann diesen Zustand her, indem es die Deltas anpasst. Das ist ganz gut für invididuell gepflegte Systeme, die man über die Zeit mal ändert.

Ansible ist AFAIK eher was für Provisioning von wegwerf-Instanzen oder Docker-Images. (Vorsicht, gefährliches Halbwissen)