it-swarm.com.de

Was unterscheidet Docker von einer virtuellen Maschine?

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

Warum ist die Bereitstellung von Software auf einem Docker-Image (wenn dies der richtige Begriff ist) einfacher als die einfache Bereitstellung in einer konsistenten Produktionsumgebung?

3432
zslayton

Docker verwendete ursprünglich LinuX Containers (LXC), wechselte aber später zu runC (früher bekannt als libcontainer ), der auf demselben Betriebssystem wie sein Host ausgeführt wird. Auf diese Weise können viele Ressourcen des Host-Betriebssystems gemeinsam genutzt werden. Außerdem verwendet es ein mehrschichtiges Dateisystem ( AuFS ) und verwaltet das Netzwerk.

AuFS ist ein geschichtetes Dateisystem, sodass Sie einen schreibgeschützten Teil und einen Schreibteil haben können, die zusammengeführt werden. Man könnte die gemeinsamen Teile des Betriebssystems schreibgeschützt haben (und von allen Containern gemeinsam genutzt werden) und dann jedem Container einen eigenen Mount zum Schreiben geben.

Angenommen, Sie haben ein 1-GB-Container-Image. Wenn Sie eine vollständige VM verwenden möchten, benötigen Sie 1 GB x die Anzahl der gewünschten VMs. Mit Docker und AuFS können Sie den Großteil der 1 GB auf alle Container verteilen. Wenn Sie über 1000 Container verfügen, steht möglicherweise nur etwas mehr als 1 GB Speicherplatz für das Containerbetriebssystem zur Verfügung (vorausgesetzt, alle führen dasselbe Betriebssystemimage aus). .

Einem vollständig virtualisierten System werden eigene Ressourcen zugewiesen, und die gemeinsame Nutzung ist minimal. Sie erhalten mehr Isolation, aber es ist viel schwerer (erfordert mehr Ressourcen). Mit Docker erhalten Sie weniger Isolation, aber die Container sind leichtgewichtig (erfordern weniger Ressourcen). Auf diese Weise können Sie problemlos Tausende von Containern auf einem Host ausführen, ohne dass diese blinken. Versuchen Sie das mit Xen, und wenn Sie keinen wirklich großen Host haben, denke ich nicht, dass es möglich ist.

Das Starten eines vollständig virtualisierten Systems dauert in der Regel Minuten, während Docker/LXC/runC-Container Sekunden und häufig sogar weniger als eine Sekunde benötigen.

Für jede Art von virtualisiertem System gibt es Vor- und Nachteile. Wenn Sie eine vollständige Isolierung mit garantierten Ressourcen wünschen, ist eine vollständige VM der richtige Weg. Wenn Sie nur Prozesse voneinander isolieren und eine Tonne von ihnen auf einem relativ großen Host ausführen möchten, ist Docker/LXC/runC der richtige Weg.

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

Warum ist die Bereitstellung von Software auf einem Docker-Image (wenn dies der richtige Begriff ist) einfacher als die einfache Bereitstellung in einer konsistenten Produktionsumgebung?

Die Bereitstellung einer konsistenten Produktionsumgebung ist einfacher gesagt als getan. Auch wenn Sie Tools wie Chef und Puppet verwenden, gibt es immer Betriebssystem-Updates und andere Dinge, die sich zwischen Hosts und Umgebungen ändern.

Docker bietet Ihnen die Möglichkeit, ein Snapshot des Betriebssystems in einem freigegebenen Image zu erstellen, und erleichtert die Bereitstellung auf anderen Docker-Hosts. Vor Ort, dev, qa, prod, etc .: alle das gleiche Bild. Sicher können Sie dies mit anderen Werkzeugen tun, aber nicht annähernd so einfach oder schnell.

Dies ist ideal zum Testen. Nehmen wir an, Sie haben Tausende von Tests, die eine Verbindung zu einer Datenbank herstellen müssen, und jeder Test benötigt eine makellose Kopie der Datenbank und nimmt Änderungen an den Daten vor. Der klassische Ansatz besteht darin, die Datenbank nach jedem Test entweder mit benutzerdefiniertem Code oder mit Tools wie Flyway zurückzusetzen. 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. Anschließend können Sie alle Tests parallel ausführen, da Sie wissen, dass alle Tests mit demselben Snapshot der Datenbank ausgeführt werden. Da die Tests parallel und in Docker-Containern ausgeführt werden, können sie alle gleichzeitig auf derselben Box ausgeführt werden und sollten viel schneller abgeschlossen sein. Versuchen Sie das mit einer vollen VM.

Aus Kommentaren ...

Interessant! Ich glaube, ich bin immer noch verwirrt von dem Gedanken "Momentaufnahme des Betriebssystems". Wie kann man das tun, ohne ein Image des Betriebssystems zu erstellen?

Mal sehen, ob ich es erklären kann. Sie beginnen mit einem Basisimage, nehmen dann Ihre Änderungen vor und übernehmen diese Änderungen mithilfe des Andockfensters. Anschließend wird ein Image erstellt. Dieses Bild enthält nur die Unterschiede zur Basis. Wenn Sie Ihr Image ausführen möchten, benötigen Sie auch die Basis und diese überlagert Ihr Image mithilfe eines Dateisystems mit Ebenen auf der Basis: Wie oben erwähnt, verwendet Docker AUFS. AUFS führt die verschiedenen Ebenen zusammen und Sie erhalten, was Sie wollen. Sie müssen es nur ausführen. Sie können immer mehr Bilder (Ebenen) hinzufügen und es werden weiterhin nur die Unterschiede gespeichert. Da Docker in der Regel auf vorgefertigten Images aus einer Registrierung aufbaut, müssen Sie selten das gesamte Betriebssystem selbst "snapshoten".

3225
Ken Cochrane

Gute Antworten. Schauen Sie sich das folgende Bild an, um eine Abbildung von container vs VM zu erhalten.

enter image description here

Quelle

490
manu97

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

Hinweis: Ich vereinfache ein bisschen in der folgenden Beschreibung. Weitere Informationen finden Sie in den Referenzen.

Wie funktioniert Virtualisierung auf niedriger Ebene?

In diesem Fall übernimmt 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 über eine eigene Hardware verfügt. Unterhaltsame Tatsache: Vor 1998 galt es als unmöglich, dies in der x86-Architektur zu erreichen, da es keine Möglichkeit gab, diese Art des Abfangens durchzuführen. Die Leute bei VMWare waren die ersten , die die Idee hatten, die ausführbaren Bytes im Speicher für privilegierte Aufrufe des Gastbetriebssystems neu zu schreiben, um dies zu erreichen.

Der Nettoeffekt ist, dass Sie durch Virtualisierung zwei völlig unterschiedliche Betriebssysteme auf derselben Hardware ausführen können. Jedes Gastbetriebssystem durchläuft den gesamten Prozess des Bootstrapens, Ladens des Kernels usw. Sie können sehr strenge Sicherheitsvorkehrungen treffen, z.

Wie funktionieren Container auf niedriger Ebene?

