Wie unterscheidet sich Docker von einer virtuellen Maschine?

Ich lese die Docker-Dokumentation immer wieder durch , 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 auf einem Docker-Image (wenn dies der richtige Begriff ist) einfacher als die Bereitstellung in einer konsistenten Produktionsumgebung?

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

AuFS ist ein mehrschichtiges 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 Ihren Containern gemeinsam nutzen) und dann jedem Container seine eigene Halterung 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 Anzahl der gewünschten VMs. Mit Docker und AuFS können Sie den Großteil der 1 GB auf alle Container verteilen. Wenn Sie 1000 Container haben, haben Sie möglicherweise immer noch etwas mehr als 1 GB Speicherplatz für das Container-Betriebssystem (vorausgesetzt, auf allen wird dasselbe Betriebssystem-Image ausgeführt). .

Einem vollständig virtualisierten System werden eigene Ressourcen zugewiesen, und es wird nur minimal freigegeben. Sie erhalten mehr Isolation, aber es ist viel schwerer (erfordert mehr Ressourcen). Mit Docker erhalten Sie weniger Isolation, aber die Container sind leicht (erfordern weniger Ressourcen). Sie können also problemlos Tausende von Containern auf einem Host ausführen, und es blinkt nicht einmal. Versuchen Sie das mit Xen, und wenn Sie keinen wirklich großen Host haben, denke ich nicht, dass dies möglich ist.

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

Für jeden Typ eines virtualisierten Systems gibt es Vor- und Nachteile. Wenn Sie eine vollständige Isolation mit garantierten Ressourcen wünschen, ist eine vollständige VM der richtige Weg. Wenn Sie nur Prozesse voneinander isolieren und eine Menge davon auf einem Host mit angemessener Größe ausführen möchten, ist Docker / LXC / runC der richtige Weg.

Weitere Informationen finden Sie in diesen Blog-Posts, in denen die Funktionsweise von LXC gut erklärt wird.

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

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

Mit Docker können Sie das Betriebssystem in ein freigegebenes Image einbinden und die Bereitstellung auf anderen Docker-Hosts vereinfachen. Vor Ort, dev, qa, prod usw.: Alle das gleiche Bild. Sicher können Sie dies mit anderen Werkzeugen tun, aber bei weitem nicht so einfach oder schnell.

Dies ist ideal zum Testen; Angenommen, 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 zeitaufwändig 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 gleichzeitig auf derselben Box ausgeführt werden und sollten viel schneller abgeschlossen sein. Versuchen Sie dies mit einer vollständigen VM.

Aus Kommentaren ...

Interessant! Ich nehme an, ich bin immer noch verwirrt von dem Begriff "Snapshot [ting] the OS". Wie macht man das, ohne sich ein Bild vom Betriebssystem zu machen?

Mal sehen, ob ich es erklären kann. Sie beginnen mit einem Basis-Image, nehmen dann Ihre Änderungen vor und übernehmen diese Änderungen mit Docker. 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, die Ihr Image mithilfe eines mehrschichtigen Dateisystems über die Basis legt: 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 normalerweise auf vorgefertigten Images aus einer Registrierung aufbaut , müssen Sie selten das gesamte Betriebssystem selbst "schnappen".

Gute Antworten. Schauen Sie sich die folgende Abbildung an, um eine Bilddarstellung von Container und VM zu erhalten.

Quelle

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

Hinweis: Ich vereinfache die Beschreibung unten ein wenig. Weitere Informationen finden Sie in den Referenzen.

Wie funktioniert 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 über eine eigene Hardware verfügt. Unterhaltsame Tatsache: Vor 1998 wurde es für unmöglich gehalten, 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 besteht darin, 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, des Ladens des Kernels usw. Sie können sehr strenge Sicherheitsvorkehrungen treffen. Beispielsweise kann das Gastbetriebssystem keinen vollständigen Zugriff auf das Hostbetriebssystem oder andere Gäste erhalten und die Dinge durcheinander bringen.

Wie funktionieren Container auf niedrigem Niveau?

