Red Hat SummitÜberblick
Linux®-Container und virtuelle Maschinen (VMs) sind paketierte Computing-Umgebungen, die verschiedene IT-Komponenten vereinen und vom Rest des Systems isolieren. Sie unterscheiden sich hauptsächlich in Bezug auf ihre Skalierbarkeit und Portierbarkeit.
- Container werden gewöhnlich in Megabyte gemessen. In einen Container werden nur die App und alle zum Ausführen erforderlichen Dateien paketiert. Häufig werden darin auch einzelne Funktionen paketiert, die bestimmte Aufgaben (sogenannte Microservices) ausführen. Container können aufgrund ihrer geringen Größe und ihres gemeinsam genutzten Betriebssystems (OS) sehr einfach in verschiedenen Umgebungen hin- und hergeschoben werden.
- VMs werden gewöhnlich in Gigabyte gemessen. Sie enthalten normalerweise ihr eigenes Betriebssystem, auf dem sie mehrere ressourcenintensive Funktionen auf einmal ausführen können. Dank der zahlreichen, ihnen zur Verfügung stehenden Ressourcen können VMs ganze Server, Betriebssysteme, Desktops, Datenbanken und Netzwerke abstrahieren, aufteilen, duplizieren und emulieren.
Neben den technologischen Unterschieden steht der Vergleich von Containern mit VMs stellvertretend für den Vergleich zwischen neuen IT-Praktiken und traditionellen IT-Architekturen.
Neue IT-Praktiken (cloudnative Entwicklung, CI/CD und DevOps) sind möglich, weil die Workloads in möglichst kleine wartungsfähige Einheiten aufgeteilt werden können – normalerweise in eine einzelne Funktion oder einen Microservice. Diese kleinen Einheiten werden am besten in Containern paketiert, sodass mehrere Teams an einzelnen Teilen einer App oder eines Service arbeiten können, ohne den in anderen Containern paketierten Code zu unterbrechen oder zu gefährden.
Traditionelle IT-Architekturen (monolithische und Legacy-Anwendungen) verwenden einen einzigen großen Dateityp für alle Aspekte einer Workload. Dieser Dateityp kann nicht aufgeteilt werden und muss daher als ganze Einheit in einer größeren Umgebung, häufig einer VM, paketiert werden. Früher war es üblich, eine komplette App innerhalb einer VM zu erstellen und auszuführen. Der gesamte Code und die Abhängigkeiten führten jedoch zu übergroßen VMs, und beim Durchführen von Updates traten Kaskadierungsfehler und Ausfallzeiten auf.
Welches Konzept ist für mich geeignet?
Das kommt darauf an: Benötigen Sie eine kleine, verschiebbare Instanz (Container) oder eine semipermanente Zuweisung von benutzerdefinierten IT-Ressourcen?
Aufgrund ihrer geringen Größe sind Container problemlos in Bare-Metal-Systemen sowie Public, Private, Hybrid und Multi-Cloud-Umgebungen verschiebbar. Sie sind auch die ideale Umgebung für die cloudnativen Apps von heute, die aus mehreren Microservices bestehen und mit denen die Entwicklung und automatisierteVerwaltung von Public, Private, Hybrid und Multi-Cloud-Umgebungen überhaupt erst möglich wird. Cloudnative Apps tragen dazu bei, die Erstellung neuer Apps, die Optimierung bestehender Apps und die Verknüpfung aller Apps zu beschleunigen. Dabei ist jedoch erforderlich, dass die Container mit dem zugrunde liegenden Betriebssystem kompatibel sind. Im Vergleich zu VMs eignen sich Container besser, um:
- cloudnative Apps zu entwickeln
- Microservices zu paketieren
- DevOps- oder CI/CD-Praktiken einzuführen
- skalierbare IT-Projekte in einer uneinheitlichen IT-Umgebung zu verschieben, die unter einem gemeinsamen Betriebssystem läuft
VMs können weit mehr Vorgänge ausführen als ein einzelner Container. Aus diesem Grund werden noch immer monolithische Workloads paketiert. Diese erweiterte Funktionalität macht VMs jedoch aufgrund ihrer Abhängigkeit vom Betriebssystem, der Anwendung und den Libraries weitaus schlechter portierbar. Im Vergleich zu Containern eignen sich VMs besser, um:
- traditionelle, Legacy- und monolithische Workloads unterzubringen
- riskante Entwicklungszyklen zu isolieren
- Infrastrukturressourcen (wie Netzwerke, Server und Daten) zu provisionieren
- ein Betriebssystem unter einem anderen Betriebssystem (z. B. Unix unter Linux) auszuführen
Wie funktioniert das?
Virtualisierung
Eine als „Hypervisor" bezeichnete Software trennt Ressourcen von ihren physischen Geräten, sodass sie partitioniert und für VMs reserviert werden können. Wenn ein Nutzer eine VM-Anweisung ausgibt, für die zusätzliche Ressourcen aus der physischen Umgebung benötigt werden, leitet der Hypervisor die Anforderung an das physische System weiter und führt eine Zwischenspeicherung der Änderungen durch. VMs sehen aus wie physische Server und verhalten sich auch so. Dies kann dazu führen, dass sich die Nachteile der zahlreichen Betriebssystem- und Anwendungsabhängigkeiten, die für eine einzelne App oder einen Microservice meist gar nicht notwendig sind, vervielfachen können.
Container
Container enthalten einen Microservice oder eine App und alles, was zu deren Ausführung erforderlich ist. Der gesamte Inhalt eines Containers wird in einem Image abgebildet. Dies ist eine codebasierte Datei, die alle Libraries und Abhängigkeiten enthält. Man kann sich diese Dateien als Installation einer Linux-Distribution vorstellen, weil das Image alle RPM-Pakete und Konfigurationsdateien enthält. Da Container sehr klein sind, werden normalerweise Hunderte von Containern lose miteinander gekoppelt. Aus diesem Grund werden Container-Orchestrierungsplattformen (wie Red Hat OpenShift und Kubernetes) verwendet, um sie bereitzustellen und zu verwalten.
Warum Red Hat?
Weil wir Virtualisierung und Container-Entwicklung seit langem unterstützen. Wir haben seit der Gründung der Entwickler-Communities für Kernel-basierte virtuelle Maschinen (KVM) und oVirt einen Beitrag zu deren Entwicklung geleistet. Zu den Codebasen Docker und Kubernetes leisten wir den zweitgrößten Beitrag. Wir investieren außerdem in die Zukunft dieser beiden Technologien. Unsere Beteiligung an containernativer Virtualisierung, KubeVirt und hyperkonvergenter Infrastruktur verbessert das Zusammenwirken von Containern und VMs als Teil desselben IT-Systems.