Um 2006 herum haben Leute, einschließlich einiger Mitarbeiter bei Google, eine neue Kernel-Level-Funktion implementiert, die Namespaces genannt wurde (wie auch immer die Idee lang zuvor existierte in FreeBSD ). Eine Funktion des Betriebssystems besteht darin, die gemeinsame Nutzung globaler Ressourcen wie Netzwerk und Festplatte für Prozesse zu ermöglichen. Was wäre, wenn diese globalen Ressourcen in Namespaces eingeschlossen würden, sodass sie nur für die Prozesse sichtbar wären, die im selben Namespace ausgeführt werden? Angenommen, Sie können einen Teil der Festplatte abrufen und in Namespace X ablegen, und dann können Prozesse, die in Namespace Y ausgeführt werden, weder darauf zugreifen noch darauf zugreifen. In ähnlicher Weise können Prozesse im Namespace X nicht auf Speicher zugreifen, der dem Namespace Y zugeordnet ist. Natürlich können Prozesse in X keine Prozesse im Namespace Y sehen oder mit diesen kommunizieren. Dies bietet eine Art Virtualisierung und Isolation für globale Ressourcen. So funktioniert Docker: Jeder Container wird in einem eigenen Namespace ausgeführt, verwendet jedoch genau den gleichen Kernel wie alle anderen Container. Die Isolation erfolgt, weil der Kernel den dem Prozess zugewiesenen Namespace kennt und bei API-Aufrufen sicherstellt, dass der Prozess nur auf Ressourcen in seinem eigenen Namespace zugreifen kann.

Die Einschränkungen von Containern gegenüber VM sollten jetzt offensichtlich sein: Sie können in Containern wie in VMs kein völlig anderes Betriebssystem ausführen. Sie können jedoch verschiedene Linux-Distributionen ausführen, da sie denselben Kernel verwenden. Die Isolationsstufe ist nicht so stark wie in VM. In der Tat gab es eine Möglichkeit für "Gast" -Container, Host in frühen Implementierungen zu übernehmen. Außerdem können Sie feststellen, dass beim Laden eines neuen Containers die gesamte neue Betriebssystemkopie nicht wie in einer VM gestartet wird. Alle Container gleichen Kernel teilen . Deshalb sind Container leicht. Im Gegensatz zu VM müssen Sie Containern auch keinen wesentlichen Teil des Arbeitsspeichers vorab zuweisen, da keine neue Kopie des Betriebssystems ausgeführt wird. Auf diese Weise können Tausende von Containern auf einem Betriebssystem ausgeführt werden, während sie in einer Sandbox gespeichert werden. Dies ist möglicherweise nicht möglich, wenn eine separate Kopie des Betriebssystems in einer eigenen VM ausgeführt wird.

427
Shital Shah

Ich mag Ken Cochranes Antwort.

Ich möchte jedoch eine zusätzliche Sichtweise hinzufügen, auf die hier nicht näher eingegangen wird. Meiner Meinung nach unterscheidet sich Docker auch im gesamten Prozess. Im Gegensatz zu VMs geht es bei Docker nicht (nur) um eine optimale gemeinsame Nutzung von Ressourcen auf der Hardware, sondern um ein "System" für die Paketanwendung (bevorzugt, aber nicht unbedingt erforderlich, als Satz von Mikrodiensten).

Für mich passt es in die Lücke zwischen entwicklerorientierten Tools wie rpm, Debian Packages, Maven , npm + Git auf einer Seite und ops Tools wie Puppet , VMware, Xen, Sie nennen es ...

Warum ist die Bereitstellung von Software auf einem Docker-Image (wenn dies der richtige Begriff ist) einfacher als die einfache Bereitstellung in einer konsistenten Produktionsumgebung?

Ihre Frage setzt eine konsistente Produktionsumgebung voraus. Aber wie kann man es konsistent halten? Betrachten Sie eine gewisse Anzahl (> 10) von Servern und Anwendungen, die sich in der Pipeline befinden.

Um dies synchron zu halten, werden Sie anfangen, etwas wie Puppet, Chef oder Ihre eigenen Bereitstellungsskripte, unveröffentlichten Regeln und/oder eine Menge Dokumentation zu verwenden ... Theoretisch können Server auf unbestimmte Zeit ausgeführt und aufbewahrt werden Ganz konsequent und aktuell. In der Praxis wird die Serverkonfiguration nicht vollständig verwaltet, sodass ein erheblicher Spielraum für Konfigurationsverschiebungen und unerwartete Änderungen bei der Ausführung von Servern besteht.

Um dies zu vermeiden, gibt es ein bekanntes Muster, den sogenannten nveränderlichen Server. Aber das unveränderliche Servermuster wurde nicht geliebt. Vor allem wegen der Einschränkungen der VMs, die vor Docker verwendet wurden. Der Umgang mit mehreren Gigabyte großen Bildern, das Verschieben dieser großen Bilder, um nur einige Felder in der Anwendung zu ändern, war sehr, sehr mühsam. Verständlich...

Mit einem Docker-Ökosystem müssen Sie sich niemals mit "kleinen Änderungen" um Gigabyte bewegen (danke aufs und Registry), und Sie müssen sich keine Sorgen machen, 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 können Sie sogar komplexe Produktionsumgebungen häufig selbst auf Ihrem Linux-Laptop reproduzieren (rufen Sie mich nicht an, wenn dies in Ihrem Fall nicht funktioniert;))

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

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

315
aholbreich

Docker ist keine Virtualisierungsmethode. Es basiert auf anderen Tools, die tatsächlich eine Virtualisierung auf Containerbasis oder auf Betriebssystemebene implementieren. Dafür verwendete Docker ursprünglich den LXC-Treiber und wechselte dann zu libcontainer, der jetzt in runc umbenannt wird. Docker konzentriert sich hauptsächlich auf die Automatisierung der Bereitstellung von Anwendungen in Anwendungscontainern. Anwendungscontainer sind für das Packen und Ausführen eines einzelnen Dienstes ausgelegt, während Systemcontainer für das Ausführen mehrerer Prozesse ausgelegt sind, z. B. für virtuelle Maschinen. Docker wird daher als Tool für die Containerverwaltung oder Anwendungsbereitstellung auf containerisierten Systemen betrachtet.

Lassen Sie uns die Virtualisierung und ihre Typen durchgehen, um herauszufinden, wie sie sich von anderen Virtualisierungen unterscheidet. Dann wäre es einfacher zu verstehen, wo der Unterschied liegt.

Virtualisierung

In seiner konzipierten Form wurde es als Methode zur logischen Aufteilung von Mainframes angesehen, um die gleichzeitige Ausführung mehrerer Anwendungen zu ermöglichen. Das Szenario änderte sich jedoch drastisch, als Unternehmen und Open Source-Communities in der Lage waren, die privilegierten Anweisungen auf die eine oder andere Weise zu verarbeiten und die gleichzeitige Ausführung mehrerer Betriebssysteme auf einem einzigen x86-basierten System zu ermöglichen.

