LXC-Container eignen sich nicht nur für Entwickler, sondern bieten auch ambitionierten Heimanwendern interessante Möglichkeiten.

Vielleicht erinnern Sie sich noch daran, wie 2007 das Erscheinen des freien Hypervisors Virtualbox das Testen von Linux-Distributionen plötzlich erheblich vereinfachte. Vorher gab es zwar bereits den Vmware-Player, der aber zum einen einer proprietären Lizenz unterlag und zum anderen das ständige Patchen neu installierter Kernel erforderte. Mit Virtualbox und der Hilfe von DKMS [1] gehören solche Probleme der Vergangenheit an. Die einzige Limitierung in der Anzahl gestarteter Maschinen stellen der Hauptspeicher und Prozessor des Wirt-Rechners dar.

Hier könnten Container-Lösungen künftig auch beim Endanwender Boden gutmachen, denn ihr Überbau benötigt wesentlich weniger Ressourcen als Hypervisoren. So wäre es denkbar, dass sich hunderte Container den Kernel des Hosts teilen. Container virtualisieren auf Betriebssystem-Ebene, während das bei Hypervisoren auf der Hardware passiert. Deshalb testen wir in diesem Artikel, wie viel Aufwand es derzeit verursacht, eine Distribution in einem Container zum Laufen zu bringen, wobei das Ziel darin besteht, deren grafische Ausgabe auf den Host umzulenken.

Runderneuert

Container sind nicht so neu, wie es anhand des Booms der letzten Zeit erscheint: Linux Container (LXC) gibt es bereits seit 2006 [2]. Es geriet aber nie in den Fokus einer größeren Anwenderschar, bis im Frühjahr 2013 Docker [3] die Szene betrat. Außerhalb von Linux existierten seit Längerem ähnliche Technologien, wie etwa die FreeBSD Jails [4] oder das Zonensystem von Solaris [5], das ursprünglich auf den Jails aufbaute.

Als Urvater all dieser Virtualisierungstechniken gilt vom Prinzip her die bereits aus Unix bekannte Chroot, auch wenn sich die Anwendungsszenarien nicht immer decken. In einer Changed-Root-Umgebung kann es durchaus erwünscht sein, dass ein Prozess aus der Umgebung “ausbricht”, während das bei Containern nicht passieren darf.

Der derzeitige Hype um Container im Allgemeinen und Docker im Besonderen resultiert aus der Tatsache, dass im Unternehmensumfeld zunehmend spezialisierte Anwendungen die Oberhand über die eher statischen Software-Stacks der Vergangenheit gewinnen. Hier eignen sich die reproduzierbaren, leichtgewichtigen und transportablen Container besonders gut, um Anwendungen aus Einzelstücken vom lokalen Rechner über Server bis in die Cloud zu entwickeln.

Im Fokus dieses Artikels stehen allerdings die Qualitäten der Containerlösung LXC für den Endanwender. Dafür wollen wir in einem installierten Ubuntu 14.10 einen Container aufsetzen und ein CentOS-Image hineinladen. Ubuntu kommt deswegen als Wirt zum Einsatz, weil es die benutzerfreundlichsten Voreinstellungen in Kernel und System bietet. So ist beispielsweise die in LXC integrierte Netzwerkbrücke lxcbr0 bereits einsatzbereit, was unter Debian noch einiges an Konfiguration voraussetzt.

Vorbereitungen

Eine essenzielle Zutat von LXC stellt die Kernelfunktion Control Groups dar, kurz Cgroups. Sie kontrolliert und steuert Prozesse und Gruppen von Prozessen auf mannigfaltige Weise. Der aktuelle Ubuntu-Kernel stellt diese Funktion bereits aktiviert bereit, sodass ein Eintrag in der Datei /etc/fstab nicht mehr nötig ist.

Die einzige Limitierung von LXC: Nur mit dem Kernel des Wirts laufen kompatible Distributionen in einem Container. Auf einem Linux-Wirt erlaubt LXC entsprechend auch nur Linux-Gäste. Nach der Installation des Pakets lxc überprüfen Sie dessen Funktionsbereitschaft mit dem Aufruf lxc-checkconfig (Abbildung 1). Hinter jeder Zeile sollte enabled stehen.

Bevor Sie einen Container aufspannen, müssen Sie entscheiden, welches Betriebssystem Sie darin erstellen wollen. LXC bringt einige Vorlagen mit, die den Einstieg erleichtern. Diese finden Sie mit folgendem Befehl heraus (Abbildung 2):

$ sudo ls /usr/share/lxc/templates

