Matthias B. schrieb:
[...]
Okay, wenn Du nicht schon wieder "Hans", "Laurenz", "CISO" oder "VMFreak" bist, dann wollen wir das mal sachlich diskutieren.
Zunächst einmal IPv6: Docker unterstützt IPv6, wenngleich es in einigen Dokumenten noch als "experimental" eingestuft wird. De facto kenne ich allerdings mehrere Mesos-, Swarm- und Kubernetes-Cluster, die zum Teil bereits seit Jahren prima auf IPv6-only laufen.
1 |
Die Verwechslung von "Docker" und "Dockerhub": Ihr habt recht, in
|
meinem Beitrag habe ich nicht klar zwischen Docker und Dockerhub
unterschieden. Wenn man eigene Images erstellt, anstatt vorgefertigte
von Dockerhub zu verwenden, kann man das Update-Problem besser
kontrollieren. Allerdings bedeuten eigene Images auch, dass ich einige
Vorteile von Docker verliere, wie die Möglichkeit, schnell und einfach
auf eine Vielzahl von bereits existierenden Images zugreifen zu können.
In der Regel sind ja irgendwo die Dockerfiles zu den Images erhältlich, damit kann man eigene Images bauen. Und das Aufsetzen einer eigenen privaten Registry ist auch kein Hexenwerk und zumindest für verteilte Umgebungen ohnehin dringend geraten. Der Rest läßt sich relativ easy wahlweise mit einer CI-/CD-Software oder zur Not mit deren Poor man's Variante Ansible bauen, und für einfache Docker-Instanzen kann man seine eigenen Images ebenfalls mit Ansible bauen, mit "docker save" als Tar-Archiv ins lokale Dateisystem sichern, das Archiv ebenfalls mit Ansible auf den Zielhost kopieren und da mit "docker load" importieren, ohne Registry.
Darüber hinaus listet der Dockerhub verschiedene Anhaltspunkte auf, unter "Tags" zum Beispiel wann der letzte Push des Image erfolgt ist oder, bei Images, die vom betreffenden Projekt gepflegt und aktuell gehalten werden, den Badge "Docker Official Image", außerdem wie viele Downloads und wie viele "Sterne" ein Image von den Docker-Usern erhalten hat. Oder oft auch gleich (ebenfalls unter Tags) Verweise auf Verwundbarkeiten, nach einem Klick auf die betreffenden Marker kommt man dann sogar auf eine Liste, in der für jedes verwundbare Softwarepaket die CVEs angegeben sind. Bei einem PostgreSQL-Image zum Beispiel, das über 1 Milliarde Downloads, über 10.000 Sterne und offensichtlich eine gut gepflegte Liste an CVEs enthält, kann man sich IMHO schon ganz gut einen Überblick verschaffen, ob man dieses Image benutzen möchte oder sich lieber etwas anderes sucht.
Ansonsten ist das mit dem Patch-Management kein Alleinstellungsmerkmal von Docker, wie ich just letzte Woche wieder am lebenden Patienten erleben mußte. Stell' Dir das mal vor: auch Hosts und Gäste in VM-Umgebungen muß man pflegen, warten und aktualisieren. Bei Docker tauscht man da einfach ein aktualisiertes und getestetes Image aus, und das funktioniert in der Regel ziemlich problemlos. Bei VM-Hosts und -Gästen dagegen... da können durchaus ein paar mehr Dinge schief gehen, und häufig kann man sie zuvor eben nicht einfach mal schnell zuhause starten und testen, wie das mit Docker-Images meistens recht einfach möglich ist.
Letzten Endes ist das wie bei Donkervoort: No Power Steering, No ABS, the driver is in charge. Oder, übertragen auf Docker, the sysop. Natürlich ist nicht die Technologie, sondern der Betreiber für seinen Technologiestack, und dessen Kompatibilität, Sicherheit und Aktualität verantwortlich. Das ist keine Raketenwissenschaft, man muß es eben einfach machen, und darin unterscheidet sich Docker von keiner anderen Technologie, weder von VMs, noch von LXC, noch von... you get the idea. Vielleicht betrifft Deine Kritik eher Deine eigene Erwartungshaltung, daß Docker Probleme lösen könnte, ohne daß Du die Lösung erarbeiten und umsetzen mußt?
1 |
Vorschlag von LXC und Proxmox: Vielen Dank für den Vorschlag! LXC
|
und Proxmox sind sicherlich gute Alternativen zu Docker, und ich
verstehe, dass sie möglicherweise einige der genannten Probleme lösen
können. Allerdings schätze ich die umfangreiche Sammlung von
vorgefertigten Images in der Docker-Community und möchte nicht auf diese
Möglichkeit verzichten.
Darüber hinaus habe ich mit Proxmox an einigen Stellen leider einige durchwachsene Erfahrungen machen müssen, zum Beispiel im Zusammenhang mit Snapshots (Stichwort Backup), bei denen die VMs dann in einem Kernel-Oops gelandet sind. Darüber hinaus sehe ich auch nicht allzuviel Sinn darin, eine Virtualisierungstechnologie unter einer anderen zu betreiben, solange man das nicht unbedingt muß.
1 |
Die Rolle der Open-Source-Gemeinschaft: Ich bin mir der Bedeutung
|
der Open-Source-Gemeinschaft bewusst und schätze ihre Beiträge sehr. Ich
bin jedoch kein Entwickler und habe möglicherweise nicht das technische
Know-how, um aktiv zum Projekt beizutragen. Dennoch glaube ich, dass es
legitim ist, als Benutzer Feedback zu geben und auf Unzulänglichkeiten
hinzuweisen, um Verbesserungen anzuregen.
Tja, der australische Anästhäsist Con Kolivas hat extra C auf dem Niveau von Kernel-Enwicklern gelernt und dann den Staircase-Deadline-Scheduler entwickelt, der Linux-Desktops deutlich responsiver gemacht hat. Was will ich damit sagen: auch als Nichtentwickler kann man das mit der Entwicklung durchaus lernen, wenn man möchte. Das haben die Entwickler auch alle mal gemacht (auch wenn manche das bisweilen vergessen zu haben scheinen).
1 |
Die Aussage zu Hans und Wiederholungen: Entschuldigt bitte das
|
Missverständnis, aber ich bin nicht Hans und habe den Beitrag zum ersten
Mal veröffentlicht. Es tut mir leid, wenn es sich ähnlich angehört hat
wie frühere Beiträge, aber ich wollte einfach meinen Frust teilen und
die Meinungen anderer Benutzer dazu hören.
Naja, die Ausdrucksweise und die Aussagen sind sich doch sehr ähnlich.