Hypervisor

Der Hypervisor erstellt die virtuelle Umgebung, in der die virtuellen Gastmaschinen ausgeführt werden. Es überwacht die Gastsysteme und stellt sicher, dass die Ressourcen den Gästen nach Bedarf zugewiesen werden. Der Hypervisor befindet sich zwischen der physischen Maschine und den virtuellen Maschinen und stellt Virtualisierungsdienste für die virtuellen Maschinen bereit. Um dies zu realisieren, werden die Vorgänge des Gastbetriebssystems auf den virtuellen Maschinen abgefangen und die Vorgänge auf dem Betriebssystem der Hostmaschine emuliert.

Die rasante Entwicklung von Virtualisierungstechnologien, vor allem in der Cloud, hat die Nutzung der Virtualisierung weiter vorangetrieben, da mithilfe von Hypervisoren wie Xen, VMware Player, KVM usw. und mehrere virtuelle Server auf einem einzigen physischen Server erstellt werden konnten Integration von Hardware-Unterstützung in Standardprozessoren wie Intel VT und AMD-V.

Arten der Virtualisierung

Die Virtualisierungsmethode kann basierend darauf kategorisiert werden, wie sie die Hardware eines Gastbetriebssystems imitiert und die Gastbetriebsumgebung emuliert. In erster Linie gibt es drei Arten der Virtualisierung:

  • Emulation
  • Paravirtualisierung
  • Container-basierte Virtualisierung

Emulation

Die Emulation, auch als vollständige Virtualisierung bezeichnet, führt den Betriebssystemkern der virtuellen Maschine vollständig in Software aus. Der in diesem Typ verwendete Hypervisor wird als Typ 2-Hypervisor bezeichnet. Es wird auf dem Host-Betriebssystem installiert, das für die Übersetzung des Kernel-Codes des Gastbetriebssystems in Softwareanweisungen verantwortlich ist. Die Übersetzung erfolgt vollständig in Software und erfordert keinen Hardwareeinsatz. Mit der Emulation kann jedes nicht geänderte Betriebssystem ausgeführt werden, das die zu emulierende Umgebung unterstützt. Der Nachteil dieser Art von Virtualisierung ist der zusätzliche Systemressourcenaufwand, der im Vergleich zu anderen Arten von Virtualisierungen zu Leistungseinbußen führt.

Emulation

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

Paravirtualisierung

Die Paravirtualisierung, auch Hypervisor des Typs 1 genannt, 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 bei der Zusammenarbeit, um eine optimale Leistung zu erzielen. Diese Hypervisoren haben in der Regel einen relativ geringen Platzbedarf und erfordern selbst keine umfangreichen Ressourcen.

Beispiele in dieser Kategorie sind Xen, KVM usw.

Paravirtualization

Container-basierte Virtualisierung

Container-basierte Virtualisierung, auch als Virtualisierung auf Betriebssystemebene bekannt, ermöglicht mehrere isolierte Ausführungen innerhalb eines einzelnen Betriebssystemkerns. Es bietet die bestmögliche Leistung und Dichte und verfügt über ein dynamisches Ressourcenmanagement. Die isolierte virtuelle Ausführungsumgebung, die durch diese Art der Virtualisierung bereitgestellt wird, wird als Container bezeichnet und kann als verfolgte Gruppe von Prozessen betrachtet 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. Der Zugriff erfolgt über den Systemaufruf clone () , 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 im Container ausgeführt werden, scheinen auf einem normalen Linux-System ausgeführt zu werden, obwohl sie den zugrunde liegenden Kernel mit Prozessen gemeinsam nutzen, die sich in anderen Namespaces befinden, wie dies auch für andere Arten von Objekten der Fall ist. Wenn Sie beispielsweise Namespaces verwenden, wird der Root-Benutzer innerhalb des Containers nicht als Root außerhalb des Containers behandelt, was zusätzliche Sicherheit bietet.

Das Linux Control Groups-Subsystem (cgroups), die nächste wichtige Komponente zur Aktivierung der containergestützten Virtualisierung, wird zum Gruppieren von Prozessen und zum Verwalten ihres gesamten 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 die Container vollständig sichtbar macht, gibt es nur eine Ebene für die Ressourcenzuweisung und -planung.

Für Linux-Container stehen verschiedene Verwaltungstools zur Verfügung, darunter LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker usw.

Container gegen virtuelle Maschinen

Im Gegensatz zu einer virtuellen Maschine muss ein Container den Betriebssystemkern nicht booten, sodass Container in weniger als einer Sekunde erstellt werden können. Diese Funktion macht die container-basierte Virtualisierung einzigartig und wünschenswerter als andere Virtualisierungsansätze.

Da die containergestützte Virtualisierung dem Hostcomputer nur wenig oder gar keinen Overhead hinzufügt, weist die containergestützte Virtualisierung eine nahezu native Leistung auf

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

Alle Container auf einem Host-Computer teilen sich den Scheduler des Host-Computers, wodurch zusätzliche Ressourcen eingespart werden.

Containerzustände (Docker- oder LXC-Images) sind im Vergleich zu Images virtueller Maschinen klein, sodass Container-Images einfach zu verteilen sind.

Das Ressourcenmanagement in Containern wird durch cgroups erreicht. Cgroups erlaubt Containern nicht, mehr Ressourcen zu verbrauchen, als ihnen zugewiesen sind. Ab sofort sind jedoch alle Ressourcen des Host-Computers in virtuellen Computern sichtbar, können jedoch nicht verwendet werden. Dies kann durch gleichzeitiges Ausführen von top oder htop auf Containern und Host-Rechnern realisiert werden. Die Ausgabe in allen Umgebungen sieht ähnlich aus.

Aktualisieren:

Wie führt Docker Container auf Nicht-Linux-Systemen aus?

Wenn Container aufgrund der im Linux-Kernel verfügbaren Funktionen möglich sind, ist die offensichtliche Frage, wie Container auf Nicht-Linux-Systemen ausgeführt werden. Sowohl Docker für Mac als auch Windows verwenden Linux-VMs, um die Container auszuführen. Docker Toolbox zum Ausführen von Containern in Virtual Box-VMs. Der neueste Docker verwendet Hyper-V unter Windows und Hypervisor.framework unter Mac.

Lassen Sie mich nun beschreiben, wie Docker für Mac Container ausführlich ausführt.

Docker für Mac verwendet https://github.com/moby/hyperkit , um die Hypervisor-Funktionen zu emulieren, und Hyperkit verwendet hypervisor.framework in seinem Kern. Hypervisor.framework ist die native Hypervisor-Lösung von Mac. Hyperkit verwendet auch VPNKit und DataKit für das Namespace-Netzwerk bzw. das Dateisystem.

Das Linux VM, das Docker auf einem Mac ausführt, ist schreibgeschützt. Sie können jedoch darauf einwirken, indem Sie Folgendes ausführen:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

Jetzt können wir sogar die Kernel-Version dieser VM überprüfen:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

Alle Container werden in dieser VM ausgeführt.

