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

Haftungsausschluss / Disclaimer

Methode „Holzweg“

Manchmal verrennt man sich in einer Sackgasse. Das merkt man leider meistens erst, wenn man an deren Ende angekommen ist.

Wir hatten damals in der Schule einen ganz besonderen Mathe/Physik Lehrer. Allseits bekannt unter seinem Beinamen »Captain Chaos«. Von ihm stammt der Spruch, den ich in der Überschrift so nonchalant benutze.

Er schrieb uns eine Gleichung an die Tafel und wir haben die ganze Stunde damit verbracht, diese zu lösen. Nach zwei vollgeschriebnen Heftseiten und 40 Minuten, die vergangen waren, kam dann und wann von vorne ein murmelndes »hmm, da kann aber was nicht stimmen«. Prüfende Blicke auf den Anfang der Rechnung. Ein Blick zum Himmel und ein Stoßseufzer. Dann schrieb er unter den langen Rechnungsweg »Methode Holzweg«. Wir waren am Anfang falsch abgebogen und merkten erst am Schluss, dass wir uns verrannt hatten.

Das ist frustrierend, das nervt. Aber erstens hilft es nichts, und zweitens sind diese falschen Verzweigungen lehrreich. Na, sagen wir, wenigstens manche.

Hier und heute ist mir das auch mit der Serverconfig passiert.

Nachdem an der Maschine von Seiten des Providers etwas verändert wurde, kam das Verschlüsselungsmodul nach einem Update nicht mehr hoch. Von außen gab es keine Möglichkeit, dieses wieder einzurichten. Also hatte ich den Worst Case direkt vor mir: Der komplette Server war nur noch Datenmüll.

© Warner Bros.

Zum Glück hatte ich umfangreiche Backups und konnte die Maschine – diesmal ohne Verschlüsselung – wieder zum Laufen bewegen. Aber der Schmerz sitzt tief.

Neuausrichtung der Wunschliste
Gleichzeitig wollte ich von WordPress »Single Site« auf WordPress »Multi Site« umsteigen, damit viele aber kleine Webpräsenzen auf einem Host in kurzer Zeit einzurichten und zu verwalten kein Problem mehr wären. Auch hierbei musste ich kläglich scheitern. Nach ein paar Wochen sehr chaotischer Konfiguriererei.

Im Endeffekt klappt es nicht, viele Instanzen in eine Config zu bekommen, wenn ich sie auch noch mit zwei PHP Versionen am Laufen haben will. Dazu braucht man eine »Upstream« Deklaration. Und die kann man genau ein mal in der Config setzen. Ich brauche aber für jede Internetseite eine eigene. Die Config für WordPress war mittlerweile fast zwei A4 Seiten lang. Immer und immer wieder hatte ich eine Möglichkeit gefunden, von der Basis ausgehend meine Wünsche in Code zu gießen. Aber DAS überstieg dann letztlich meine Fähigkeiten. Ich habe nie herausgefunden, wie man so etwas regeln kann. Wahrscheinlich gar nicht. Und damit war ich schließlich an einem toten Punkt angekommen…

A little Help from my Friends :)
Auf meine Misere hin angesprochen fragte mich Jürgen, warum ich überhaupt zwei PHP-Versionen nebeneinander betreiben will. Das erklärte ich ihm damit, dass ich schon zwei Mal einen Server frühzeitig wechseln musste, weil die PHP-Version des Host-Systems nicht mehr aktualisiert wurde. Und obwohl noch der eine oder andere Patch kam, waren einige Internet-Apps nicht mehr mit der alten PHP-Version kompatibel.

Ende vom Lied. Ein Update der systemeigenen PHP-Bibliotheken auf eine neue Version versagte zwei Mal sehr spektakulär. Darum bin ich auch auf die HHVM aufmerksam geworden, da diese ja aktiv weiterentwickelt wurde und das PHP-Problem somit gelöst war. Allein die Stabilität verhinderte den Einsatz der HHVM als einzigen PHP-Interpreter. Ich musste ihr die PHP-Version vom Host als Rettungsanker zur Seite stellen, damit im Falle eines Ausfalls diese in die Bresche springen konnte. Es folgte ein langer Säufzer. Dann erzählte mir Jürgen, dass ich doch, wenn es mir nur um aktuelle Bibliotheken ginge, »Docker« eine Chance geben sollte.

Docker. Der Weg ist das Ziel!
Docker… Schon mal gehört. Aber nie wirklich damit beschäftigt.

Docker sollte die nächsten zwölf Wochen mein täglich Brot werden. Quell großer Freude. Aber auch tiefer Enttäuschung. Und erst mal anders rum. Willkommen zurück in der Welt der Admins :)

