Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

Warum basteln wir an den Docker Images rum?!

Bei Traefik, MariaDB und phpMyAdmin haben wir einfach die offiziellen Images von Docker herunterladen lassen und alles läuft. So sollte es eigentlich sein.

Für Matomo, WordPress und Nextcloud hingegen bauen wir unsere eigenen Images, obwohl es hier ja auch für jeden Dienst ein fertiges, offizielles Docker Image gibt. Also warum tun wir uns diesen Stress an und fummeln hier manuell in der Config herum?

Kombiniert lauten die Antworten auf diese Frage „E-Mail“ und „Grenzwerte“:

Docker Philosophie

Eine der Kernphilosophien hinter Docker sagt folgendes:

Nur eine Anwendung pro Container!

Das ist der Grund, warum aus den offiziellen Images teils wichtige Hilfsprogramme rausgeschmissen wurden.

Und das trifft insbesondere den Punkt „E-Mail“.

E-Mail

Moderne Web-Anwendungen kommunizieren auch per E-Mail mit dem Anwender. WordPress zum Beispiel sendet Dir eine Mail mit Zugangsdaten, wenn Du einen neuen Benutzer anlegst. Oder gleich eine Bestätigung direkt nach der Installation. Von der Passwort-Rücksetz-Mail mal ganz zu schweigen, die eigentlich alle verschicken.

Hast Du ein Kontaktformular? Da geht auch eine E-Mail raus, wenn jemand das ausfüllt und abschickt.

Matomo kann periodisch Reports per Mail versenden. Das ist schön, um regelmäßig einen Überblick über diverse Webseiten zu bekommen.

Nextcloud schickt Freigabelinks an die entsprechenden Empfänger…

Wir können uns also darauf einigen, dass der Mailversand ein integraler Bestandteil der jeweiligen Anwendung und darum sehr wichtig ist.

Da sich aber offenbar alle Entwickler an diese Docker Regel halten, haben sie die E-Mail Funktionalität aus den Images entfernt. Erwähnt natürlich niemand mit keinem Wort. Und da schaust dann ganz schön dumm aus der Wäsche, wenn Du mit Mails rechnest, diese aber nicht kommen. Und Du den Grund dafür nicht kennst. Weil es ja niemand für nötig befindet, darauf hinzuweisen, dass Mailversand mit dem offiziellen Image / Container nicht mehr funktioniert… Das war eine lange, erfolglose Fehlersuche.

Um wieder mit E-Mails arbeiten zu können, müssen wir die jeweiligen Images mit dieser Funktionalität nachrüsten. Wobei „nachrüsten“ das falsche Wort dafür ist, denn das geht leider nicht. Hier hilft nur komplett selber bauen – mit E-Mail Versand!

Früher habe ich das Tool „ssmtp“ verwendet, das schnell und einfach zu konfigurieren war. Leider wird das nicht mehr weiterentwickelt und ist schon aus diversen Repositories geflogen…

Momentan benutze ich „msmtp“, einen „Fork“ von „ssmtp“. Dieser ist ein wenig umfangreicher zu konfigurieren. Und er schleust die Mails nicht einfach an den Host durch, der sie verschickt, nein, für msmtp brauchen wir ein richtiges Konto bei einem Mailserver, das wir mit Benutzername / Passwort ansprechen und darüber die Mails verschicken.

Habe ich mich anfänglich noch darüber geärgert, bin ich doch mittlerweile ganz froh über dieses Verfahren. Denn es vereinfacht die Konfiguration mehrerer Maschinen. Wir können von allen Servern aus auf das gleiche Mailkonto zugreifen und darüber Mails verschicken lassen. Also müssen wir auch nur ein einziges Mal die Parameter anpassen und verwenden ein und den selben msmtp „Config-Block“ für alle unsere modifizierten Docker Images auf allen Servern. Was recht praktisch ist, wenn man sich einmal daran gewohnt hat. Außerdem braucht der jeweilige Host dann keinen MTA („Mailserver“) mehr, was auch eine Vereinfachung darstellt.

Aber da beißt die Maus keinen Faden ab: Um Mails verschicken zu können, müssen wir die Images selber bauen und sie eigenhändig um diese Funktionalität ergänzen. Philosophie hin oder her…

Zu enge Grenzwerte

Da bin ich gleich ganz am Anfang beim Experimentieren mit Docker drübergeflogen…

Nimm mal ein offizielles Standard WordPress Image und lass es in einem Container laufen. Wo meinst Du, sind da die Limits? Genau, bei den Standard-Limits, die PHP vorsieht. Und die sind für das Hochladen von Dateien genau 2 Megabyte. Megabyte, ja, keine Gigabyte. Die meisten Plugins haben schon zwei MB, von Themes möchte ich gar nicht anfangen. Bilder, die Du auf Deine Seite hochladen möchtest, fallen auch unter diese Grenze.

Das Memory-Limit ist auch recht eng gesetzt. Nagel mich bitte nicht fest, aber ich meine, es sind 32 MB. Das reicht gerade mal so eben, dass sich WordPress nicht dauernd aufhängt, wenn Du eine neue Seite erstellst oder ein Index frisch aufgebaut werden muss. „Updates“ des WordPress Kerns sind da allerdings schon abenteuerlich, mit 32 MB…

Diese Werte könnte man auch über eine Config-Datei nachreichen, die wir über die „docker-compose“-Datei als Volume einbinden. Andererseits, wenn wir für den Mailversand eh schon pfuschen müssen… Was soll’s ^^

Fazit

Ihr seht, dass wir uns diese Arbeit nicht aus Spaß machen oder weil uns langweilig ist. Der ganze Aufwand hat leider wirklich seinen Grund…

Auf der anderen Seite ist es sicher nicht schlecht, wenn wir das auch mal gemacht haben. Es ist schon ein ganz besonderes Gefühl, wenn Du Dein erstes selbst gebautes Image anwirfst – und es dann tatsächlich funktioniert :)

Das ist aber auch wirklich Frankensteinerei in Reinkultur. Also ein paar Haarbuschel oder der eine oder andere Fingernagel gehen schon kaputt, bis das eine gewisse Routine entwickelt ^^

Anzeige *

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top