Build it, ship it, run it? Dockers Versprechen auf dem Prüfstand
Build it, ship it, run it? Dockers Versprechen auf dem Prüfstand
Wenn auch nicht bis ins letzte ausgeführt, so ist es doch eine ganze Reihe von Problemen in der alltäglichen SysAdmin-Arbeit, die einige Programmierer im Frühjahr 2015 zu einem Boykott-Aufruf gegen Docker bewegt hat. Eine teils kontroverse Debatte war die Folge und einige weitere Docker-Kritiker meldeten sich zu Wort. Wir fassen noch einmal zusammen: Woher kommt die Wut auf Docker? Und welche Kritikpunkte haben noch immer ihre Berechtigung?
Im Aufruf zum Boykott von Docker werden nacheinander alle Ziele und Versprechungen der Docker-Technologie auseinander genommen. Technisch überbewertet, umständlich in der Anwendung und vor allem ausgerichtet auf einen veritablen Anbieter-Lock-in, bleibe der einzige Vorzug von Docker seine Popularität, die bestenfalls als Marketing-Vehikel für eigene Projekte zu nutzen sei, so die Kritiker. Einige der Kritikpunkte im einzelnen:
Im Vergleich zur Anwendung von Virtual Machines, insbesondere der KVM, unterstellen die Autoren des Aufrufs Docker eine weit schlechtere Variabilität und Vielseitigkeit in der Nutzung. Docker Images könnten nur auf „dockerisierten“ GNU- bzw. Linux-Systemen laufen. Der Vorteil der leichtgewichtigen Container für die Rechnerleistung werde durch ein lastenreiches Ökosystem und entsprechende Netzwerk-Auslastung wieder aufgefressen. Die Arbeit von SysAdmins mit Docker bezeichnen die Autoren gar als Deployment-Hölle:
OS running Docker becomes DockerOS. All you default standard commands like ps, ls, find, netstat, sockstat, tail and similar are useless here. You have to learn all that bunch of yet another new commands with totally different behaviour. In fact you can not expect to run anything else that is related to network on DockerOS machine.
Vergesst alles, was ihr gelernt habt, rufen die Docker-Boykotteure den System-Administratoren zu. Denn Docker ist nur mit Docker-eigenen Tools und Befehlen anzuwenden, die die mühsam angelegten eigenen Regeln, die Hierarchien der Netzwerk-Interfaces und die Routing-Tabellen zerstören. In die gleiche Kerbe schlägt auch Cal Leeming, dessen Docker-Kritik für einiges Aufsehen gesorgt hat:
If your development workflow is sane, then you will already understand that Docker is unnecessary. All of the features which it claims to be helpful are either useless or poorly implemented, and it’s primary benefits can be easily achieved using namespaces directly. Docker would have been a cute idea 8 years ago, but it’s pretty much useless today.
Auch was das Netzwerk angeht, sei Docker nicht auf dem Laufenden. Während die Autoren das Protokoll IPv6 für den neuesten Stand halten, bezeichnen sie NAT, auf dem Docker basiert, als damit völlig inkompatibel und technisch rückständig. Zusammen mit den vielen Netzwerk-Layern sei Geschwindigkeit das letzte, was Docker-Admins erwarten sollten. Ähnliches hat wohl auch Cal Leeming im Sinn, wenn er schreibt:
These problems are caused by the poor architectural design of Docker as a whole, enforcing linear instruction execution even in situations where it is entirely inappropriate (per #2439).
Dem Versprechen, dass für Docker keinerlei neue Sprache, kein neues Framework oder ein neues Packaging-System notwendig sei, stehe die Tatsache gegenüber, dass letztlich die gesamte Entwicklungsumgebung und System-Architektur ausgetauscht werden muss: „Your application has to be Docker locked-in“. Dabei sei der Build by Command im Shell beileibe kein exklusiver Vorzug von Docker.
Die mangelnde Sicherheit der Repositories im Docker Hub war bereits Thema auf JAXenter und ist ein weiterer Beleg für die Verfasser des Aufrufs, dass die Begeisterung für Docker nichts als ein großer Hype sei, von dem außer den großen Cloud-Anbietern niemand so wirklich etwas habe.
Die teils harrsche Kritik in allen Statements scheint sich einer großen Enttäuschung angesichts der Versprechen von Dockers Container-Technologie zu verdanken, die Sebastian Jung in seinem Blog auf den Punkt gebracht hat.
The theory and ideas behind Docker are great, its architecture and implementation is a mess. Docker is completely unusable in production. It is unreliable, it is unpredictable, it is flaky.
Was meinen Sie? Liegen die Docker-Hasser falsch? Teilen Sie Ihre Erfahrungen im Kommentar-Bereich.
Aufmacherbild: Modern Maritime Pirates Attacking Cargo Ship von Shutterstock
Urheberrecht: Crystal Eye Studio