Es gibt einige Einschränkungen für hypervisor.framework. Aus diesem Grund stellt Docker die docker0 Netzwerkschnittstelle in Mac nicht zur Verfügung. Sie können also nicht vom Host aus auf Container zugreifen. Ab sofort ist docker0 nur innerhalb der VM verfügbar.

Hyper-v ist der native Hypervisor in Windows. Sie versuchen auch, die Funktionen von Windows 10 für die native Ausführung von Linux-Systemen zu nutzen.

201
Ashish Bista

In diesem Beitrag werden wir einige Unterschiede zwischen VMs und LXCs aufzeigen. Definieren wir sie zuerst.

VM:

Eine virtuelle Maschine emuliert eine physische Computerumgebung, Anforderungen für CPU, Speicher, Festplatte, Netzwerk und andere Hardwareressourcen werden jedoch von einer Virtualisierungsebene verwaltet, die diese Anforderungen in die zugrunde liegende physische Hardware übersetzt.

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

LXC s:

Linux-Container (LXC) sind Funktionen auf Betriebssystemebene, mit denen mehrere isolierte Linux-Container auf einem Steuerhost (dem LXC-Host) ausgeführt werden können. Linux-Container stellen eine einfache Alternative zu VMs dar, da sie keine Hypervisoren benötigen. Virtualbox, KVM, Xen usw.

Wenn Sie nicht von Alan (Zach Galifianakis aus der Hangover-Serie) unter Drogen gesetzt wurden und das letzte Jahr in Vegas waren, werden Sie sich des enormen Interesses für die Linux-Containertechnologie bewusst sein und ob ich ein bestimmter Container sein werde Das Projekt, das in den letzten Monaten weltweit für Aufsehen gesorgt hat, ist - Docker, das zu einigen Echo-Meinungen geführt hat, wonach Cloud-Computing-Umgebungen virtuelle Maschinen (VMs) aufgeben und diese aufgrund ihres geringeren Overheads und der potenziell besseren Leistung durch Container ersetzen sollten.

Aber die große Frage ist, ist es machbar, wird es sinnvoll sein?

ein. LXCs sind auf eine Instanz von Linux beschränkt. Es könnte verschiedene Linux-Varianten geben (z. B. ein Ubuntu-Container auf einem CentOS-Host, aber immer noch Linux). Ebenso sind Windows-basierte Container jetzt auf eine Instanz von Windows beschränkt, wenn wir uns VMs ansehen, die einen ziemlich breiteren Anwendungsbereich haben und das verwenden Hypervisor Sie sind nicht auf Betriebssysteme Linux oder Windows beschränkt.

b. LXCs haben im Vergleich zu VMs einen geringen Overhead und eine bessere Leistung. Werkzeuge nämlich. Docker, die auf den Schultern der LXC-Technologie aufbauen, bieten Entwicklern eine Plattform, auf der sie ihre Anwendungen ausführen können. Gleichzeitig haben sie den Mitarbeitern im Betrieb ein Tool zur Verfügung gestellt, mit dem sie denselben Container auf Produktionsservern oder Rechenzentren bereitstellen können. Es wird versucht, die Erfahrung zwischen einem Entwickler, der eine Anwendung ausführt, eine Anwendung bootet und testet, und einer Betriebsperson, die diese Anwendung nahtlos bereitstellt, zu machen, da hier die ganze Reibung und der Zweck von DevOps darin besteht, diese Silos zu zerstören.

Der beste Ansatz ist daher, dass die Cloud-Infrastrukturanbieter eine angemessene Verwendung der VMs und des LXC befürworten, da diese jeweils für bestimmte Workloads und Szenarien geeignet sind.

Das Verlassen von VMs ist derzeit nicht praktikabel. Somit haben sowohl VMs als auch LXCs ihre eigene Existenz und Bedeutung.

139
Pankaj Arora

Die meisten Antworten hier beziehen sich auf virtuelle Maschinen. Ich werde Ihnen eine einzeilige Antwort auf diese Frage geben, die mir in den letzten Jahren bei der Verwendung von Docker am meisten geholfen hat. Es ist das:

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

Lassen Sie mich nun etwas näher erläutern, was das bedeutet. Virtuelle Maschinen sind ihr eigenes Biest. Ich würde gerne erklären, was Docker ist, damit Sie dies besser verstehen als 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 Prozesse), der mithilfe von cgroups im Kernel des Host-Systems von den übrigen Prozessen getrennt wird. Sie können Ihre Docker-Containerprozesse tatsächlich anzeigen, indem Sie ps aux auf dem Host ausführen. Wenn Sie beispielsweise Apache2 "in einem Container" starten, wird Apache2 nur als spezieller Prozess auf dem Host gestartet. Es wurde nur von anderen Prozessen auf der Maschine getrennt. Es ist wichtig zu beachten, dass Ihre Container nicht außerhalb der Lebensdauer Ihres containerisierten Prozesses existieren. Wenn Ihr Prozess stirbt, stirbt Ihr Container. Docker ersetzt pid 1 in Ihrem Container durch Ihre Anwendung (pid 1 ist normalerweise das Init-System). Dieser letzte Punkt über pid 1 ist sehr wichtig.

Was das Dateisystem anbelangt, das von jedem dieser Containerprozesse verwendet wird, verwendet Docker nionFS - unterstützte Bilder. Dies wird heruntergeladen, wenn Sie einen docker pull ubuntu ausführen. Jedes "Bild" ist nur eine Reihe von Ebenen und zugehörigen Metadaten. Das Konzept der Schichtung ist hier sehr wichtig. Jede Ebene ist nur eine Änderung gegenüber der darunter liegenden Ebene. Wenn Sie beispielsweise eine Datei in Ihrer Docker-Datei löschen, während Sie einen Docker-Container erstellen, erstellen Sie lediglich eine Ebene über der letzten Ebene mit der Meldung "Diese Datei wurde gelöscht". Dies ist übrigens der Grund, warum Sie eine große Datei aus Ihrem Dateisystem löschen können, das Image jedoch immer noch den gleichen Speicherplatz beansprucht. Die Datei befindet sich immer noch in den Ebenen unter der aktuellen. Ebenen selbst sind nur Tarballs von Dateien. Sie können dies mit docker save --output /tmp/ubuntu.tar ubuntu und dann cd /tmp && tar xvf ubuntu.tar testen. Dann können Sie sich umschauen. Alle diese Verzeichnisse, die wie lange Hashes aussehen, sind eigentlich die einzelnen Ebenen. Jedes enthält Dateien (layer.tar) und Metadaten (json) mit Informationen zu dieser bestimmten Ebene. Diese Ebenen beschreiben lediglich Änderungen am Dateisystem, die als Ebene "über" ihrem ursprünglichen Zustand gespeichert werden. Beim Lesen der "aktuellen" Daten liest das Dateisystem die Daten so, als würden nur die obersten Ebenen der Änderungen betrachtet. Aus diesem Grund scheint die Datei gelöscht zu sein, obwohl sie noch in "vorherigen" Ebenen vorhanden ist, da das Dateisystem nur die obersten Ebenen betrachtet. Auf diese Weise können völlig unterschiedliche Container ihre Dateisystemebenen gemeinsam nutzen, obwohl möglicherweise einige wesentliche Änderungen am Dateisystem auf den obersten Ebenen in jedem Container vorgenommen wurden. Dadurch können Sie eine Menge Speicherplatz sparen, wenn Ihre Container ihre Basis-Image-Ebenen gemeinsam nutzen. Wenn Sie jedoch Verzeichnisse und Dateien vom Host-System über Volumes in Ihren Container laden, umgehen diese Volumes das UnionFS, sodass Änderungen nicht in Ebenen gespeichert werden.

