Frage Wie unterscheidet sich Docker von einer virtuellen Maschine?


Ich lese immer wieder die Docker-Dokumentation um zu versuchen, den Unterschied zwischen Docker und einer vollständigen VM zu verstehen. Wie schafft es es, ein vollständiges Dateisystem, eine isolierte Netzwerkumgebung usw. bereitzustellen, ohne so schwer zu sein?

Warum ist die Bereitstellung von Software für ein Docker-Image (wenn das der richtige Begriff ist) einfacher als die einfache Bereitstellung in einer konsistenten Produktionsumgebung?


2910
2018-04-16 21:19


Ursprung


Antworten:


Docker ursprünglich verwendet LinuX Container (LXC), wechselte aber später zu runC (früher bekannt als libcontainer), die im selben Betriebssystem wie ihr Host läuft. Dies ermöglicht es, eine Menge der Host-Betriebssystemressourcen zu teilen. Außerdem verwendet es ein geschichtetes Dateisystem (AuFS) und verwaltet die Vernetzung.

AuFS ist ein geschichtetes Dateisystem, so dass Sie einen schreibgeschützten Teil und einen schreibenden Teil haben können, die zusammengeführt werden. Man könnte die gemeinsamen Teile des Betriebssystems als schreibgeschützt haben (und unter all Ihren Containern teilen) und dann jedem Container eine eigene Halterung zum Schreiben geben.

Nehmen wir an, Sie haben ein 1-GB-Container-Image. Wenn Sie eine vollständige VM verwenden möchten, benötigen Sie 1 GB x Anzahl der gewünschten VMs. Mit Docker und AuFS können Sie den Großteil der 1 GB zwischen allen Containern teilen, und wenn Sie über 1000 Container verfügen, haben Sie immer noch etwas mehr als 1 GB Speicherplatz für das Container-Betriebssystem (vorausgesetzt, sie führen alle das gleiche BS-Image aus) .

Ein vollständig virtualisiertes System erhält seine eigenen Ressourcen zugewiesen und teilt nur minimal. Sie erhalten mehr Isolation, aber es ist viel schwerer (erfordert mehr Ressourcen). Mit Docker erhalten Sie weniger Isolation, aber die Container sind leicht (benötigen weniger Ressourcen). So können Sie problemlos Tausende von Containern auf einem Host ausführen, und es wird nicht einmal blinken. Versuchen Sie das mit Xen, und wenn Sie keinen wirklich großen Host haben, glaube ich nicht, dass es möglich ist.

Ein voll virtualisiertes System dauert normalerweise nur wenige Minuten, während Docker / LXC / runC-Container Sekunden und oft sogar weniger als eine Sekunde benötigen.

Für jede Art von virtualisiertem System gibt es Vor- und Nachteile. Wenn Sie vollständige Isolierung mit garantierten Ressourcen wünschen, ist eine vollständige VM der richtige Weg. Wenn Sie nur Prozesse voneinander isolieren möchten und eine Menge davon auf einem vernünftig dimensionierten Host ausführen möchten, dann scheint Docker / LXC / runC der richtige Weg zu sein.

Weitere Informationen finden Sie unter diese Reihe von Blog-Posts die erklären, wie LXC funktioniert.

Warum ist die Bereitstellung von Software für ein Docker-Image (wenn das der richtige Begriff ist) einfacher als die einfache Bereitstellung in einer konsistenten Produktionsumgebung?

Die Bereitstellung einer konsistenten Produktionsumgebung ist einfacher gesagt als getan. Selbst wenn Sie Tools wie Koch und MarionetteEs gibt immer Betriebssystem-Updates und andere Dinge, die sich zwischen Hosts und Umgebungen ändern.

Docker gibt Ihnen die Möglichkeit, das Betriebssystem in einem freigegebenen Abbild festzuhalten und es auf anderen Docker-Hosts einfach bereitzustellen. Lokal, dev, qa, prod, etc .: alle das gleiche Bild. Sicher kannst du das mit anderen Tools machen, aber nicht annähernd so einfach oder schnell.