Einige der aufgeführten Systeme nutzen bereits Systemd, was innerhalb eines LXC-Containers derzeit noch Probleme bereitet. Sollten Sie eine dieser Distributionen testen wollen, wie etwa OpenSuse, Arch Linux oder Fedora, müssen Sie im Container zu SysVinit wechseln, falls Probleme auftauchen. Das Debian-Wiki beschreibt das Prozedere [6]. Spielt die Distribution keine Rolle, bietet sich Debian als Gast an, denn das Template installiert die jeweils aktuelle Veröffentlichung, derzeit also Debian 7 “Wheezy”, das noch SysVinit benutzt.

Container aufgesperrt

Um den Container zu starten und ein Debian-Grundsystem zu erstellen, genügt die Eingabe des folgenden Kommandos (Abbildung 3):

$ sudo lxc-create -n Wheezy -t debian

Dabei tauschen Sie Wheezy gegebenenfalls gegen einen anderen Namen aus. Innerhalb von rund zehn Minuten erstellt LXC anhand der Vorlage mittels Debootstrap [7] ein Debian-Grundsystem.

Die Templates installieren in der Voreinstellung immer das stabile Release der jeweiligen Distribution. Das ändern Sie bei Bedarf, indem Sie das Release mit angeben. Entsprechende Befehle für Debian “Unstable” und den Entwicklungsstand von Ubuntu 15.04 zeigt Listing 1.

$ sudo lxc-create -n Unstable -t debian -- --release sid
$ sudo lxc-create -n Vivid -t ubuntu -- --release vivid

Die verständlich aufgebauten Vorlagen lassen sich bei Bedarf leicht an die eigenen Bedürfnisse anpassen. LXC legt neue Container im Ordner /var/lib/lxc/Container-Name ab. Die während des Erstellens heruntergeladenen Pakete parkt es unter /var/cache/lxc, sodass weitere Container, die auf dem gleichen Template aufbauen, nur wenige Sekunden zum Aufsetzen benötigen.

Zum Starten eines Containers dient der Befehl sudo lxc-start -n Container-Name, in unserem Beispiel Wheezy. Sie landen damit direkt im Terminal des im Container gestarteten Systems. Ein angehängtes -d startet den Container als Daemon im Hintergrund. Die benötigten Nutzernamen und Passwörter zeigt das Setup nach Abschluss der Installation an. Zumindest das Passwort sollten Sie beim ersten Login ändern. Über den Status mehrerer installierter Container informiert Sie der Befehl sudo lxc-ls --fancy (Listing 2).

$ sudo lxc-ls --fancy
NAME       STATE       IPV4        IPV6  AUTOSTART
--------------------------------------------------
lxc        STOPPED     -           -            NO
unstable   STOPPED     -           -            NO
wheezy     RUNNING     10.0.3.189  -            NO

Fenster auf!

Die meisten Endanwender legen Wert darauf, grafische Applikationen in den Containern zu starten. Sinnvolle Anwendungsszenarien wären beispielsweise Programme, denen Sie nicht vertrauen, die Sie aber trotzdem des Öfteren benötigen. Das könnte beispielsweise Skype sein oder aber auch ein Webbrowser. Es gibt mehrere Wege, um eine grafische Ausgabe von im Container laufenden Anwendungen zu erhalten.

Möchten Sie verstehen, was dabei genau passiert, halten Sie sich an die Anleitung von LXC-Paketbetreuer Stéphane Graber und nehmen die entsprechende Konfiguration manuell vor [8]. Weitere Möglichkeiten wären der Einsatz von Xpra [9] oder Virtenv [10]. Wir gehen an dieser Stelle aber auf X2go [11] ein, da es am einfachsten erscheint.

Im neuen Container legen Sie nach dem Login zunächst mit sudo adduser x2gouser einen neuen Nutzer an. Dann installieren Sie eine Desktop-Umgebung Ihrer Wahl, etwa mit sudo apt-get install kde-standard. Alternativ verwenden Sie auch Leichtgewichte wie LXDE oder Fluxbox. Nach der Installation der Desktop-Umgebung starten Sie den Container mit sudo shutdown -r now neu.

Nun melden Sie sich als User x2gouser an, ergänzen die Datei sources.list.d/debian.list um den Eintrag deb http://packages.x2go.org/debian wheezy main und speichern sie ab. Dann fügen Sie den Schlüssel für das Repository ein (Listing 3, Zeile 1). Nach einem Update der Paketdatenbank installieren Sie den X2go-Server in den Container (Zeile 2 und 3). Im Ubuntu-Host müssen Sie jetzt noch den X2go-Client aus dem entsprechenden PPA installieren (ab Zeile 4).