Um 2006 herum implementierten Mitarbeiter, darunter einige Mitarbeiter von Google, eine neue Funktion auf Kernel-Ebene, die als Namespaces bezeichnet wurde (die Idee existierte jedoch schon lange zuvor 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ären, sodass sie nur für die Prozesse sichtbar sind, die im selben Namespace ausgeführt werden? Angenommen, Sie können einen Teil der Festplatte abrufen und in den Namespace X einfügen. Prozesse, die im Namespace Y ausgeführt werden, können ihn nicht sehen oder darauf zugreifen. In ähnlicher Weise können Prozesse in Namespace X auf nichts im Speicher zugreifen, das dem Namespace Y zugeordnet ist. Natürlich können Prozesse in X Prozesse im Namespace Y nicht sehen oder mit ihnen 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 denselbenKernel wie alle anderen Container. Die Isolierung 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 diese denselben Kernel verwenden. Die Isolationsstufe ist nicht so stark wie bei VM. Tatsächlich gab es eine Möglichkeit für "Gast" -Container, den Host in frühen Implementierungen zu übernehmen. Sie können auch sehen, dass beim Laden eines neuen Containers nicht die gesamte neue Kopie des Betriebssystems wie in VM gestartet wird. Alle Container teilen sich den gleichen Kernel. Deshalb sind Behälter leicht. Im Gegensatz zu VM müssen Sie Containern keinen signifikanten Speicherbereich 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.

Ich mag Ken Cochranes Antwort.

Aber ich möchte einen zusätzlichen Gesichtspunkt hinzufügen, der hier nicht im Detail behandelt wird. Meiner Meinung nach unterscheidet sich Docker auch im gesamten Prozess. Im Gegensatz zu VMs geht es bei Docker nicht (nur) um die optimale gemeinsame Nutzung von Hardware, sondern um ein "System" zum Packen von Anwendungen (vorzuziehen, aber kein Muss als Satz von Microservices).

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

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

Ihre Frage setzt eine konsistente Produktionsumgebung voraus. Aber wie kann man es konsistent halten? Berücksichtigen Sie eine bestimmte Anzahl (> 10) von Servern und Anwendungen, Phasen in der Pipeline.

Um dies synchron zu halten, verwenden Sie beispielsweise Puppet, Chef oder Ihre eigenen Bereitstellungsskripte, unveröffentlichte Regeln und / oder viele Dokumentationen. Theoretisch können Server unbegrenzt ausgeführt werden und sind vollständig konsistent und auf dem neuesten Stand. In der Praxis wird die Konfiguration eines Servers nicht vollständig verwaltet, sodass ein erheblicher Spielraum für Konfigurationsabweichungen und unerwartete Änderungen an laufenden Servern besteht.

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

Mit einem Docker-Ökosystem müssen Sie sich bei "kleinen Änderungen" (danke aufs und Registry) nie um Gigabyte bewegen, und Sie müssen sich keine Sorgen über Leistungseinbußen machen, 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 oft komplexe Produktionsumgebungen auch 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 die Serverbereitstellung auf VM-Ebene. Alle oben genannten Funktionen können von Docker verwaltet werden.

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

Docker ist keine Virtualisierungsmethode. Es basiert auf anderen Tools, die tatsächlich containergestützte Virtualisierung oder Virtualisierung auf Betriebssystemebene implementieren. Zu diesem Zweck verwendete Docker zunächst 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 dienen zum Packen und Ausführen eines einzelnen Dienstes, während Systemcontainer zum Ausführen mehrerer Prozesse wie virtuelle Maschinen ausgelegt sind. Daher wird Docker als Containerverwaltungs- oder Anwendungsbereitstellungstool auf containerisierten Systemen betrachtet.

Um zu wissen, wie es sich von anderen Virtualisierungen unterscheidet, gehen wir die Virtualisierung und ihre Typen durch. Dann wäre es einfacher zu verstehen, was dort den Unterschied ausmacht.

Virtualisierung

In seiner konzipierten Form wurde es als Methode zur logischen Aufteilung von Mainframes angesehen, 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 zum Behandeln 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 verwaltet die virtuelle Umgebung, in der die virtuellen Gastmaschinen ausgeführt werden. Es überwacht die Gastsysteme und stellt sicher, dass den Gästen bei Bedarf Ressourcen zugewiesen werden. Der Hypervisor befindet sich zwischen der physischen Maschine und den virtuellen Maschinen und stellt den virtuellen Maschinen Virtualisierungsdienste zur Verfügung. Um dies zu realisieren, fängt es die Operationen des Gastbetriebssystems auf den virtuellen Maschinen ab und emuliert die Operation auf dem Betriebssystem der Hostmaschine.

Die rasche Entwicklung von Virtualisierungstechnologien, hauptsächlich in der Cloud, hat die Verwendung der Virtualisierung weiter vorangetrieben, indem mithilfe von Hypervisoren wie Xen, VMware Player, KVM usw. 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 Hardware für ein Gastbetriebssystem nachahmt und eine Gastbetriebsumgebung emuliert. In erster Linie gibt es drei Arten der Virtualisierung:

• Emulation
• Paravirtualisierung
• Containerbasierte 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 ist als Typ 2-Hypervisor bekannt. Es wird oben 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 keine Hardware-Beteiligung. Die Emulation ermöglicht die Ausführung jedes nicht geänderten Betriebssystems, das die zu emulierende Umgebung unterstützt. Der Nachteil dieser Art der Virtualisierung ist ein zusätzlicher Overhead an Systemressourcen, der zu einer Leistungsminderung im Vergleich zu anderen Arten von Virtualisierungen führt.

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

Paravirtualisierung

Die Paravirtualisierung, auch als Typ 1-Hypervisor bezeichnet, 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 normalerweise einen relativ geringen Platzbedarf und erfordern selbst keine umfangreichen Ressourcen.

Beispiele in dieser Kategorie sind Xen, KVM usw.

Containerbasierte Virtualisierung

Die containergestützte Virtualisierung, auch als Virtualisierung auf Betriebssystemebene bezeichnet, ermöglicht mehrere isolierte Ausführungen innerhalb eines einzelnen Betriebssystemkerns. Es bietet die bestmögliche Leistung und Dichte sowie ein dynamisches Ressourcenmanagement. Die isolierte virtuelle Ausführungsumgebung, die von dieser Art der Virtualisierung bereitgestellt wird, wird als Container bezeichnet und kann als verfolgte Gruppe von Prozessen angesehen werden.

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 zuvor globaler 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 teilen, 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 im Container nicht als Root außerhalb des Containers behandelt, was zusätzliche Sicherheit bietet.

Das Subsystem Linux Control Groups (cgroups), die nächste Hauptkomponente 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 ist, 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 starten, sodass Container in weniger als einer Sekunde erstellt werden können. Diese Funktion macht die containergestützte Virtualisierung einzigartig und wünschenswert 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 containergestützte Virtualisierung ist im Gegensatz zu anderen Virtualisierungen keine zusätzliche Software erforderlich.

Alle Container auf einem Hostcomputer teilen sich den Scheduler des Hostcomputers und sparen zusätzliche Ressourcen.

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. In Cgroups dürfen Container nicht mehr Ressourcen verbrauchen, als ihnen zugewiesen wurden. Ab sofort sind jedoch alle Ressourcen der Host-Maschine in virtuellen Maschinen sichtbar, können jedoch nicht verwendet werden. Dies kann durch gleichzeitiges Ausführen topoder htopauf Containern und Hostcomputern realisiert werden . Die Ausgabe in allen Umgebungen sieht ähnlich aus.

Aktualisieren:

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

Wenn Container aufgrund der im Linux-Kernel verfügbaren Funktionen möglich sind, ist die offensichtliche Frage, wie Nicht-Linux-Systeme Container ausführen. 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 jedoch Hyper-V unter Windows und Hypervisor.framework unter Mac.

Lassen Sie mich nun detailliert beschreiben, wie Docker für Mac Container 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 außerdem VPNKit und DataKit, um das Netzwerk bzw. das Dateisystem zu benennen.

Die Linux-VM, die Docker auf einem Mac ausführt, ist schreibgeschützt. Sie können jedoch darauf zugreifen, 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 macht Docker die docker0Netzwerkschnittstelle in Mac nicht verfügbar . Sie können also nicht vom Host aus auf Container zugreifen. Ist ab sofort docker0nur noch in der VM verfügbar.

Hyper-v ist der native Hypervisor in Windows. Sie versuchen auch, die Funktionen von Windows 10 zu nutzen, um Linux-Systeme nativ auszuführen.

In diesem Beitrag werden wir einige Unterschiede zwischen VMs und LXCs ziehen. 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 Virtualisierungsschicht verwaltet, die diese Anforderungen in die zugrunde liegende physische Hardware übersetzt.

In diesem Zusammenhang 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 Betriebssystemebene, mit denen mehrere isolierte Linux-Container auf einem Steuerungshost (dem LXC-Host) ausgeführt werden können. Linux-Container dienen als einfache Alternative zu VMs, 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 an der Linux-Containertechnologie ziemlich bewusst sein, und wenn ich einen bestimmten Container sein werde Das Projekt, das in den letzten Monaten weltweit für Aufsehen gesorgt hat, ist: - Docker führt zu einigen wiederholten Meinungen, dass Cloud-Computing-Umgebungen virtuelle Maschinen (VMs) aufgeben und aufgrund ihres geringeren Overheads und ihrer 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 Linux-Instanz beschränkt. Es kann sich um verschiedene Linux-Varianten handeln (z. B. einen Ubuntu-Container auf einem CentOS-Host, aber es ist immer noch Linux). In ähnlicher Weise sind Windows-basierte Container jetzt auf eine Windows-Instanz beschränkt, wenn wir uns VMs ansehen, die einen ziemlich breiteren Anwendungsbereich haben und die verwenden Hypervisoren Sie sind nicht auf Betriebssysteme Linux oder Windows beschränkt.

b. LXCs haben einen geringen Overhead und eine bessere Leistung als VMs. Tools nämlich. Docker, die auf den Schultern der LXC-Technologie basieren, haben Entwicklern eine Plattform zum Ausführen ihrer Anwendungen zur Verfügung gestellt und gleichzeitig den Mitarbeitern des Betriebs 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 Person, die diese Anwendung nahtlos bereitstellt, zu machen, da hier die gesamte Reibung liegt und der Zweck von DevOps darin besteht, diese Silos aufzubrechen.

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

Das Aufgeben von VMs ist derzeit nicht praktikabel. So haben sowohl VMs als auch LXCs ihre eigene individuelle Existenz und Bedeutung.

Die meisten Antworten 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 möchte Ihnen erklären, was Docker ist, um 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 bedeutet, wenn er "virtuelle Maschine" sagt. Damit...

Ein Docker-Container ist nur ein Prozess (und seine untergeordneten Elemente ), der mithilfe von cgroups im Kernel des Hostsystems von den übrigen Prozessen getrennt wird. Sie können Ihre Docker-Containerprozesse tatsächlich anzeigen, indem Sie sie ps auxauf dem Host ausführen. Zum Beispiel ist das Starten apache2"in einem Container" nur apache2ein spezieller Prozess auf dem Host. 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. Dies liegt daran, dass Docker pid 1in Ihrem Container durch Ihre Anwendung ersetzt wird ( pid 1normalerweise das Init-System). Dieser letzte Punkt pid 1ist sehr wichtig.

In Bezug auf das Dateisystem, das von jedem dieser Containerprozesse verwendet wird, verwendet Docker UnionFS- gestützte Images, die Sie herunterladen, wenn Sie a ausführen 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 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 tatsächlich nur eine Ebene über der letzten Ebene mit der Meldung "Diese Datei wurde gelöscht". Aus diesem Grund können Sie aus diesem Grund eine große Datei aus Ihrem Dateisystem löschen, aber das Image belegt immer noch den gleichen Speicherplatz. Die Datei befindet sich noch in den Ebenen unter der aktuellen. Ebenen selbst sind nur Tarballs von Dateien. Sie können dies mit testendocker save --output /tmp/ubuntu.tar ubuntuund dann cd /tmp && tar xvf ubuntu.tar. Dann können Sie sich umschauen. Alle diese Verzeichnisse, die wie lange Hashes aussehen, sind tatsächlich die einzelnen Ebenen. Jeder enthält Dateien ( layer.tar) und Metadaten (json) mit Informationen zu dieser bestimmten Schicht. 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ürde es nur die obersten Änderungsebenen betrachten. 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. Dies kann Ihnen eine Menge Speicherplatz sparen, wenn Ihre Container ihre Basis-Image-Ebenen gemeinsam nutzen. Jedoch,

Die Vernetzung in Docker erfolgt über eine Ethernet-Bridge ( docker0auf dem Host aufgerufen ) und virtuelle Schnittstellen für jeden Container auf dem Host. Es wird ein virtuelles Subnetz erstellt, in dem docker0Ihre Container "untereinander" kommunizieren können. Hier gibt es viele Optionen für die Vernetzung, einschließlich der Erstellung benutzerdefinierter Subnetze für Ihre Container und der Möglichkeit, den Netzwerkstapel Ihres Hosts für den direkten Zugriff Ihres Containers freizugeben.

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

Docker kapselt eine Anwendung mit all ihren Abhängigkeiten.

Ein Virtualizer kapselt ein Betriebssystem, das alle Anwendungen ausführen kann, die normalerweise auf einem Bare-Metal-Computer ausgeführt werden können.

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

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

Was ist mit Speicher, E / A, CPU usw.? Dies wird mithilfe von cgroups gesteuert, in denen Sie Gruppen mit bestimmten Ressourcenspezifikationen (CPU, Speicher usw.) erstellen und Ihre Prozesse dort ablegen können. Zusätzlich zu LXC bietet Docker ein Speicher-Backend ( http://www.projectatomic.io/docs/filesystems/ ), z. B. ein Union Mount-Dateisystem, in dem Sie Ebenen hinzufügen und Ebenen zwischen verschiedenen 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- / Schreibpartition (auch als Kopie beim Schreiben bezeichnet). Es bietet auch viele andere Wrapper wie die Registrierung und Versionierung von Bildern.

Bei normalem LXC müssen Sie einige Rootfs verwenden 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 eingebetteten 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.

Eine normale VM (z. B. VirtualBox und VMware) verwendet einen Hypervisor, und verwandte Technologien verfügen entweder über eine dedizierte Firmware, die die erste Schicht für das erste Betriebssystem (Host-Betriebssystem oder Gast-Betriebssystem 0) darstellt, oder über eine Software, die auf dem Host-Betriebssystem ausgeführt wird Stellen Sie den Gastbetriebssystemen Hardware-Emulationen wie CPU, USB / Zubehör, Speicher, Netzwerk usw. zur Verfügung. VMs sind (ab 2015) in Umgebungen mit mehreren Mandanten mit hoher Sicherheit immer noch beliebt.

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

Hier ist ein Bild von Docker / Rightscale:

1. Leichtgewicht

Dies ist wahrscheinlich der erste Eindruck für viele Docker-Lernende.

Erstens sind Docker-Images normalerweise kleiner als VM-Images, was das Erstellen, Kopieren und Freigeben erleichtert.

Zweitens können Docker-Container in mehreren Millisekunden gestartet werden, während VM in Sekunden gestartet wird.

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 erstellt werden können.

Wenn alle Container Ubuntu als Basisimages verwenden, verfügt nicht jedes Image über ein eigenes Dateisystem, sondern verwendet dieselben unterstrichenen Ubuntu-Dateien und unterscheidet sich nur in ihren 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 verwenden denselben Betriebssystemkern und kapseln nur die Systembibliothek und Abhängigkeiten.

Dies ist in den meisten Fällen gut (kein zusätzlicher Betriebssystemkern wird verwaltet), kann jedoch ein Problem sein, 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 qualitativer Transformation .

Denken Sie an die Anwendungsbereitstellung. Wenn Sie eine neue Software (einen neuen Dienst) bereitstellen oder eine aktualisieren möchten, ist es besser, die Konfigurationsdateien und -prozesse zu ändern, als eine neue VM zu erstellen. Da das Erstellen einer VM mit aktualisiertem Service, das Testen (Freigabe zwischen Entwickler und Qualitätssicherung) und die Bereitstellung in der Produktion Stunden oder sogar Tage dauern. Wenn etwas schief geht, müssen Sie erneut beginnen und noch mehr Zeit verschwenden. Verwenden Sie daher das Konfigurationsmanagement-Tool (Marionette, Saltstack, Koch usw.), um neue Software zu installieren. Das Herunterladen neuer Dateien wird bevorzugt.

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, teilen Sie es mit der Qualitätssicherung, testen Sie es. Die Bereitstellung dauert nur Minuten (wenn alles automatisiert ist), im schlimmsten Fall Stunden. Dies wird als unveränderliche Infrastruktur bezeichnet : Warten Sie keine Software (aktualisieren Sie sie), sondern erstellen Sie stattdessen eine neue.

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

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 die Hardwarevirtualisierung unterstützt . 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 dieselbe, wenn Sie sie in verschiedenen Bereitstellungsumgebungen wie "Testen" oder "Produktion" bereitstellen.

Wenn Sie beispielsweise einen Webserver entwickeln, der auf Port 4000 ausgeführt wird, wenn Sie ihn in Ihrer "Test" -Umgebung bereitstellen, wird dieser Port 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 Bilds. Überall dort, wo das Bild angezeigt wird, sind also auch die Abhängigkeiten vorhanden.

In dem unten gezeigten Beispiel verfügt der Hostcomputer über drei VMs. Um die Anwendungen in den VMs vollständig zu isolieren, verfügen sie jeweils über eigene Kopien von Betriebssystemdateien, Bibliotheken und Anwendungscode sowie über eine vollständige In-Memory-Instanz eines Betriebssystems. Die folgende Abbildung zeigt dasselbe Szenario mit Containern. Hier teilen sich Container einfach das Host-Betriebssystem, einschließlich des Kernels und der Bibliotheken, sodass sie kein Betriebssystem starten, keine Bibliotheken laden oder für diese Dateien private Speicherkosten zahlen müssen. Der einzige inkrementelle Speicherplatz, den sie belegen, ist Speicher und Speicherplatz, 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 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 VM-Fall.

Quelle: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

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

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

1) Herkömmliche Serverstapel bestehen aus einem physischen Server, auf dem ein Betriebssystem und Ihre Anwendung ausgeführt werden.

Vorteile:

• Nutzung von Rohstoffen

• Isolation

Nachteile:

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

2) Der VM-Stack besteht aus einem physischen Server, auf dem ein Betriebssystem ausgeführt wird, und einem Hypervisor, der Ihre virtuelle Maschine, gemeinsam genutzte Ressourcen und die Netzwerkschnittstelle verwaltet. Auf jeder 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
• Vendor Lockin
• Komplexe Konfiguration