Dies ist großartig zum Testen; Angenommen, Sie haben Tausende von Tests, die eine Verbindung zu einer Datenbank herstellen müssen, und jeder Test benötigt eine unveränderte Kopie der Datenbank und nimmt Änderungen an den Daten vor. Der klassische Ansatz dazu ist, die Datenbank nach jedem Test entweder mit benutzerdefiniertem Code oder mit Tools wie Weg fliegen - Dies kann sehr zeitaufwendig sein und bedeutet, dass Tests seriell ausgeführt werden müssen. Mit Docker können Sie jedoch ein Image Ihrer Datenbank erstellen und eine Instanz pro Test ausführen und dann alle Tests parallel ausführen, da Sie wissen, dass sie alle mit demselben Snapshot der Datenbank ausgeführt werden. Da die Tests parallel und in Docker-Containern ausgeführt werden, können sie alle auf derselben Box zur gleichen Zeit ausgeführt werden und sollten viel schneller beenden. Versuchen Sie das mit einer vollständigen VM.

Von Kommentaren ...

Interessant! Ich denke, ich bin immer noch verwirrt von dem Begriff "Snapshot [ting] the OS". Wie macht man das, ohne ein Image des Betriebssystems zu erstellen?

Na, mal sehen, ob ich es erklären kann. Sie beginnen mit einem Basisimage, nehmen Ihre Änderungen vor und übernehmen diese Änderungen mit dem Andockfenster und erstellen ein Image. Dieses Bild enthält nur die Unterschiede zur Basis. Wenn Sie Ihr Bild ausführen möchten, benötigen Sie auch die Basis und es wird Ihr Bild oben auf der Basis mit einem mehrschichtigen Dateisystem überlagert: Docker verwendet wie oben erwähnt AUFS. AUFS führt die verschiedenen Ebenen zusammen und Sie erhalten, was Sie wollen; Sie müssen es nur ausführen. Sie können mehr und mehr Bilder (Ebenen) hinzufügen und es wird weiterhin nur die Diffs speichern. Da Docker in der Regel auf vorgefertigte Bilder von einem erstellt Registrierung, Sie müssen selten das gesamte Betriebssystem selbst "abfotografieren".


2807
2018-04-16 22:35



Gute Antworten. Um eine Bilddarstellung von Container vs VM zu erhalten, schauen Sie sich die folgende an.

enter image description here

Quelle: https://www.docker.com/what-container#/package_software


338
2017-10-14 18:02



Es kann hilfreich sein zu verstehen, wie Virtualisierung und Container auf niedriger Ebene funktionieren. Das wird viele Dinge klären.

Hinweis: Ich vereinfache ein wenig bei der Beschreibung unten. Siehe Referenzen für weitere Informationen.

Wie funktioniert die Virtualisierung auf niedriger Ebene?

In diesem Fall übernimmt der VM-Manager den CPU-Ring 0 (oder den "Root-Modus" in neueren CPUs) und fängt alle privilegierten Aufrufe des Gastbetriebssystems ab, um die Illusion zu erzeugen, dass das Gastbetriebssystem seine eigene Hardware hat. Fun fact: Vor 1998 wurde davon ausgegangen, dass dies in der x86-Architektur unmöglich ist, weil es keine Möglichkeit gab, diese Art von Interception durchzuführen. Die Leute bei VMWare waren die Ersten Wer hatte eine Idee, die ausführbaren Bytes im Speicher für privilegierte Aufrufe des Gastbetriebssystems neu zu schreiben, um dies zu erreichen.

Im Endeffekt ermöglicht die Virtualisierung die Ausführung von zwei völlig verschiedenen Betriebssystemen auf derselben Hardware. Jedes Gastbetriebssystem durchläuft den gesamten Prozess des Bootstrappings, des Ladens des Kernels usw. Sie können sehr enge Sicherheitsvorkehrungen treffen, zum Beispiel kann das Gastbetriebssystem keinen vollen Zugriff auf das Hostbetriebssystem oder andere Gäste erhalten und Dinge durcheinander bringen.

