© Jozef Polc, 123RF

Container-Virtualisierung ist keine Erfindung der Gegenwart. Tatsächlich existieren solche Lösungen für Linux bereits seit Jahren. Das Linux-Magazin stellt die Platzhirsche und ihren Charakter vor.

Wenn es heute um Linux und Container-Virtualisierung geht, fällt fast immer nur ein Name: Docker. Tatsächlich ist es Docker gelungen, dieses Thema mit beachtlicher Wucht zurück ins Bewusstsein von Admins und IT-Strategen zu befördern. Regelmäßig entsteht sogar der Eindruck, Docker habe Container-Virtualisierung auf Linux-Systemen überhaupt erst erfunden. Doch das ist nicht richtig, es gibt sie seit rund 15 Jahren und sie wird auch schon seit längerer Zeit produktiv eingesetzt.

Wodurch werden Container für Admins überhaupt interessant? Der folgende Artikel verrät, warum Container für Admins so attraktiv sind und welche grundsätzlichen Ansätze sich gegenüberstehen.

Container versus Vollvirtualisierung

Virtualisierung gibt es bekanntlich in mehreren Geschmacksrichtungen. Auf der einen Seite steht die vollständige Virtualisierung in Form virtueller Computer. Hier entsteht ein komplettes System mit virtuellem Bios, das für die auf ihm laufende Software wie ein physischer Server aussieht. Unter normalen Umständen merkt die Software in der VM gar nicht, dass sie nicht auf echtem Blech läuft. Heute verwenden Admins meist diesen Ansatz. Besonders die Paravirtualisierung hat geholfen Vollvirtualisierung bekannt zu machen: Bei der Paravirtualisierung nutzt der Virtualisierer die Hardware des Hosts besser aus, wodurch sich eine bessere Performance ergibt.

Vollvirtualisierung hat allerdings einen großen Nachteil: Weil bei diesem Ansatz stets ein kompletter Computer simuliert wird, entsteht Overhead. Anders formuliert: Der Host, auf dem mehrere VMs etwa mit KVM und Qemu oder Xen laufen, verbrät alleine dafür Ressourcen, die den virtualisierten Rechnern dann nicht zur Verfügung stehen.

Im kleinen Maßstab ist der Effekt nicht so tragisch, aber bekanntlich macht eben auch Kleinvieh Mist. Insbesondere Cloudanbieter sind betroffen: Je mehr VMs in einem Setup laufen und zu verwalten sind, desto größer ist der Overhead. Damit ist auch die Dichte virtueller Maschinen pro Host oder Rack beschränkt, mit der Anbieter großer Rechenzentren planen können.

Container-Virtualisierung kommt da wie gerufen: Bei Containern emuliert der Host eben keinen kompletten Host, kein virtuelles Bios und auch keinen Kernel auf dem virtuellen Host. Alle Container eines Systems teilen denselben Kernel des Betriebssystems und greifen unmittelbar auf die Hardware zu, die der Hostkernel verwaltet. Damit entfällt der Overhead durch den Vollvirtualisierer praktisch vollständig.

Spötter behaupten, dass Container gar keine echte Virtualisierung seien. Denn “virtuell” ist bei Containern nur das Dateisystem. Der ganze Rest passiert über Funktionen des Hostkernels, die dafür sorgen, dass sich diverse Container nicht in die Haare kriegen.

Vom Kernel abhängig

Egal ob man Container als Virtualisierung betrachtet oder nicht: In jedem Fall muss der Kernel des Hostsystems Funktionen bereitstellen, damit die Container wie gewünscht funktionieren. Diese Funktionen waren in der Vergangenheit regelmäßig Grund für Zwist in der Riege der Kernelentwickler.

Doch der Reihe nach: Vor einigen Jahren trat Open VZ, dessen kommerzielle Variante sich später Virtuozzo nannte, als eine der ersten Container-Lösungen für Linux überhaupt auf den Markt. Im Linux-Kernel war Container-Virtualisierung damals kein Thema und entsprechende Funktionen fehlten komplett.

Open VZ löste das Problem durch einen eigens gepatchten Frankenstein-Kernel, der zwingend nötig war, um Open-VZ-Container auf dem Host zu verwenden. Viele Anläufe, die Patches für Open VZ in den Kernel zu bekommen, schlugen aber aus technischen Gründen fehl. Am Ende wurden Teile von Open VZ zur Basis für Cgroups und Network Namespaces, die heute das Rahmenwerk für Container in Linux bilden. Bis heute braucht Open VZ aber einen eigens gepatchten Kernel, wenn Admins die volle Funktionalität einsetzen wollen, die die Software ihnen anbietet.

