Sie haben sicherlich genügend über Docker-Container gehört und wie sie Continuous Delivery (CI/CD) ermöglichen. Wenn sie so fabelhaft funktional sind, warum sind dann virtuelle Maschinen (VMs) – ihre Vorgänger – noch nicht ausgestorben?

Wie alles anfing

Tatsächlich ist es ein großer Irrglaube, dass Container und virtuelle Maschinen gegenseitig austauschbar sind. In Wirklichkeit erfüllt jede seinen eigenen Zweck. Die Technologien können aber auch zusammen verwendet werden.

Entwickler sahen sich mit der Notwendigkeit konfrontiert, ihre Anwendungen mit jedem Betriebssystem (OS) kompatibel zu machen. Aus diesem Grund brauchten sie eine schnelle Möglichkeit, ihre Anwendungen auf allen vorhandenen Betriebssystemen zu testen, ohne zusätzliche Hardware einsetzen zu müssen.

Aus diesem Bedürfnis heraus entstanden Hypervisoren: eine Software, die die Ressourcen einer physischen Maschine in mehrere aufteilt. Virtuelle Maschinen laufen auf Hypervisoren. Als ob ein Computer buchstäblich zu vielen wird.

Da ein physischer Computer mehrere virtuelle Computer beherbergen muss, können virtuelle Maschinen Leistungsprobleme haben. Selbst eine virtuelle Maschine zu starten kann mehrere Minuten dauern, im Vergleich zu nur wenigen Millisekunden bei ihren Nachfolgern und Rivalen: Containern.

Container haben einen anderen Job

Container emulieren nur das Betriebssystem und nicht die Hardware. Damit isolieren sie nur eine bestimmte zu testende Anwendung mitsamt ihren Abhängigkeiten. Diese Selektivität lässt sie schneller arbeiten. 

Aber Container können auf einmal nur ein Betriebssystem imitieren, obwohl der Zweck ihrer Existenz darin besteht, eine Basisanwendung zu entwerfen, die OS-agnostisch ist. Container sind gut, um eine stabile Grundlage für die Softwareentwicklung zu schaffen, indem sie Ihre Anwendung oder einen Teil davon in eine virtuelle Umgebung isolieren. Sie heben beispielsweise die Unterschiede zwischen einem Server und einem Laptop auf und ermöglichen es einem Entwickler, eine Anwendung auf einer Maschine zu entwerfen und sie dann nahtlos auf der anderen Maschine einzusetzen. 

Container sind perfekt für Microservices-Infrastrukturen geeignet, die derzeit auch boomen. Microservices sind winzige Anwendungen, die über APIs miteinander verbunden sind und als Gruppe eine Anwendung abbilden. Da sie einzeln entwickelt und bereitgestellt werden, ist der Bedarf, sie isoliert zu testen, groß genug, um die Popularität von Containern zu erhalten.

Virtuelle Maschinen: Wir brauchen sie ebenfalls

Eine weitere Schattenseite der Container-Technologie sind einige Sicherheitsprobleme. Da der Umfang der Isolation kleiner ist, ist auch die Robustheit geringer. Eine Sicherheitslücke kann das gesamte Betriebssystem betreffen, während virtuelle Maschinen klar voneinander abgegrenzt sind und das Host OS nie infiziert werden kann. 

Außerdem brauchen Sie manchmal vielleicht eine komplette Funktionalität des Betriebssystems, anstatt nur einige Bausteine auszuschneiden, um sie in ein Container zu packen. In anderen Fällen haben Sie vielleicht ressourcenintensive Aufgaben, die ein vollwertiges Betriebssystem benötigen. 

Wenn Sie einen Server, Speicher oder eine andere Infrastrukturkomponente bereitstellen müssen, müssen Sie eine virtuelle Maschine verwenden, da Container nicht den gleichen Umfang bieten können. Container erlauben die gemeinsame Nutzung eines Kernels für die Ausführung mehrerer Aufgaben, aber das wird zu einer Einschränkung, wenn Sie die volle Leistung des Kernels für diese Aufgabe benötigen. 

Aber das sind nicht die einzigen Gründe, warum Virtualisierungstechnologie nie aufgegeben werden soll. Der Hauptvorteil ist, dass Sie Container und VMs zusammen verwenden können, um Ihr Testing, Qualitätssicherung (QA) und CI/CD auf eine neue Ebene zu bringen.

Docker und MacOS: Es ist kompliziert

Docker ist die branchenführende Containerisierungsplattform. Leider hat sie eine Menge Probleme mit MacOS. Einer der Hauptgründe dafür ist die architektonische Komplexität von MacOS. Wenn Docker auf Linux läuft, hat es eine direkte Verbindung zu seinem Host-Betriebssystem. Wenn Sie es unter MacOS ausführen, erwacht die Docker Engine zum Leben… eine virtuelle Linux-Maschine! Nicht die, die Sie installiert haben – wenn Sie es überhaupt getan haben, natürlich – sondern die, die in seiner Architektur mit integriert ist.

Docker muss sich also durch mehrere Schichten kämpfen, um die Festplatten seiner Container und die des Host-Betriebssystems zu synchronisieren. Das führt zu langsamen Dateizugriffen und Problemen bei der Netzwerkkonfiguration.

Folglich wenden sich Entwickler allmählich von der Verwendung von MacOS ab und ersetzen es durch Linux. Diejenigen, die Apple besonders treu sind, verwenden VirtualBox – die beliebteste Software zum Ausführen virtueller Maschinen – mit einem Docker. Aber auch das bringt noch nicht die Performance wie auf einem Linux-System.

Fazit

Ein weiteres Beispiel für die Zusammenarbeit von Docker und VMs ist, wenn Sie den selben Server für Test- und Produktionsumgebung verwenden. In diesem Fall starten Sie eine VM, die einen Teil des Servers für Entwicklung und Tests verwendet, und der Rest des Servers wird ganz normal für andere Arbeitsabläufe genutzt. 

Container und virtuelle Maschinen koexistieren also weiterhin recht friedlich. Allerdings versuchen Docker-Fans, die aktuellen Defizite auszugleichen. Einer dieser Versuche hat Kubernetes ins Leben gerufen, ein Open-Source-Tool zur Container-Orchestrierung.

Aber das ist schon eine andere Geschichte. Bleiben Sie dran!