Wie funktioniert der Container auf niedrigem Niveau?

Um 2006, Menschen einschließlich einiger Mitarbeiter bei Google implementiert neue Kernel-Level-Funktion namens Namespaces (jedoch die Idee lange Vor existiert in FreeBSD). Eine Funktion des Betriebssystems besteht darin, die Freigabe globaler Ressourcen wie Netzwerk und Festplatte für Prozesse zu ermöglichen. Was wäre, wenn diese globalen Ressourcen in Namespaces eingebettet wären, sodass sie nur für die Prozesse sichtbar sind, die im selben Namespace ausgeführt werden? Nehmen wir an, Sie können einen Teil des Datenträgers holen und ihn in den Namespace X einfügen. Dann können Prozesse, die im Namespace laufen, nicht sehen oder darauf zugreifen. Ebenso können Prozesse im Namespace X auf nichts im Speicher zugreifen, der dem Namespace Y zugeordnet ist. Natürlich können Prozesse in X keine Prozesse im Namespace Y sehen oder mit ihnen kommunizieren. Dies bietet eine Art Virtualisierung und Isolation für globale Ressourcen. So funktioniert docker: Jeder Container läuft in seinem eigenen Namespace, verwendet aber genau das gleich Kernel wie alle anderen Container. Die Isolierung geschieht, weil der Kernel den Namespace kennt, der dem Prozess zugewiesen wurde, und während der API-Aufrufe stellt er sicher, dass der Prozess nur auf Ressourcen in seinem eigenen Namespace zugreifen kann.

Die Einschränkungen von Containern vs. VM sollten jetzt offensichtlich sein: Sie können nicht komplett unterschiedliche Betriebssysteme in Containern wie in VMs ausführen. Aber du kann verschiedene Distributionen von Linux ausführen, da sie denselben Kernel verwenden. Die Isolationsstufe ist nicht so stark wie in VM. In der Tat gab es einen Weg für den "Gast" -Container, Host in frühen Implementierungen zu übernehmen. Außerdem können Sie sehen, dass beim Laden eines neuen Containers die gesamte neue Kopie des Betriebssystems nicht wie in VM gestartet wird. Alle Behälter teilen Sie den gleichen Kernel. Deshalb sind die Behälter leicht. Im Gegensatz zu VM müssen Sie den Containern keinen wesentlichen Speicherplatz zuweisen, da keine neue Kopie des Betriebssystems ausgeführt wird. Dies ermöglicht es, Tausende von Containern auf einem Betriebssystem auszuführen, während Sandboxing durchgeführt wird, was möglicherweise nicht möglich ist, wenn wir eine separate Kopie des Betriebssystems in einer eigenen VM ausführen.


294
2018-01-13 01:49



Ich mag Ken Cochranes Antwort.

Aber ich möchte zusätzliche Gesichtspunkte hinzufügen, die hier nicht im Detail behandelt werden. Meiner Meinung nach unterscheidet sich Docker auch im ganzen Prozess. Im Gegensatz zu VMs bietet Docker nicht (nur) optimale Ressourcenfreigabe von Hardware, außerdem stellt es ein "System" für die Paketanwendung bereit (vorzuziehen, aber nicht zwingend, als eine Reihe von Microservices).

Für mich passt es in die Lücke zwischen den entwicklerorientierten Tools wie rpm, debian packages, maven, npm + git auf der einen Seite und Ops Tools wie Puppet, VMWare, Xen, you name it it ...

Warum ist die Bereitstellung von Software für ein Docker-Image (wenn das der richtige Begriff ist) einfacher als die einfache Bereitstellung in einer konsistenten Produktionsumgebung?

