Ich muss meinen Frust über Docker loswerden! In meinem Berufsalltag habe ich mit zahlreichen Unzulänglichkeiten zu kämpfen, die mich zunehmend zur Verzweiflung bringen. Lasst mich euch von meinen Erfahrungen erzählen und diese Technologie mal so richtig durch den Kakao ziehen! Beginnen wir mit dem offensichtlichen Problem: IPv6. Docker scheint immer noch im Zeitalter von IPv4 festzustecken und ignoriert beharrlich die Bedeutung von IPv6 in der modernen Netzwerklandschaft. Während die Welt sich weiterentwickelt, kämpfen wir mit veralteten Technologien und müssen uns mit zahllosen Workarounds herumschlagen, um Docker mit IPv6 zum Laufen zu bringen. Es ist einfach lächerlich, dass eine so fortschrittliche Technologie wie Docker diese grundlegende Funktion nicht vernünftig unterstützt. Und was ist mit NAT-Problemen? Docker behauptet, die Lösung für die Isolierung von Anwendungen zu sein, aber ich kann euch sagen, dass es genau das Gegenteil ist! Das Docker-Netzwerkmodell führt zu massiven Problemen mit der Netzwerkkonfiguration und dem Routing. Port-Kollisionen, undurchsichtige Netzwerkregeln und eine endlose Kette von NAT-Regeln sind an der Tagesordnung. Statt uns das Leben zu erleichtern, macht Docker es uns unnötig schwer, das Netzwerk richtig zu konfigurieren und Anwendungen miteinander kommunizieren zu lassen. Ach, und lasst mich das Thema Firewalling ansprechen. Docker scheint der Meinung zu sein, dass wir keine Firewall benötigen. Warum sollten wir auch? Sicherheit ist doch überbewertet! Docker ignoriert schlichtweg die grundlegenden Prinzipien des Firewallings und lässt uns mit ungeschützten Containern im Regen stehen. Es ist frustrierend, dass wir zusätzliche Tools und Konfigurationen benötigen, nur um ein grundlegendes Sicherheitsniveau zu erreichen. Docker sollte besser seine Prioritäten überdenken und uns vernünftige Möglichkeiten zum Schutz unserer Anwendungen bieten. Und dann gibt es noch das Thema schlampiges Patch Management. Docker ist nicht gerade dafür bekannt, in puncto Updates und Patches glänzend dazustehen. Statt uns mit regelmäßigen und verlässlichen Updates zu versorgen, müssen wir uns mit veralteten Images und Sicherheitslücken herumschlagen. Es ist unverantwortlich, wie Docker seine Benutzer im Stich lässt und uns allein mit den Risiken und Problemen im Zusammenhang mit veralteter Software zurücklässt. Wir sollten uns darauf verlassen können, dass Docker seine Verantwortung wahrnimmt und uns die erforderlichen Updates zur Verfügung stellt. Ich könnte noch stundenlang über die zahlreichen Mängel und Frustmomente sprechen, die Docker in meinem Berufsalltag verursacht. Aber ich denke, ihr habt den Punkt verstanden. Docker mag einige Vorteile haben, aber sie verblassen im Vergleich zu den Fehlern und Unzulänglichkeiten, mit denen wir täglich konfrontiert sind.
Du verwechselst "Docker" und "Dockerhub". Wenn du deine Images selber baust, und keinen Fertig-Kram von Dockerhub beziehst, ist zumindest das Update-Problem beherrschbar.
Nach vielen Rum experimentieren und ausprobieren und Trial and Error Tagen kann ich dir nun seit ca. zwei Jahren vollumfänglich folgendes sagen: Das gute alte LXC... am besten über Proxmox. Und deine Probleme sind gegessen.
Matthias B. schrieb: > Ich muss meinen Frust über Docker loswerden! Docker muss seinen Frust über dich und die Millionen der anderen User loswerden, die zwar das Produkt gerne nutzen, noch lieber Forderungen stellen, aber nichts zur open source Gemeinde beitragen. All das, was du bemängelst, könntest du selbst mit etwas Eigeninitiative am open source Projekt verbessern, aber du bist zu faul, nimmst nur und gibst nichts. Logisch, dass auch die Originalersteller keinen Bock haben, jedem seine Sonderwünsche für lau zu implementieren. Und wer die Ausrede 'kann ich nicht' gebraucht, soll die Füsse still halten, und bewundern was es wundernswertes schon gibt.
Matthias B. schrieb: > Ich muss meinen Frust über Docker loswerden! Aber Hans, das kennen wir doch alles schon, und Du hast uns das jetzt schon mehrmals in epischer Breite und unter verschiedenen Namen erzählt. Und wie die letzten Male kann ich Dir wieder einmal nur raten, mit der Technologie zu arbeiten anstatt gegen sie. Probier das doch mal aus! :-)
ja echter Schrott!
Ja und? Schmeiß noch Kubernetes oben drauf und du siehst kaum noch was von Docker. Das geht so weit, dass aktuelle Kubernetes-Versionen zwar Docker (eigentlich OCI) Images verwenden, aber als Runtime containerd oder CRI-O läuft. Mit den NetworkPolicys von Kubernetes (wenn vom jeweiligen Network Plugin unterstützt) hast du Basisfunktionen für Firewalling an der Hand. Wenn die dir nicht reichen schmeiß halte eine echte Firewall mit rein. Für abgefahrenes Networking setzt du noch ein Service-Mesh wie istio oder Linkerd oben drauf. Spaß für die ganze Familie.
Hallo zusammen,
vielen Dank für eure Rückmeldungen und Kritik zu meinem Beitrag. Ich
möchte gerne auf einige Punkte eingehen:
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.
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.
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.
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.
Ich hoffe, dass wir eine konstruktive Diskussion führen können und
möglicherweise Lösungen für die genannten Probleme finden. Vielen Dank
für eure Zeit und eure Beiträge!
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. > 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? > 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ß. > 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). > 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.
Sag dreimal Docker und der Schaumschläger erscheint. Haha, hab dich wieder getriggert. Ausdrucksweise kann übrigens nicht ähnlich sein. Hat ChatGPT geschrieben. Ciao Schaumi.
Stimmt. CICS und TSO auf System/360 waren ein Fortschritt gegenüber allen vorhergehenden und allen nachfolgenden Virtualisierungen.
Also ich nutze Docker viel auf Arbeit und habe keine großen Probleme damit. Probier doch mal docker compose für den Netzwerkkram zwischen Containern.
Matthias B. schrieb: > Sag dreimal Docker und der Schaumschläger erscheint. Haha, hab dich > wieder getriggert. > > Ausdrucksweise kann übrigens nicht ähnlich sein. Hat ChatGPT > geschrieben. Ciao Schaumi. Tja, ich hab' Dich aber trotzdem gleich durchschaut. Gut, ne? :-) Und wiedermal kommt von Dir nichts Substanzielles. Naja, ich hatte Dir ja oben schon den Rat zu geben, einfach etwas ganz Neues zu probieren: nicht gegen, sondern mit der Technologie zu arbeiten. Dann klappts nämlich auch mit dem Docker, weißt Du... Hab' jedenfalls noch einen schönen Tag, bis zum nächsten Mal. :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.