Mit einem Rahmenwerk für Container im Kernel war das freie Betriebssystem relativ spät dran: Besonders Free BSD bot frühzeitig eigene Container-Implementierungen. Das sagt natürlich nichts über die technische Qualität der Linux-Implementierung aus: Cgroups gelten im Allgemeinen als zuverlässig. LXC war die erste Lösung, die auf Basis von Cgroups tatsächlich die Möglichkeit bot, Container mit Linux zu nutzen. Praktisch alle Container-Lösungen der Gegenwart für Linux setzen auf die Cgroups und ihre diversen Namespaces für Netzwerke und Prozesse auf.

Docker hat sich von Anfang an auf die Kernelfunktionalität zum Containern eingeschossen. Andere Lösungen wie der V-Server für Linux gehen hingegen bis heute ihren eigenen Weg, was ihren Einsatz meist komplizierter gestaltet. Doch der Pionier in Sachen Container verdient besondere Erwähnung.

Aller Anfang: Der Linux-V-Server

Beim Linux-V-Server-Projekt mag man über den aktuellen Docker-Hype bereits einige Male geschmunzelt haben. Denn der Preis für die erste Container-artige Lösung für Linux geht eindeutig an das V-Server-Projekt: Schon 2001 trat man mit entsprechenden Kernelpatches an die Öffentlichkeit (Abbildung 1). Damals war die Idee in vielerlei Hinsicht revolutionär: Selbst Vollvirtualisierer wie Xen oder KVM waren zu dieser Zeit weit von den Erfolgen entfernt, die sie zwischenzeitlich feiern konnten.

Abbildung 1: Bis heute baut das V-Server-Patch den Linux-Kernel gehörig um. Für die Lösung ist das ein Nachteil: Kein Admin betreibt gern selbst gebaute Frankenstein-Kernel.

Ein Server war für die meisten Anwender schlichtweg Blech, das in einem Serverschrank im Rechenzentrum hing. Zwar gab es damals Hardware, die deutlich weniger potent als die moderner Server war. Dafür waren aber auch die Anforderungen an Server insgesamt deutlich geringer: Web 1.0 war gerade erst in die Gänge gekommen und vom “Mitmach-Web 2.0” war keine Rede. Websites mit Flash waren Hingucker und nicht die Regel, sondern die Ausnahme.

Längst nicht jeder brauchte damals eine eigene Website oder gar einen eigenen (virtuellen) Server. Wer trotzdem eine Website oder einen Server wollte, griff nicht selten zu den Free-Hosting-Angeboten, die schon damals existierten. Und genau diese Webhoster waren es, die erstmals auf die Idee kamen, Container zu verwenden. Auch wenn das damals nicht so hieß: Aus der Notwendigkeit, auf einem physischen Server etliche Kunden gleichzeitig zu hosten (anstatt für jeden Kunden einen separaten Server anzuschaffen), entstanden die Container.

Eine Frage der Sicherheit

Die Idee des Linux-V-Servers war geboren. Was seine Entwickler motivierte, glich in vielen Belangen dem, was auch heute von Containern erwartet wird: Einzelne Kunden sollten innerhalb eines Linux-Systems ein eigenes Dateisystem bekommen. Die Hardware sollten und mussten sie sich allerdings mit anderen Kunden teilen. Ein Benutzer sollte dabei auf keinen Fall die Möglichkeit haben, aus seinem eigenen V-Server zu entkommen und zu sehen, was andere Kunden auf demselben System trieben.

Am Ende der Bemühungen stand ein ziemlich großes Kernelpatch, das bis heute nötig ist, um den Linux-V-Server sinnvoll zu nutzen. Wohlgemerkt: Als das V-Server-Projekt Fahrt aufnahm, war an entsprechende Funktionen im Linux-Kernel nicht zu denken. Mittlerweile gibt es die zwar, die V-Server-Entwickler haben aber bis heute keine Anstalten gemacht, ihr Projekt an die neuen Gegebenheiten anzupassen. Wer einen V-Server-fähigen Kernel will, kommt in der Regel also nicht darum herum, ihn selbst zu bauen. Immerhin: Ein Patch für Linux 3.18 stellen die Developer auf ihrer Website [1] zur Verfügung.