Ihre Frage geht von einer konsistenten Produktionsumgebung aus. Aber wie kann man es konsistent halten?  Betrachten Sie eine Menge (> 10) von Servern und Anwendungen, Stufen in der Pipeline. Um dies zu synchronisieren, werden Sie anfangen, etwas wie Puppet, Chef oder Ihre eigenen Provisionierungsskripte, unveröffentlichte Regeln und / oder viel Dokumentation zu verwenden ... Theoretisch können Server unbegrenzt laufen und vollständig konsistent und auf dem neuesten Stand gehalten werden. Die Praxis kann die Konfiguration eines Servers nicht vollständig verwalten. Daher gibt es erheblichen Spielraum für Konfigurationsabweichungen und unerwartete Änderungen an laufenden Servern.

Es gibt also ein bekanntes Muster, das zu vermeiden, das sogenannte Unveränderlicher Server. Aber das unveränderliche Servermuster wurde nicht geliebt. Vor allem wegen der Einschränkungen von VMs wurde es vor Docker verwendet. Der Umgang mit mehreren Gigabyte großen Bildern, das Verschieben dieser großen Bilder, um nur einige Felder in der App zu ändern, war sehr mühsam. Verständlich...

Mit einem Docker-Ökosystem müssen Sie sich nie mit kleinen Änderungen ("Danke" und "Registrierung") in Gigabyte bewegen, und Sie müssen sich nicht darum sorgen, die Leistung zu verlieren, indem Sie Anwendungen zur Laufzeit in einen Docker-Container packen. Sie müssen sich keine Gedanken über Versionen dieses Bildes machen. Und schließlich werden Sie oft sogar auf Ihrem Linux-Laptop komplexe Produktionsumgebungen reproduzieren können (rufen Sie mich nicht an, wenn das bei Ihnen nicht funktioniert;))

Und natürlich können Sie Docker Container in VMs starten (es ist eine gute Idee). Reduzieren Sie Ihre Server-Bereitstellung auf VM-Ebene. All dies könnte von Docker verwaltet werden.

P.S. Inzwischen verwendet Docker eine eigene Implementierung "libcontainer" anstelle von LXC. Aber LXC ist immer noch verwendbar.


279
2017-09-19 16:21



Docker ist keine Virtualisierungsmethode. Es basiert auf anderen Tools, die tatsächlich Container-basierte Virtualisierung oder Betriebssystem-Virtualisierung implementieren. Zu diesem Zweck verwendete Docker zunächst den LXC-Treiber und wechselte dann zu libcontainer, der jetzt in runc umbenannt wurde. Docker konzentriert sich hauptsächlich auf die Automatisierung der Bereitstellung von Anwendungen in Anwendungscontainern. Anwendungscontainer sind so konzipiert, dass sie einen einzelnen Service bündeln und ausführen, während Systemcontainer für die Ausführung mehrerer Prozesse ausgelegt sind, z. B. für virtuelle Maschinen. Daher wird Docker als Containerverwaltungs- oder Anwendungsimplementierungswerkzeug für containerisierte Systeme betrachtet.

Um zu verstehen, wie es sich von anderen Virtualisierungen unterscheidet, lassen Sie uns die Virtualisierung und ihre Typen betrachten. Dann wäre es leichter zu verstehen, worin der Unterschied besteht.

Virtualisierung

In seiner konzipierten Form wurde es als eine Methode betrachtet, Mainframes logisch zu unterteilen, damit mehrere Anwendungen gleichzeitig ausgeführt werden können. Das Szenario änderte sich jedoch drastisch, als Unternehmen und Open-Source-Communities in der Lage waren, eine Methode zur Handhabung der privilegierten Anweisungen auf die eine oder andere Weise bereitzustellen und die gleichzeitige Ausführung mehrerer Betriebssysteme auf einem einzigen x86-basierten System zu ermöglichen.

Hypervisor

