{"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 grundlegenden Abstraktionen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Am 10. August startete in Sljorm ein Videokurs zu Docker<\/a><\/noindex>, in dem wir es komplett behandeln \u2013 von den grundlegenden Abstraktionen bis hin zu den Netzwerkeinstellungen. <\/p>\n

<\/p>\n

In diesem Artikel sprechen wir \u00fcber die Entstehungsgeschichte von Docker und seine grundlegenden Abstraktionen: Image, CLI, Dockerfile. Die Vorlesung richtet sich an Anf\u00e4nger, daher wird sie erfahrene Benutzer wahrscheinlich nicht interessieren. Hier wird es keine blutigen Details, keinen Appendix und keine tiefgehende Analyse geben. Nur die Grundlagen.<\/p>\n

<\/p>\n

\"Was<\/p>\n

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

Was ist Docker<\/h2>\n

<\/p>\n

Lassen Sie uns die Definition von Docker aus Wikipedia betrachten.<\/p>\n

<\/p>\n

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

Aus dieser Definition wird nichts klar. Besonders unverst\u00e4ndlich ist, was \"in containerisierungsf\u00e4higen Umgebungen\" bedeutet. Um das zu kl\u00e4ren, gehen wir in die Vergangenheit zur\u00fcck. Beginnen wir mit einer \u00c4ra, die ich als \"Monolithische \u00c4ra\" 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, mit vielen Abh\u00e4ngigkeiten. Die Entwicklung dauerte lange. Zu diesem Zeitpunkt gab es nicht so viele Server, wir kannten sie alle beim Namen und \u00fcberwachten sie. Es gibt einen interessanten Vergleich:<\/p>\n

\n

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

Haustiere \u2014 das sind unsere treuen Begleiter. In der \u00c4ra der Monolithen behandelten wir unsere Server wie Haustiere, k\u00fcmmerten uns um sie und entfernten jeden Staub. Um die Ressourcen besser zu verwalten, setzten wir Virtualisierung ein: Wir nahmen einen Server und teilten ihn in mehrere virtuelle Maschinen auf, um so eine isolierte Umgebung zu schaffen.<\/p>\n

<\/p>\n

Hypervisor-basierte Virtualisierungssysteme<\/h2>\n

<\/p>\n

\u00dcber Virtualisierungssysteme hat sicher jeder schon geh\u00f6rt: VMware, VirtualBox, Hyper-V, Qemu KVM usw. Diese bieten Anwendungsisolierung und Ressourcenmanagement, haben jedoch auch Nachteile. Um Virtualisierung durchzuf\u00fchren, ben\u00f6tigt man einen Hypervisor, was einen Ressourcen\u00fcberhead bedeutet. Zudem ist eine virtuelle Maschine oft ziemlich umfangreich \u2014 ein schweres Abbild, auf dem ein Betriebssystem, Nginx, Apache und m\u00f6glicherweise auch MySQL laufen. Dieses gro\u00dfe Abbild macht die Verwaltung virtueller Maschinen unhandlich. In der Folge kann die Arbeit mit virtuellen Maschinen langsam sein. Um dieses Problem zu l\u00f6sen, wurden Kernvirtualisierungssysteme entwickelt.<\/p>\n

<\/p>\n

Kernvirtualisierungssysteme<\/h2>\n

<\/p>\n

Kernvirtualisierung wird von Systemen wie OpenVZ, Systemd-nspawn und LXC unterst\u00fctzt. Ein herausragendes Beispiel daf\u00fcr ist LXC (Linux-Container). <\/p>\n

<\/p>\n

LXC \u2014 ein Betriebssystem-virtualisierungssystem zur Ausf\u00fchrung mehrerer isolierter Instanzen des Linux-Betriebssystems auf einem Knoten. LXC verwendet keine virtuellen Maschinen, sondern schafft eine virtuelle Umgebung mit eigenen Prozessr\u00e4umen und Netzwerkstacks.<\/p>\n

<\/p>\n

Im Grunde genommen 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 Kernvirtualisierungssystemen gibt es Schwachstellen, die es erm\u00f6glichen, aus dem Container auf den Host zu gelangen. Daher ist es besser, eine virtuelle Maschine zu verwenden, wenn Sie etwas isolieren m\u00fcssen.<\/p>\n

<\/p>\n

Die Unterschiede zwischen Virtualisierung und Containerisierung k\u00f6nnen in der Abbildung gesehen werden.
\nEs gibt Hardware-Hypervisoren, Hypervisoren \u00fcber dem Betriebssystem und Container. <\/p>\n

<\/p>\n

\"Was<\/p>\n

<\/p>\n

Hardware-Hypervisoren sind eine gro\u00dfartige Sache, wenn Sie wirklich etwas isolieren m\u00f6chten. Denn hier besteht die M\u00f6glichkeit, auf Seitenebene und Prozessoren zu isolieren.<\/p>\n

<\/p>\n

Es gibt Hypervisoren als Programme und Container, \u00fcber die wir im Folgenden sprechen werden. In Containerisierungssystemen gibt es keinen Hypervisor, sondern eine Container-Engine, die Container erstellt und verwaltet. Diese Technologie ist leichter und hat aufgrund der Arbeit mit dem Kernel weniger Overhead oder keinen \u00fcberhaupt.<\/p>\n

<\/p>\n

\n

Was auf Kernel-Ebene f\u00fcr die Containerisierung verwendet wird<\/h2>\n

Die wichtigsten Technologien, 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 zur Vereinfachung konzentrieren wir uns auf diese.<\/p>\n

Der PID Namespace beschr\u00e4nkt Prozesse. Wenn wir zum Beispiel einen PID Namespace erstellen und dort einen Prozess platzieren, erh\u00e4lt dieser die PID 1. Normalerweise ist in Systemen PID 1 systemd oder init. Wenn wir also einen Prozess in einen neuen Namespace verschieben, erh\u00e4lt auch dieser 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 eine Einschr\u00e4nkung des Dateisystems. User ist eine Einschr\u00e4nkung der Nutzer.<\/p>\n

Control Groups: Memory, CPU, IOPS, Network \u2013 insgesamt etwa 12 Einstellungen. Sie werden auch als Cgroups (\"C-Gruppe\") bezeichnet.<\/p>\n

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

Um die Containerisierung vollst\u00e4ndig zu nutzen, werden zus\u00e4tzliche Technologien verwendet: Capabilities, Copy-on-Write und andere.<\/p>\n

Capabilities legen fest, was ein Prozess tun darf und was nicht. Auf Kernel-Ebene handelt es sich dabei einfach um Bitmaps mit vielen Parametern. Zum Beispiel hat der Root-Benutzer vollst\u00e4ndige Berechtigungen und kann alles tun. Der Zeitserver kann die Systemzeit \u00e4ndern: Er hat die entsprechenden Capabilities f\u00fcr Time Capsule \u2013 und das war's. Mit Berechtigungen lassen sich die Einschr\u00e4nkungen f\u00fcr Prozesse flexibel festlegen und so die eigene Sicherheit erh\u00f6hen.<\/p>\n

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

Derzeit hat Docker Probleme mit der Kompatibilit\u00e4t zu Cgroups v2, daher werden in diesem Artikel speziell Cgroups v1 behandelt.<\/em><\/p><\/blockquote>\n

Kehren wir zur Geschichte zur\u00fcck. <\/p>\n

<\/p>\n

Als die Virtualisierungssysteme auf Kernel-Ebene eingef\u00fchrt wurden, wurden sie schnell eingesetzt. Der Overhead des Hypervisors fiel weg, aber einige Probleme blieben bestehen:<\/p>\n

<\/p>\n