3) Das Container-Setup , der Hauptunterschied zu anderen Stacks, ist die containergestützte Virtualisierung, bei der der Kernel des Host-Betriebssystems verwendet wird, um mehrere isolierte Gastinstanzen zu ermitteln. Diese Gastinstanzen werden als Container bezeichnet. Der Host kann entweder ein physischer Server oder eine VM sein.

Vorteile:

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

Nachteile:

• Gleiche Architektur
• Ressourcenintensive 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, ressourcenschonendste und sicherste Setup ist, das wir bisher kennen. Container sind isolierte Instanzen, auf denen Ihre Anwendung ausgeführt wird. Docker dreht den Container auf eine Art und Weise hoch, Layer erhalten Laufzeitspeicher mit Standardspeichertreibern (Overlay-Treibern), die innerhalb von Sekunden ausgeführt werden, und Copy-on-Write-Layer, die darüber erstellt werden, sobald wir den Container festschreiben, der die Ausführung von unterstützt Behälter.Bei VMs dauert es ungefähr eine Minute, bis alles in die Virtualisierungsumgebung geladen ist. Diese leichtgewichtigen Instanzen können problemlos ersetzt, neu erstellt und verschoben werden. Dies ermöglicht es uns, die Produktions- und Entwicklungsumgebung zu spiegeln 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.