Der Hypervisor übernimmt die Erstellung der virtuellen Umgebung, in der die virtuellen Gastmaschinen arbeiten. Es überwacht die Gastsysteme und stellt sicher, dass die Ressourcen den Gästen bei Bedarf zugewiesen werden. Der Hypervisor befindet sich zwischen der physischen Maschine und virtuellen Maschinen und stellt den virtuellen Maschinen Virtualisierungsdienste bereit. Um dies zu realisieren, fängt es die Gastbetriebssystemoperationen auf den virtuellen Maschinen ab und emuliert die Operation auf dem Betriebssystem des Host-Rechners.

Die schnelle Entwicklung von Virtualisierungstechnologien, vor allem in der Cloud, hat den Einsatz von Virtualisierung weiter vorangetrieben, indem mehrere virtuelle Server mit Hilfe von Hypervisoren wie Xen, VMware Player, KVM usw. auf einem einzigen physischen Server erstellt werden konnten Integration von Hardware-Unterstützung in Standard-Prozessoren wie Intel VT und AMD-V.

Arten der Virtualisierung

Die Virtualisierungsmethode kann basierend darauf kategorisiert werden, wie sie Hardware an ein Gastbetriebssystem nachahmt und die Gastbetriebsumgebung emuliert. In erster Linie gibt es drei Arten der Virtualisierung:

  • Emulation
  • Paravirtualisierung
  • Containerbasierte Virtualisierung

Emulation

Bei der Emulation, die auch als vollständige Virtualisierung bezeichnet wird, wird der Betriebssystemkern der virtuellen Maschine vollständig in Software ausgeführt. Der in diesem Typ verwendete Hypervisor ist als Typ 2-Hypervisor bekannt. Es wird auf dem Host-Betriebssystem installiert, das für die Übersetzung des Betriebssystem-Kernel-Codes in Software-Anweisungen zuständig ist. Die Übersetzung erfolgt vollständig in Software und erfordert keine Hardware-Beteiligung. Die Emulation ermöglicht das Ausführen eines nicht modifizierten Betriebssystems, das die zu emulierende Umgebung unterstützt. Der Nachteil dieser Art von Virtualisierung ist zusätzlicher Systemressourcen-Overhead, der im Vergleich zu anderen Arten von Virtualisierung zu einer Leistungsminderung führt.

Emulation

Beispiele in dieser Kategorie sind VMware Player, VirtualBox, QEMU, Bochs, Parallels usw.

Paravirtualisierung

Paravirtualisierung, auch bekannt als Hypervisor Typ 1, wird direkt auf der Hardware oder "Bare-Metal" ausgeführt und stellt Virtualisierungsdienste direkt für die darauf ausgeführten virtuellen Maschinen bereit. Es hilft dem Betriebssystem, der virtualisierten Hardware und der realen Hardware zusammenzuarbeiten, um eine optimale Leistung zu erzielen. Diese Hypervisoren haben typischerweise einen eher geringen Platzbedarf und benötigen selbst keine umfangreichen Ressourcen.

Beispiele in dieser Kategorie sind Xen, KVM usw.

Paravirtualization

Containerbasierte Virtualisierung

Die containerbasierte Virtualisierung, auch als Virtualisierung auf Betriebssystemebene bekannt, ermöglicht mehrere isolierte Ausführungen innerhalb eines einzelnen Betriebssystemkerns. Es hat die bestmögliche Leistung und Dichte und bietet dynamische Ressourcenverwaltung. Die isolierte virtuelle Ausführungsumgebung, die von diesem Virtualisierungstyp bereitgestellt wird, wird als Container bezeichnet und kann als eine nachverfolgte Gruppe von Prozessen angesehen werden.

Container-based virtualization

Das Konzept eines Containers wird durch die Namespaces-Funktion ermöglicht, die der Linux-Kernel-Version 2.6.24 hinzugefügt wurde. Der Container fügt jedem Prozess seine ID hinzu und fügt jedem Systemaufruf neue Zugriffskontrollprüfungen hinzu. Es ist zugänglich von der Klon() Systemaufruf, mit dem separate Instanzen von zuvor globalen Namespaces erstellt werden können.

