|
ContainervirtualisierungContainervirtualisierung (oder Containering) ist eine Methode, um mehrere Instanzen eines Betriebssystems (als „Gäste“) isoliert voneinander den Kernel eines Hostsystems nutzen zu lassen. Im Gegensatz zur Virtualisierung mittels eines Hypervisors hat Containervirtualisierung zwar einige Einschränkungen in der Art ihrer Gäste, gilt aber als besonders ressourcenschonend. Populär in der IT wurde die Software Docker im Jahr 2013, unter anderem durch eine intensive Zusammenarbeit mit Red Hat und die Integration in deren Produkt OpenShift.[1] Es hatte allerdings auch davor schon vergleichbare Projekte gegeben. PrinzipAuf einem gewöhnlichen Betriebssystem kann jedes Programm normalerweise alle Systemressourcen einsehen und verwenden. Unter anderem:
Das Betriebssystem kann den Zugriff auf solche Ressourcen einschränken in Abhängigkeit davon, unter welchem Benutzer und Kontext der Prozess läuft. Durch Containering lässt sich verwalten, welche Systemressourcen den Prozessen in dem Container zugewiesen werden.[2] Geschichte1979 führten die Entwickler von Unix den Systemaufruf chroot ein, mit dem sich ein Teilbereich des Dateisystems vom Rest isolieren ließ und damit einen ersten Schritt zur Virtualisierung des Betriebssystems ging[3]. Viele Jahre wurde der Ansatz nur sporadisch zu Zwecken von Softwaretests und dem Schutz von Servern genutzt, besonders unter den Derivaten von BSD-Unix, die es unter dem Namen Jails weiterentwickelten[4]. Auch wenn es in den späten 1990er-Jahren mit User Mode Linux Aktivitäten bei Linux-Entwicklern gab, um das Betriebssystem im Betriebssystem zu starten, fand dieser Ansatz nur in Fachkreisen höhere Beachtung[5]. Verbreitet war mit dem Open-Source-Projekt OpenVZ und dem darauf basierenden Produkt Virtuozzo Mitte der 2000er Jahre Software, die es Webhostern gestattete, viele Linux-Websites auf einem einzigen Server zu betreiben. Die Betriebssysteme Solaris und BSD hatten jeweils eigene Realisierungen des Prinzips. Die Entwickler des Linux-Kernels hatten unter dem Eindruck dieser Entwicklungen Vorsorge getroffen, ähnliche Funktionen in ihr Betriebssystem einzubauen. Dazu zählen unter anderem die Namespaces, Cgroups und Capabilities. Unter dem Begriff LXC kamen viele dieser Techniken zum Einsatz, bedurften aber noch viel Detailwissens im Aufbau von Betriebssystemen und Betriebssystemdistributionen. Das änderte sich, als 2013 das damals dotCloud genannte Unternehmen Docker vorstellte, das es Anwendungsentwicklern vereinfachte, ihre Software in Containern zu verpacken. In der Folge sind besonders für Linux eine Reihe von Alternativen zu Docker entstanden, darunter rkt (ausgesprochen Rocket) und das Teilprojekt Nspawn von systemd. Einige Projekte und Anbieter paketieren Containervirtualisierung auch in Produkten, die weitere Verwaltungssoftware enthält, etwa zur Orchestrierung oder um Platform as a Service anzubieten. Beispiele dafür sind die Projekte Kubernetes oder OpenShift. RealisierungenViele Projekte und Produkte implementieren das Prinzip der Containervirtualisierung, unterscheiden sich jedoch im Umfang, welche Systemressourcen (zum Beispiel Prozesse, Dateisystem, Netzwerkschnittstellen) sie virtualisieren und voneinander isolieren. Einige Realisierungen umfassen:
HostbetriebssystemeDie meisten Realisierungen von Containervirtualisierungen stammen aus dem Umfeld der Betriebssystemfamilie Unix. Populär wurde sie besonders im Kontext von Linux ab 2013 durch Docker. Dafür gibt es auch Realisierungen für die Hostbetriebssysteme Windows und MacOS, die jedoch letztlich zusätzlich zur Containervirtualisierung einen leichtgewichtigen Hypervisor verwenden, um wieder einen Linux-Kernel zu starten und diesen dann mit Docker zu nutzen. Es gibt auch native Containervirtualisierung für andere Betriebssysteme als Linux, die jedoch noch keine große Verbreitung gefunden haben. KritikDa alle Gäste der Containervirtualisierung den gleichen Kernel nutzen, muss dieser starke Mechanismen mitbringen, um die Isolation der einzelnen Gäste zu realisieren. Das ist bei einer komplexen Software wie etwa einem Linux-Kernel mit mehreren hundert Systemaufrufen und diversen anderen Wegen der Kommunikation mit dem Kernel nicht ganz einfach.[9] Durch die Isolation der Dateisysteme nutzt jeder Container seine eigene Fassung von Systembibliotheken. Werden in ihnen Schwachstellen bekannt, wie beispielsweise die als Heartbleed bezeichnete Schwachstelle der SSL/TLS-Bibliotheken OpenSSL, so muss ein Systemverwalter alle ihre Instanzen auf einem Computer aktualisieren, anstatt nur einmal pro Server. Durch die Vielfalt an Einstellungs- und Konfigurationsmöglichkeiten lassen sich Container leicht so einstellen, dass sie ungewollte Zugriffsmöglichkeiten eröffnen. So erlauben privilegierte Container zwar mehr Funktionen innerhalb des Containers auszuführen, aber schwächen die Isolation der Container vom Host.[10] Als Dienstleistung für Container sind Repositories entstanden, die bereits fertig zusammengestellte Images anbieten, die direkt auf der Containerplattform lauffähig sind. Einige dieser Artefakte sind von zweifelhafter Qualität und können durch Unwissenheit oder bösen Willen der Anbieter Schwachstellen enthalten, wenn sie nicht vor dem Download und Betrieb geprüft wurden.[11] Einzelnachweise
|