Im Verhältnis zu:-

"Warum ist die Bereitstellung von Software auf einem Docker-Image einfacher als die 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. Gemeinsame Testumgebung
5. QS-Umgebung
6. UAT-Umgebung
7. Last- / Leistungstests
8. Live-Inszenierung
9. Produktion
10. Archiv

Es sind auch die folgenden Faktoren zu berücksichtigen:

• Entwickler und in der Tat Tester haben je nach Art des Auftrags entweder subtil oder stark unterschiedliche PC-Konfigurationen
• Entwickler können häufig auf PCs entwickeln, die außerhalb der Kontrolle von Unternehmens- oder Geschäftsstandardisierungsregeln liegen (z. B. Freiberufler, die auf ihren eigenen Computern (häufig remote) entwickeln, oder Mitarbeiter von Open Source-Projekten, die nicht für die Konfiguration ihrer PCs "angestellt" oder "beauftragt" sind Weg)
• Einige Umgebungen bestehen aus einer festen Anzahl mehrerer Computer in einer Konfiguration mit Lastenausgleich
• In vielen Produktionsumgebungen werden Cloud-basierte Server je nach Verkehrsaufkommen dynamisch (oder "elastisch") erstellt und zerstört

Wie Sie sehen können, ist die extrapolierte Gesamtzahl der Server für eine Organisation selten einstellig, sehr oft dreistellig und kann leicht noch deutlich höher sein.

