Loading
20Dez 2017

0

2091

LXC und LXD: was sind Linux Container?

Linux ContainerLXC und LXD sind zwei wichtige Begriffe, wenn Sie mit Linux Container arbeiten. Leider sind diese beiden auch sehr schwer voneinander zu unterscheiden. Sie klingen gleich und beziehen sich auf ähnliche Plattformen, welche zu großen Teilen von derselben Firma erstellt wurden. Weiterhin sind sie auf technischer Ebene eng miteinander verwoben.

Dies kling verwirrend, zumindest am Anfang. Mit ein wenig Hintergrundwissen ist es jedoch recht einfach die Unterschiede zwischen LXC und LXD zu erkenne und zu verstehen.

In diesem Beitrag erklären wir Ihnen was LXC und LXD ist, Sie lernen den Unterschied zwischen den beiden kenne und wann es Sinn für Entwickler und Administratoren macht diese zu nutzen. Weiterhin sehen wir uns auch andere Möglichkeiten wie Docker oder CoreOS an.

LXC

Um LXD zu verstehen, sollten Sie zunächst LXC verstehen.

LXC – die Kurzform für “Linux Container”, ist eine Lösung zur Virtualisierung von Software auf Betriebssystemebene innerhalb des Linux-Kernels.
Im Gegensatz zu herkömmlichen Hypervisoren (wie zum Beispiel VMWare, KVM oder Hyper-V), können auch einzelne Anwendungen in virtuellen Umgebungen ausgeführt werden. Zusätzlich kann jedoch auch ein ganzes Betriebssystem in einem LXC-Container ausgeführt werden.

Zu den Hauptvorteilen von LXC gehört die einfache Steuerung einer virtuellen Umgebung mit Usernamespace-Tools aus dem Hostsystem, die weniger Overhead als ein herkömmlicher Hypervisor erfordern und die Portabilität einzelner Apps erhöhen.

Nun könnte man denken, dass sich LXC sehr nach Docker oder CoreOS-Container anhört. Dies liegt daran, dass LXC die zugrundeliegende Technologie war, die Docker und CoreOS zum Leben erweckte. In letzter Zeit ist Docker jedoch in eine eigene Richtung gegangen und nicht mehr von LXC abhängig. CoreOS hat ebenfalls seinen eigenen Weg Hand in Hand mit “Rocket” (auch bekannt als rkt) nun eingeschlagen. Dennoch war LXC vor einigen Jahren der Ursprung der Containerrevolution und die LXC-Prinzipien – wenn auch nicht der LXC-Code – bleiben für die Entwicklung von Container von zentraler Bedeutung.

LXD

Die einfachste Art LXD zu erklären ist zu sagen, dass es eine Erweiterung von LXC ist.

Der technischere Weg zur Definition von LXD besteht darin, es als eine REST-API zu beschrieben, die mit libxlc, der LXC-Softwarebibliothek, verbunden ist. LXD, das in Go geschrieben ist, erstellt einen Systemdämon, auf den Apps lokal über einen Unix-Socket oder über das Netzwerk via HTTPS zugreifen können.

Die Hauptpunkte von LXD sind:

  • Ein Host kann viele LXC-Container mit nur einem einzigen Systemdaemon ausführen, was die Verwaltung vereinfacht und den Overhead reduziert. Mit Pure-Play LXC werden separate Prozesse für jeden Container benötigt.
  • Der LXD-Daemon kann die Sicherheitsfunktionen auf Host-Ebene nutzen um Container sicherer zu machen. Auf einem LXC Host ist die Containersicherheit problematischer
  • Der der LXD-Daemon Netzwerk- und Datenspeicher verwaltet und Benutzer diese über die LXD-CLI-Schnittstelle steuern können, wird der Prozess der gemeinsamen Nutzung von Ressourcen mit Containern vereinfacht.
  • LXD bietet erweiterte Funktionen, die bei LXC nicht verfügbar sind, einschließlich der Migration von Live-Container und der Möglichkeit von einem laufenden Container einen Snapshot zu erstellen.

Cannonical, das Unternehmen, das Ubuntu GNU finanziert, startete Ende 2014 LXD.
In letzter Zeit hat sich einiges getan und LXD 2.0, das erste Produktions-Release ist seit April 2016 verfügbar. Nun ist LXD endlich bereit für den produktiven Einsatz.

LXC und LXD

Wenn Sie ein App-Entwickler oder ein Datacenter-Administrator sind, stellt sich Ihnen sicherlich die Frage, was nun die genannten Punkte für Sie bedeuten und welche Lösung Sie schlussendlich wählen sollten.

Die Antwort hierauf ist kompliziert. Vor allem wenn man bedenkt, dass man nicht zwischen LXC und LXD wählen kann weil Sie unterschiedliche Anforderungen abdecken. LXC und LXD sind nicht als Forks voneinander entwickelt worden. Wenn Sie als LXD verwenden, verwenden Sie unweigerlich im Hintergrund auch LXC.

Selbstverständlich können Sie LXC auch ohne LXD nutzen. Dies wäre sicherlich eher ungünstig. LXC bietet Ihnen nur eine grundlegende Untermenge an Funktionen. In einer Produktionsumgebung sollte daher LXD verwendet werden.

LXC+LXD vs. Docker/CoreOS

Auch stellen Sie sich möglicherweise die Frage ob LXC + LXD in Kombination besser ist als Docker oder CoreOS. Auch hier hängt die Antwort von Ihren Bedürfnissen ab.

Beachten Sie zunächst, dass Canonical nicht beabsichtigt LXC + LXD als Ersatz für Docker zu einzusetzen. Stattdessen, so schreibt Stephane Gräber, einer der LXD-Entwickler, ist LXD dafür ausgelegt, virtuelle Umgebungen zu hosten, “die in der Regel lange laufen und auf einem sauberen Verteilungsbild basieren”. Während “Docker sich auf ephemere, zustandslose, minimale Container konzentriert”.

Das bedeutet, dass Sie die Art der Bereitstellung – welche Sie verwalten – berücksichtigen sollten bevor Sie eine Entscheidung bezüglich LXD oder Docker treffen (möglicherweise auch CoreOS, was in dieser Hinsicht mit Docker vergleichbar ist).
Erstellen Sie schnell eine große Anzahl von Container basierend auf generischen App-Images? Wenn ja eignet sich hierfür Docker oder CoreOS. Wenn Sie jedoch beabsichtigen ein gesamtes Betriebssystem zu virtualisieren oder eine dauerhafte virtuelle App über einen längeren Zeitraum auszuführen, wird sich LXD wahrscheinlich als bessere Lösung erweisen.

Der zweite zu berücksichtigende Faktor ist Ihre Host-Umgebung. LXD unterstützt nur Linux – und zumindest für den Moment – ist es nur in Verbindung mit Ubuntu dokumentiert. Im Gegensatz dazu sind Docker und CoreOS auf fast jedem Linux-basiertem Betriebssystem einsetzbar. Zudem können Sie Docker nun auch nativ unter Windows und OS X ausführen.

Aber das sind nur die Grundlagen. Jetzt, glücklich containering!