tostphoto - stock.adobe.com
Docker-Container versus VMs als Entwicklungsumgebung
Während es wichtige technische Unterschiede zwischen virtuellen Maschinen und Containern gibt, entscheiden sich Entwickler für letztere eher aus kulturellen Gründen.
Wenn ein Softwareentwickler Docker installiert, wird er davon begeistert sein, wie schnell eine Instanz bereitgestellt wird. Doch dann kommt dem Entwickler ein Verdacht: Habe ich das gleiche nicht schon mit einer virtuellen Maschine (VM) gemacht?
Containersoftware bietet zweifellos einen schnellen Weg zur Bereitstellung, Nutzung und zum Verschieben von Anwendungen. Aber die Kernkonzepte rund um die Containerisierung von Stacks sind nicht neu. Zuverlässige VMs können technisch genau dasselbe erreichen, was Container können – einschließlich der Aufgliederung ganzer Stacks, Portabilität und der Full-Stack-Bereitstellung.
Der Grund, warum VMs nicht auf breiter Basis von Entwicklern angenommen wurden, kann daran liegen, wie diese VMs ihnen vermittelt wurden und wie sie tatsächlich funktionieren. Das bedeutet, dass die Ursache für die stärkere Präferenz für Container im Vergleich zu virtuellen Maschinen sowohl philosophischer als auch technischer Natur ist.
Technologievergleich
Um die Unterschiede zwischen Docker-Containern und virtuellen Maschinen zu verstehen, hier ein Vergleich der technischen Aspekte:
Hypervisor: Die Anforderungen an den Hypervisor für VMs sind groß und zwangsläufig an den Installationsort des Hypervisors und seine Version gebunden. Es gibt zwar viele Konvertierungswerkzeuge, aber der Konvertierungsprozess muss stattfinden, bevor man von einem Hypervisor zum anderen wechselt. Container hingegen sind Hypervisor-unabhängig, haben aber einige andere Abhängigkeiten. Ein Docker-Container benötigt beispielsweise noch Docker, und er läuft nicht unbedingt auf jeder Container-Engine.
Backend Support: VMs bieten eine breitere Unterstützung für das Backend von Anwendungen. Es ist weder praktikabel, Docker-Container für Ihr Backend zu erstellen, noch passt dies wirklich zu den Prinzipien von Containern, die ja eine relativ kurze Lebensdauer haben. Im Idealfall werden bei jedem Release alle aktuellen Container gelöscht und durch neue ersetzt.
Größe: Ohne die mangelnde Unterstützung für Backends, die jeden Container aufblasen können, sind Container wesentlich kleiner. Ein Eins-zu-eins-Vergleich von Frontend-Softwareimplementierungen auf einem Docker-Container fällt kleiner aus als bei entsprechenden VMs. Dies bedeutet, dass die Bereitstellung, die die Kopie der physischen Image-Datei erfordert, mit Containern viel schneller ist.
Geschwindigkeit: Der Unterschied in der Geschwindigkeitsabnahme vom Host-Betriebssystem zum Container ist ein wichtiger Aspekt. Es gibt bei VMs einen Verlust, während Container keinen haben - mit Ausnahme des geringen Overheads für den Docker-Service. Es gibt weitere Leistungsvorteile von Containern im Vergleich zu VMs. Dies ist jedoch oft ein strittiger Punkt, da die meisten Docker-Instanzen auf VMs laufen. Es darf keinen Geschwindigkeitsverlust geben, aber sie erhalten die Abwertung der VM von ihrem Bare-Metal-Host. Im Allgemeinen ist es die beste Vorgehensweise, auf einer VM und nicht auf dem lokalen Computer zu laufen.
Host-Betriebssystem: Eine VM ist vollständig vom Host-Betriebssystem isoliert, während Docker isolierten Arbeitsspeicher und Festplattenspeicher hat – obwohl Container den gleichen Host-Betriebssystem-Kernel verwenden. Darüber hinaus unterstützt Docker nicht die Breite der Host- oder Container-Betriebssystemoptionen, die eine virtuelle Maschine unterstützt. Wenn Sie Microsoft-Anwendungen nutzen, haben Sie mehr Möglichkeiten, Docker auf Windows Server 2016 auszuführen, doch VMs haben immer noch mehr Optionen als Container.
Networking: VMs verfügen über eine breitere Palette von Netzwerkfunktionen. VMs unterstützen virtuelle Netzwerke, die Snapshots sein können, zusammen mit einer Sammlung von vernetzten VMs. Dies bietet viel mehr Flexibilität, ist aber eher für Desktop-Umgebungen und weniger für die Anwendungsentwicklung relevant. Container können auch vernetzt werden, aber die Technologie ist weniger ausgereift und die Konfiguration komplexer.
Images: VM-Snapshots und Container-Images sind beides Möglichkeiten, eine Bibliothek von Instanzen zu verwalten, die Entwickler in Zukunft bereitstellen können. Eine VM-Funktion, die mit Docker nicht möglich ist, ist die Option, den Arbeitsspeicherzustand zu verändern. Dadurch können Full-Stack-Bereitstellungen beschleunigt und Anwendungsfehler behoben werden. Docker unterstützt PAUSE und UNPAUSE, ist aber für die aktive Instanz nur noch lokal.
Management: Sowohl VMs als auch Docker-Container haben einzigartige Managementeigenschaften. Entwickler müssen Docker-Container wie Anwendungskomponenten behandeln: Sie sollten sie versionieren und in einem Repository ablegen. Docker-Container sind in Schichten aufgebaut und haben viele bewegliche Bestandteile, weshalb es wichtig ist, alle Änderungen zu verfolgen. VMs ändern sich ebenfalls, aber seltener. Im Vergleich zur Anzahl der VMs in einem typischen Hypervisor-Setup hat ein typisches Docker-Setup wahrscheinlich mehr Container. Daher ist ein Container Sprawl wahrscheinlicher als ein VM Spawl.
Portabilität: Docker-Container sind aufgrund ihrer Größe, ihrer Vernetzung und anderer Elemente im Allgemeinen portabler als VMs. Während Sie mit VMs relativ beweglich sind, ist die Bereitstellung einer neuen Instanz nicht so nahtlos möglich wie mit Docker-Containern.
Philosophischer Vergleich
Es ist zwar schwierig, den Einfluss von Menschen auf die Übernahme von Technologien zu quantifizieren, aber das bedeutet nicht, dass es überhaupt keinen Einfluss gibt.
Docker wurde als ein von Entwicklern für Entwickler bereitgestelltes Tool gestartet. Es ist etwas, das Entwickler in ihrem typischen Entwicklungsablauf verstehen und für sie leichter zugänglich ist. Docker unterstützt zum Beispiel die Automatisierung von Software-Releases und Full-Stack-Implementierungen besser. Auf der anderen Seite wurden VMs zu einer Zeit eingeführt, in der die IT die volle Kontrolle über die gesamte Infrastruktur, einschließlich der Entwicklung, hatte.
Da VMs an einen Hypervisor gebunden und größer sind, gibt es typischerweise noch den Prozess der Beschaffung. Daher unterstützen sie moderne DevOps-Entwicklung ebenso wenig wie Container.
Aber ein relativ offensichtlicher Punkt, den man sich merken sollte, ist, dass die Docker Containersoftware fast immer auf einer VM läuft. Und da VMs eine fest installierte Infrastruktur sind, schafft die Ausführung von Docker auf ihnen mehr Flexibilität.
Die Einschränkungen der VM-Einführung in der Entwicklung resultieren vor allem aus der Art und Weise, wie Organisationsstrukturen um VMs herum aufgebaut wurden. Dockers Containersoftware gewinnt an Agilität, aber neben den wichtigsten Unterschieden in Bezug auf Größe und Geschwindigkeit gibt es nichts, was verhindert, dass virtuelle Maschinen eine vollwertige containerisierte Option für die moderne Softwarelieferkette sind.