Es ist tragisch, dass es im ganzen Netz mal wieder keine einzige Anleitung gibt, die von vorne bis hinten das Aufsetzen der kompletten Maschinerie erklärt. Und einige Teilanleitungen sind dazu noch grob fehlerhaft. Das hat echt keinen Spaß gemacht. Naja, irgendwie schon, aber auf eine sehr schmerzhafte, masochistische Art und Weise.

Ich notiere Dir mal schnell in Kurzform, was in den drei Monaten meiner großen »Docker auf dem Produktivsystem« – Odyssee so alles schief gelaufen ist:

  • Docs.Docker – diejenigen, welche diese Anleitungen geschrieben haben, müssten sie ausgedruckt zu Fressen bekommen! Die sind so hilfreich wie zum Beispiel in einem Tuning Forum diese fiktive Anleitung zum Einbau eines Turboladers: 1.) Motorhaube auf. 2.) Turbolader einbauen. 3.) Motorhaube zu. Experten können damit vielleicht etwas anfangen. Anfänger bekommen hingegen einen Tritt in den Allerwertesten :/
  • Also auf einem Testsystem in einer Virtuellen Maschine (VM) angefangen, mit Docker zu experimentieren. Experimentieren im Sinne von »Versuch und Irrtum«. Das waren zwei harte Wochen, bis ich überhaupt verstanden habe, wie dieses System generell arbeitet und wie man an welchen Schrauben drehen kann.
  • WordPress Container auf der VM aufsetzen. Läuft! Cool! Erstes Theme hochladen: »Datei zu groß« Fehler. Weil die für die Container die absoluten Standards benutzen. Das wären 2 MB maximale Upload Größe. In einer WordPress Umgebung?! Das hat gebraucht, bis ich rausgefunden habe, wie man die Limits direkt in dem Image für den Container erhöht …
  • Aufsetzen des zentralen Teils des Systems: Der Reverse-Proxy! Das ging nur »live«, weil auf der Test-VM bekomme ich ja keine Domains gemapped. Klappt erstaunlich gut … Zu gut! Denn in der Anleitung, die das beschreibt, ist der oben erwähnte grobe Fehler drin. Da stolpert man aber erst am Schluss drüber. Das waren viele Kopfschmerzen, das zu finden. Und vor allem, das zu beheben!
  • WordPress Container »live« aufsetzen. Läuft! Cool! Erstes Theme hochladen: »Datei zu groß« Fehler. Dejavu?! Ja genau! Aber diesmal klemmt es im Proxy, weil der auch eine Upload-Limitierung drin hat. Und zwar auf 1 MB. Herrlich, kann man sich gar nicht ausdenken, das alles. Und hier pfuscht man an vier Containern rum. Aussichtslos. Das löst man dann über eine externe Config-Datei, welche die Container beim Starten zusätzlich einlesen.
  • Postfix installiert, WordPress Container läuft, Theme hochgeladen. Ich bekomme aber keine Mails? Genau, keine Mails! Weil die im Container aus der Laufzeit den »sendmail« rausgenommen haben. Und das mit keinem Wort erwähnen! Nirgends!
  • Beim Pfuschen im Container dann drauf gekommen, dass auch noch die Firewall den gesamten Traffic zwischen den Containern frisst. Kopfschmerzen! Shorewall (<5.0.6) und Docker mögen sich per Default nämlich nicht. Aber auch das kann man fixen. Wäre halt schön, wenn das Thema irgendwo in den offiziellen Anleitungen angeschnitten werden würde. Aber nix is - muss man selber drauf kommen. Bzw. in meinem Fall Robe fragen :)
  • Mail-Problem gelöst. Nach drei Anläufen mit völlig unterschiedlichen Methoden. Läuft aber noch nicht sauber. Der »From« ist einfach »www-data«. Uncool!
  • Absender-Thematik gelöst. Postfix angepasst. Mailversand läuft sauber.
  • Für jede WordPress Instanz läuft eine eigene MariaDB. Das ist nach der Docker-Philosophie auch so gewollt. Aber vom Performance- und Ressourcenstandpunkt aus ist das eine furchtbare Verschwendung. Also alle Configs noch mal umgebaut und eine »Master«-Datenbank eingerichtet, die für alle Container zuständig ist. Vorteil: Neben massiver Einsparung von RAM (rund 200 MB pro WordPress Instanz) kann man den zentralen Container auch auf den Host verlinken und die Backups »ganz normal« wie früher auch per Datenbank-Dump über die Kommandozeile machen.
  • Absicherung gegen den Unbill aus dem Internet. Bah! Kann man da nicht ein paar einfache Standard-Werte in den Container pflanzen, um wenigstens die größten Angriffs-Scheunentore zu schließen? Nein, macht man nicht. Und diese »per-Container« Fixes gehen mir auf den Zeiger. Also habe ich ein Plug-in für WordPress gesucht und auch gefunden, das gut funktioniert. Problem: Das zeigt als Angreifer-IP die innere IP des Containers an. Dank des reverse-Proxys. Rasende Kopfschmerzen. Durch einen Zufallsfund konnte ich das Problem nach ein paar Tagen beheben. Aber da müssen doch noch mehr Leute drüber gestolpert sein? Warum erwähnt da niemand mit keinem Wort, wie man das lösen kann? Bin ich da echt der Einzige, der da drüber gefallen ist?
  • Der eingangs erwähnte Fehler in der Config des reverse-Proxy schlägt jetzt zu. Und zwar beim Erstellen der letsencrypt Zertifikate bei neuen WordPress Containern. Da werden ein paar Dienste nicht mehr neu gestartet und man muss das Ding manuell ein paar mal »anschieben«, damit die Seiten mit den Zertifikaten laufen. Und diesen Fehler auszubügeln… Oh boah ey, wow. Das waren ein paar Tage »Hirnschmelze« jeweils gefolgt vom Verputzen eines 500 ml Kartons Eiscreme, um das mentale Gleichgewicht wiederherzustellen. Als das dann endlich lief, hab ich mich an meinen Schnapsvorräten vergriffen … Echt, warum stellt jemand eine Config ins Netz, die falsch ist? Die Fehler wirft?! So was verstehe ich nicht …
  • Die Datenbanknutzer waren früher immer an »localhost« gebunden. Jetzt müssen die »systemweit« Zugriff bekommen, weil die Docker Container auf verschiedenen privaten Klasse B Netzwerken laufen. »localhost« wird nicht mehr gefunden und darum die Anmeldung verweigert. Sagt einem auch niemand in der Anleitung. Muss man selber drauf kommen, wie bei den anderen Sachen :/
  • Den phpMyAdmin Container mit dem MariaDB Datenbank Container zu verknüpfen. Nicht schön, wirklich nicht schön. Und wieder keine Hilfe in der Beschreibung vom phpMyAdmin Container, wie das genau mit einem docker-compose File gehen soll. Einige Stunde Trial and Error – dann ging’s …
  • Der piwik-Container kann keine Mails erzeugen. Aber das Problem hatte ich ja bei WordPress schon und konnte die Lösung 1:1 auf Piwik übertragen. Fantastico!
  • Selbiges beim nextcloud-Container. Ehrlich, Leute … Das mit dem Mail-Versand wäre schon wichtig. Ein kleiner Hinweis, dass das nicht mehr »out of the Box« funktioniert plus ein Link auf diverse Workarounds. Ist das zu viel verlangt?

Was fehlt noch?

  • Die Logs von nginx auswerten und fail2ban dazu schalten. Hab aber schon läuten hören, dass hier auch das IP-Problem durchschlägt, weil per Default die innere IP des Containers genommen wird (Klasse B Netz) statt der IP des Angreifers von außen.
  • Grundlegendes Verständnis, ob das ganze Ding so passt, wie ich das aufgesetzt habe. Laufen tut es und es macht auch, was es soll. Aber irgendwie hab ich noch ein ganz mulmiges Gefühl bei der Sache…

Fazit
Docker ist die höchste Form von Frankensteinerei, die ich bis jetzt gesehen habe. Jeder bastelt irgendwelche Dockerfiles zusammen und teilt sie mit dem Rest der Mannschaft. Das ist wahrer Austausch von Ideen. Gelebtes Open Source! Aber auch brandgefährlich, wenn man die falschen Sachen zusammenstopft.

Sonstiges

  • Ich habe bei der Gelegenheit gleich noch die Artikelstruktur meiner Anleitungen umgestellt, damit das Jahr und der Monat der Erstellung mit in die Adresszeile kommen. Damit kannst Du schnell sehen, wie alt eine Anleitung ist. Außerdem werde ich am Anfang der Artikel betonen, auf welcher Linux Distribution und welcher Version sie zugrunde liegt, sofern das relevant ist. Dann kannst Du schnell entscheiden, ob sie für Dich noch in Betracht kommt.
  • Ebenfalls werde ich jeweils am Anfang vermerken, ob die Anleitung nach heutigen Maßstäben noch klappt, oder schon überholt wurde. Dann lasse ich sie nur noch aus historischen oder bildungstechnischen Gründen stehen, aber verweise auf den Nachfolger…
  • Anstatt der Begleittexte werde ich die Code-Schnipsel via Github als Gists einbinden. Die kann man schöner verwalten.

Na denn, sehen wir mal zu, dass es diesmal klappt :)

Anzeige *

Kommentar verfassen

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