Dies alles bedeutet, dass die Erstellung konsistenter Umgebungen in erster Linie aufgrund des hohen Volumens (selbst in einem Szenario auf der grünen Wiese) schwierig genug ist. Angesichts der hohen Anzahl von Servern und der Hinzufügung neuer Server (dynamisch oder ) ist es jedoch nahezu unmöglich, sie konsistent zu halten manuell), automatische Updates von O / S-Anbietern, 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 Um die Umgebung konsistent zu halten (okay, für Puristen ist dies möglich, erfordert jedoch viel Zeit, Mühe und Disziplin, weshalb VMs und Container (z. B. Docker) ursprünglich entwickelt wurden).

Stellen Sie sich Ihre Frage also eher so vor: "Ist es angesichts der extremen Schwierigkeit, alle Umgebungen konsistent zu halten, einfacher, Software für ein 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.

Es gibt viele Antworten, die die Unterschiede detaillierter erklären, aber hier ist meine sehr kurze Erklärung.

Ein wichtiger Unterschied besteht darin, dass VMs einen separaten Kernel verwenden, um das Betriebssystem auszuführen . 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 inaktiv ist. In Docker werden die Container nicht mit einer festen Menge an Hardwareressourcen zugewiesen und können die Ressourcen je nach den Anforderungen frei verwenden. Daher ist sie hoch skalierbar.

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

