Docker - Eine komische Tragödie

« | 23 May 2020 | »

Die Existenz von Docker beweist, dass alles, was nur hätte schief gehen können, auch schief gegangen ist.

So in etwa würde ich ein Kapitel meiner Autobiografie einleiten.
Gefolgt von:

Und Schuld hat Linux.

Aber man sagt auch, ich würde zu Übertreibungen neigen …

---

Bevor man mir Negativität vorwirft sei erwähnt, dass ich die Software Docker besonders für einige ihrer Einsatzorte sehr schätzen gelernt habe. Besonders die Arbeit am Windows Nano Server beweist, dass Container auch ein Segen sein können.
Und ich könnte mir größere Linux-Buildumgebungen ohne dieses Tool heute nur mehr schwer vorstellen.

Doch hier möchte ich mal mein Leid klagen, welches schon vor dem Jahr 2000 begann:

Die DLL-Hell Saga

Mir liegen immer noch die zynischen Kommentare der Chaos Radio Moderatoren in den Ohren, die Windows 95 und 98 (zu Recht!) verteufelten, und nur all zu gerne die DLL-Hölle als Schwachpunkt nannten.

Das Problem bei der Weiterentwicklung von Software ist, dass man zwangsläufig Kompatibilität verliert, weil neue Technologien immer weniger zu alten Schnittstellen passen.
Die DLL-Hölle entstand, wenn die Installationsroutine einer älteren Software neue DLLs des Systems durch ältere Versionen ersetzte, oder umgekehrt, wenn neue Software ältere Komponenten stillschweigend erweiterten.

Damit funktionierte immer nur die zuletzt installierte Software während andere Produkte plötzlich grafisch fehlerhaft wurden oder gleich ganz abstürzten.

Und so erlangte Windows den Ruf, kein brauchbares System zu sein, weil “nicht mal” eine einfache Versionsverwaltung für Systemkomponenten hatte.

Ein solches Feature wurde dann schritteweise eingeführt und mit SxS (auch als Side-by-Side-Assemblies bekannt) etabliert. Nun konnten mehrere DLLs parallel installiert werden und ein Programm bekam nur jene Version zu sehen, die zu ihm passte.

Container, weil … warum?

Mich stört, dass seit ein paar Jahren krampfhaft mit “Docker” versucht wird ein vergleichbares Feature auch auf Linux zu etablieren.

Denn die anfangs so gelobte Versionsverwaltung zeigt bei allen Distributionen ihre Grenzen und so laufen unter Linux viele Programme nur dann, wenn andere Programme NICHT installiert sind, oder nur in einer bestimmten Version vorliegen.

Brauchte man zwei sich nicht leiden wollende Programme auf einem System, musste man entweder auf eines verzichten oder durfte sich mit Softwarefehlern herumschlagen.

Docker-Container lösen dieses Problem durch eine besondere Trennschicht zwischen den Prozessen namens cgroups. Während nur ein Kernel läuft, kann das Userland in mehreren Instanzen (==Containern) parallel laufen ohne sich sehen oder stören zu können.

So können auch unterschiedliche inkompatible Bibliotheken parallel genutzt werden. Und rein theoretisch wäre das eine gute Sache …

Warum nicht gleich alles richtig machen?

Bibliotheken stören sich grundsätzlich nicht gegenseitig … außer man programmiert sie so störrisch.

Meist sind es Kleinigkeiten, wie ein globaler Socket oder eine named Pipe. Vielleicht eine temporäre Datei oder ein bestimmter laufender Prozess. Am häufigsten kam mir jedoch eine unterschiedliche Version der C-Runtime unter.

… aber alle reden sie doch mit dem exakt gleichen Kernel. Und genau das ist der Punkt. Die Kernelschnittstelle ist standardisiert. Egal was eine Bibliothek tut, am Ende nutzen alle den gleichen Kernel, auch ohne Docker.

Würden also die Bibliotheken “ordentlich” ausprogrammiert sein und sich nicht gegenseitig stören und z.B. die C-Runtime statisch linken, so gäbe es keinen Grund nicht alles parallel zu installieren und ohne Docker störungsfrei auszuführen.

Und wer mit dem Argument Sicherheit kommt, dem möchte ich hiermit chroot vorstellen.

Fazit

Es fällt mir daher schwerer die guten Seiten von Docker zu bewundern, wenn ich es als Mogelwerkzeug in der Softwareentwicklung sehe. Und deshalb werde ich weiter dafür kämpfen, dass Software so entwickelt wird, dass sie ohne Virtualisierungskäfige störungsfrei betrieben werden kann.

Man vergisst auch gerne, dass Docker-Container wie kleine VMs betrieben werden und einmal aufgesetzt auch Wartung und Updates bräuchten. Doch mit der Quantität sinkt die Qualität und so laufen dann unzählige Container mit veralteten Softwareständen und -fehlern weiter.

Aber genug gelästert. Es bleibt mir wohl auch nichts anderes übrig als diese Technologie “mitzumachen”, weil es die anderen auch tun.

Einen Vorteil hat es für mich aber: Ich kann schneller an andere Linux-Distributions-Eigenheiten herankommen, als wenn ich sie in VMs mühsam aufsetzen müsste.

In diesem Sinne: docker pull *!