Das Netzwerk in Docker wird mithilfe einer Ethernet-Bridge (auf dem Host docker0 genannt) und virtueller Schnittstellen für jeden Container auf dem Host hergestellt. Es erstellt ein virtuelles Subnetz in docker0, in dem Ihre Container "untereinander" kommunizieren. Hier gibt es viele Netzwerkoptionen, einschließlich der Erstellung benutzerdefinierter Subnetze für Ihre Container und der Möglichkeit, den Netzwerkstapel Ihres Hosts für den direkten Zugriff auf Ihren Container freizugeben.

Docker bewegt sich sehr schnell. Seine Dokumentation ist eine der besten Dokumentationen, die ich je gesehen habe. Es ist im Allgemeinen gut geschrieben, präzise und genau. Ich empfehle Ihnen, die verfügbare Dokumentation zu prüfen, um weitere Informationen zu erhalten, und vertrauen Sie der Dokumentation über alles, was Sie online lesen, einschließlich Stapelüberlauf. Wenn Sie spezielle Fragen haben, empfehle ich dringend, #docker bei Freenode IRC beizutreten und dort zu fragen (dafür können Sie sogar Freenodes Webchat verwenden!).

121
L0j1k

Docker kapselt eine Anwendung mit all ihren Abhängigkeiten.

Ein Virtualizer kapselt ein Betriebssystem, das alle Anwendungen ausführen kann, die es normalerweise auf einer Bare-Metal-Maschine ausführen kann.

81

Sie sind beide sehr unterschiedlich. Docker ist leichtgewichtig und verwendet LXC/libcontainer (das sich auf Kernel-Namespace und cgroups stützt) und verfügt nicht über eine Computer-/Hardware-Emulation wie Hypervisor, KVM. Xen die schwer sind.

Docker und LXC sind eher für Sandboxing, Containerisierung und Ressourcenisolierung gedacht. Es verwendet die Clone-API des Host-Betriebssystems (derzeit nur Linux-Kernel), die Namespaces für IPC, NS (Mount), Netzwerk, PID, UTS usw. bereitstellt.