Dazu gibt es die fast schon etwas empörte Feststellung, dass V-Server bis heute in vielen Setups zum Einsatz kommt und weiterhin aktiv gepflegt wird. Das kann aber nicht darüber hinwegtäuschen, dass die Projektwebseite insgesamt ziemlich altbacken wirkt und die letzten Einträge in den News oder im Wiki schon etwas älter sind – mehrere Jahre.

Letztlich wirkt der Linux-V-Server also etwas aus der Zeit gefallen. Der Aufwand des Kernel-Patchens zahlt sich nicht aus. Mit einer der Lösungen, die auf Kernelfunktionalität beruhen, ist der Admin deutlich besser dran.

Silberstreif am Horizont: Virtuozzo

Virtuozzo (zuvor unter dem Namen Open VZ bekannt, Abbildung 2) war ebenfalls ein Pionier in Sachen Container für Linux: Zwar brauchte es deutlich länger als der Linux-V-Server, um sich im Markt zu positionieren, dafür klappte das ganz gut: Open Virtuozzo, von dem es später auch kommerzielle Ableger gab, baute sich schnell eine große Fangemeinde auf. Dazu beigetragen haben mag auch, dass der Anbieter Swsoft (der später Parallels kaufte und sich noch später selber so nannte) Anwendern erstmals eine vollständige Virtualisierungslösung auf Linux-Basis bot – Werkzeuge und Kernelpatches inklusive.

Abbildung 2: Nostalgische Gefühle bei Open VZ: Die stabile Version der Lösung setzt noch immer auf Linux 2.6.32. Immerhin verspricht Parallels bald eine neue Version auf Basis von RHEL 7.

Wer sich Virtuozzo ins Rechenzentrum stellt, kann folglich mit einem Wunschlos-glücklich-Paket rechnen: Die fertige Distribution bietet direkt nach der Installation an, Container (Virtual Private Servers (VPS) oder Virtual Environments (VEs)) zu erstellen.

Aus technischer Sicht ist der Aufwand, den Virtuozzo betreibt, beachtlich: Weil es, wie Linux-V-Server, aus einer Zeit stammt, in der im Linux-Kernel die nötige Virtualisierungs-Infrastruktur noch gar nicht vorhanden war, ist auch für die Virtuozzo-Releases bis heute ein gepatchter Kernel nötig.

Technisch haben die Entwickler ganze Arbeit geleistet. Für Container lassen sich CPU- und I/O-Quotas definieren, sodass eine in einem Container Amok laufende Applikation nicht die Container anderer Nutzer über den Umweg des Hosts in den Abgrund reißt. Jeder Container bekommt einen eigenen Netzwerkstack, für den sich separate Firewallregeln definieren lassen. Das muss der Admin aber ausdrücklich so konfigurieren.

Aus einem Container heraus erhalten Anwender keinen Zugriff auf andere Ressourcen des Systems. Prozess-IDs sind virtualisiert, sodass auch jeder Container einen Initprozess mit der ID 1 hat. Welche Prozesse in VEs von anderen Nutzern laufen, sieht der Nutzer eines Containers nicht. Gleiches gilt für den Zugriff auf sämtliche Systembibliotheken oder die Files in »/dev« , »/proc« und »/sys« .

Das leidige Kernel-Thema

Virtuozzo war über viele Jahre hinweg ein kommerzielles Zugpferd. Mit der Open-Source-Version teilten sich Virtuozzo beziehungsweise der Parallels Cloud Server, wie das Projekt später genannt wurde, über viele Jahre Teile desselben Codes. Das kommerzielle Parallels-Angebot enthielt mehrere Komponenten, die beim Open-Source-Teil der Lösung fehlten.

2014 entschied man sich dazu, freie und kommerzielle Komponenten zu verschmelzen und künftig als komplett freies Produkt zu veröffentlichen. Dieser Schritt dürfte allerdings nicht alleine dem Umstand geschuldet sein, dass man plötzlich sein Herz für freie Software entdeckte. Denn die Pflege von Open VZ war für Parallels über weite Strecken eine echte Sisyphusarbeit.

