LXD gegen Docker

Nicht alles Neues ist gut und nicht alles Revolutionäre ist notwendig. Mit Container -Technologien sehen wir, wie bei jeder anderen „nächsten großen Sache“.

Beginnen wir mit welchen Behältern in der Vergangenheit tatsächlich waren. In den frühen 2000er Jahren stellte FreeBSD das Konzept der „Gefängnisse“ vor, das eine neue Umgebung bot, wie eine neue Installation des Betriebssystems, das alle bereits vorhanden. Ein sauberer Taf für Entwickler, um neue Software zu testen.

Dies steht in starkem Gegensatz zu VMware, KVM oder VirtualBox -ähnlichen Technologien, bei denen die gesamte Hardware virtualisiert wird, wo Ihr Host -Betriebssystem eine virtuelle Reihe von CPU, RAM und anderen Ressourcen vorsieht. Ihr Gastbetriebssystem befindet sich auf diesen virtuellen Hardware -Ressourcen. Fast jede Abstraktionsebene wird zweimal wiederholt und Ressourcen wie RAM und CPU, die dem Gast zugewiesen wurden, sind dem Host nicht mehr verfügbar (unabhängig davon, ob der Gast sie vollständig verwendet oder nicht).

Docker- und Linux-y-Container

Wenn das Betriebssystem virtualisiert wird, können Container mit dem für ihre Ressourcenauslastung festgelegten Quoten aufgerechnet werden. Wenn wir beispielsweise eine maximale Grenze von 2 GB RAM -Nutzung für den Container einrichten, kann es sie nicht übertreffen. Andererseits kann der Kernel die verbleibende Ressource an anderer Stelle einsetzen.

Der erste Nachteil, der mit dem Containermodell realisierte.

Es gibt kein so etwas wie Windows -Container unter Linux- oder Linux -Containern unter Windows. Docker unter Windows verwendet beispielsweise Moby Linux, das tatsächlich in einem VM in Ihrem Windows -Feld ausgeführt wird.

Wenn es jedoch um eine Linux -Verteilung geht, können Sie viele interessante Dinge tun. Da das, was wir Linux nennen, nur der Kernel ist und einen GNU -Stapel Bibliotheken benötigt, um eine vollständige OS.

Dies gilt sowohl für LXD als auch für Docker.

Docker als Verpackungsmechanismus

Docker wird es mit dem Tar tun. Das heißt, Sie werden immer noch APT verwenden, aber mit einer zusätzlichen Abstraktionsebene darüber hinaus. Um zu verstehen, wie das folgende Beispiel betrachten.

Sie haben eine Instanz Ihrer Website, die in einem PHP5 ausgeführt wird.6 Und Sie müssen einen weiteren Webdienst auf demselben Server mit PHP7 ausführen.0. Jetzt zwei verschiedene Versionen von PHP selbst zu führen, ist eine beängstigende Idee, ohne zu wissen, welche Konflikte aus ihnen entstehen würden. Das Aktualisieren und Aufrüsten wird bald ein hoffnungsloses Unterfangen.

Aber was wäre, wenn wir unsere ursprüngliche Webinstanz in einem Docker -Container ausführen würden? Jetzt brauchen wir nur noch ein neuer Docker -Container, in dem wir PHP7 installieren können.0 und unser zweiter Webdienst funktioniert von diesem neu gesponnenen Container. Wir werden APT im Hintergrund immer noch verwenden, genau wie APT TAR im Hintergrund verwendet, aber Docker würde sicherstellen, dass verschiedene Anwendungen aus verschiedenen Containern nicht miteinander in Konflikt stehen.

Docker ist besonders nützlich für die Ausführung von staatenlosen Anwendungen und Sie werden Leute oft sagen, dass Sie nicht mehr als einen Prozess in einem Container ausführen können. Obwohl dies falsch ist, kann es häufig Docker dazu veranlassen, inkonsistente Ergebnisse zu erzielen. Sie werden bald immer wieder die gleichen Container neu starten.

LXD als Hypervisor

Mit LXD -Containern ist das, was Sie bekommen. Docker -Container teilen sich alle den gleichen Netzwerkstapel und den Speicherstapel.

Dies bedeutet grundlegende Befehle wie Klingeln oder Ifconfig sind in einem Docker -Container nicht verfügbar. Tatsächlich können Sie fast nichts über das Netzwerk wissen, in dem Sie sich befinden, aus diesem Container. Docker Nat, das auf dem Networking -Stack des Hosts ausgeführt wird.

LXD -Container sind der Kurve weit voraus und unterstützen Netzwerkbrücken, MacVlan und mehrere andere Optionen. Ihre LXD -Container und Ihr Host bilden alle ein eigenes privates Netzwerk und können miteinander kommunizieren, als ob sie über ein Netzwerk mit verschiedenen Computern sprechen würden.

Gleiches gilt für den Speicherstapel. Es ist oft viel praktischer, LXD mit ZFS -Pools zu verwenden, in denen Sie Datensätze mit Quoten zuweisen, die die Speicherauslastung einschränken. LXD befindet sich im direkten Wettbewerb mit VMware, KVM und anderen Hypervisor -Technologien.

Mit der Verwendung kann Ihr Cloud -Anbieter Ihnen jetzt Ihren persönlichen Container bereitstellen, der riechen und sich wie ein vollständiges Betriebssystem anfühlen würde und immer noch billig und schnell ist, zusammen mit all den Feinheiten anhaltender Daten, die Sie erwarten.

Aus der Sicht des Anbieters sind auch die Dinge wirtschaftlich. Da nicht jeder den gesamten RAM benutzt, den er verlang.

Für die Endbenutzer mag es zunächst wie Betrug klingen, aber sie gewinnen auch am Ende. LX -Container sind schneller zu drehen und zu töten, was den Prozess viel reibungsloser und „skalierbar“ macht (wie die Menschen gern sagen).

Sie können Container auf einem Rechenknoten drehen, in dem sich Ihre Daten befinden, die Berechnung durchführen, die Sie ausführen möchten, und dann den Container zerstören, wobei die Daten intakt bleiben. Dies ist viel schneller als das Abrufen relevanter Daten bis zu Ihrer virtuellen Maschine, die in einem anderen Rechenzentrum ausgeführt wird. Dies funktioniert besonders gut zu ZFs in der Schleife.

Tl; DR

Um alles zusammenzufassen, was wir kennen, sind sowohl LXD als auch Docker Containerisierungstechnologien. Docker ist leicht, simpel und eignet sich gut für die Isolierung von Anwendungen voneinander. Eine App pro Docker -Container.

LXD hingegen ist viel besser ausgestattet und ist viel näher an einer vollständigen Betriebssystemumgebung mit Netzwerk- und Speicherschnittstellen. Sie können mehrere Docker -Container ausführen, die in LXD verschachtelt sind, wenn Sie möchten.