Was ist mit Speicher, E/A, CPU usw.? Dies wird mithilfe von Gruppen gesteuert, in denen Sie Gruppen mit bestimmten Ressourcen CPU, Speicher usw.) Spezifikationen/Einschränkungen erstellen und Ihre Prozesse dort ablegen können. Docker bietet zusätzlich zu LXC ein Speicher-Backend (--- (http://www.projectatomic.io/docs/filesystems/ ), z. B. ein Union-Mount-Dateisystem, in dem Sie Layer hinzufügen und Layer für verschiedene Mount-Namespaces freigeben können .

Dies ist eine leistungsstarke Funktion, bei der die Basisimages normalerweise schreibgeschützt sind. Nur wenn der Container etwas in der Ebene ändert, schreibt er etwas in eine Lese-Schreib-Partition (Kopie bei Schreibzugriff). Es bietet auch viele andere Wrapper wie Registrierung und Versionierung von Bildern.

Bei normalem LXC müssen Sie einige Rootfs mitbringen oder die Rootfs freigeben, und wenn sie freigegeben sind, werden die Änderungen auf andere Container übertragen. Aufgrund vieler dieser zusätzlichen Funktionen ist Docker beliebter als LXC. LXC ist in Embedded-Umgebungen beliebt, um Sicherheit für Prozesse zu implementieren, die externen Entitäten wie Netzwerk und Benutzeroberfläche ausgesetzt sind. Docker ist in Cloud-Umgebungen mit mehreren Mandanten beliebt, in denen eine konsistente Produktionsumgebung erwartet wird.

Ein normales VM (z. B. VirtualBox und VMware) verwendet einen Hypervisor, und verwandte Technologien verfügen entweder über eine dedizierte Firmware, die als erste Schicht für das erste Betriebssystem (Host-Betriebssystem oder Gast-Betriebssystem 0) fungiert, oder über eine entsprechende Software Läuft auf dem Host-Betriebssystem, um den Gastbetriebssystemen Hardware-Emulationen wie CPU, USB/Zubehör, Speicher, Netzwerk usw. bereitzustellen. VMs sind (ab 2015) in Umgebungen mit mehreren Mandanten und hoher Sicherheit immer noch beliebt.

Docker/LXC kann fast auf jeder billigen Hardware ausgeführt werden (weniger als 1 GB Arbeitsspeicher sind auch in Ordnung, solange Sie einen neueren Kernel haben). Normale VMs benötigen mindestens 2 GB Arbeitsspeicher usw., um irgendetwas Sinnvolles damit zu tun . Die Docker-Unterstützung auf dem Host-Betriebssystem ist jedoch in Betriebssystemen wie Windows (Stand: November 2014) nicht verfügbar, in denen VM-Typen unter Windows, Linux und Mac ausgeführt werden können.

Hier ist ein Bild von docker/rightscale: Here is a pic from rightscale

57
resultsway

1. Leichtgewicht

Dies ist wahrscheinlich der erste Eindruck für viele Hafenarbeiter.

Erstens sind Docker-Images in der Regel kleiner als VM Images. Dies erleichtert das Erstellen, Kopieren und Freigeben.

Zweitens können Docker-Container in einigen Millisekunden starten, während VM in Sekunden startet.

2. Layered File System

Dies ist eine weitere wichtige Funktion von Docker. Bilder haben Ebenen, und verschiedene Bilder können Ebenen gemeinsam nutzen, wodurch sie noch platzsparender und schneller zu erstellen sind.

Wenn alle Container Ubuntu als Basis-Images verwenden, verfügt nicht jedes Image über ein eigenes Dateisystem, sondern teilt die gleichen Ubuntu-Unterstreichungsdateien und unterscheidet sich nur in den eigenen Anwendungsdaten.

3. Shared OS Kernel

Stellen Sie sich Container als Prozesse vor!

Alle Container, die auf einem Host ausgeführt werden, sind in der Tat eine Reihe von Prozessen mit unterschiedlichen Dateisystemen. Sie haben den gleichen Betriebssystemkernel und kapseln nur die Systembibliothek und Abhängigkeiten.

Dies ist in den meisten Fällen gut (kein zusätzlicher Betriebssystemkern wird gewartet), kann jedoch ein Problem darstellen, wenn strenge Isolierungen zwischen Containern erforderlich sind.

Warum es wichtig ist?

All dies scheint eine Verbesserung zu sein, keine Revolution. Nun, quantitative Akkumulation führt zu einer qualitativen Transformation .

Denken Sie an die Anwendungsbereitstellung. Wenn wir eine neue Software (einen neuen Dienst) bereitstellen oder eine aktualisieren möchten, ist es besser, die Konfigurationsdateien und -prozesse zu ändern, anstatt eine neue VM zu erstellen. Da das Erstellen eines VM mit einem aktualisierten Dienst zum Testen (Freigabe zwischen Entwickler und Qualitätssicherung) für die Bereitstellung in der Produktion Stunden und sogar Tage in Anspruch nimmt. Wenn etwas schief geht, müssen Sie von vorne anfangen und noch mehr Zeit verschwenden. Verwenden Sie also das Konfigurationsmanagement-Tool (Marionette, Saltstack, Koch usw.), um neue Software zu installieren. Laden Sie neue Dateien herunter.

Wenn es um Docker geht, ist es unmöglich, einen neu erstellten Docker-Container zu verwenden, um den alten zu ersetzen. Die Wartung ist viel einfacher: Erstellen Sie ein neues Image, geben Sie es für die Qualitätssicherung frei, testen Sie es, und die Bereitstellung dauert nur Minuten (wenn alles automatisiert ist), im schlimmsten Fall Stunden. Dies nennt man nveränderliche Infrastruktur: Keine Software warten (aktualisieren), sondern eine neue erstellen.

Es verändert die Art und Weise, wie Dienstleistungen erbracht werden. Wir wollen Anwendungen, müssen aber VMs warten (was sehr mühsam ist und wenig mit unseren Anwendungen zu tun hat). Mit Docker können Sie sich auf Anwendungen konzentrieren und alles glätten.

31
cizixs

Docker, im Grunde genommen Container, unterstützt die Betriebssystemvirtualisierung , dh Ihre Anwendung hat das Gefühl, eine vollständige Instanz eines Betriebssystems zu haben, während VM Hardware unterstützt Virtualisierung . Sie haben das Gefühl, dass es sich um eine physische Maschine handelt, auf der Sie jedes Betriebssystem starten können.

In Docker teilen sich die ausgeführten Container den Kernel des Host-Betriebssystems, während sie in VMs ihre eigenen Betriebssystemdateien haben. Die Umgebung (das Betriebssystem), in der Sie eine Anwendung entwickeln, ist identisch, wenn Sie sie in verschiedenen Serving-Umgebungen wie "Testen" oder "Produktion" bereitstellen.

Wenn Sie beispielsweise einen Webserver entwickeln, der auf Port 4000 ausgeführt wird, wird dieser Port beim Bereitstellen in Ihrer "Test" -Umgebung bereits von einem anderen Programm verwendet, sodass er nicht mehr funktioniert. In Behältern gibt es Schichten; Alle Änderungen, die Sie am Betriebssystem vorgenommen haben, werden in einer oder mehreren Ebenen gespeichert und diese Ebenen sind Teil des Abbilds. Wo immer sich das Abbild befindet, sind auch die Abhängigkeiten vorhanden.

In dem unten gezeigten Beispiel verfügt der Host-Computer über drei VMs. Damit die Anwendungen in den VMs vollständig isoliert sind, verfügen sie jeweils über eigene Kopien der Betriebssystemdateien, Bibliotheken und des Anwendungscodes sowie über eine vollständige speicherinterne Instanz eines Betriebssystems. Without Containers Die folgende Abbildung zeigt dasselbe Szenario mit Containern. In diesem Fall teilen sich Container einfach das Host-Betriebssystem, einschließlich des Kernels und der Bibliotheken, sodass sie kein Betriebssystem starten, Bibliotheken laden oder die Kosten für den privaten Speicher für diese Dateien bezahlen müssen. Der einzige inkrementelle Speicherplatz, den sie in Anspruch nehmen, ist der Speicher und der Festplattenspeicher, die für die Ausführung der Anwendung im Container erforderlich sind. Während sich die Umgebung der Anwendung wie ein dediziertes Betriebssystem anfühlt, wird die Anwendung genau wie auf einem dedizierten Host bereitgestellt. Die containerisierte Anwendung startet in Sekunden und es können viel mehr Instanzen der Anwendung auf den Computer passen als im Fall VM. enter image description here

Quelle: https://Azure.Microsoft.com/en-us/blog/containers-docker-windows-and-trends/

24
Ali Kahoot

Es gibt drei verschiedene Setups, die einen Stack zum Ausführen einer Anwendung bereitstellen (dies hilft uns zu erkennen, was ein Container ist und was ihn so leistungsfähig macht als andere Lösungen):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) traditioneller Server Der Stack besteht aus einem physischen Server, auf dem ein Betriebssystem und Ihre Anwendung ausgeführt werden.

Vorteile:

  • Nutzung von Rohstoffen

  • Isolierung

Nachteile:

  • Sehr langsame Bereitstellungszeit
  • Teuer
  • Verschwendete Ressourcen
  • Schwer zu skalieren
  • Schwer zu migrieren
  • Komplexe Konfiguration

2) Der VM-Stapel besteht aus einem physischen Server, auf dem ein Betriebssystem ausgeführt wird, und einem Hypervisor, der die virtuelle Maschine, die freigegebenen Ressourcen und die Netzwerkschnittstelle verwaltet. Auf jedem VM wird ein Gastbetriebssystem, eine Anwendung oder eine Reihe von Anwendungen ausgeführt.

Vorteile:

  • Gute Ressourcennutzung
  • Einfach zu skalieren
  • Einfach zu sichern und zu migrieren
  • Kosteneffizienz
  • Flexibilität

Nachteile:

  • Die Ressourcenzuweisung ist problematisch
  • Anbietersperrung
  • Komplexe Konfiguration

3) Das Container-Setup, der Hauptunterschied zu anderen Stacks ist, dass die container-basierte Virtualisierung den Kernel des Host-Betriebssystems verwendet, um mehrere isolierte Gastinstanzen zu durchsuchen. Diese Gastinstanzen werden als Container bezeichnet. Der Host kann entweder ein physischer Server oder eine virtuelle Maschine sein.

Vorteile:

  • Isolierung
  • Leicht
  • Ressource effektiv
  • Einfach zu migrieren
  • Sicherheit
  • Geringer Overhead
  • Spiegel Produktions- und Entwicklungsumgebung

Nachteile:

  • Gleiche Architektur
  • Ressourcenlastige Apps
  • Netzwerk- und Sicherheitsprobleme.

