Was ist LXD? Container verwalten mit dem Linux Container Daemon

Bei LXD, dem „Linux Container Daemon“, handelt es sich um ein Ma­nage­ment-Tool für Linux Be­triebs­sys­tem-Container. Dieser wurde von Canonical, der Firma hinter Ubuntu Linux, ent­wi­ckelt; Canonical setzt die Wei­ter­ent­wick­lung von LXD bis heute fort und leitet das Projekt an.

LXD ist eine Schwes­ter­tech­no­lo­gie zu LXC, den „Linux Con­tai­ners“. Bei LXC handelt es sich um eine con­tai­ner­ba­sier­te Vir­tua­li­sie­rungs-Tech­no­lo­gie auf Ebene des Be­triebs­sys­tems. Technisch kom­bi­niert LXC isolierte Na­mens­räu­me und die „cgroups“ des Linux-Kernels, um ab­ge­schot­te­te Um­ge­bun­gen für die Aus­füh­rung von Code zu rea­li­sie­ren. His­to­risch war LXC auch die Grundlage für die weit ver­brei­te­te Vir­tua­li­sie­rungs-Tech­no­lo­gie Docker.

Eines der grund­le­gen­den Ziele bei der Ent­wick­lung von LXD war, die Ver­wal­tung von LXC-Con­tai­nern so kom­for­ta­bel zu gestalten, wie mit vir­tu­el­len Maschinen üblich. Im Vergleich zum Einsatz einer vir­tu­el­len Maschine liefert der con­tai­ner­ba­sier­te Ansatz jedoch eine höhere Per­for­manz.

Mittels LXD lassen sich Linux-Be­triebs­sys­tem-Container über einen de­fi­nier­ten Satz von Befehlen kon­fi­gu­rie­ren und steuern. LXD eignet sich daher für die Au­to­ma­ti­sie­rung der mas­sen­haf­ten Container-Ver­wal­tung und findet Ver­wen­dung in Cloud-Computing und Da­ten­cen­tern.

• Si­cher­heit: Die Container laufen in iso­lier­ten Na­mens­räu­men und können nur auf de­fi­nier­te Res­sour­cen zugreifen.
• Ska­lier­bar­keit: LXD erlaubt die Ver­wal­tung von einzelnen Con­tai­nern auf dem eigenen Laptop bis hin zu Tausenden von Con­tai­nern in ver­teil­ten Um­ge­bun­gen.
• Intuitive Nutz­bar­keit: LXD stellt eine einfache, klare API und einen ent­spre­chen­den Kom­man­do­zei­len-Client zur Verfügung.
• Basiert auf Linux-Images: LXD funk­tio­niert mit jeglichen Linux-Images und pro­fi­tiert damit von der großen Anzahl exis­tie­ren­der Linux-Dis­tri­bu­tio­nen.
• Aus­ge­feil­te Res­sour­cen-Kontrolle: Für einen Container werden Be­schrän­kun­gen für CPU, Haupt­spei­cher, Netzwerk-Nutzung, Mas­sen­spei­cher-Nutzung und Kernel-Res­sour­cen fest­ge­legt.
• Zugriff auf System-Hardware: Sofern die Kon­fi­gu­ra­ti­on es zulässt, können Container u. a. auf USB-Geräte, GPU und Mas­sen­spei­cher-Medien zugreifen.
• Netz­werk­ma­nage­ment: Per Kon­fi­gu­ra­ti­on lassen sich Netz­werk­brü­cken und -tunnel erzeugen.
• Mas­sen­spei­cher-Ma­nage­ment: LXD un­ter­stützt ver­schie­de­ne Speicher-Backends, Speicher-Pools und Speicher-Volumen.

Haupt­säch­li­cher Vorteil ist, dass LXD die Vir­tua­li­sie­rung eines kom­plet­ten Linux-Be­triebs­sys­tems auf Container-Basis er­mög­licht. Damit vereint LXD den Komfort vir­tu­el­ler Maschinen mit der Per­for­manz von Con­tai­nern.

