Für das Testsystem wird eine isolierte Umgebung benötigt, die ausreichend Kontrolle über Netzwerkdetails erlaubt und trotzdem möglichst frei von etwaigen Netzwerkproblemen ist. Würde hier echte Hardware eingesetzt werden, so käme das Problem hinzu, dass auf Hardware-Ebene Probleme und Fehler das System beeinträchtigen könnten. Eine manuelle lokale Konfiguration innerhalb eines Host-Systems, die das simulieren mehrerer MTAs erlaubt, ist aufgrund der Konfigurationskomplexität ebenso unerwünscht. Ebenso würde dies eine Abhängigkeit vom Host-System und dessen Konfiguration bedeuten. Aus diesem Grund wird eine Container-Software eingesetzt, die die entsprechenden Abstraktionsschichten bereits bereitstellt. Sie erlaubt mehrere gleichartige Prozesse isoliert laufen zu lassen und dieselben über eine definierte softwareseitige Netzwerkschnittstelle kommunizieren zu lassen. Für diese Art von Software existieren mehrere Lösungen. Für die Realisierung wird hier allerdings die Software \QuoteM{Docker} \RefIt{dockerhp} eingesetzt.

Docker ist keine Hardwarevirtualisierung. Es ist eine Abstraktionsschicht, die es erlaubt Prozesse in isolierten User-Spaces auf demselben Betriebssystemkernel laufen zu lassen. Dazu benutzt es Kernel Features wie Cgroups und Kernel Namespaces. Auf Dateisystem-Ebene wird UnionFS benutzt.

Die praktische Funktionsweise reduziert sich auf folgenden Ablauf: Der Benutzer erstellt eine Definitionsdatei mit dem Namen \QuoteM{Dockerfile}. Diese definiert gewissermaßen den Installationsprozess eines vollständigen Betriebssystems, der darin benötigten Applikationen, sowie die Art und Weise wie diese ausgeführt und konfiguriert werden. Auf Basis dieses Dockerfiles kann ein \QuoteM{Docker Image} erstellt werden. Ein Docker Image kann als Vorlage betrachtet werden, mit der eine Chroot-ähnliche Umgebung erstellt und ausgeführt werden kann. Diese ausgeführte Umgebung wird \QuoteM{Docker Container} genannt. Wichtig ist dabei, zu wissen, dass das Image aus mehreren UnionFS-Layern besteht (pro Dockerfile-Anweisung ein Layer). Wenn ein Container gestartet wird, so wird auf die Daten aus dem Image zugegriffen. Allerdings sind diese immer read-only. Sobald Änderungen an Dateien innerhalb eines Containers gemacht werden, wird die read-only Schicht des Images mit einer read-write Schicht des laufenden Containers zusammengeführt, ohne dass die Daten des Images sich dabei verändern. Somit können auf Basis eines beispielsweise gemeinsamen MySQL-Images mehrere MySQL-Instanzen gestartet werden, die alle dieselbe Version, dasselbe Betriebssystem und dieselbe Umgebung besitzen, aber dennoch voneinander isoliert sind, sowohl auf Prozess-, Netzwerk- und Dateisystem-Ebene. Beim Starten von Containern ist es allerdings möglich, diese miteinander zu verbinden, so dass sie auf Netzwerkebene miteinander kommunizieren können.

Mithilfe dieses Systems wird es möglich, mehrere gleiche MTAs zu starten und zu verbinden. Dabei können diese sich dennoch in der Konfiguration unterscheiden, da im laufenden Container Änderungen vorgenommen werden können. Ebenso ist es möglich, über Umgebungsvariablen oder Mountpoints, die vom Host in den Container zeigen, den Zustand und die Konfiguration eines Containers zu steuern. Ebenso sind die Container nahezu vollständig unabhängig vom laufenden Host-System, da ein Container bereits ein vollständiges Betriebssystem darstellt und lediglich mit dem Kernel des Host-Systems über den Docker Daemon kommuniziert wird.

Es werden gemäß \autoref{fig:algorithmus} also 5 E-Mail Container gestartet. Alle 3 Hops und der E-Mail Server des Empfängers haben dieselbe Konfiguration. Nur der E-Mail Server des Senders hat eine abweichende Konfiguration, da dieser als SMTP Gateway fungiert und anstelle des MUAs die initiale MystMail generiert. Alle Container werden in einem Netzwerk zusammengefasst und können untereinander kommunizieren.

Dieses System erlaubt es nun, fortlaufend Laufzeittests durchzuführen. Diese finden nicht automatisiert statt, sondern werden über die laufenden Prozesse in den Containern und deren Logdateien manuell durchgeführt.

Die Implementierung des Testsysems ist im Anhang einsehbar.