Namespaces können auf viele verschiedene Arten verwendet werden. Am häufigsten wird jedoch ein isolierter Container erstellt, der keine Sichtbarkeit oder keinen Zugriff auf Objekte außerhalb des Containers hat. Prozesse, die innerhalb des Containers ausgeführt werden, scheinen auf einem normalen Linux-System zu laufen, obwohl sie den zugrundeliegenden Kernel mit Prozessen teilen, die sich in anderen Namespaces befinden, gleich für andere Arten von Objekten. Wenn beispielsweise Namespaces verwendet werden, wird der root-Benutzer innerhalb des Containers nicht als root außerhalb des Containers behandelt, wodurch zusätzliche Sicherheit hinzugefügt wird.

Das Linux Control Groups (Cgroups) -Subsystem, die nächste Hauptkomponente zur Aktivierung der containerbasierten Virtualisierung, wird zum Gruppieren von Prozessen und zum Verwalten ihres aggregierten Ressourcenverbrauchs verwendet. Es wird häufig verwendet, um den Speicher- und CPU-Verbrauch von Containern zu begrenzen. Da ein containerisiertes Linux-System nur einen Kernel hat und der Kernel volle Transparenz in den Containern hat, gibt es nur eine Ebene der Ressourcenzuweisung und -planung.

Mehrere Management-Tools sind für Linux-Container verfügbar, darunter LXC, LXD, Systemd-Nspawn, Lmctfy, Warden, Linux-VServer, OpenVZ, Docker usw.

Container vs virtuelle Maschinen

Im Gegensatz zu einer virtuellen Maschine muss ein Container den Betriebssystemkern nicht starten, sodass Container in weniger als einer Sekunde erstellt werden können. Diese Funktion macht die containerbasierte Virtualisierung einzigartig und wünschenswert im Vergleich zu anderen Virtualisierungsansätzen.

Da die containerbasierte Virtualisierung dem Hostcomputer wenig oder keinen zusätzlichen Aufwand hinzufügt, weist die containerbasierte Virtualisierung eine nahezu native Leistung auf

Für die containerbasierte Virtualisierung ist im Gegensatz zu anderen Virtualisierungen keine zusätzliche Software erforderlich.

Alle Container auf einem Hostcomputer teilen sich den Scheduler des Hostcomputers, wodurch zusätzliche Ressourcen eingespart werden müssen.

Container-Zustände (Docker- oder LXC-Bilder) sind im Vergleich zu Images virtueller Maschinen klein. Container-Images sind daher einfach zu verteilen.

Die Ressourcenverwaltung in Containern erfolgt über Kontrollgruppen. Cgroups erlaubt Containern nicht, mehr Ressourcen als ihnen zugewiesen zu verbrauchen. Ab sofort sind alle Ressourcen des Host-Rechners in virtuellen Maschinen sichtbar, können jedoch nicht verwendet werden. Dies kann durch Laufen realisiert werden top oder htop auf Containern und Host-Maschine zur gleichen Zeit. Die Ausgabe in allen Umgebungen wird ähnlich aussehen.


121
2018-04-02 00:55



Durch diesen Beitrag werden wir einige Unterschiede zwischen VMs und LXCs ziehen. Lassen Sie uns zuerst sie definieren.

VM:

Eine virtuelle Maschine emuliert eine physische Computerumgebung, aber Anfragen nach CPU-, Speicher-, Festplatten-, Netzwerk- und anderen Hardwareressourcen werden von einer Virtualisierungsschicht verwaltet, die diese Anforderungen in die zugrunde liegende physische Hardware übersetzt.

In diesem Kontext wird die VM als Gast bezeichnet, während die Umgebung, in der sie ausgeführt wird, als Host bezeichnet wird.

LXCs:

Linux Container (LXC) sind Funktionen auf Systemebene, die es ermöglichen, mehrere isolierte Linux-Container auf einem Steuerhost (dem LXC-Host) auszuführen. Linux-Container bieten eine leichte Alternative zu VMs, da sie keine Hypervisoren erfordern. Virtualbox, KVM, Xen usw.