Im Gegensatz zu den meisten Docker-basierten An­wen­dungs­fäl­len liegt der Fokus bei LXD nicht auf der Vir­tua­li­sie­rung einer einzelnen Anwendung („App-Vir­tua­li­sie­rung“). Vielmehr dient ein Linux-System-Image als Grundlage eines jeden LXD-Con­tai­ners („System-Vir­tua­li­sie­rung“). Für den Ad­mi­nis­tra­tor ist dies von Vorteil, da es den Zugriff auf eine große Anzahl frei ver­füg­ba­rer Linux-Dis­tri­bu­tio­nen eröffnet und die Nutzung viel­fäl­ti­ger exis­tie­ren­der Tools er­mög­licht.

Einen Nachteil hat LXD jedoch gegenüber anderen Vir­tua­li­sie­rungs-Tech­no­lo­gien: Da alle auf einem Host laufenden Container auf denselben Linux-Kernel zugreifen, ist der LXD-Daemon nur unter Linux verfügbar. Ferner kann mit LXD einzig und allein Linux als Gast-Be­triebs­sys­tem vir­tua­li­siert werden. Der Kom­man­do­zei­len-Client funk­tio­niert jedoch auch auf Nicht-Linux-Be­triebs­sys­te­men.

Die REST-API des LXD-Daemon lässt sich über das Netzwerk an­spre­chen. Somit können Container zwischen Maschinen bewegt oder kopiert werden. Ferner un­ter­stützt LXD das Erzeugen von Maschinen-Clustern, die viele einzelne Re­chen­ein­hei­ten zu einem vir­tu­el­len Su­per­com­pu­ter bündeln.

Die Kern­kom­po­nen­te von LXD ist der pri­vi­le­gier­te, na­mens­ge­ben­de Daemon, der auf dem Host-Linux-System läuft. Der LXD-Daemon stellt eine REST-API über einen lokalen Linux-Socket zur Verfügung. Per Kon­fi­gu­ra­ti­ons­ein­stel­lung lässt sich der Daemon auch über das Netzwerk an­spre­chen. Unter der Haube greift LXD über die Bi­blio­thek liblxc und seine Go-Bindings auf LXC als Backend zurück.

Ein Client in­ter­agiert mit dem Daemon über die REST-API. Die API definiert eine Sprache, mit der Container erzeugt, gesteuert und verändert werden können. Der simpelste Client ist das of­fi­zi­el­le Kom­man­do­zei­len-Tool. Der Kom­man­do­zei­len-Client stellt Befehle für viele häufige Ope­ra­tio­nen zur Verfügung und greift intern auf die REST-API zu.

Im Folgenden haben wir der Übersicht halber ein paar grund­le­gen­de LXD-Befehle für Sie zu­sam­men­ge­stellt. Lassen Sie sich nicht verwirren: Der Name des LXD Kom­man­do­zei­len-Befehls lautet lxc, nicht lxd. Sie können die Befehle selbst aus­pro­bie­ren, ohne den Kom­man­do­zei­len-Clienten auf Ihrem System in­stal­lie­ren zu müssen. Nutzen Sie dafür einfach die web­ba­sier­te Ober­flä­che des li­nux­con­tai­ners.org-Projekts.

Prin­zi­pi­ell lässt sich LXD auf jedem modernen Linux-System in­stal­lie­ren. Zum einen erfolgt der Einsatz auf privaten Rechnern, zum anderen wird LXD auch in Cloud-Computing Platt­for­men und ver­teil­ten Da­ten­cen­tern genutzt. Dabei zielt LXD in erster Linie darauf ab, ein kom­plet­tes Linux-Be­triebs­sys­tem zu vir­tua­li­sie­ren, das langlebig in der Nutzung ist. Damit steht LXD im Gegensatz zu Docker; dort liegt der Fokus mehr auf kurz­le­bi­gen Con­tai­nern, welche eine einzelne Anwendung kapseln. In den Worten des LXD-Ent­wick­lers Stéphane Graber:

Für die Steuerung einer geringen Anzahl an Con­tai­nern eignet sich der mit­ge­lie­fer­te Kom­man­do­zei­len-Client. Dieser ist jedoch nicht dafür ausgelegt, eine große Anzahl an Con­tai­nern auf einer Vielzahl ver­teil­ter Hosts zu verwalten. Für diese An­wen­dungs­fäl­le kommen An­bin­dun­gen an die Platt­for­men OpenStack und Open­Ne­bu­la zum Einsatz.