Mit einer virtuellen Maschine haben wir einen Server, wir haben ein Host-Betriebssystem auf diesem Server und dann haben wir einen Hypervisor. Wenn wir dann auf diesem Hypervisor laufen, haben wir eine beliebige Anzahl von Gastbetriebssystemen mit einer Anwendung und ihren abhängigen Binärdateien sowie Bibliotheken auf diesem Server. Es bringt ein ganzes Gastbetriebssystem mit. Es ist ziemlich schwer. Außerdem gibt es eine Begrenzung, wie viel Sie tatsächlich auf jede physische Maschine setzen können.

Docker-Container hingegen unterscheiden sich geringfügig. Wir haben den Server. Wir haben das Host-Betriebssystem. Aber stattdessen einen Hypervisor , haben wir den Docker Motor , in diesem Fall. In diesem Fall bringen wir kein ganzes Gastbetriebssystem mit. Wir bringen eine sehr dünne Schicht des Betriebssystems mit , und der Container kann mit dem Host-Betriebssystem kommunizieren, um dort auf die Kernelfunktionalität zuzugreifen. Und das ermöglicht uns einen sehr leichten Behälter.

Es enthält lediglich den Anwendungscode sowie 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 was uns dies ermöglicht, ist eine Reihe von Dingen. Sie haben eine viel schnellere Startzeit . Sie können nicht in wenigen Sekunden eine einzelne VM hochfahren. Und genauso schnell nehmen wir sie runter ... damit wir sehr schnell auf und ab skalieren können und wir werden uns das später ansehen.