Durch den Vergleich des Container-Setups mit seinen Vorgängern können wir den Schluss ziehen, dass die Containerisierung das schnellste, ressourceneffizienteste und sicherste Setup ist, das wir bisher kennen. Container sind isolierte Instanzen, die Ihre Anwendung ausführen. Docker drehen den Container in gewisser Weise auf, Ebenen erhalten Laufzeitspeicher mit Standardspeichertreibern (Overlay-Treibern), die innerhalb von Sekunden ausgeführt werden, und eine Kopie-beim-Schreiben-Ebene, die darüber erstellt wird, sobald wir den Container übergeben.) treibt die Ausführung von Containern an. Bei VMs dauert es ungefähr eine Minute, bis alles in die Virtualisierungsumgebung geladen ist. Diese kompakten Instanzen können problemlos ersetzt, neu erstellt und verschoben werden. Dies ermöglicht es uns, die Produktions- und Entwicklungsumgebung widerzuspiegeln und ist eine enorme Hilfe bei CI/CD-Prozessen. Die Vorteile, die Container bieten können, sind so überzeugend, dass sie definitiv hier bleiben werden.

20
mohan08p

Es gibt viele Antworten, die die Unterschiede näher erläutern, aber hier ist meine kurze Erklärung.

Ein wichtiger Unterschied ist, dass VMs einen separaten Kernel zum Ausführen des Betriebssystems verwenden . Das ist der Grund, warum es schwer ist und Zeit zum Booten benötigt, wodurch mehr Systemressourcen verbraucht werden.

In Docker teilen sich die Container den Kernel mit dem Host. Daher ist es leicht und kann schnell starten und stoppen.

In der Virtualisierung werden die Ressourcen zu Beginn der Einrichtung zugewiesen, und daher werden die Ressourcen nicht vollständig genutzt, wenn die virtuelle Maschine häufig im Leerlauf ist. In Docker wird den Containern keine feste Menge an Hardwareressourcen zugewiesen. Sie können die Ressourcen je nach Anforderungen frei verwenden und sind daher hoch skalierbar.

Docker verwendet UNION-Dateisystem . Docker verwendet eine Copy-on-Write-Technologie, um den von Containern belegten Speicherplatz zu reduzieren. Lesen Sie hier mehr

17
Jayabalan Bala

Im Verhältnis zu:-

"Warum ist die Bereitstellung von Software auf einem Docker-Image einfacher als die einfache Bereitstellung in einer konsistenten Produktionsumgebung?"

Die meiste Software wird in vielen Umgebungen bereitgestellt, normalerweise in mindestens drei der folgenden Umgebungen:

  1. Einzelne Entwickler-PCs
  2. Gemeinsame Entwicklerumgebung
  3. Einzelne Tester-PCs
  4. Geteilte Testumgebung
  5. QA-Umgebung
  6. UAT-Umgebung
  7. Last-/Leistungstests
  8. Live-Inszenierung
  9. Produktion
  10. Archiv

Folgende Faktoren sind ebenfalls zu berücksichtigen:

  • Entwickler und in der Tat Tester werden je nach Art des Auftrags entweder subtile oder sehr unterschiedliche PC-Konfigurationen haben
  • Entwickler können sich häufig auf PCs entwickeln, die sich der Kontrolle von Unternehmens- oder Geschäftsstandardisierungsregeln entziehen (z. B. Freiberufler, die sich auf ihren eigenen Computern entwickeln (häufig remote), oder Mitwirkende an Open-Source-Projekten, die für die Konfiguration ihrer PCs nicht „angestellt“ oder „beauftragt“ sind Weg)
  • Einige Umgebungen bestehen aus einer festen Anzahl von mehreren Computern in einer Konfiguration mit Lastenausgleich
  • In vielen Produktionsumgebungen werden cloudbasierte Server je nach Verkehrsaufkommen dynamisch (oder "elastisch") erstellt und zerstört

Wie Sie sehen, ist die extrapolierte Gesamtzahl der Server für eine Organisation selten in einzelnen Zahlen angegeben, liegt sehr häufig in dreifachen Zahlen und kann leicht noch erheblich höher sein.

Dies alles bedeutet, dass die Schaffung konsistenter Umgebungen an erster Stelle schon aufgrund des enormen Volumens (selbst in einem Szenario auf der grünen Wiese) schwierig genug ist, aber es ist so gut wie unmöglich, sie konsistent zu halten angesichts der hohen Anzahl von Servern, Hinzufügen neuer Server (dynamisch oder manuell), automatische Updates von Anbietern von Betriebssystemen, Antiviren-Anbietern, Browser-Anbietern und dergleichen, manuelle Softwareinstallationen oder Konfigurationsänderungen durch Entwickler oder Servertechniker usw. Lassen Sie mich das wiederholen Es ist praktisch (kein Wortspiel beabsichtigt) unmöglich, Umgebungen konsistent zu halten (okay, für Puristen ist dies möglich, aber es erfordert viel Zeit, Mühe und Disziplin, weshalb VMs und Container (z. B. Docker) entwickelt wurden der erste Ort).

Stellen Sie sich Ihre Frage also wie folgt vor: "Ist es angesichts der extremen Schwierigkeit, alle Umgebungen konsistent zu halten, einfacher, Software auf einem Docker-Image bereitzustellen, selbst wenn die Lernkurve berücksichtigt wird?" . Ich denke, Sie werden feststellen, dass die Antwort immer "Ja" lautet - aber es gibt nur einen Weg, dies herauszufinden: Stellen Sie diese neue Frage auf Stack Overflow.

17
Greg Trevellick

Bei einer virtuellen Maschine haben wir einen Server, wir haben ein Host-Betriebssystem auf diesem Server und wir haben dann einen Hypervisor. Auf diesem Hypervisor laufen dann beliebig viele Gastbetriebssysteme mit einer Anwendung und ihren abhängigen Binärdateien sowie Bibliotheken auf diesem Server. Es bringt ein ganzes Gastbetriebssystem mit. Es ist ziemlich schwer. Es gibt auch eine Grenze, wie viel Sie tatsächlich auf jede physische Maschine setzen können.

Enter image description here

Docker-Container sind dagegen etwas anders. Wir haben den Server. Wir haben das Host-Betriebssystem. Aber statt eines Hypervisors haben wir in diesem Fall die Docker-Engine . In diesem Fall bringen wir kein gesamtes Gastbetriebssystem mit. Wir bringen eine sehr dünne Schicht des Betriebssystems mit , und der Container kann in das Host-Betriebssystem herunterreden, um dort auf die Kernelfunktionalität zuzugreifen . Und das ermöglicht es uns, einen sehr leichten Container zu haben.

Alles, was darin enthalten ist, ist der Anwendungscode und alle erforderlichen Binärdateien und Bibliotheken. Und diese Binärdateien und Bibliotheken können tatsächlich für verschiedene Container freigegeben werden, wenn Sie dies auch möchten. Und das ermöglicht uns eine Reihe von Dingen. Sie haben viel schnellere Startzeiten . Sie können nicht ein einziges VM in ein paar Sekunden so aufstehen. Und genauso, wenn wir sie so schnell reduzieren ... damit wir sehr schnell hoch- und runterskalieren können und wir uns das später ansehen werden.

Enter image description here

Jeder Container denkt, dass er auf einer eigenen Kopie des Betriebssystems ausgeführt wird. Es hat ein eigenes Dateisystem, eine eigene Registrierung usw., was eine Art Lüge ist. Es wird tatsächlich virtualisiert.

