{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"Was ist Docker: ein kurzer \u00dcberblick \u00fcber die Geschichte und die wichtigsten Abstraktionen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Am 10. August startete ein Videokurs zu Docker<\/a><\/noindex>, in dem wir ihn vollst\u00e4ndig behandeln \u2013 von den grundlegenden Abstraktionen bis zu den Netzwerkkonfigurationen. <\/p>\n

<\/p>\n

In diesem Artikel sprechen wir \u00fcber die Geschichte von Docker und seine grundlegenden Abstraktionen: Image, Cli, Dockerfile. Die Lektion richtet sich an Anf\u00e4nger, weshalb sie wahrscheinlich f\u00fcr erfahrene Benutzer nicht interessant sein wird. Hier wird es keine Blutbad, keinen Blinddarm und kein tiefes Eintauchen geben. Die Grundlagen.<\/p>\n

<\/p>\n

\"Was<\/p>\n

<\/a><\/noindex><\/p>\n

Was ist Docker<\/h2>\n

<\/p>\n

Schauen wir uns die Definition von Docker auf Wikipedia an.<\/p>\n

<\/p>\n

Docker ist eine Software zur Automatisierung der Bereitstellung und Verwaltung von Anwendungen in containerisierten Umgebungen.<\/p><\/blockquote>\n

Aus dieser Definition wird nichts klar. Besonders unklar ist, was \u201ein containerisierten Umgebungen\u201c bedeutet. Um dies zu kl\u00e4ren, gehen wir zur\u00fcck in die Vergangenheit. Beginnen wir in der Zeit, die ich bedingt als \u201emonolithische \u00c4ra\u201c bezeichne.<\/p>\n

<\/p>\n

Monolithische \u00c4ra<\/h2>\n

<\/p>\n

Die monolithische \u00c4ra ist der Anfang der 2000er Jahre, als alle Anwendungen monolithisch waren und viele Abh\u00e4ngigkeiten hatten. Die Entwicklung dauerte lange. Zu dieser Zeit gab es nicht viele Server, wir kannten sie alle beim Namen und \u00fcberwachten sie. Es gibt einen am\u00fcsanten Vergleich:<\/p>\n

\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Haustiere \u2013 das sind Haustiere. In der monolithischen \u00c4ra behandelten wir unsere Server wie Haustiere, pflegten und hegen sie und bliesen den Staub ab. Um die Ressourcen besser zu verwalten, nutzten wir Virtualisierung: Wir nahmen einen Server und teilten ihn in mehrere virtuelle Maschinen, um damit Isolierung der Umgebung zu gew\u00e4hrleisten.<\/p>\n

<\/p>\n

Virtualisierungssysteme auf Hypervisor-Basis<\/h2>\n

<\/p>\n

\u00dcber Virtualisierungssysteme hat sicherlich jeder schon geh\u00f6rt: VMware, VirtualBox, Hyper-V, Qemu KVM usw. Sie bieten Isolierung f\u00fcr Anwendungen und Ressourcenmanagement, haben jedoch auch Nachteile. Um Virtualisierung zu erm\u00f6glichen, wird ein Hypervisor ben\u00f6tigt. Und ein Hypervisor bedeutet Ressourcen\u00fcberkopf. Au\u00dferdem ist die virtuelle Maschine normalerweise ziemlich gro\u00df \u2013 ein schweres Image, mit einem Betriebssystem, Nginx, Apache und m\u00f6glicherweise MySQL. Das Image ist gro\u00df, und es ist unpraktisch, mit einer virtuellen Maschine zu arbeiten. Infolgedessen kann die Arbeit mit virtuellen Maschinen langsam sein. Um dieses Problem zu l\u00f6sen, wurden Virtualisierungssysteme auf Kernel-Ebene entwickelt.<\/p>\n

<\/p>\n

Virtualisierungssysteme auf Kernel-Ebene<\/h2>\n

<\/p>\n

Die Virtualisierung auf Kernel-Ebene wird von Systemen wie OpenVZ, Systemd-nspawn, LXC unterst\u00fctzt. Ein bekanntes Beispiel f\u00fcr eine solche Virtualisierung ist LXC (Linux-Container). <\/p>\n

<\/p>\n

LXC ist ein Betriebssystem-Virtualisierungssystem, das es erm\u00f6glicht, mehrere isolierte Instanzen des Betriebssystems Linux auf einem einzigen Knoten auszuf\u00fchren. LXC verwendet keine virtuellen Maschinen, sondern erstellt eine virtuelle Umgebung mit eigenem Prozess- und Netzwerk-Stack.<\/p>\n

<\/p>\n

Im Grunde erstellt LXC Container. Was ist der Unterschied zwischen virtuellen Maschinen und Containern?<\/p>\n

<\/p>\n

\"Was<\/p>\n

<\/p>\n

Container sind nicht geeignet, um Prozesse zu isolieren: In Virtualisierungssystemen auf Kernel-Ebene werden Schwachstellen gefunden, die es erlauben, aus dem Container auf den Host zu gelangen. Wenn Sie also etwas isolieren m\u00fcssen, ist es besser, eine virtuelle Maschine zu verwenden.<\/p>\n

<\/p>\n

Die Unterschiede zwischen Virtualisierung und Containerisierung sind in dem Diagramm zu sehen.
\nEs gibt hardwarebasierte Hypervisoren, Hypervisoren \u00fcber Betriebssystemen und Container. <\/p>\n

<\/p>\n

\"Was<\/p>\n

<\/p>\n

Hardware-Hypervisoren sind eine gro\u00dfartige L\u00f6sung, wenn Sie tats\u00e4chlich etwas isolieren m\u00f6chten. Denn dort gibt es die M\u00f6glichkeit, auf Seitenebene und Prozessoren zu isolieren.<\/p>\n

<\/p>\n

Es gibt Hypervisoren als Programme und es gibt Container, \u00fcber die wir nun sprechen werden. In Containerisierungssystemen gibt es keinen Hypervisor, aber es gibt eine Container-Engine, die Container erstellt und verwaltet. Diese L\u00f6sung ist leichter, weshalb der Overhead durch die Arbeit mit dem Kernel geringer ist oder gar nicht vorhanden.<\/p>\n

<\/p>\n

\n

Was wird auf Kernel-Ebene zur Containerisierung verwendet?<\/h2>\n

Die Haupttechnologien, die es erm\u00f6glichen, einen von anderen Prozessen isolierten Container zu erstellen, sind Namespaces und Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount und User. Es gibt noch weitere, aber der Einfachheit halber konzentrieren wir uns auf diese.<\/p>\n

Der PID-Namespace beschr\u00e4nkt Prozesse. Wenn wir beispielsweise einen PID-Namespace erstellen und einen Prozess dort platzieren, erh\u00e4lt dieser die PID 1. Normalerweise ist PID 1 in Systemen systemd oder init. Wenn wir also einen Prozess in einen neuen Namespace verschieben, erh\u00e4lt er ebenfalls die PID 1.<\/p>\n

Der Networking-Namespace erm\u00f6glicht es, das Netzwerk zu beschr\u00e4nken\/zu isolieren und darin eigene Schnittstellen zu platzieren. Mount ist die Beschr\u00e4nkung des Dateisystems. User ist die Beschr\u00e4nkung der Benutzer.<\/p>\n

Control Groups: Memory, CPU, IOPS, Network \u2013 insgesamt etwa 12 Einstellungen. Sie werden auch Cgroups (\u201eC-Gruppen\u201c) genannt.<\/p>\n

Control Groups verwalten die Ressourcen f\u00fcr den Container. \u00dcber Control Groups k\u00f6nnen wir festlegen, dass der Container nicht mehr als eine bestimmte Menge an Ressourcen verbrauchen darf.<\/p>\n

Damit die Containerisierung voll funktionsf\u00e4hig ist, werden zus\u00e4tzliche Technologien verwendet: Capabilities, Copy-on-Write und andere.<\/p>\n

Capabilities sind die Vorgaben, was ein Prozess machen darf und was nicht. Auf Kernel-Ebene sind das einfach Bitmaps mit vielen Parametern. Zum Beispiel hat der Benutzer root volle Berechtigungen und kann alles tun. Der Zeitserver kann die Systemzeit \u00e4ndern: Er hat Capabilities f\u00fcr die Time Capsule, und das war's. Mit Privilegien k\u00f6nnen Einschr\u00e4nkungen f\u00fcr Prozesse flexibel eingestellt und somit die Sicherheit erh\u00f6ht werden.<\/p>\n

Das Copy-on-Write-System erm\u00f6glicht es uns, effizienter mit Docker-Images zu arbeiten.<\/p>\n

Zurzeit hat Docker Kompatibilit\u00e4tsprobleme mit Cgroups v2, daher behandelt der Artikel speziell Cgroups v1.<\/em><\/p><\/blockquote>\n

Aber kehren wir zur Geschichte zur\u00fcck. <\/p>\n

<\/p>\n

Mit dem Aufkommen von Virtualisierungssystemen auf Kernel-Ebene wurden diese aktiv eingesetzt. Der Overhead auf den Hypervisor entfiel, aber einige Probleme blieben bestehen:<\/p>\n

<\/p>\n