$ sudo apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
$ sudo apt-get update
$ sudo apt-get install x2goserver x2goserver-session
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:x2go/stable
$ sudo apt-get update
$ sudo apt-get install x2goclient

Nach dem Setup starten Sie den X2go-Client auf dem Host und nehmen die Sitzungseinstellungen vor (Abbildung 4). Sie wählen einen beliebigen Sitzungsnamen und geben bei Host die IP-Adresse des Containers ein. Diese erfahren Sie mit lxc-ls --fancy im Host. Bitte beachten Sie dabei, dass jeder Container eine eigene IP verwendet. Unter Login tragen Sie den User des Containers ein und als Sitzungsart die Desktop-Umgebung. Auf dem zweiten Reiter schieben Sie bei Verbindungsart den Schieber ganz nach rechts auf LAN. Im nächsten Reiter richten Sie das gewünschte Display in passender Größe ein.

Abbildung 4: In einer übersichtlichen Maske geben Sie im X2go-Client die Verbindungseinstellungen ein.

Danach wählen Sie sich in den grafischen Desktop ein (Abbildung 5). Alle Änderungen, die Sie hier vornehmen, wirken sich nur auf den Container aus. Möchten Sie den Container wieder stoppen, so genügt dazu der Befehl lxc-stop -n Container-Name. Ersetzen Sie stop durch destroy, löscht der Befehl den Container. Im Netz findet sich eine ausführliche und eingängige Dokumentation zur Handhabung von LXC [12].

Abbildung 5: Nach dem initialen Setup melden Sie sich am grafischen Display von X2go an.

Docker und GUI

Docker-Container bieten wesentlich mehr Funktionen als das LXC-Pendant. Deren Bandbreite reicht von Schnittstellen zu Apps für die Container-Orchestrierung in der Cloud bis hin zum Verwalten ganzer Rechnercluster. Diese Fähigkeiten interessieren Endanwender, um die es hier ja geht, in der Regel herzlich wenig.

Gleichwohl stehen auch für Docker Endanwender-Lösungen bereit, die aber mehr Aufwand erfordern, ohne jedoch einen Mehrwert zu bringen. Die vorhandenen Lösungen setzen auf SSH [13], Xpra und Xephyr oder ebenfalls auf X2go [14]. Wie auch bei LXC steckt der Aufwand hauptsächlich im ersten Aufsetzen, danach lassen sich die Container in Sekundenschnelle starten. Möchten Sie eines der Verfahren selbst testen, finden Sie Hinweise dazu im Internet.

Fazit

Erst die rasante Entwicklung von Docker in den letzten 18 Monaten brachte LXC-Container ins Rampenlicht. Als Grundlage für Docker erhielt LXC dabei einen Entwicklungsschub, der es überhaupt erst ohne großen Aufwand für Endanwender benutzbar macht.

Um nur einmal gelegentlich eine Distribution zu begutachten, lohnt sich der Aufwand zum Einstieg in LXC eher nicht. Wollen oder müssen Sie allerdings ständig mit mehreren Images gleichzeitig arbeiten, profitieren Sie auf jeden Fall davon, dass LXC wesentlich sparsamer mit den Hardware-Ressourcen umgeht als Virtualbox oder KVM. Ein weiteres Szenario stellt der Einsatz von LXC als eine Art Sandbox dar, in der Sie Applikationen, denen Sie nicht vertrauen, vom Host-System abschotten.

In der Kritik stehen Container oft noch wegen ihrer mangelnden Sicherheit, bei der Hypervisoren derzeit noch einen Vorsprung haben. An der besseren Absicherung von Containern arbeiten zurzeit viele Spezialisten. In besonders sicherheitskritischen Umgebungen starten Sie die LXC-Container gegebenenfalls in einer virtuellen Maschine, was allerdings die Komplexität der Netzwerkstruktur erhöht. Mit der Einführung von Kernel 3.12 ermöglichen es die Kernel-Namespaces, Container mit LXC 1.0 unter einer anderen Benutzerkennung als der von root zu starten. Das verhindert, dass der Container Änderungen beim Host vornehmen kann.

Es bleibt schwer abzuschätzen, ob sich der Gebrauch von Containern beim Endanwender etabliert. Dazu müsste das Aufsetzen des Systems noch etwas einfacher vonstatten gehen. Allerdings besitzen auch Virtualbox und KVM ihre Einstiegshürden.