Die Kern­be­stand­tei­le von LXD sind der bereits erwähnte Daemon, die darüber zur Verfügung gestellte REST-API und der Kom­man­do­zei­len-Client. Im Folgenden be­trach­ten wir die bei der Arbeit mit LXD primär zum Einsatz kommenden Entitäten.

Der Container ist die grund­le­gen­de von LXD zur Verfügung gestellte Abs­trak­ti­on. Ein LXD-Container umfasst die folgenden Ei­gen­schaf­ten:

• Ein Linux-Da­tei­sys­tem
• Kon­fi­gu­ra­ti­ons-Ein­stel­lun­gen wie Res­sour­cen-Limits, Um­ge­bungs­va­ria­blen, Si­cher­heits-Optionen etc.
• Mas­sen­spei­cher- und Netz­werk­ge­rä­te
• Kon­fi­gu­ra­ti­ons-Profile, von denen der Container Ein­stel­lun­gen erbt
• Generelle Ei­gen­schaf­ten wie Container-Ar­chi­tek­tur, Name sowie die Angabe, ob der Container kurzlebig oder lang­lau­fend ist
• Laufzeit-Zustand wie Netzwerk-Durchsatz, Speicher-Aus­las­tung etc.

Wie bei anderen Vir­tua­li­sie­rungs-Tech­no­lo­gien üblich, lassen sich von einem Container so genannte Snapshots („Schnapp­schüs­se“) erzeugen. Ein Snapshot ist identisch mit dem zu­grun­de­lie­gen­den Container. Snapshots sind „immutable“, können also nicht verändert werden. Sie lassen sich lediglich um­be­nen­nen und löschen. Von einem Snapshot lässt sich der exakte Zustand eines Con­tai­ners wie­der­her­stel­len.

Obwohl es sich bei LXD um eine con­tai­ner­ba­sier­te Tech­no­lo­gie handelt, kommt zur Erzeugung des Con­tai­ners ein Linux-System-Image zum Einsatz. Per De­fi­ni­ti­on entstammt jeder LXD-Container einem Image.

Bei den Images handelt es sich nor­ma­ler­wei­se um un­mo­di­fi­zier­te Linux-Dis­tri­bu­tio­nen, wie sie auch für virtuelle Maschinen oder Cloud-Instanzen verwendet werden. Ein Image wird eindeutig über seinen SHA256-Hash iden­ti­fi­ziert. Um die Zuordnung für mensch­li­che Nutzer freund­li­cher zu gestalten, lässt sich ein Alias-Name für ein Image festlegen.

Linux-Images für die Nutzung mit LXD lassen sich von ver­schie­de­nen Quellen online beziehen. Die folgenden Image-Server sind in LXD vor­de­fi­niert:

• ubuntu: Stellt stabile Ubuntu-Images zur Verfügung.
• ubuntu-daily: Stellt tägliche Builds von Ubuntu Images zur Verfügung.
• images: Stellt eine Vielzahl von Images anderer Linux-Dis­tri­bu­tio­nen bereit und wird von der Community selbst verwaltet.

Die vom LXD-Daemon her­un­ter­ge­la­de­nen Images werden au­to­ma­tisch in einem Cache vor­ge­hal­ten, so dass diese bei wie­der­hol­ter Nutzung ohne Zeit­ver­zug zur Verfügung stehen. Sofern nicht anders kon­fi­gu­riert, überprüft LXD die Version her­un­ter­ge­la­de­ner Images und lädt bei Bedarf neue Versionen nach. Ähnlich dem Konzept der „Vagrant Box” lässt sich mit LXD ein be­stehen­der Container als neues Image ver­öf­fent­li­chen.

Ein LXD-Profil bündelt ver­schie­de­ne Container-Kon­fi­gu­ra­ti­ons­ein­stel­lun­gen. Ein Profil lässt sich auf mehrere Container anwenden; ferner können mehrere Profile nach­ein­an­der auf einen Container angewandt werden. Ab­schlie­ßend wird die lokale Container-Kon­fi­gu­ra­ti­on ein­ge­spielt. Während dieses Prozesses werden ggf. mehrmals de­fi­nier­te Kon­fi­gu­ra­ti­ons­wer­te über­schrie­ben. So lassen sich einfach Familien von Con­tai­nern erzeugen. Von Hause aus wird LXD mit zwei exis­tie­ren­den Profilen aus­ge­lie­fert:

• Das default-Profil wird au­to­ma­tisch auf einen Container an­ge­wen­det, sofern kein al­ter­na­ti­ves Profil fest­ge­legt ist. Dieses Profil umfasst grund­le­gen­de Kon­fi­gu­ra­ti­ons­ein­stel­lun­gen, wie das eth0-Netz­werk­ge­rät des Con­tai­ners.
• Das docker-Profil dient der Kon­fi­gu­ra­ti­on eines LXD-Con­tai­ners, der Docker-Container enthalten soll. Das Profil ver­an­lasst den LXD-Container, not­wen­di­ge Kernel-Module zu laden und Geräte-Ein­stel­lun­gen zu setzen. Ferner wird das Schach­teln von Con­tai­nern an­ge­schal­tet.

Bei LXD handelt es sich um einen Netzwerk-Daemon: der Kom­man­do­zei­len-Client kann mit mehreren ent­fern­ten LXD-Servern und Image-Servern kom­mu­ni­zie­ren. Per Kon­fi­gu­ra­ti­on lassen sich mehrere Server als Remotes de­fi­nie­ren. So lassen sich be­stehen­de Container zwischen LXD-Servern kopieren und bewegen; ferner erfolgt über die Remotes der Zugriff auf die Image-Server. Neben den im Abschnitt „Images” bereits vor­ge­stell­ten Image-Servern kennt der Kom­man­do­zei­len-Client ab Werk noch das 'local'-Remote. Dieses dient zur Kom­mu­ni­ka­ti­on mit dem lokalen LXD-Daemon über einen UNIX-Socket.

Heut­zu­ta­ge existiert ein großes Spektrum an Vir­tua­li­sie­rungs-Tech­no­lo­gien, die prin­zi­pi­ell als Al­ter­na­ti­ven zu LXD ein­ge­setzt werden können. Diese un­ter­schei­den sich in Hinsicht auf ver­schie­de­ne Kriterien und lassen sich grob in zwei große Gruppen einteilen: Neben den tra­di­tio­nel­len VM-basierten Vir­tua­li­sie­rungs-Tools haben sich con­tai­ner­ba­sier­te Tech­no­lo­gien durch­ge­setzt. LXD fällt hier aus dem Rahmen und nutzt einen hybriden Ansatz, bei der ein gesamtes Linux-Be­triebs­sys­tem auf Container-Basis vir­tua­li­siert wird.

Manche Vir­tua­li­sie­rungs-Tools setzen Linux als Host-System voraus, andere laufen auf allen ver­brei­te­ten Be­triebs­sys­te­men. Glei­cher­ma­ßen un­ter­stüt­zen manche Vir­tua­li­sie­rungs-Um­ge­bun­gen nur Linux als Gast-System, andere ganz ver­schie­de­ne. Bei vielen con­tai­ner­ba­sier­ten Tech­no­lo­gien liegt der Fokus primär auf der App-Vir­tua­li­sie­rung, während virtuelle Maschinen immer auf einem kom­plet­ten Be­triebs­sys­tem aufsetzen.

Da LXD auf LXC aufbaut, ist die Nutzung einer „nackten“ LXC-In­stal­la­ti­on als Al­ter­na­ti­ve zu LXD möglich. Dann gestaltet sich der Einsatz jedoch ggf. weniger kom­for­ta­bel. Da ohne LXD kein Daemon zum Einsatz kommt, lässt sich die Vir­tua­li­sie­rung nicht über das Netzwerk steuern. Ferner fehlt dann die REST-API als ein­heit­li­che Schnitt­stel­le.

Von den ver­brei­te­ten Vir­tua­li­sie­rungs-Tools ist wohl con­tai­nerd am ehesten mit LXD ver­gleich­bar. So läuft con­tai­nerd ebenfalls als Daemon, der eine API zur Verfügung stellt. Dies erlaubt wie bei LXD die Ver­wal­tung der Container über das Netzwerk. Die Tech­no­lo­gie ist in Docker in­te­griert und wird häufig ein­ge­setzt.

Generell ist es anzuraten, je nach spe­zi­fi­schen An­for­de­run­gen die passende Tech­no­lo­gie zu wählen. Hier eine Übersicht häufig ein­ge­setz­ter Vir­tua­li­sie­rungs-Tech­no­lo­gien: