Containerunwesen

Nachdem meine ersten Schritte mit Docker ja etwas schwierig waren, werde ich langsam damit warm.

Ich habe das Urprungsprojekt etwas erweitert, da ich mit der Lösung postfix + courier-imapd nicht wirklich glücklich werden würde: der Versuch, per imapcopy meine Mailbox vom alten Rechner (sendmail + dovecot) auf den direkt auf dem Host laufenden Container zu übertragen, zeigte eine zunehmende Verlangsamung der Übertragung: nach rd. 4 Stunden waren gerade einmal 50.000 Mails transferiert, von anfänglich 3-5 Mails pro Sekunde waren es kurz vor dem Abbruch eher 1-3 Sekunden pro Mail :-(

Außerdem habe ich das Problem, daß ich eigentlich aus dem einen Mailserver mehrere machen möchte, um private Mails von geschäftlichen nun endlich sauber trennen zu können — was dank der Container-Lösung ja recht einfach gehen müßte. Allerdings ist mir unklar, wie ich bei mehreren v4/v6-Adressen auf dem Rechner/der VM nur bestimmte Sockets jeweils auf bestimmte Container umbiege. Sprich: es nützt mir da nichts, Port 993 umzuleiten; es müßte 10.11.12.13:993 auf Port 993 in Container A, 172.22.33.44:993 auf Port 993 in Container 2 umgeleitet werden (wobei der Zielport nicht sooo wichtig wäre). Aber das hat nun zum Glück ersteinmal wieder Zeit.

Ich habe jedenfalls nun zwei Container mit meinem »wusel42/docker-mailserver« laufen, die nur SMTP-MX machen und u. a. besagte Fedora-Core-1-VM endlich abgelöst haben. Der erste Schritt war ein Test (»mx.uu.org«) des neuen Containers; um das ohne große Gefahr des Mailverlustes zu testen, habe ich auf der alten VM (»famine.uu.org«) den Mailserver heruntergefahren und per ssh im screen einfach die Ports 25 und 587 zu »mx« weitergeleitet. Zwar ging die orginale Einlieferungsadresse verloren, aber ich konnte so relativ gefahrlos die Funktion des Scannings und der Weiterleitung testen. (»mx.uu.org« ist aktuell ein Container auf meinem i3-NUC, mittelfristig wird das aber wohl umziehen auf meinen Host bei Hetzner — das Filtering muß man ja nicht hinter der heimischen [V]DSL-Leitung machen.)

Nachdem dieses Setup rund zwei Tage erfolgreich lief – mit deutlich reduziertem Spam-Aufkommen, yeah! –, habe ich Dienstag abend eine neue VM »famine.uu.org« auf meinem i5-NUC hochgefahren und dort »wusel42/docker-mailserver« ein zweites Mal, mit fast identischer Konfiguration, installiert. Zuvor mußte natürlich die alte »famine«-VM ihre Service-IPs abgeben, die nun auf der VM liegen … Und schon kurz nach dem Start zeigte sich ein grundsätzliches Problem: die VM war mit 1 CPU und 1 GB RAM etwas schwachbrüstig bemessen, so zwei bis drei GB hätten spamd, clamav, amavis und Co. schon gerne — und eine swappende VM will man ganz bestimmt nicht (trust me on this ;)). Mit 2 CPUs und 4 GB läuft das jetzt aber fluffig. Evtl. ziehe ich das aber doch auf die Hosteben um, Docker auf KVM vereinigt ja eher das Schlechteste aus beiden Welten ;-)

Nächster Schritt ist dann der Austausch von courier-imap durch dovecot, sodaß ich einfach die mbox-Files kopieren kann statt mühsahm konvertieren zu müssen — und dann der Austausch von »mail.uu.org«. Na, schaun’ ‘mer mal …

3 thoughts on “Containerunwesen

  1. Ich hab mich auch vor ein paar Tagen zum ersten Mal mit Docker gespielt. Portforwarding für einzelne IPs sollte mit -p 172.131.13.1:993:993 gehen, aber Vorsicht: Das Tierchen baut seine eigenen Firewallregeln die nach überall offen sind, ich hab dann lieber in /etc/default/docker (bei nicht-systemd-systemen) docker mit –iptables=false aufgerufen und alles selbst gemacht, siehe auch https://fralef.me/docker-and-iptables.html. Doof fand ich auch anfangs, dass wenn ich den Container neu generiert habe (weil z.B. auf docker.io eine frische Version rauskam) alle Daten daraus weg waren, ich hab dann mit “-v” ein Verzeichnis vom Hostrechner als Datenverzeichnis und eins für die Konfigurationsdatei an den Container übergeben, damit diese persistent waren. Dockerfiles hab ich noch nicht angefasst, kann aber noch passieren, so langsam werde ich auch warm damit…

  2. Ich halte das Docker zeugs ja für totalen Schwachsinn. Das ist security Technisch eine Vollkatastrophe (Hat jeder schon seine 5000 Container mit der neuen libc geupdated?) etc .. Das ist ein Hype der hoffentlich schnell wieder verschwindet.

  3. Jein. Wenn Du mit heißem Scheiß arbeitest, ist Docker ein cooler Weg, Dein System sauber zu halten, und dennoch, ohne jedesmal den Dependency Devil als Endgegner vor dem Deployment erlegen zu müssen, noch dampfende Ruby/node/…-Libs nutzen zu können. OpenVZ, reduziert auf das Wesentliche. Im Grunde baut man Service-Päckchen, ob Du die dann auf RedHat oder Ubuntu startest, ist genauso egal wie der Patchstand Deines Servers: alles Benötigte bringt der Container mit. Integrationstests sind einfacher, ergo auch die Updatezyklen. Und die neueste glibc fällt da automatisch mit rein … An sich eine nette Idee.

    Nur völlig overhyped.

Comments are closed.