Jeder Container glaubt, 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.

Quelle: Kubernetes in Aktion.

Ich habe Docker in Produktionsumgebungen und im Staging sehr häufig verwendet. Wenn Sie sich daran gewöhnt haben, 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 können es sehen, wenn Sie den topBefehl in einem Docker-Container ausgeben, der aus einem Docker-Image erstellt wurde.

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

Sie können beispielsweise ein Docker-Image erstellen und eine Docker-Datei konfigurieren und mitteilen, dass beispielsweise wenn sie ausgeführt wird, dann "this", "apt-get" that "," ein Shell-Skript "ausgeführt, Umgebungsvariablen festgelegt usw. werden.

In Mikrodienstleistungsprojekten und in der Architektur ist Docker ein sehr praktikables Gut. Mit Docker, Docker Swarm, Kubernetes und Docker Compose können Sie Skalierbarkeit, Ausfallsicherheit und Elastizität erreichen.

Ein weiteres wichtiges Problem in Bezug auf Docker ist Docker Hub und seine Community. Zum Beispiel habe ich ein Ökosystem zur Überwachung von Kafka mit Prometheus, Grafana, Prometheus-JMX-Exporter und Docker implementiert.

Dazu 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 mithilfe von YAML-Dateien bereitgestellt, oder für andere habe ich einige Dateien und Konfigurationen im Docker-Container geändert und ich Erstellen Sie ein ganzes System zur Überwachung von Kafka mithilfe von Dockern mit mehreren Containern auf einem einzelnen Computer mit Isolation, Skalierbarkeit und Ausfallsicherheit, sodass diese Architektur problemlos auf mehrere Server übertragen werden kann.