Nun, es sei denn, Sie wurden von Alan (Zach Galifianakis aus der Hangover-Serie) unter Drogen gesetzt und waren das letzte Jahr in Las Vegas. Sie werden sich ziemlich sicher sein, dass die Linux-Containertechnologie sehr interessant ist Ein Projekt, das in den letzten Monaten weltweit für Aufsehen gesorgt hat - Docker führt zu der Meinung, dass Cloud-Computing-Umgebungen virtuelle Maschinen (VMs) aufgeben und sie aufgrund ihres geringeren Overheads und potenziell höherer Leistung durch Container ersetzen sollten.

Aber die große Frage ist: Ist es machbar? Wird es vernünftig sein?

ein. LXCs sind auf eine Instanz von Linux beschränkt. Es kann verschiedene Linux-Varianten sein (zB ein Ubuntu-Container auf einem CentOS-Host, aber es ist immer noch Linux). Windows-basierte Container sind in ähnlicher Weise auf eine Instanz von Windows beschränkt. Wenn wir uns VMs ansehen, haben sie einen ziemlich breiteren Anwendungsbereich Hypervisor Sie sind nicht auf Betriebssysteme Linux oder Windows beschränkt.

b. LXCs haben einen geringen Overhead und eine bessere Leistung als VMs. Werkzeuge nämlich. Docker, die auf den Schultern der LXC-Technologie aufgebaut sind, bieten Entwicklern eine Plattform zum Ausführen ihrer Anwendungen und gleichzeitig befähigte Mitarbeiter mit einem Tool, mit dem sie denselben Container auf Produktionsservern oder Rechenzentren bereitstellen können. Es versucht, die Erfahrung zwischen einem Entwickler, der eine Anwendung ausführt, zu booten und eine Anwendung zu booten, und einer Operationsperson, die diese Anwendung nahtlos implementiert, zu machen, weil die ganze Reibung und der Zweck von DevOps darin liegt, diese Silos zu durchbrechen.

Der beste Ansatz ist daher, dass die Cloud-Infrastrukturanbieter eine angemessene Nutzung der VMs und LXC befürworten, da sie jeweils für die Verarbeitung bestimmter Workloads und Szenarien geeignet sind.

Der Verzicht auf VMs ist ab sofort nicht praktikabel. Daher haben sowohl VMs als auch LXCs ihre eigene Existenz und Wichtigkeit.


117
2017-08-26 07:46



Die meisten Antworten hier sprechen über virtuelle Maschinen. Ich werde Ihnen auf diese Frage, die mir in den letzten Jahren bei der Verwendung von Docker am meisten geholfen hat, eine One-Liner-Antwort geben. Es ist das:

Docker ist nur eine elegante Möglichkeit, einen Prozess auszuführen, keine virtuelle Maschine.

Lassen Sie mich nun ein bisschen mehr darüber erklären, was das bedeutet. Virtuelle Maschinen sind ihr eigenes Biest. Ich möchte erklären was Docker Es wird Ihnen helfen, dies besser zu verstehen als zu erklären, was eine virtuelle Maschine ist. Vor allem, weil es hier viele gute Antworten gibt, die Ihnen genau sagen, was jemand meint, wenn er "virtuelle Maschine" sagt. Damit...

Ein Docker-Container ist nur ein Prozess (und seine untergeordneten Elemente), der unter Verwendung von Gruppen im Kernel des Host-Systems von den übrigen Prozessen. Sie können die Prozesse Ihres Docker-Containers tatsächlich sehen, indem Sie ihn ausführen ps aux auf dem Host. Zum Beispiel, starten apache2 "in einem Container" fängt gerade erst an apache2 als ein spezieller Prozess auf dem Host. Es wurde nur von anderen Prozessen auf der Maschine kompartimentiert. Es ist wichtig zu beachten, dass Ihre Container außerhalb der Lebensdauer Ihres Container-Prozesses nicht existieren. Wenn Ihr Prozess stirbt, stirbt Ihr Container. Das liegt daran, dass Docker ersetzt wird pid 1 in Ihrem Container mit Ihrer Anwendung (pid 1 ist normalerweise das init-System). Dieser letzte Punkt über pid 1 ist sehr wichtig.