Das liegt wie beim Linux-V-Server am separaten Kernelpatch, das Virtuozzo benötigt: Zwar machten sich die Entwickler auch daran, Teile der nötigen Funktionen neu zu schreiben und in den Linux-Kernel zu mergen. So entstanden Teile der Cgroups-Implementierung maßgeblich unter ihrer Federführung. Wirklich losgesagt von seinen Sonderfunktionen hat sich Virtuozzo aber bis heute nicht. Noch immer benötigt ein aktueller Kernel ein Patch, damit alles funktioniert.

Der Parallels Cloud Server setzt bis heute auf Red Hat Enterprise Linux 6 und kommt mit Linux 2.6.32 daher, freilich in Red Hats Frankenstein-Inkarnation. Auf aktueller Hardware kann ein so alter Kernel aber versagen, sodass Virtuozzo für neue Deployments kaum in Betracht kommt. Aktuell existiert zumindest eine Betaversion auf RHEL-7-Basis, die vollständig den Regeln von FL/OSS folgt. Ob es dem heutigen Hersteller Odin damit gelingen wird [2], verlorenes Vertrauen in das Produkt zurückzugewinnen, darf allerdings bezweifelt werden.

Der richtige Weg: LXC

Und das auch, weil mit LXC (Abbildung 3, [3]) eine fertige Container-Lösung schon bereitsteht, die mit jedem Vanilla-Kernel sofort nutzbar ist. Dass es gerade die Open-VZ-Entwickler waren, die mit ihren diversen Patches LXC in der ursprünglichen Form möglich machten, ist wohl ein Treppenwitz der Geschichte.

Abbildung 3: LXC war die erste echte Container-Lösung für Linux, ist allerdings nicht die erfolgreichste oder bekannteste Variante.

Offiziell erblickten LXC-Container im Jahre 2008 das Licht der Welt. Damals war Linux 2.6.24 gerade frisch erschienen. Schon einige Kernel-Releases zuvor flossen in Linux die Funktionen ein, die für LXC-Container nötig sind: Cgroups (oder Control Groups) sind eine Kernel-Schnittstelle, über die sich Rechte und Berechtigungen einzelner Programme eines Linux-Systems einschränken lassen. Ursprünglich hießen Cgroups selbst Process Containers, weil sie den Betrieb von einzelnen Prozessen in virtuellen Umgebungen ermöglichten, die vom Rest des Systems abgeschirmt waren.

Hauptinitiator war Google, doch bald kam aus vielen Richtungen Support für die neue Technologie. Kurz nach der Release der ersten LXC-Version entbrannte um die neue Technik ein kleiner Hype: Admins hatten zum ersten Mal ein Werkzeug in der Hand, mit dem sich Prozesse in einem System ohne komplette VM virtualisieren ließen. In Test-Setups fanden sich auf LXC-basierende Lösungen seinerzeit regelmäßig.

Doch schafften sie es selten aus der Planung in die Produktion. Denn LXC warf einige vorerst ungeklärte Fragen auf, was die Sicherheit einzelner Container betraf: Wer in einem Container Rootrechte hatte, konnte über lange Zeit auch auf dem Host beliebige Befehle mit Rechten von Root absetzen. Das änderte sich erst mit dem Linux-Kernel 3.8, der erstmals ganz neue Cgroup-Funktionen bot.

Denn 2013 unterzogen die Kernelentwickler die Cgroups einem sehr tiefgreifenden Redesign. Hinzu gesellten sich nun auch Namespaces: Sie schaffen virtuelle Netzwerkstacks oder PIDs und sind strikt von den anderen Namespaces oder dem Hauptsystem getrennt. Läuft ein Prozess in einem Netzwerk-Namespace, sieht er nur die (rein virtuellen) Netzwerkschnittstellen eben dieses Namespace.

Auf die Netzwerkkarten, die der Host nutzt, erhält er nur indirekten Zugriff und sehen kann er sie gar nicht. Ebenso wenig sieht ein Prozess, der zu einem separaten PID-Namespace gehört, welche Prozesse in anderen Namespaces des Systems laufen. Namespaces bieten zusammen mit Cgroups also eine viel tiefgreifendere Trennung einzelner Containern, als es vorher der Fall war.

Tatsächlich bot Linux also spätestens ab Version 3.8 alle nötigen Tools, um Container sinnvoll zu betreiben. Vom schlechten Marketing erholte sich LXC aber nicht mehr vollständig. Als es für Unternehmen interessant geworden wäre, hatte längst ein anderes Werkzeug die Bühne betreten und die Herzen von Admins und Hipstern erobert: Docker [4].

Blick über den Tellerrand

Docker & Co. haben Container im produktiven Umfeld nutzbar gemacht. Oder zumindest im Linux-Umfeld: Kommt man einem gestandenen Free-BSD- oder Solaris- Admin nämlich mit Containern nach dem Docker- oder LXC-Prinzip, erntet man in der Regel nur ein müdes Lächeln. Andere Unix-artige Betriebssysteme haben das Thema Container-Funktionen im Mainstream-Kernel deutlich früher bearbeitet als Linux. Und in vielen Fällen auch erfolgreicher.

Free BSD und seine Gefängnisse

Das Paradebeispiel sind zweifellos Jails in Free BSD (Abbildung 5). Bereits seit Free BSD 4 gehören hier die Jails zum Lieferumfang. Entstanden sind sie auf Drängen von Derrick Woolworth, der für seine Hosting-Firma R&D Associates Inc. vor vielen Jahren auf der Suche nach einer verlässlichen Virtualisierungslösung ohne den typischen Overhead war.

Abbildung 5: Jails existieren auf Free BSD bereits seit der Version 4.0 und haben sich als zuverlässige Lösung herausgestellt.

Unter Federführung von Poul-Henning Kamp machten sich die BSD-Entwickler daran, in Free BSD so etwas wie eine zusätzliche Ebene für die Zuteilung von Zugriffsrechten zu etablieren. Ein Jail ist genau das: Die Erlaubnis, auf einen bestimmten abgetrennten Bereich des Betriebssystems zuzugreifen. Andere Jails sind völlig unberührt. Fast die gesamte Trennmagie spielt sich auf Kernelebene ab; Nutzer sehen stets nur die Komponenten, die sie sehen sollen.

Jails gehören seit Free BSD 4.0 zum System, haben mittlerweile also mehr als 15 Jahre auf dem Buckel. Bis heute sind sie bei Free-BSD-Admins ausgesprochen beliebt, und noch immer erfahren die Kernelstrukturen für Jails in Free BSD regelmäßige Updates.

Solaris-Zonen

Auch Solaris-Admins staunen nicht über LXC, Docker & Co. Das Container-Zeitalter begann für Solaris vor mehr als zehn Jahren: Die Zones waren erstmals in Solaris 10 enthalten und heißen mittlerweile Container. Sie funktionieren in Solaris so ähnlich wie beispielsweise Docker-Container auf Linux: Verschiedene Kernelfunktionen trennen einen laufenden Container vom Rest des Systems. Der Container selbst erhält nur Zugriff auf ausgewählte und definierte Ressourcen des Hosts, ein Ausbrechen ist so gut wie unmöglich. Die Applikationen innerhalb eines Containers merken nicht, dass sie überhaupt in einem Container laufen.

Fernab von Free BSD und Solaris sieht es nicht ganz so rosig aus, wenn es um Container auf Unix-artigen Betriebssystemen geht. Open BSD und Net BSD setzten beide zunächst auf die so genannten Sysjails. Inzwischen ist das Projekt aber tot. Container auf BSD sind also zurzeit nur mit den Jails in Free BSD befriedigend bereitzustellen.

HP-UX kennt Container, die Zugriffsbeschränkungen und eigene Namespaces für Files, Host- und Domainnamen, Netzwerkadressen und IPC-Strukturen wie Semaphoren, Queues und Shared Memory bieten. IBMs AIX offeriert mit den Workload Partitions (WPARs) etwas Verwandtes und selbst unter Windows gibt es nicht nur Hyper-V-Container, sondern neuerdings sogar eine Docker-Engine.

Dafür, dass man Docker (Abbildung 4) bereits bei den Etablierten einordnen kann, spricht, dass die Lösung bereits seit mehreren Jahren im Markt aktiv ist. Um Docker hat sich obendrein ein eigener Minikosmos von Drittanbieter-Software gebildet. Dank Googles Kubernetes lässt sich Docker nun beispielsweise auch im Verbund betreiben. Der einzelne Docker-Container auf einem einzelnen Host ist von untergeordneter Bedeutung; relevant ist ein ganzer Container-Schwarm, der vollautomatisch auf beliebig viele Hosts ausgerollt werden kann.

Abbildung 4: The Winner takes it all: Docker ist die Lösung der Gegenwart, wenn es um Container-Virtualisierung für Linux geht.

Docker: The Winner takes it all

Technisch ist der Erfolg von Docker durchaus beachtlich. Denn im Grunde ist Docker LXC sehr ähnlich: Wie LXC setzt Docker auf Cgroups und Namespaces im Linux-Kernel. Mit einem Vanilla-Kernel lassen sich LXC-Container also genauso betreiben wie die Docker-Variante. Zwar baut Docker um jene Kernelfunktionen viele Features, etwa die Möglichkeit einer Versionsverwaltung für Container. Doch das macht noch nicht den Unterschied aus, der über Erfolg oder Misserfolg zwischen Docker und LXC entscheidet. Fakt ist viel mehr, dass die Entwickler hinter Docker von Anfang nicht nur technisch gut waren, sondern auch das Marketing konsequent vorantrieben.

Docker scheint Admins mit einer Fülle neuer Möglichkeiten zu versorgen. So gelingt “Platform as a Service” mit Docker sehr leicht: Ein neuer Container, der eine gewünschte Applikation enthält, lässt sich in kürzester Zeit erstellen. Genau diese Funktionen betont Docker Inc. dann auch immer wieder und exzessiv.

Dunkle Wolken

Mittlerweile scheint der Hype um Docker zumindest ein bisschen abgeebbt – das legt jedenfalls der Umstand nahe, dass sich die kritischen Stimmen zu Docker mehren. Core OS kehrte Docker kürzlich den Rücken und entwickelt nun ein eigenes Container-Format namens Rocket. Auch die Art und Weise, wie Docker mit Containern umgeht, stößt nicht mehr durchgängig auf Begeisterung.

Admins etwa wenden ein, dass Docker-Container im administrativen Alltag ein erhebliches Sicherheitsrisiko sein können. Denn bei der Entwicklung von Docker-Containern gilt oft das Prinzip “Works for me” als einziger Qualitätsmaßstab: Was etwa beim Entwickler in einem Container auf dem Notebook funktioniert, wird so mit hoher Wahrscheinlichkeit auch auf Servern seinen Dienst verrichten. Dass sich der betreibende Admin damit oft ein schwer kalkulierbares Risiko aufs System holt, fiel lange unter den Tisch.

Ähnliche Beweggründe gaben die Core-OS-Entwickler an, als sie den Umstieg von Docker auf das eigene Format erklärten. Soviel steht fest: Langweilig wird es in Sachen Docker in naher Zukunft sicher nicht.

Fazit

Ein Vergleich der etablierten Container-Lösungen für Linux macht eins sehr deutlich: Die Zukunft gehört Cgroups und Namespaces. Beide Werkzeuge sind integraler Bestandteil des Linux-Kernels. Die gängigen Lösungen wie etwa LXC und Docker nutzen sie bereits intensiv. Andere Lösungen, die bisher noch eigene Ansätze verfolgten, etwa Virtuozzo, bereiten derzeit die Migration auf die Kernelfunktionen vor oder haben diese zum Teil sogar bereits vollzogen.

Linux-V-Server ist unter den hier vorgestellten Kandidaten ein Spezialfall, weil sich dieses Projekt dazu entschieden hat, seinen Sonderweg allein weiterzugehen. Für die Entwickler ist das eine Hypothek auf die Zukunft und für Admins ein Unsicherheitsfaktor: Nur wenn sich jemand findet, der die nötigen Patches auch künftig für jeden neuen Kernel weiterhin zur Verfügung stellt, kann diese Lösung bestehen bleiben.

Dass Cgroups und Namespaces und mit ihnen LXC und Docker verschwinden, darf hingegen als sehr unwahrscheinlich gelten. Zu viele Unternehmen haben Geld und Aufwand in die Entwicklung der entsprechenden Schnittstellen gesteckt, und eine Alternative zu dieser Variante der Container ist nicht in Sicht. LXC und Docker sind die Linux-Container der Gegenwart und auch die neuartigen Container-Lösungen, die ein weiterer Artikel des Themenschwerpunkts in dieser Ausgabe vorstellen wird, sind voll und ganz auf Cgroups und Namespaces ausgerichtet.

Linux hat damit ganz offiziell und endlich die Funktionalität, die Container in Solaris oder Jails in Free BSD seit Jahren bieten – eine standardisierte Schnittstelle direkt im Herzen des Betriebssystems, die Drittanbieter nach Belieben verwenden können.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.