Neben der Docker Hub-Site gibt es eine weitere Site namens quay.io, auf der Sie Ihr eigenes Docker-Image-Dashboard erstellen und von dort aus ziehen / verschieben können. Sie können sogar Docker-Images von Docker Hub zum Kai importieren und sie dann vom Kai auf Ihrem eigenen Computer ausführen.

Hinweis: Docker zu lernen scheint zunächst komplex und schwierig zu sein, aber wenn Sie sich daran gewöhnt haben, können Sie ohne Docker nicht arbeiten.

Ich erinnere mich an die ersten Tage der Arbeit mit Docker, als ich fälschlicherweise die falschen Befehle ausgegeben oder meine Container und alle Daten und Konfigurationen entfernt habe.

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. Die heutigen Unternehmen stehen unter dem Druck, sich digital zu transformieren, werden jedoch durch vorhandene Anwendungen und Infrastrukturen eingeschränkt, während ein zunehmend vielfältiges Portfolio an Clouds, Rechenzentren und Anwendungsarchitekturen rationalisiert wird. Docker ermöglicht echte Unabhängigkeit zwischen Anwendungen und Infrastruktur sowie Entwicklern und IT-Mitarbeitern, um ihr Potenzial auszuschöpfen, und schafft ein Modell für eine bessere Zusammenarbeit und Innovation.

So Docker ist Container basiert, das heißt , Sie haben Bilder und Behälter , die auf der aktuellen Maschine ausgeführt werden können. Es enthält nicht das Betriebssystem wie VMs , sondern ein Paket verschiedener Arbeitspakete wie Java, Tomcat usw.

Wenn Sie Container verstehen, erfahren Sie, was Docker ist und wie es sich von VMs unterscheidet ...

Also, was ist ein Container?

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

Wie Sie in der Abbildung unten sehen können, verfügt jeder Container über ein separates Paket, das auf einer einzelnen Maschine ausgeführt wird, die das Betriebssystem dieser Maschine gemeinsam nutzt. Sie sind sicher und einfach zu versenden.

Hier gibt es viele nette technische Antworten, die die Unterschiede zwischen VMs und Containern sowie die Ursprünge von Docker klar diskutieren.

Für mich besteht der grundlegende Unterschied zwischen VMs und Docker darin, wie Sie die Werbung für Ihre 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 der Abhängigkeiten für alle Anwendungen.
3. Für das Backout müssen Änderungen in der VM rückgängig gemacht werden. Oder wenn möglich wiederherstellen.

Mit Docker besteht die Idee darin, dass Sie Ihre Anwendung zusammen mit den benötigten Bibliotheken in einem eigenen Container bündeln und dann den gesamten Container als eine Einheit bewerben .

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 mit VMs fördern Sie 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.