Soweit das von jedem dieser Containerprozesse verwendete Dateisystem verwendet Docker UnionFS-Backed Images, die Sie herunterladen, wenn Sie eine docker pull ubuntu. Jedes "Bild" besteht nur aus einer Reihe von Ebenen und zugehörigen Metadaten. Das Konzept der Schichtung ist hier sehr wichtig. Jede Schicht ist nur eine Änderung von der darunter liegenden Schicht. Wenn Sie zum Beispiel beim Erstellen eines Docker-Containers eine Datei in Ihrer Docker-Datei löschen, erstellen Sie lediglich eine Ebene über der letzten Ebene, die besagt, dass diese Datei gelöscht wurde. Übrigens, das ist der Grund, warum Sie eine große Datei aus Ihrem Dateisystem löschen können, aber das Bild nimmt immer noch den gleichen Speicherplatz ein. Die Datei befindet sich immer noch in den Layern unterhalb des aktuellen. Layer selbst sind nur Tarballs von Dateien. Sie können dies mit testen docker save --output /tmp/ubuntu.tar ubuntuund dann cd /tmp && tar xvf ubuntu.tar. Dann kannst du dich umsehen. Alle diese Verzeichnisse, die wie lange Hashes aussehen, sind eigentlich die einzelnen Ebenen. Jeder enthält Dateien (layer.tar) und Metadaten (json) mit Informationen zu dieser bestimmten Schicht. Diese Layer beschreiben nur Änderungen am Dateisystem, die als Layer "über dem ursprünglichen Zustand" gespeichert werden. Beim Lesen der "aktuellen" Daten liest das Dateisystem Daten so, als würde es nur die obersten Schichten von Änderungen betrachten. Aus diesem Grund scheint die Datei gelöscht zu sein, obwohl sie immer noch in "vorherigen" Ebenen vorhanden ist, da das Dateisystem nur die obersten Ebenen betrachtet. Auf diese Weise können vollständig unterschiedliche Container ihre Dateisystemebenen gemeinsam nutzen, obwohl das Dateisystem auf den obersten Ebenen in jedem Container möglicherweise erhebliche Änderungen erfahren hat. Dies kann Ihnen eine Menge Speicherplatz sparen, wenn Ihre Container ihre Basis-Image-Ebenen teilen. Wenn Sie jedoch Verzeichnisse und Dateien über Volumes vom Hostsystem in Ihren Container einbinden, "umgehen" diese Volumes das UnionFS, sodass Änderungen nicht in Layern gespeichert werden.

Die Vernetzung in Docker erfolgt über eine Ethernet-Bridge (genannt docker0 auf dem Host) und virtuelle Schnittstellen für jeden Container auf dem Host. Es erstellt ein virtuelles Subnetz in docker0 damit Ihre Container "untereinander" kommunizieren. Hier gibt es viele Optionen für das Netzwerk, einschließlich der Erstellung benutzerdefinierter Subnetze für Ihre Container und der Möglichkeit, den Netzwerk-Stack Ihres Hosts für den direkten Zugriff auf Ihren Container "freizugeben".

Docker bewegt sich sehr schnell. Es ist Dokumentation ist eine der besten Dokumentationen, die ich je gesehen habe. Es ist im Allgemeinen gut geschrieben, präzise und präzise. Ich empfehle Ihnen, die Dokumentation zu lesen, um weitere Informationen zu erhalten, und der Dokumentation zu vertrauen, was Sie sonst noch online lesen, einschließlich Stack Overflow. Wenn Sie spezifische Fragen haben, empfehle ich Ihnen, beizutreten #docker auf Freenode IRC und fragen dort (Sie können sogar Freenode verwenden internetchat dafür!).


89
2018-04-04 02:35