14
Nedzad G

Ich habe Docker in Produktionsumgebungen und in der Inszenierung sehr oft verwendet. Wenn Sie sich daran gewöhnen, werden Sie feststellen, dass es sehr leistungsfähig ist, um mehrere Container und isolierte Umgebungen zu erstellen.

Docker wurde auf Basis von LXC (Linux Container) entwickelt und funktioniert perfekt in vielen Linux-Distributionen, insbesondere in Ubuntu.

Docker-Container sind isolierte Umgebungen. Sie sehen es, wenn Sie den Befehl top in einem Docker-Container absetzen, der aus einem Docker-Image erstellt wurde.

Außerdem sind sie dank der dockerFile-Konfiguration sehr leicht und flexibel.

Zum Beispiel können Sie ein Docker-Image erstellen und eine Docker-Datei konfigurieren und sagen, dass Sie zum Beispiel, wenn sie ausgeführt wird, 'this', apt-get 'that', 'some Shell script' ausführen, Umgebungsvariablen setzen und so weiter.

In Micro-Services-Projekten und -Architekturen ist Docker eine sehr nützliche Ressource. Mit Docker, Docker Swarm, Kubernetes und Docker Compose erreichen Sie Skalierbarkeit, Ausfallsicherheit und Elastizität.

Ein weiteres wichtiges Thema in Bezug auf Docker ist Docker Hub und seine Community. Ich habe zum Beispiel ein Ökosystem zur Überwachung von kafka mit Prometheus, Grafana, Prometheus-JMX-Exporter und Dokcer implementiert.

Dafür habe ich konfigurierte Docker-Container für zookeeper, kafka, Prometheus, Grafana und jmx-collector heruntergeladen und dann meine eigene Konfiguration für einige von ihnen mit yml-Dateien gemountet oder für andere habe ich einige Dateien und Konfigurationen im Docker-Container geändert und ein Ganzes erstellt System zur Überwachung von kafka mithilfe von Dockern mit mehreren Containern auf einem einzelnen Computer mit Isolierung, Skalierbarkeit und Ausfallsicherheit, sodass diese Architektur problemlos auf mehrere Server verschoben werden kann.

Neben der Docker Hub-Site gibt es eine weitere Site mit dem Namen quay.io, auf der Sie Ihr eigenes Docker-Image-Dashboard erstellen und es öffnen/schließen können. Sie können Docker-Images sogar von Docker Hub in den Quay importieren und sie dann vom Quay auf Ihrem eigenen Computer ausführen.

Hinweis: Das Erlernen von Docker erscheint zunächst komplex und schwierig, aber wenn Sie sich daran gewöhnen, können Sie nicht ohne Docker arbeiten.

Ich erinnere mich an die ersten Tage mit Docker, als ich aus Versehen die falschen Befehle ausgegeben oder meine Container sowie alle Daten und Konfigurationen entfernt habe.

9
Touraj Ebrahimi

Difference between how apps in VM use cpu vs containers

Quelle: Kubernetes in Aktion.

9
TastyCode

So stellt sich Docker vor:

Docker ist das Unternehmen, das die Containerbewegung vorantreibt, und der einzige Anbieter von Containerplattformen, der jede Anwendung in der Hybrid-Cloud adressiert. Heutzutage stehen Unternehmen unter dem Druck, sich digital zu verändern, werden jedoch durch vorhandene Anwendungen und Infrastrukturen eingeschränkt, während ein immer breiteres Portfolio von Clouds, Rechenzentren und Anwendungsarchitekturen rationalisiert wird. Docker ermöglicht eine echte Unabhängigkeit zwischen Anwendungen und Infrastruktur sowie Entwicklern und IT-Abteilungen, um deren Potenzial auszuschöpfen, und schafft ein Modell für eine bessere Zusammenarbeit und Innovation.

Docker basiert auf Containern, dh Sie haben Bilder und Container, die auf Ihrem aktuellen Computer ausgeführt werden können. Es enthält nicht das Betriebssystem wie VM s, sondern ein Paket mit verschiedenen Arbeitspaketen wie Java, Tomcat usw.

Wenn Sie Container verstehen, wissen Sie, was Docker ist und wie es sich von VM s unterscheidet ...

Also, was ist ein Container?

Ein Container-Image ist ein kompaktes, eigenständiges, ausführbares Paket einer Software, das alles enthält, was zum Ausführen erforderlich ist: Code, Laufzeit, Systemtools, Systembibliotheken und Einstellungen. Container-Software, die sowohl für Linux- als auch für Windows-basierte Apps verfügbar ist, wird unabhängig von der Umgebung immer gleich ausgeführt. Container isolieren Software von der Umgebung, z. B. Unterschiede zwischen Entwicklungs- und Staging-Umgebungen, und reduzieren Konflikte zwischen Teams, die unterschiedliche Software auf derselben Infrastruktur ausführen.

Docker

Wie Sie in der Abbildung unten sehen können, hat jeder Container eine separate Packung und läuft auf einer einzelnen Maschine, die das Betriebssystem dieser Maschine gemeinsam nutzt. Sie sind sicher und einfach zu versenden.

6
Alireza

Hier gibt es eine Menge technischer Antworten von Nice, die die Unterschiede zwischen VMs und Containern sowie die Ursprünge von Docker klar erläutern.

Für mich besteht der grundlegende Unterschied zwischen VMs und Docker darin, wie Sie die Bewerbung Ihrer Anwendung verwalten.

Mit VMs fördern Sie Ihre Anwendung und ihre Abhängigkeiten von einer VM zur nächsten DEV zu UAT zu PRD.

  1. Oft haben diese VMs unterschiedliche Patches und Bibliotheken.
  2. Es ist nicht ungewöhnlich, dass mehrere Anwendungen eine VM gemeinsam nutzen. Dies erfordert die Verwaltung der Konfiguration und Abhängigkeiten für alle Anwendungen.
  3. Für das Zurücksetzen müssen Änderungen an der VM rückgängig gemacht werden. Oder wenn möglich wiederherstellen.

Bei Docker besteht die Idee darin, dass Sie Ihre Anwendung zusammen mit den benötigten Bibliotheken in einem eigenen Container bündeln und dann den Container whole als einzelne Einheit hochstufen.

  1. Mit Ausnahme des Kernels sind die Patches und Bibliotheken identisch.
  2. In der Regel gibt es nur eine Anwendung pro Container, was die Konfiguration vereinfacht.
  3. Backout besteht aus dem Stoppen und Löschen des Containers.

Auf der grundlegendsten Ebene bewerben Sie mit VMs die Anwendung und ihre Abhängigkeiten als diskrete Komponenten, während Sie mit Docker alles mit einem Schlag bewerben.

Und ja, es gibt Probleme mit Containern, einschließlich deren Verwaltung, obwohl Tools wie Kubernetes oder Docker Swarm die Aufgabe erheblich vereinfachen.

4
TJA