Hallo guten Tag, hat jemand ein Beispiel aus dem Alltag, wo Docker sinnvoll war? Vielen Dank.
:
Damit gehen alle Softwarepakete auf dem Server ihren eigenen Weg und kommen sich nicht ins Gehege. Wenn du das nicht brauchst nutze es nicht.
- Deine Anwendung läuft in einer gekapselten Umgebung mit minimalem Userland. - die üblichen Installationstätigkeiten gehören mit Docker zum Entwicklungsprozess und werden (wenn es gut läuft) versionsverwaltet und getestet. - Daten und Applikation werden zwingend voneinander getrennt. - Zwei Instanzen der gleichen Anwendung sind gleich ausfgesetzt
Benedikt L. schrieb: > Damit gehen alle Softwarepakete auf dem Server ihren eigenen Weg und > kommen sich nicht ins Gehege. > Wenn du das nicht brauchst nutze es nicht. Nicht nur das - einige andere Faktoren spielen damit einher und da ist es unerheblich ob nun Docker, LXC oder was auch immer: - Serverhardware: wird besser ausgelastet. - Migration: Ein Container von einer Maschine auf eine andere zur porten ist super easy - Sicherheit: Jeder Container läuft in seiner eigenen Instanz - Angriffe enden an diesem einen - Übersicht: Man hat bessere Übersicht über die laufenden Services als wenn alle auf einer Maschine rödeln - Lastverteilung: Container können die Last auf verschiedene Nodes verteilen und nun das beste Argument: - Skalierung: man kann sich einfach in binnen von 10min einen zweiten, dritten, vierten Server daneben stellen und die Container skalieren sich auf die Hardware. Fällt ein Server aus, übernimmt ein andere die Arbeit und man wechselt / repariert diesen und fügt ihm den Netz wieder hinzu. Für den "Heimgebrauch" ist das natürlich alles nicht wirklich sinnvoll, dafür ist "Containern" aber auch nicht gedacht.
Angehängte Dateien:
-
IOT-Stack.png
180 KB
Ein Beispiel: #295 Raspberry Pi Server based on Docker, with VPN, Dropbox backup, Influx, Grafana, etc: IOTstack https://www.youtube.com/channel/UCu7_D0o48KbfhpEohoP7YSQ #352 Raspberry Pi4 Home Automation Server (incl. Docker, OpenHAB, HASSIO, NextCloud) https://www.youtube.com/watch?v=KJRMjUzlHI8 IOTstack lässt sich unter Linux Mint auch auf x86_64 PC-Plattformen installieren. Der Screenshot zeigt eine Applikation von IOTstack mit zwei Pi4, die mit TFREC 868 an zwei Standorten T[°C] und H[%] Daten sammeln und diese mit NodeRed, InfluxDB in einem Nuc[Mint] abspeichern. Dargestellt werden die Daten mit Grafana auf einem Notebook[Mint].
Dockercontainer sind von Informatikern zusammengepfuschter Murks weil sie keine saubere Buildumgebung koennen/kennen. Aktualisierungen sind reine Glueckssache. Sicherheit wird nur ganz klein geschrieben. Natuerlich trotz anderslautender Beteuerungen. Im Zweifelsfall besser richtige VMs. Manches braucht beides nicht, ist dann aber u.U. schwieriger zu realisieren.
KeinDockerFan schrieb: > Dockercontainer sind von Informatikern zusammengepfuschter Murks > weil sie keine saubere Buildumgebung koennen/kennen. > Aktualisierungen sind reine Glueckssache. Sicherheit wird nur > ganz klein geschrieben. Natuerlich trotz anderslautender Beteuerungen. > > Im Zweifelsfall besser richtige VMs. > > Manches braucht beides nicht, ist dann aber u.U. schwieriger > zu realisieren. Ich sehe nicht wie jemand, der nicht in der Lage ist ein Dockerimage sicher zu bauen und zu pflegen, das Gleiche mit einer VM erfolgreich hinbekommen sollte. Der einzige Unterschied ist, dass die VM althergebracht ist
KeinDockerFan schrieb: > Dockercontainer sind von Informatikern zusammengepfuschter Murks > weil sie keine saubere Buildumgebung koennen/kennen. > Aktualisierungen sind reine Glueckssache. Sicherheit wird nur > ganz klein geschrieben. Natuerlich trotz anderslautender Beteuerungen. Wow, so viele Argumente.
danke an alle MitLeserin schrieb: > https://www.youtube.com/channel/UCu7_D0o48KbfhpEohoP7YSQ ist ein interessatens Bsp. Dort wird gezeigt dass man die einzelnen Programme nicht auf Linux installieren muss, sondern ein Dockersystem mit fertig konfigurierter Software nutzen kann.
Docker ist das Mittel, mit dem man in kürzester Zeit den größen Stuß fabrizieren kann. Gerne eingesetzt von "DevOps" u.o. externen Beratern, die weit weg sind, wenn der mit der heißen Nadel zusammengestoppelte Mist in der Produktion verreckt.
In FreeBSD gab es schon immer die Jail … docker halte ich für Murx - dann lieber gleich komplette virtuelle Maschine, so wie einige hier auch schon schrieben
Docker ist eine Variante der Virtualisierung, bei der im Wesentlichen nur die Umgebung (bspw. Sichtbares Dateiverzeichnissystem, Zugriff auf System-Resourcen) virtualisiert wird und nicht die komplette Hardware. Ein wichtiger Unterschied zu Virtuellen Maschinen ist, dass bei Docker über eine Skriptsprache die Umgebung mehr oder weniger leicht aus verschiedenen Layern zusammengestellt werden kann. M.E. die Haupteinsatzgebiete sind * Test von Anwendungen in verschiedenen Umgebungen * Dynamische Bereitstellen von gleichartigen Service-Endpoints, wenn diese keine so starke Trennung wie bei Virtuellen Maschinen benötigen. * Schnelle Bereitstellung einer bestimmten Applikation in einer höchstwahrscheinlich lauffähigen Umgebung (z.B. Webserver mit Datenbank und allen notwendigen Paketen, die für die Lauffähigkeit notwendig sind). Docka schrieb: > Gerne eingesetzt von "DevOps" u.o. externen Beratern, > die weit weg sind, wenn der mit der heißen Nadel zusammengestoppelte > Mist in der Produktion verreckt. Warum sind die DevOps nicht in der Produktion ("Operation") -- dafür steht doch der "Ops"-Anteil? Und vermutlich würde das gleiche passieren, wenn diese statt Docker die fertigen VM-Images zusammenbauen.
:
Bearbeitet durch User
Achim H. schrieb: > Und vermutlich würde das gleiche passieren, wenn diese statt Docker die > fertigen VM-Images zusammenbauen. Die vorhandene jahrelange Erfahrung bestätigt dies NICHT.
Ich kann noch eine Spezialanwendung einwerfen: Docker bietet dir eine von dir definierte Umgebung auf deinem Host-System. Du bist damit unabhängig vom Host. Wir haben aus diesem Grund Dockercontainer auf Mess- und Steuerrechner eingesetzt in einem Testfeld. Die Rechner dort sind fix mit der Testhardware verbaut und die Abteilung, welche das Testfeld betreut, erlaubt natürlich nicht, dass da jede Abteilung dann alle möglich Software auf diesen Rechnern installiert. Mit Docker war die Entwicklung und Deployment unserer Testprogramme sehr einfach. Applikationsingenieur kann mit USB-Stick, auf dem das Image gespeicheert ist zum Testrechner. Kopiert das Image, ladet es und startet den Test und kann sich auf den Test konzentrieren. Und muss nicht erst das Hostsystem konfigurieren, irgendwas installieren usw.usf.
Rene K. schrieb: > - Sicherheit: Jeder Container läuft in seiner eigenen Instanz Das ist ein Streitthema, Docker Anhänger behaupten gerne, dass Docker die Anwendung isoliert und damit irgendwie sicherer macht. Auf der anderen Seite, ist der Vorteil von Docker, dass jede Anwendung Ihre eigene Umgebung mit zum teils stark veralten Software Versionen mitbringt, auch der größte Nachteil, denn die Exploits für diese Versionen sind bekannt. Wie überall wird also die Wahrheit irgendwo in der Mitte liegen und Docker Befürworter werden nun einwenden, dass man den Container natürlich auch aktualisieren sollte, aber was war doch dann gleich der Vorteil von gegenüber einem gepflegten System ohne Docker? Die These Docker macht das System per se sicherer, halte ich deshalb für zu gewagt.
imonbln schrieb: > Die These Docker macht das System per se sicherer, halte ich deshalb für > zu gewagt. Gut, mit Docker kenne ich mich nicht so aus, ich nutze exzessiv LXC Container. Das Prinzip ist aber das gleiche. Einfaches Beispiel: Wenn ich einen Webserver habe, ein Angreifer über diesen Port, wie auch immer, Zugriff auf diesen erlangt haben. Dann bleibt er da, er kommt von diesem isolierten Container nicht weiter auf den Host oder hat Zugriffe auf andere Instanzen / Container... Container hält man nicht per Hand auf dem aktuellen Stand, dazu nutzt man Tools wie Ansible oder schreibt sich halt ein Script (vorzugsweise in einem eigenen Container). Docker gefällt mir persönlich dahingehend nicht, das man die Container "selbst schreiben" muss. Bei LXC ist dies wesentlich effektiver gelöst.
Rene K. schrieb: > Docker gefällt mir persönlich dahingehend nicht, das man die Container > "selbst schreiben" muss. Bei LXC ist dies wesentlich effektiver gelöst. Das ist eigentlich ein ziemlich geniales Konzept, da ein einmal erstelltes Image in großer Stückzahl ausgerollt werden kann. Eine Verwaltung mit Ansible würde irgendwann unverhältnismäßig lange laufen. Rene K. schrieb: > Container hält man nicht per Hand auf dem aktuellen Stand, dazu nutzt > man Tools wie Ansible oder schreibt sich halt ein Script (vorzugsweise > in einem eigenen Container). Aber genau da wird das Konzept von Docker eben zur Schwachstelle, weil es eben keine einfache Möglichkeit gibt auch nur die Distributionspakete im Container aktuell zu halten.
Achim H. schrieb: > Dynamische Bereitstellen von gleichartigen Service-Endpoints z.B. drei Webserver gleichzeitig auf Port 443? Geht das? Wo sind überhaupt die Grenzen? Mal angenommen, ich hätte ein GTK2/X11-Programm auf einem alten Debian laufen. Könnte das im Container auf Ubuntu mit Wayland laufen? Auch, wenn Ubuntu kein GTK2 mehr mitliefert?
Bauform B. schrieb: > z.B. drei Webserver gleichzeitig auf Port 443? Geht das? Geht, aber dafür brauchst du dann einen Reverse Proxy davor der das je nach Hostnamen aufteilt.
Vor 50 Jahren gab es mal den Spruch: "Es wurde noch keiner entlassen, weil er IBM gekauft hatte." Da hat sich nichts dran geändert. Ganz egal was schief geht - du kannst dem Chef immer noch sagen: Hätten wir nicht den Marktführer ausgewählt, wäre es noch schlimmer gekommen.
Boomer schrieb: > Bauform B. schrieb: >> z.B. drei Webserver gleichzeitig auf Port 443? Geht das? > > Geht, aber dafür brauchst du dann einen Reverse Proxy davor der das je > nach Hostnamen aufteilt. Richtig, ich habe hier auf einem Server ca. 50 Webserver, jeder in seinem eigenen Container, in denen der User vollen root Zugriff hat, der seine eigene MySql Server hat, der sich seinen eigenen Mailserver darin aufsetzen kann... der darin machen kann was er will. Was denkst du denn wie das in großen Hostingfirmen gemacht wird?!
Bauform B. schrieb: > Wir reden aber schon noch von Docker? Naaaaaa... ich eigentlich eher von LXC :-D
Man muss in der Diskussion auch immer sagen wofür man es nutzen will. Im Embedded Bereich bin ich ähnlich noch nicht so richtig begeistert. Im Serverbereich schon. Was hier meines Erachtens noch nicht genannt wurde: Dokumentation Ich habe in unserem kleinen Unternehmen die Verwaltung des Servers übernommen. Linux-Dateiserver mit SFTP/SAMBA, Gitlab und ein paar andere Dienste. Im alten System war im Nachhinein auch nicht so richtig sichtbar, was installiert wurde und wie die Abhängigkeiten waren. Das ist mit Dockerfiles und docker-compose ein ziemlicher Traum. Umgebungen, Ports, Verzeichnisse und anwendungsspezifische Modifikationen/Konfigurationen sind meist alles auf einem Blick sichtbar. Außerdem finde ich es manchmal sehr angenehm Dinge unabhängig voneinander zu aktualisieren (Container untereinander und Host), jedem Service von nicht betreffenden Abhängigkeiten breinigt laufen zu lassen und nur die Berechtigungen zuzuteilen, die der Service wirklich benötigt. Dabei hat Docker weniger Overhead als VMs und die Ressourcen können dynamischer verteilt werden. Dass man das auch mit LXC machen kann und Systemd mittlerweile ebenso Werkzeuge dafür bereitstellt, sei dahingestellt. Ich habe für mich Docker entschieden und es keine Sekunde bereut.
Achim H. schrieb: > Docker ist eine Variante der Virtualisierung, bei der im Wesentlichen > nur die Umgebung (bspw. Sichtbares Dateiverzeichnissystem, Zugriff auf > System-Resourcen) virtualisiert wird und nicht die komplette Hardware. Virtualisiert wird bei Docker eigentlich nichts, außer vielleicht das Netzwerk. Die Ressourcen werden nicht virtualisiert, sondern lediglich gekapselt. Wenn man eine Ressource an einen Container "durchreicht", greift der exakt genauso darauf zu wie ein Programm außerhalb des Containers. Ein zusätzliches Virtualisierungslayer gibt es nicht. dsa schrieb: > Ich kann noch eine Spezialanwendung einwerfen: > > Docker bietet dir eine von dir definierte Umgebung auf deinem > Host-System. Du bist damit unabhängig vom Host. > > Wir haben aus diesem Grund Dockercontainer auf Mess- und Steuerrechner > eingesetzt in einem Testfeld. > Die Rechner dort sind fix mit der Testhardware verbaut und die > Abteilung, welche das Testfeld betreut, erlaubt natürlich nicht, dass da > jede Abteilung dann alle möglich Software auf diesen Rechnern > installiert. Ich nutze es zum Compilieren für bestimmte Zielsysteme. Ich habe Kunden, die noch irgendwelche uralten Centos-Systeme haben, wo keine aktuellen Bibliotheken vorhanden sind. Um das auch mal auf meinem Rechner statt des Zielrechners zu bauen, nehme ich Docker. Und für die CI/CD-Pipeline in Bamboo verwende ich auch Docker zum bauen, weil ich dann nicht erst den Admin bitten muss, mir alle devel-Pakete und sonstigen Dinge, die ich brauche, zu installieren. Im Container kann ich mir einfach selbst installieren, was ich brauche.
imonbln schrieb: > dass man den Container > natürlich auch aktualisieren sollte, aber was war doch dann gleich der > Vorteil von gegenüber einem gepflegten System ohne Docker? das ich das dockerfile nur einmal anpassen muss und dieses dann leicht verteilen kann? VMs sind größer und schwieriger zu synchronisieren
der docker daemon wird häufiger bemängelt, aber dann kann man auch sowas wie podman benutzen. ich möchte docker für die Entwicklung nicht mehr missen. zb. kann der Entwickler lokal in seinem container mit allen build tools entwickeln und auf dem Buildserver läuft die gleiche Umgebung und kann leicht synchron gehalten werden. Sicherheitsaspekte interessieren mich persönlich weniger da ich das nicht Produktiv einsetze und da niemand externen auf einen webserver oÄ. Zugriff hat. Da mögen dann andere Regeln & Bedürfnisse ins Spiel kommen
Bauform B. schrieb: > z.B. drei Webserver gleichzeitig auf Port 443? Geht das? Ja, mit einem Reverse Proxy davor ist das überhaupt kein Problem. Ich betreibe alle meine Webprojekte so und nutze den Letsencrypt-Companion als Reverse Proxy. Der kümmert sich dann auch vollautomatisch um das Erstellen, die Installation und die Erneuerung der Zertifikate von Letsencrypt, alles gesteuert über einige wenige Environment-Variablen. > Wo sind > überhaupt die Grenzen? Mal angenommen, ich hätte ein GTK2/X11-Programm > auf einem alten Debian laufen. Könnte das im Container auf Ubuntu mit > Wayland laufen? Auch, wenn Ubuntu kein GTK2 mehr mitliefert? Ja, das geht, ich betreibe meinen Chrome-Webbrowser so. Hier [1] findest Du Dockerfiles der ehemaligen Docker-Mitarbeiterin Jessica Frazelle für eine große Vielzahl an X-Programmen. [1] https://github.com/jessfraz/dockerfiles
Ein T. schrieb: > Ja, das geht, ich betreibe meinen Chrome-Webbrowser so. Hier [1] findest > Du Dockerfiles der ehemaligen Docker-Mitarbeiterin Jessica Frazelle für > eine große Vielzahl an X-Programmen. > > [1] https://github.com/jessfraz/dockerfiles Welchen X Server reichst du dem denn unter Wayland durch?
Laut https://github.com/mviereck/x11docker/wiki/How-to-provide-Wayland-socket-to-docker-container den selben wie bei Xorg.
:
Bearbeitet durch User
Hans schrieb: > Ein T. schrieb: >> Ja, das geht, ich betreibe meinen Chrome-Webbrowser so. Hier [1] findest >> Du Dockerfiles der ehemaligen Docker-Mitarbeiterin Jessica Frazelle für >> eine große Vielzahl an X-Programmen. >> >> [1] https://github.com/jessfraz/dockerfiles > > Welchen X Server reichst du dem denn unter Wayland durch? Das geht wohl mit xwayland [1,2]. Mehr kann ich dazu nicht sagen, ich bin mit Xorg happy und nutze Wayland daher nicht. [1] https://hub.docker.com/r/x11docker/xwayland [2] https://github.com/mviereck/x11docker/wiki/How-to-provide-Wayland-socket-to-docker-container
Bauform B. schrieb: > Ein T. schrieb: >> Ja, das geht >> https://github.com/jessfraz/dockerfiles > > Dankeschön! Sehr gerne, viel Spaß und Erfolg! ;-)
Walter K. schrieb: > In FreeBSD gab es schon immer die Jail Ja, basierend auf chroot und Solaris hat davon die Zones uebernommen. Trotzdem hat sich Docker/podman durchgesetzt. Warum? U.a. wegen dem Framework (Openshift & Kubernetes). > … docker halte ich für Murx - dann lieber gleich komplette virtuelle > Maschine, so wie einige hier auch schon schrieben Du verwechseltst (wie so viele) VMs und Container. Ein Container und eine VM haben ueberhaupt nichts miteinander zu tun. Docker benutzt im Gegensatz zu Jails Namespaces und Cgroups um einen Prozess zu isolieren und laeuft direkt auf deiner HW (Performance!). Die VM laeuft auf virtueller HW (Qemu eingebetted in KVM,..). Mit den bekannten Vor- und Nachteilen.
Schukostecker schrieb: > Die VM laeuft auf virtueller HW (Qemu eingebetted in KVM,..). Mit den > bekannten Vor- und Nachteilen. Wo läuft Docker denn wirklich auf echter Hardware? In den ganzen Clouds mit Sicherheit nicht.
Hans schrieb: > Wo läuft Docker denn wirklich auf echter Hardware? In einem Openshift-Cluster auf den Workernodes beispielsweise. Oder auf einem Desktop-System zum Ausprobieren.
Schukostecker schrieb: > Hans schrieb: >> Wo läuft Docker denn wirklich auf echter Hardware? > > In einem Openshift-Cluster auf den Workernodes beispielsweise. Oder auf > einem Desktop-System zum Ausprobieren. Richtig. Zudem glaube ich, daß die Diskussionen über Docker viel zu oft die Ähnlichkeiten mit den klassischen Virtualisierungsansätzen gesehen wird. Es geht aus meiner Sicht aber eher um Deployment und Lifecycle-Management.
Ein T. schrieb: > Richtig. Zudem glaube ich, daß die Diskussionen über Docker viel zu oft > die Ähnlichkeiten mit den klassischen Virtualisierungsansätzen gesehen > wird. Es geht aus meiner Sicht aber eher um Deployment und > Lifecycle-Management. Sehe ich genauso. Ein Developer muss sich in Kubernetes/Openshift keine Gedanken ueber IP-Adressen oder Routes zu seiner App machen. Das macht das Framework fuer ihn. Ein neues Release? Es wird ueber die Pipeline mit den gleichen Parametern eingespielt.
Schukostecker schrieb: > Sehe ich genauso. Ein Developer muss sich in Kubernetes/Openshift keine > Gedanken ueber IP-Adressen oder Routes zu seiner App machen. Das macht > das Framework fuer ihn. Das auch, ja, aber das ist ja ein Kubernetes- und Openshift-Thema. ;-) > Ein neues Release? Es wird ueber die Pipeline mit den gleichen > Parametern eingespielt. Ja, und das Beste: es ist versioniert! Wenn das neue Image aus welchen Gründen auch immer nicht richtig funktioniert, kann man ganz leicht auf eine funktionierende Vorversion zurückgehen. Oder ich will den Fehler in einer Version debuggen, die beim Kunden läuft: dann ziehe ich mir nur die Version des Kunden aus der Registry und habe exakt dieselbe Software wie unser Kunde, um den Fehler nachzustellen. Das ist schon schick und spart manchmal eine Menge Arbeit und Zeit.
Ein T. schrieb: > Schukostecker schrieb: >> Hans schrieb: >>> Wo läuft Docker denn wirklich auf echter Hardware? >> >> In einem Openshift-Cluster auf den Workernodes beispielsweise. Oder auf >> einem Desktop-System zum Ausprobieren. > > Richtig. Zudem glaube ich, daß die Diskussionen über Docker viel zu oft > die Ähnlichkeiten mit den klassischen Virtualisierungsansätzen gesehen > wird. Es geht aus meiner Sicht aber eher um Deployment und > Lifecycle-Management. Also wenn mir jemand mit dem Performance Vorteil kommt, muss er nun mal einsehen, dass docker in vielen Umgebungen tatsächlich ein zusätzlicher Layer auf einer VM ist. Mal abgesehen von den paar Ausnahmen wo jemand lokal rumbastelt oder sein Cluster on-prem in Hardware aufbaut. Da hilft es nicht etwas über andere Vorteile zu erzählen und abzulenken.
Hans schrieb: > Also wenn mir jemand mit dem Performance Vorteil kommt, muss er nun mal > einsehen, dass docker in vielen Umgebungen tatsächlich ein zusätzlicher > Layer auf einer VM ist. Mal abgesehen von den paar Ausnahmen wo jemand > lokal rumbastelt oder sein Cluster on-prem in Hardware aufbaut. Da hilft > es nicht etwas über andere Vorteile zu erzählen und abzulenken. Der offensichtlich Einzige, der hier ablenkt, bist Du. Performanceverluste durch VMs sind ein Problem der besagten VMs, nicht von Docker. Daß manche Leute dann Docker auf einer VM betreiben und ihre Performance dann unter der VM leidet, ändert daran nichts und ist natürlich allein deren Problem.
Ein T. schrieb: > Der offensichtlich Einzige, der hier ablenkt, bist Du. > Performanceverluste durch VMs sind ein Problem der besagten VMs, nicht > von Docker. Daß manche Leute dann Docker auf einer VM betreiben und ihre > Performance dann unter der VM leidet, ändert daran nichts und ist > natürlich allein deren Problem. Ach ja, der Schaumschläger. Ich habe nicht von schlechter Performance gesprochen, sondern nur, dass das kein echter Vorteil in einer Cloud Umgebung ist. Und das wirst du nicht widerlegen können.
> Daß manche Leute dann Docker auf einer VM betreiben und ihre > Performance dann unter der VM leidet, ändert daran nichts und ist > natürlich allein deren Problem. Manche? In Zeiten von Cloud-Native Clustern liegt da wohl bei den allermeisten eine VM drunter. Scheint wohl kein Problem zu sein. Aber man hat mit docker natürlich dann einen Layer mehr. Docker spart zwar RAM und Disk, auch ein bisschen CPU aber der ineffiziente Layer bleibt.
Hans schrieb: > Ein T. schrieb: >>> Hans schrieb: >>> Also wenn mir jemand mit dem Performance Vorteil kommt, >>> >> Performanceverluste durch VMs sind ein Problem der besagten VMs, > > Ach ja, der Schaumschläger. Als hätte ich nicht schon gemerkt, daß unser Dockerhassertroll wieder am Werk ist. > Ich habe nicht von schlechter Performance gesprochen, Ich habe Dein Zitat jetzt mal ergänzt, Dein Erinnerungsvermögen scheint ja wieder einmal deutlich zu schwächeln. > sondern nur, dass das kein echter Vorteil in einer Cloud > Umgebung ist. Und das wirst du nicht widerlegen können. Es interessiert mich schlicht und ergreifend nicht, weil es vollkommen irrelevant ist. Der Performanceimpact bei einer VM kommt von der VM, egal was auf der VM läuft. Auch in VMs bietet Docker in vielen Bereichen große Vorteile, von denen auch diejenigen profitieren, welche Docker innerhalb von VMs betreiben. Das kannst Du nicht wegschwätzen.
Ein T. schrieb: > Es interessiert mich schlicht und ergreifend nicht, weil es vollkommen > irrelevant ist. Der Performanceimpact bei einer VM kommt von der VM, > egal was auf der VM läuft. Auch in VMs bietet Docker in vielen Bereichen > große Vorteile, von denen auch diejenigen profitieren, welche Docker > innerhalb von VMs betreiben. Habe doch nichts andere behauptet. Aber du interpretierst ja immer gerne mal alles mögliche in Aussagen hinein. Schaumschläger.
Ein T. schrieb: >> Ich habe nicht von schlechter Performance gesprochen, > > Ich habe Dein Zitat jetzt mal ergänzt, Dein Erinnerungsvermögen scheint > ja wieder einmal deutlich zu schwächeln. > >> sondern nur, dass das kein echter Vorteil in einer Cloud >> Umgebung ist. Und das wirst du nicht widerlegen können. Der Schaumschläger, wie er leibt und lebt. Das hast du ja mal wieder schön aus dem Kontext gerissen und absichtlich missverstanden. Aber dann erklär es mal: Welchen PERFORMANCEVORTEIL habe ich beim Einsatz von Docker auf einer Cloud-VM? Und jetzt lenk nicht wieder mit anderen Vorteilen ab. Eben, keinen. Das ist nicht schlimm (also KEIN NACHTEIL), aber es ist eben auch KEIN VORTEIL. Wer von einem PERFORMANCEVORTEIL spricht, der lügt sich bei der Mehrheit der Umgebungen eben selbst in die Tasche.
Ein T. schrieb: > Auch in VMs bietet Docker in vielen Bereichen > große Vorteile, von denen auch diejenigen profitieren, welche Docker > innerhalb von VMs betreiben. Völlig richtig. Und ich habe dir schon oft genug erklärt, dass ich Docker sogar selbst einsetze und es sogar selbst in VMs betreibe. Ich komme trotzdem nicht auf die Idee, die Technologie durch die Rosa-Blümchenbrille zu sehen und jeden, der nur ein wenig berechtigte Kritik äußert blöd anzumachen und als Ein T. schrieb: > Dockerhassertroll zu bezeichnen. Aber NACHTEILE haben hier im Thread weder etwas was verloren, noch werde ich sie mit dir diskutieren, da Sachlichkeit bei dir leider ohnehin ein Fremdwort ist. Du bist eben nur ein Schaumschläger.
Hans schrieb: > Wer von einem PERFORMANCEVORTEIL > spricht, der lügt sich bei der Mehrheit der Umgebungen eben selbst in > die Tasche. Und bevor du mir jetzt mit effizienterer Ressourcennutzung kommst: Ja, damit hättest du selbst in VMs recht, wenn eine Applikation in x Containern in einer VM läuft, statt in x VMs. Das ist aber eben nicht Performance.
Rene K. schrieb: > ich habe hier auf einem Server ca. 50 Webserver Kein kluger Bauer legt alle Eier in einen Korb. Andere nutzten z.B. Office364 und haben einen kleinen Ausfall https://www.heise.de/news/Analyse-Microsoft-liefert-erste-Details-zum-Ausfall-von-Teams-Office-und-Co-7473885.html Je mehr man hat, desto unübersichtlicher wird es. Je mehr man im Docker hat, desto mehr muß man verwalten. Ob es Jahrzehnte funktioniert?
oszi40 schrieb: > Rene K. schrieb: >> ich habe hier auf einem Server ca. 50 Webserver > > Kein kluger Bauer legt alle Eier in einen Korb. Andere nutzten z.B. > Office364 und haben einen kleinen Ausfall > https://www.heise.de/news/Analyse-Microsoft-liefert-erste-Details-zum-Ausfall-von-Teams-Office-und-Co-7473885.html > Je mehr man hat, desto unübersichtlicher wird es. Je mehr man im Docker > hat, desto mehr muß man verwalten. Ob es Jahrzehnte funktioniert? Die alle auf einen Server zu legen wäre vielleicht wirklich ein bisschen unglücklich. An der Stelle geht man besser auf ein Kubernetes Cluster. Das kann entsprechend Redundant aufgebaut werden, um automatisch auf Hardwareausfälle zu reagieren. Aber deine Forderung nach Jahrzehnten Laufzeit halte ich für weit überzogen. Welche Webseite läuft schon unverändert nur wenige Jahre? Vielleicht ein paar statische HTML Websites, aber oft werden ja Webapplikationen gehostet und da braucht es ohnehin Updates. Und wenn wir uns die Historie von Microsoft mit Sharepoint, Lync, Skype for Business und Teams ansehen, zeigt sich doch, wie schnelllebig IT ist. Aber ja: Wartung und den Überblick über seine Docker Container (im Kubernetes Cluster) zu behalten ist eine der zentralen Herausforderungen in so einer Umgebung. Denn einerseits ist alles klar dokumentiert durch die eingesetzten Images und im besten Fall yml Definitionen oder Helm Charts. Aber andererseits bleiben veraltete Images leider oft unbemerkt und entwickeln sich mit der Zeit zum Sicherheitsrisiko. Wobei das natürlich in einer klassischen Umgebung auch nicht viel anders ist.
Docktor schrieb: > hat jemand ein Beispiel aus dem Alltag, wo Docker sinnvoll war? Ich habe ein automatisiertes VoIP Tool (Telefonmenü) geschrieben. Es arbeitet automatisiert, also brauchte es keinen Zugriff auf Audiodevices (was vielleicht auch möglich wäre, habe ich aber nicht ausprobiert). Das Problem ist nur, dass VoIP eine Krankheit ist und die verfügbaren Libraries dazu auch. So kam es, dass sich schon die Demoanwendung aufgrund nicht auflösbarer Abhängigkeiten auf meinem System nicht bauen ließ. Deshalb läuft diese Anwendung in einem Docker Container mit einer Betriebssystemversion nach Entwicklervorgabe. Da wird Docker dann schon nützlich, auch wenn dieser Anwendungszweck von einigen zurecht kritisiert wird. Aber machen wir uns nichts vor: Python z.B. bietet mit virtualenv eine ähnliche Lösung, an der sich die selben Kritikpunkte finden lassen. Und wenn wir darüber nachdenken, dass es auch Anwendungen gibt, deren Abhängigkeiten sich teilweise gegenseitig ausschließen, macht so eine Kapselung den Betrieb und die Wartung schon einfacher.
Hans schrieb: > Deshalb läuft diese Anwendung in einem Docker Container mit einer > Betriebssystemversion nach Entwicklervorgabe. Genau. Dann läuft das Ding ewig, wird 3x umgezogen und keiner ist mehr zuständig? Die gewissenhafte Verwaltung solcher Sachen mit allen Updates funktioniert ähnlich gut, wie Reinigung schmutziger Tassen in der Kaffeeküche ...
oszi40 schrieb: > Die gewissenhafte Verwaltung solcher Sachen mit allen Updates > funktioniert ähnlich gut, wie Reinigung schmutziger Tassen in der > Kaffeeküche ... Dieses Problem ist aber technologieunabhängig, wenn ihr es mit Docke habt, dann hättet ihr es auch ohne. Kaputte Prozesse können durch technische Lösungen halt nur bedingt repariert werden.
oszi40 schrieb: > Genau. Dann läuft das Ding ewig, wird 3x umgezogen und keiner ist mehr > zuständig? Die gewissenhafte Verwaltung solcher Sachen mit allen Updates > funktioniert ähnlich gut, wie Reinigung schmutziger Tassen in der > Kaffeeküche ... In dem Fall ist es ein noch supportetes Debian 10. Von daher kann ich damit Leben. Das keiner ist zuständig Problem gibt es ja auch auf klassischen Systemen. Das wäre ja nicht anders, wenn die Anwendung in einer VM laufen würde, die über die Hardwaregenerationen hinweg umziehen würde. Du brauchst halt vernünftiges Tooling, um solche Leichen zu erkennen. Da geht schon ein bisschen was, aber so richtig glücklich bin ich damit auch noch nicht.
Vn N. schrieb: > Dieses Problem ist aber technologieunabhängig, wenn ihr es mit Docke > habt, dann hättet ihr es auch ohne. Kaputte Prozesse können durch > technische Lösungen halt nur bedingt repariert werden. Faierweise muss man vielleicht dazusagen, dass eine (Linux) VM von der IT zentral gepatcht werden kann. Sei es durch automatische Update Policies oder durch Automatisierungen wie Ansible. Wenn irgendwo eine Dockercontainer rumdümpelt, der nichtmal mehr Systemupdates bekommt, merkt das erstmal keiner und die IT kann je nachdem auch außer abschalten nicht korrigierend eingreifen. Um eine Docker Umgebung aktuell zu halten, brauchst du schon ausgefeiltere Prozesse.
Beitrag #7339597 wurde von einem Moderator gelöscht.
Beitrag #7339725 wurde von einem Moderator gelöscht.
Beitrag #7339912 wurde von einem Moderator gelöscht.
Hans schrieb im Beitrag #7339725: > Der einzige > > Trolldetektor schrieb im Beitrag #7339597: >> Schwachkopp der hier von "Performance Vorteil" [ge]schwallt > > hat war, Trommelwirbel: > > Schukostecker schrieb: >> Docker benutzt im Gegensatz zu Jails Namespaces und Cgroups um einen >> Prozess zu isolieren und laeuft direkt auf deiner HW (Performance!). > > Schukostecker. Die eleganteste Art jemandem zu widersprechen, ist bekanntlich ihn zu zitieren. In diesem Sinne: Hans schrieb: > Das hast du ja mal wieder schön aus dem Kontext gerissen und > absichtlich missverstanden. Der Herr Schukostecker hat das Wort "Vorteil" nie gesagt, das hast Du Dir dazugedichtet damit Du endlich wieder herumpöbeln kannst. Denn daß VMs (um die es in jenen Abschnitt der Diskussion ging) einen negativen Einfluß auf die Performance haben, wie Schukostecker es implizit gesagt hat, ist unter Fachleuten natürlich ebenso bekannt wie unbestritten, auch wenn der Effekt auf modernen Prozessorarchitekturen nicht allzu groß ist. Im Übrigen gibt es eine Stelle in dieser Diskussion, die eindeutig zeigt, daß Du nur gegen Docker trollen willst, nämlich als die Frage aufkam, wie grafische X-Clients unter Docker betrieben werden können. Wenn Dich das wirklich interessieren würde, hättest Du ganz kurz eine dieser modernen "Internet-Suchmaschinen" benutzt und binnen Sekundenbruchteilen dieselbe Lösung dafür gefunden wie Herr Magnus und Herr Typ. Offensichtlich ging es Dir aber gar nicht um diese Frage sondern nur darum etwas zu konstruieren, das mit Docker angeblich nicht geht. So würde sich kein Mensch verhalten, der an einer ernsthaften, sachlichen Diskussion interessiert wäre. Auch Deine Pöbeleien, gefälschten Zitate und Deine Sockenpuppen zeigen klar daß Du nur trollen willst. Das kennen wir schon in Deinen Inkarnationen als Helmut, VMFreak, CISO und so weiter. Für den TE und die anderen Interessierten hier möchte ich aber dennoch meine Erfahrungen und die daraus gewonnenen Erkenntnisse schildern. Du solltest hier jetzt vielleicht nicht weiterlesen, HansHelmutVMFreakCISO, denn meine Ausführungen würden Dich womöglich verstören. In diesem Fall danke ich herzlich und wünsche einen schöneren Tag als gestern. Auch Docker hat einen negativen Einfluß auf die Performance, nämlich auf der Netzwerkebene durch S- oder DNAT. Andererseits sind das nur ein paar Einträge im IP-Stack des Kernels, deshalb ist der Gesamteinfluß natürlich überschaubar und insgesamt viel geringer als bei VMs. Gleichzeitig ist der Ressourcenbedarf bei Docker kleiner als bei VMs, denn in jeder VM müssen natürlich alle Prozesse des Betriebssystems ablaufen: Kernelthreads und diverse -Scheduler, ein Init-System und so weiter. Das kostet natürlich Prozessorlast, Festplatten- und Arbeitsspeicher. Man kann diesen Punkt gut einschätzen, wenn man die Unterschiede in der Startzeit ansieht: während ein Docker-Container quasi sofort den Prozeß startet muß bei einer VM vorher zunächst das Betriebssystem gebootet werden. Geteilte Ressourcen wie die Dateisystemlayer unter Docker, durch die eventuell die Festplatten und die Dateisystempuffer des Hostsystems effizienter genutzt werden könnten, sind mit VMs prinzipbedingt unmöglich. Auch die Angriffsoberfläche der Softwareumgebung kann mit Docker deutlich reduziert werden gegenüber VMs. In einer VM müssen nämlich üblicherweise verschiedene Systemprogramme installiert sein um die Funktion des Systems zu gewährleisten. In Docker-Images dagegen können die allermeisten dieser Werkzeuge hingegen einfach wieder entfernt werden. Die Arbeit ein Docker-Image zu härten ist zwar aufwändig, aus Ressourcen- und vor allem aus Sicherheitssicht jedoch sinnvoll und lohnend. Insofern bietet Docker in vieler Hinsicht handfeste Vorzüge gegenüber VMs, aber auch gegenüber dem nativen Betrieb. Während Dockers Vorzüge gegenüber dem nativen Betrieb sich im Wesentlichen auf das einfachere Deployment und Management, und in Teilen auch auf die Sicherheit beziehen, geraten die Vorteile gegenüber VMs noch deutlicher. Nichtsdestotrotz ist Docker zweifellos kein Allheilmittel und bedarf eines gewissen Aufwandes, um seine Vorteile voll ausnutzen zu können. Dabei ist ein automatisierter und gut gepflegter Workflow zweifellos ebenso sinnvoll wie entsprechende organisatorische Maßnahmen. Das lohnt sich natürlich erst ab einer gewissen Größenordnung oder bei besonderen Anforderungen - oder wenn ohnehin geplant ist, in eine Cloud zu migrieren, wo deren erweiterte Features wie Hochverfügbarkeit und automatische Skalierung winken.
Karl Käfer schrieb: > Der Herr Schukostecker hat das Wort "Vorteil" nie gesagt, das hast Du > Dir dazugedichtet damit Du endlich wieder herumpöbeln kannst. Denn daß > VMs (um die es in jenen Abschnitt der Diskussion ging) einen negativen > Einfluß auf die Performance haben, wie Schukostecker es implizit gesagt > hat, ist unter Fachleuten natürlich ebenso bekannt wie unbestritten, > auch wenn der Effekt auf modernen Prozessorarchitekturen nicht allzu > groß ist. Ok, er hat das Wort Vorteil nicht gesagt. Ob er es gesagt hat oder nicht ist aber völlig egal, denn er hat es gemeint. Selbst wenn nicht: Threadtitel ist VORTEILE von Docker. Wie sonst soll ich es also interpretieren? Und dann ist ganz klar: Wenn Docker (wie so oft) in einer VM läuft, geht Performance (ich benutzte das Wort Vorteil jetzt ganz bewusst nicht) verloren. Damit läuft die Anwendung nicht performanter als direkt in einer VM. Jetzt merkst du aber vielleicht auch selber, dass es in ganzen Sätzen eben mit dem Füllwort Vorteil wesentlich einfacher zu formulieren und verständlicher ist. Von daher verstehe ich eure ganze Aufregung darüber nicht. Es ist fachlich richtig. Punkt. In diesem Sinne: Hans schrieb: > Das hast du ja mal wieder schön aus dem Kontext gerissen und > absichtlich missverstanden. Karl Käfer schrieb: > Im Übrigen gibt es eine Stelle in dieser Diskussion, die eindeutig > zeigt, daß Du nur gegen Docker trollen willst Das ist völliger Quatsch. Denn es gibt auch ganz viele Stellen, an denen ich auf die Vorteile eingehe. Das überliest du Schaumschläger aber natürlich mal wieder ganz gekonnt. Scheinbar wollt ihr also eher gegen mich trollen. Karl Käfer schrieb: > nämlich als die Frage > aufkam, wie grafische X-Clients unter Docker betrieben werden können Und da merkt man, dass du die Frage nicht verstanden hast. Es ging konkret um die Kombination X-Anwendungen in Docker unter Wayland. Das habe ich halt noch nie gemacht und dachte tatsächlich, dass es wesentlich schwieriger ist bzw. unmöglich, da ggf. die Sockets so nicht da sind oder inkompatibel. Aber dafür ist ein Forum da: Fragen stellen und Dinge lernen. Das kann ich in Zukunft anwenden. Auch die Frage des TO hätte dieser einfach mal schnell Googeln können. Wäre auch nichts anderes rausgekommen. Willst du also in einem Forum Fragen verbieten? Karl Käfer schrieb: > Auch Docker hat einen negativen Einfluß auf die Performance, nämlich auf > der Netzwerkebene durch S- oder DNAT. Bei mir nicht. Meine Container sind über ein sauber geroutetes Netzwerk erreichbar. Das richtig zu konfigurieren kriegen eben nur die Besten hin, bietet aber richtig viele Vorteile. Mein gesamtes Kubenertes Cluster läuft sogar im Dualstack. Das kriegen nur die Besten der Besten hin. NAT kommt mir nur im äußersten Notfall ins Haus. Karl Käfer schrieb: > Auch die Angriffsoberfläche der Softwareumgebung kann mit Docker > deutlich reduziert werden gegenüber VMs. In einer VM müssen nämlich > üblicherweise verschiedene Systemprogramme installiert sein um die > Funktion des Systems zu gewährleisten. In Docker-Images dagegen können > die allermeisten dieser Werkzeuge hingegen einfach wieder entfernt > werden. Die Arbeit ein Docker-Image zu härten ist zwar aufwändig, aus > Ressourcen- und vor allem aus Sicherheitssicht jedoch sinnvoll und > lohnend. Dazu haben Andere und auch ich schon genug geschrieben. Das ist ein sehr ambivalentes Thema. Aber ja: Wenn man genug Aufwand reinsteckt, kann man damit sehr sichere Systeme bauen. Ansonsten möchte ich mich jetzt dazu nicht wiederholen. Auf deine weiteren Ausführungen zu den Vorteilen von Docker (darf ich das sagen, bin mir nämlich gerade nicht sicher, ob du das Wort verwendet hast, will dir ja nicht unterstellen, dass du über Vorteile referiert hast) gehe ich nicht ein, da ich ihnen ausnahmslos zustimme. Und jetzt frage ich auch dich: Passt dieses Verhalten zu deinen Vorwürfen gegen mich? Wohl kaum! Also erwarte ich eine Entschuldigung von dir. Ich habe eher den Eindruck, dass hier Docker Evangelisten unterwegs sind, die keinerlei Kritik vertragen können und jeglichen Nachteil oder auch eine (kritische) Frage sofort als persönlichen Angriff werden. Und ja: Solche Leute bezeichne ich dann irgendwann auch mal zurecht als Schaumschläger. Denn sie sind nichts anderes.
@Dacia-Fahrer (Gast) Der Beitrag Beitrag "Re: Vorteile von Docker?" zeigt eine Anwendung von Docker Applikationen auf zwei Pi4, einem NUC und einem Notebook. Auf allen Rechnern läuft eine Docker-Umgebung unter IOTstack. Die Pi4 sammeln [°C]- und [H%]-Daten an verschiedenen Orten mit docker-TFREC und speichern diese mit docker-Mosquitto und docker-Nodered im NUC in einer docker-Influx-DB. Das Notebook visualisiert die docker-Influx-Daten mit docker-Grafana. IOTstack: https://sensorsiot.github.io/IOTstack/Basic_setup/ IOTstack erzeugt menü-geführt eine Docker-Umgebung für Raspberry-Pi4. Das menu.sh ist auch auf weitere Docker-Applikationen erweiterbar. IOTstack funktioniert mit Linux(-Mint) auch auf PC-Plattformen unter X86_64. Die oben verlinkten Videos von Andreas Spiess zeigen, wie IOTstack eingerichtet wird, wie Daten in dieser docker-Umgebung gesammelt, verarbeitet, gespeichert und dargestellt werden und wie die docker-Umgebung unter Erhalt der Daten im Fehlerfall neu aufgesetzt wird. Das Notebook wird ausserhalb Docker für alle üblichen Anwendungen eingesetzt. IOTstack läuft im Hintergrund und ermöglicht bei Bedarf im Browser einen Zugriff auf die gespeicherten Daten.
Hans schrieb: > Ok, er hat das Wort Vorteil nicht gesagt. Ob er es gesagt hat oder nicht > ist aber völlig egal, denn er hat es gemeint. Schauen wir doch einfach mal an, was Schuko gesagt hat, und nehmen zur besseren Orientierung ein wenig Kontext hinzu: Schukostecker schrieb: > Du verwechseltst (wie so viele) VMs und Container. Ein Container und > eine VM haben ueberhaupt nichts miteinander zu tun. > > Docker benutzt im Gegensatz zu Jails Namespaces und Cgroups um einen > Prozess zu isolieren und laeuft direkt auf deiner HW (Performance!). > > Die VM laeuft auf virtueller HW (Qemu eingebetted in KVM,..). Mit den > bekannten Vor- und Nachteilen. Also ich finde das sehr eindeutig und klar, daß sich seine Aussage über die Performance auf die Hardware bezieht, auf der der Prozeß läuft: entweder im Fall von Docker "direkt auf Deiner HW", was in diesem von ihm beschriebenen Fall tatsächlich Performancevorteile hat, oder "auf virtueller HW" im Falle einer Virtualisierung mit den bekannten Performancenachteilen. In dem Satz vor jenem mit der Performance erwähnt er VMs gleich zweimal, und im darauf folgenden Satz dann sogar noch einmal. Also bitte... wie eindeutig hätte er seine Aussagen denn noch formulieren sollen? Du gehst auf seine Aussagen aber gar nicht ein, sondern machst einfach ein anderes Szenario mit einer (IMO durchaus fragwürdigen) Aussage auf: Hans schrieb: > Schukostecker schrieb: >> Die VM laeuft auf virtueller HW (Qemu eingebetted in KVM,..). Mit den >> bekannten Vor- und Nachteilen. > > Wo läuft Docker denn wirklich auf echter Hardware? In den ganzen Clouds > mit Sicherheit nicht. Das mag sein, war aber nicht sein Punkt. Er sprach gar nicht über Clouds, sondern im Gegenteil ausdrücklich vom direkten Betrieb "auf Deiner HW". Deine Behauptung, in Clouds würde Docker "mit Sicherheit" überwiegend auf virtualisierter Hardware betrieben, halte ich zudem für zweifelhaft. Ist das wirklich so? Hast Du Belege oder wenigstens Indizien dafür? Wie auch immer, unterhalte ich mich dann kurz mit Schukostecker, und dann kommst Du zu folgender Antwort auf mich: Hans schrieb: > Ein T. schrieb: >> Richtig. Zudem glaube ich, daß die Diskussionen über Docker viel zu oft >> die Ähnlichkeiten mit den klassischen Virtualisierungsansätzen gesehen >> wird. Es geht aus meiner Sicht aber eher um Deployment und >> Lifecycle-Management. > > Also wenn mir jemand mit dem Performance Vorteil kommt, muss er nun mal > einsehen, dass docker in vielen Umgebungen tatsächlich ein zusätzlicher > Layer auf einer VM ist. Mal abgesehen von den paar Ausnahmen wo jemand > lokal rumbastelt oder sein Cluster on-prem in Hardware aufbaut. Wie gesagt: er sprach ausdrücklich und klar erkennbar vom Betrieb von Docker direkt auf der Hardware, von nichts anderem. Außerdem ist mir noch etwas aufgefallen. Zuerst sagst Du: Hans schrieb: > Da hilft es nicht etwas über andere Vorteile zu erzählen und abzulenken. ...aber einige Beiträge später siehst Du das plötzlich anders: Hans schrieb: > Selbst wenn nicht: Threadtitel ist VORTEILE von Docker. Wie muß ich das jetzt verstehen: einerseits geht es hier jetzt zwar um die "VORTEILE von Docker", aber andererseits "hilft es nicht etwas über andere Vorteile zu erzählen"? Und noch viel verwirrender finde ich, daß Du Schuko und mir dann auch noch unterstellst, über andere "VORTEILE von Docker" zu sprechen diene nur dazu, "abzulenken". Bitte was? Wovon? Vom Threadthema, das Dir ausweislich Deiner eigenen Aussagen doch absolut bewußt war?
Ein T. schrieb: > Das mag sein, war aber nicht sein Punkt. Er sprach gar nicht über > Clouds, sondern im Gegenteil ausdrücklich vom direkten Betrieb "auf > Deiner HW". Ich aber. Und den Rest deiner Ergüsse lese ich gar nicht mehr. Hab keinen Bock auf dich.
Hans schrieb: > Ein T. schrieb: >> Das mag sein, war aber nicht sein Punkt. Er sprach gar nicht über >> Clouds, sondern im Gegenteil ausdrücklich vom direkten Betrieb "auf >> Deiner HW". > > Ich aber. Und den Rest deiner Ergüsse lese ich gar nicht mehr. Hab > keinen Bock auf dich. Tja, da hat Dich der Typ ja wieder einmal so richtig schön entlarvt. Ich verstehe jetzt immerhin, warum Du Docker und Kubernetes so haßt: wenn man unbedingt alles anders machen will, als es vorgesehen ist und es der Rest der Welt macht, dann macht man sich nur Ärger. Der hat aber nichts mit der Technik zu tun, sondern mit der eigenen kindischen Bockigkeit. Damit wird man sicher nicht zu einem "Besten der Besten", sondern höchstens zu einer bockigen kindischen Luftpumpe. Und ganz genau so präsentierst Du Dich dann auch jetzt wieder. LOL.
Trolldetektor schrieb: > Hans schrieb: >> Ein T. schrieb: >>> Das mag sein, war aber nicht sein Punkt. Er sprach gar nicht über >>> Clouds, sondern im Gegenteil ausdrücklich vom direkten Betrieb "auf >>> Deiner HW". >> >> Ich aber. Und den Rest deiner Ergüsse lese ich gar nicht mehr. Hab >> keinen Bock auf dich. > > Tja, da hat Dich der Typ ja wieder einmal so richtig schön entlarvt. Nö. Auf was für Hardware laufen Kubernetes Cluster in der Cloud? Richtig, auf virtueller. Profitiere ich dann von der Performance bei Ausführung direkt auf der Hardware? Nein! Für 80% aller Cluster ist das kein Vorteil. Mehr habe ich nicht gesagt. Ist nicht schlimm. Ist nur eben oft kein anwendbarer Vorteil. Aber wenn man das immer wieder überliest, ist einem nicht mehr zu helfen. > Ich verstehe jetzt immerhin, warum Du Docker und Kubernetes so haßt: Ach wenn du doch nur lesen könntest. Dann hättest du vielleicht verstanden, dass das nicht so ist. > wenn man unbedingt alles anders machen will, als es vorgesehen ist und > es der Rest der Welt macht, dann macht man sich nur Ärger. Leute esst mehr Scheiße, Milliarden von Fliegen können nicht irren. Was genau spricht gegen den Betrieb von Docker Containern / Kubernetes Clustern in einer VM? Richtig! Nichts. Macht übrigens der Rest der Welt auch so. Was spricht gegen sauber geroutete Netzwerkverbindungen zu den Containern? Richtig! Nichts. Dafür sprechen aber Performance und Nachvollziehbarkeit von Netzwerkverbindungen. Was spricht gegen Dualstack Cluster? Richtig! Nichts. Dafür spricht aber die Zukunftsfähigkeit und ganz konkret auch ein Kostenvorteil. Wenn der Rest der Welt das nicht so macht, bitte. Für mich hat sich das ganz klar bewährt. > Der hat aber > nichts mit der Technik zu tun, sondern mit der eigenen kindischen > Bockigkeit. Damit wird man sicher nicht zu einem "Besten der Besten", > sondern höchstens zu einer bockigen kindischen Luftpumpe. Ich bin bockig, weil ich es richtig mache? Glaube nicht. Und lieber Luftpumpe als Schaumschläger. Denn eine Luftpumpe kann man im Alltag öfter mal gebrauchen. Ein Schaumschläger löst dagegen bestenfalls Luxusprobleme. > Und ganz genau so präsentierst Du Dich dann auch jetzt wieder. LOL. Gegenüber Schaumschlägern wie dir und dem komischen Typen gibt es kein anderes angebrachtes Verhalten.
Beitrag #7344118 wurde von einem Moderator gelöscht.
Beitrag #7344119 wurde von einem Moderator gelöscht.
Beitrag #7344163 wurde von einem Moderator gelöscht.
Beitrag #7345224 wurde von einem Moderator gelöscht.
Beitrag #7345276 wurde von einem Moderator gelöscht.
Beitrag #7345475 wurde von einem Moderator gelöscht.
Beitrag #7345596 wurde von einem Moderator gelöscht.
Beitrag #7345635 wurde von einem Moderator gelöscht.
Beitrag #7345662 wurde von einem Moderator gelöscht.
Beitrag #7345832 wurde von einem Moderator gelöscht.
Beitrag #7346039 wurde von einem Moderator gelöscht.
Beitrag #7346136 wurde von einem Moderator gelöscht.
Beitrag #7346185 wurde von einem Moderator gelöscht.
Hans schrieb: > Trolldetektor schrieb: >> Hans schrieb: >>> Ein T. schrieb: >>>> Das mag sein, war aber nicht sein Punkt. Er sprach gar nicht über >>>> Clouds, sondern im Gegenteil ausdrücklich vom direkten Betrieb "auf >>>> Deiner HW". > Nö. Auf was für Hardware laufen Kubernetes Cluster in der Cloud? > Richtig, auf virtueller. Naja, zum Schluss ist immer Hardware drunter. Nur das die Netzwerkressourcen für eine bessere Skalierbarkeit in Form von Diensten zur Verfügung gestellt werden (Infrastruktur, Plattform, Software). Auf Azure läuft zu Hauf Docker u.ä., viel häufiger als VMs. > Was spricht gegen Dualstack Cluster? Richtig! Nichts. Dafür spricht aber > die Zukunftsfähigkeit und ganz konkret auch ein Kostenvorteil. > Da bin jetzt aber gespannt, wo Du da die Zahlen rauskramst. > Wenn der Rest der Welt das nicht so macht, bitte. Für mich hat sich das > ganz klar bewährt. Das ist doch OK. Du musst dem Trend ja nicht folgen, der vor allem kostengetrieben von den großen Konsumenten voran gebracht wird. https://www.computerweekly.com/de/tipp/Bare-Metal-versus-virtuelle-Maschinen-als-Kubernetes-Host Nachtrag: noch ein Link… https://blog.adacor.com/kubernetes-lohnt-sich-der-einsatz-fuer-ihr-unternehmen_10681.html
:
Bearbeitet durch User
Uwe D. schrieb: > Hans schrieb: >> Trolldetektor schrieb: >>> Hans schrieb: >>>> Ein T. schrieb: >>>>> Das mag sein, war aber nicht sein Punkt. Er sprach gar nicht über >>>>> Clouds, sondern im Gegenteil ausdrücklich vom direkten Betrieb "auf >>>>> Deiner HW". >> Nö. Auf was für Hardware laufen Kubernetes Cluster in der Cloud? >> Richtig, auf virtueller. > Naja, zum Schluss ist immer Hardware drunter. Nur das die > Netzwerkressourcen für eine bessere Skalierbarkeit in Form von Diensten > zur Verfügung gestellt werden (Infrastruktur, Plattform, Software). > Auf Azure läuft zu Hauf Docker u.ä., viel häufiger als VMs. Darum ging es nicht. Thema verfehlt. Natürlich ist immer Hardware drunter, aber den Performancevorteil kann ich eben nicht ausnutzen, wenn eine VM dazwischen liegt. Aber nochmal für dich: Das ist nicht schlimm. Uwe D. schrieb: >> Was spricht gegen Dualstack Cluster? Richtig! Nichts. Dafür spricht aber >> die Zukunftsfähigkeit und ganz konkret auch ein Kostenvorteil. >> > Da bin jetzt aber gespannt, wo Du da die Zahlen rauskramst. Eine IPv4 Adresse kostet im Einkauf etwa 45$. Das kleinstmögliche Netz, das ich für ein ASN einkaufen kann ist ein /24, kostet also 11520$ zuzüglich Maklerprovision. Wenn ich für M2M Kommunikation auf IPv6 Only setzen kann, spart das massiv Kosten. Die v4 Adressen muss ich nicht für irgendwelche Loadbalancer vergeuden. Dem Gegenüber stehen kosten von 0€ für ein weiteres IPv6 Netz, zumal das vorhandene (ich glaube /32) noch lange reichen wird. Verstehe jetzt aber auch nicht, welches Problem du damit hast, dass ich ein Dualstack Cluster betreibe. Uwe D. schrieb: >> Wenn der Rest der Welt das nicht so macht, bitte. Für mich hat sich das >> ganz klar bewährt. > Das ist doch OK. Du musst dem Trend ja nicht folgen, der vor allem > kostengetrieben von den großen Konsumenten voran gebracht wird. > > https://www.computerweekly.com/de/tipp/Bare-Metal-versus-virtuelle-Maschinen-als-Kubernetes-Host Sorry, Thema verfehlt. Es ging um IPv6 im Cluster und NAT-Freies Routing. > Nachtrag: noch ein Link… > https://blog.adacor.com/kubernetes-lohnt-sich-der-einsatz-fuer-ihr-unternehmen_10681.html Verstehe nicht was du mir damit sagen willst. Ich setze Kubernetes doch schon ein. Insgesamt: Setzen, sechs!
Hans schrieb: > Uwe D. schrieb: >> Auf Azure läuft zu Hauf Docker u.ä., viel häufiger als VMs. > Darum ging es nicht. Thema verfehlt. Doch, nur Du selbst redest ständig von den VMs. Es ist Deine Präferenz, aber nicht die einzige Möglichkeit. > Uwe D. schrieb: >>> die Zukunftsfähigkeit und ganz konkret auch ein Kostenvorteil. >> Da bin jetzt aber gespannt, wo Du da die Zahlen rauskramst. > Eine IPv4 Adresse kostet im Einkauf etwa 45$. Das kleinstmögliche Netz, > … ++Schnipp++ > lange reichen wird. Verstehe jetzt aber auch nicht, welches Problem du > damit hast, dass ich ein Dualstack Cluster betreibe. Kein Problem, das behauptest Du. Mir ging es um die Kosten. > > Uwe D. schrieb: > https://www.computerweekly.com/de/tipp/Bare-Metal-versus-virtuelle-Maschinen-als-Kubernetes-Host > Sorry, Thema verfehlt. Es ging um IPv6 im Cluster und NAT-Freies > Routing. Das war Dein Thema - Du hast über DS & NAT geredet, nicht ich oder der TO. Und in dem Link geht es um die Basis, auf denen Kubernetes läuft. Da steht nicht drin „100% VMs“. >> Nachtrag: noch ein Link… >> > https://blog.adacor.com/kubernetes-lohnt-sich-der-einsatz-fuer-ihr-unternehmen_10681.html > Verstehe nicht was du mir damit sagen willst. Ich setze Kubernetes doch > schon ein. > Insgesamt: Setzen, sechs! Es ging dem TO um sinnvolle Einsatzmöglichkeiten. Und Du hast sinnvolle Möglichkeiten im Einsatz, mehr wollte der TO nicht. Der Link gibt dem geneigten Leser den einen oder anderen Hinweis, ob diese Technologie für dessen Produkte geeignet ist. Der TO darf doch auch lesen, oder? PS: Du musst mich nicht verbal niederringen. Es geht ja nicht um mich.
Uwe D. schrieb: > Mir ging es um die Kosten. Ihm auch. Aber unter der Prämisse seines unprofessionellen und kindischen Hasses gegen NAT. > Das war Dein Thema - Du hast über > DS & NAT geredet, nicht ich oder > der TO Er redet halt gern über seine eigenen Themen. Die müssen nichts mit dem Thema des Threads zu tun haben. Oder mit dem was die von ihm zitierten Vorredner gesagt haben.
Uwe D. schrieb: > Hans schrieb: >> Uwe D. schrieb: >>> Auf Azure läuft zu Hauf Docker u.ä., viel häufiger als VMs. >> Darum ging es nicht. Thema verfehlt. > > Doch, nur Du selbst redest ständig von den VMs. Es ist Deine Präferenz, > aber nicht die einzige Möglichkeit. was meinst du denn, was du bekommst, wenn du im Azure ein System mit 4 CPU Einheiten und 16 GB RAM erstellst? Richtig, eine VM. Und jetzt die Frage aller Fragen: Läuft der Docker Container dann direkt auf der Hardware? Und jetzt gehen wir mal einen Schritt weiter und fragen uns, was wohl passiert, wenn du direkt ein Kubernetes Cluster bei einem Cloud Anbieter deiner Wahl erstellst. Glaubst du wirklich, dass das auf echter Hardware ohne eine VM läuft? Und jetzt merken wir: Dass Docker und insbesondere Kubernetes direkt auf der physischer Hardware läuft, ist eher ein Corner-Case als die Regel. Damit einher geht aber auch, dass es in diesen Fällen eben nicht den vom Schaumschläger versprochenen Performancegewinn gibt. Aber bevor du das wieder aus dem Kontext reißt: Nein das ist kein Nachteil. Aber man kann eben nicht Pauschal von einem Vorteil sprechen. Auf den Rest deines Geschreibsels gehe ich nicht ein. Das hat einen einfachen Grund. Ich habe hier nur auf jemanden reagiert, der behauptete Docker verliere Netzwerkdurchsatz durch den Einsatz von NAT. War also nicht mein Thema.
Trolldetektor schrieb: > Uwe D. schrieb: >> Mir ging es um die Kosten. > > Ihm auch. Aber unter der Prämisse seines unprofessionellen und > kindischen Hasses gegen NAT. > Aufgabe: Nennen Sie drei Vor- und drei Nachteile beim Einsatz von NAT in einem Kubernetescluster.
Hans schrieb: > Auf den Rest deines Geschreibsels gehe ich nicht ein. Ich will jetzt halt einfach auch mal Recht haben:-)
:
Bearbeitet durch User
Joe J. schrieb: > Hans schrieb: >> Auf den Rest deines Geschreibsels gehe ich nicht ein. > > Ich will jetzt halt einfach auch mal Recht haben:-) Nö. Das habe ich ja sowieso. Aber hier mit jemandem darüber zu diskutieren, wer wann welche Diskussion angefangen hat, halte ich jetzt wirklich für müßig. Du kannst mein Geschreibsel aber gerne fachlich angreifen.
Hans schrieb: > Trolldetektor schrieb: >> Uwe D. schrieb: >>> Mir ging es um die Kosten. >> >> Ihm auch. Aber unter der Prämisse seines unprofessionellen und >> kindischen Hasses gegen NAT. >> > Aufgabe: Nennen Sie drei Vor- und drei Nachteile beim Einsatz von NAT in > einem Kubernetescluster. Ich sehe schon, kannst du nicht. Drei Vorteile kann ich auch nicht nennen, aber drei Nachteile. Damit liegt es an dir zu beweisen, dass du du nicht der Troll bist und ich falsch liege mit meiner Abneigung gegen NAT im Kubernetes Cluster. Vorteil: Einfachere Konfiguration Nachteile: - Auswirkungen auf die Perfomance durch NAT States - Nachvollziehbarkeit von Logeinträgen leidet, da in Logfiles die IP-Adressen der Nodes, aber nicht der Pods auftauchen - Manche Applikationen (z.B. SIP Clients) haben Probleme mit NAT und können nur über einen externen Proxy/STUN Server betrieben werden
Beitrag #7348655 wurde von einem Moderator gelöscht.
Beitrag #7348676 wurde von einem Moderator gelöscht.
Hans schrieb: > Dass Docker und insbesondere Kubernetes direkt auf > der physischer Hardware läuft, ist eher ein Corner-Case als die Regel. Das ist nur Deine Behauptung aber bisher konntest Du sie nicht belegen. > Damit einher geht aber auch, dass es in diesen Fällen eben nicht den vom > Schaumschläger versprochenen Performancegewinn gibt. Du mußt dringend lesen lernen. Diese Behauptung hattest Du böswillig dem Schukostecker unterstellt obwohl er das nie gesagt hat. Der Typ hat Dir das erklärt aber Du warst bockig und wolltest ihn nicht lesen. Was Du echt kannst und nur darin bist Du der "Beste der Besten": dummschwätzen, trollen, böswillige Unterstellungen und unbewiesene Behauptungen aufstellen, böswillig falsch zitieren, mit Strohmännern und Sockenpuppen "arbeiten" und bei ernsthaftem Widerspruch mit echten Argumenten bockig werden und alles verweigern. Jetzt schon zum zweiten Mal. Lachnummer.
Beitrag #7348678 wurde von einem Moderator gelöscht.
Beitrag #7348679 wurde von einem Moderator gelöscht.
Beitrag #7348700 wurde von einem Moderator gelöscht.
Beitrag #7348723 wurde von einem Moderator gelöscht.
Beitrag #7348735 wurde von einem Moderator gelöscht.
Beitrag #7348740 wurde von einem Moderator gelöscht.
Beitrag #7348787 wurde von einem Moderator gelöscht.
Beitrag #7348798 wurde von einem Moderator gelöscht.
Beitrag #7348801 wurde von einem Moderator gelöscht.
Beitrag #7348806 wurde von einem Moderator gelöscht.
Beitrag #7348827 wurde von einem Moderator gelöscht.
Beitrag #7348829 wurde von einem Moderator gelöscht.
Beitrag #7348868 wurde von einem Moderator gelöscht.
Beitrag #7348872 wurde von einem Moderator gelöscht.
Beitrag #7349021 wurde von einem Moderator gelöscht.
Beitrag #7349024 wurde von einem Moderator gelöscht.
Beitrag #7349186 wurde von einem Moderator gelöscht.
Ihr macht hier einen ganz schönen Kindergarten. Der Behauptung, dass Docker häufig, wenn nicht sogar überwiegend auf virtuellen Servern betrieben wird, kann ich nur beipflichten. Die meisten heutzutage gemieteten Server sind nun mal vServer und VPS. Und auf denen laufen dann ein, zwei oder mal mehrere Projekete in ihren jeweiligen Docker Containern. Besonders viele Vorteile bietet das dann oft nicht, gegenüber klassischen Strukturen. Insbesondere im Webbereich, wenn auf den Containern dann irgendeine alte Version von irgendeinem Framework, etc läuft ist das nicht unbedingt ein Plus an Sicherheit. Statt ein Basissystem aktuell zu halten und den Projektcode nachzuziehen, muss man dann ein Basisystem, x-Container und den Projektcode aktuell halten. Es verschieben sich oft nur die Zuständigkeiten, was für viele Verantwortliche die Sache attraktiver macht...
Hans schrieb: > Auf was für Hardware laufen Kubernetes Cluster in der Cloud? > Richtig, auf virtueller. Nein du verdrehst da irgendwie völlig etwas... die Kubernetes Cluster laufen auf reiner Hardware und stellen die Virtuellen zur Verfügung. DAS ist der Sinn hinter KN Clustern.
Docktor schrieb: > hat jemand ein Beispiel aus dem Alltag, wo Docker sinnvoll war? Ich nutze Docker als Anwender auf meinem Heimserver und hätte evtl. wirklich ein Beispiel aus dem Alltag im Angebot: Auf der Kiste läuft auch NextCloud-Stack mit einer MariaDB-Datenbank. Da gab es vor nicht all zu langer Zeit ein NextCloud-Update das sich mit der MariaDB nicht mehr verstanden hat (war m.W. ein Feature, kein Bug,..). Im Stackfile das Tag für den NextCloudcontainer passend zu einer älteren noch funktionsfähigen Version gesetzt, Stack neu gestartet und läuft wieder. Als dann ein Update kam, das den Fehler behoben hat, wieder das Tag latest gesetzt. Für mich ist auch ein großer Vorteil, dass ich den Container Watchtower mit laufen lassen kann. Der aktualisiert ohne mein Zutun regelmäßig sämtliche Container - es haben sich mittlerweile doch schon einige angesammelt - und das ohne mein Zutun. Für mich ist da der Arbeitsaufwand mal ein verschlucktes Update auszubessern deutlich geringer als die ganze Zeit den Updates der Einzelanwendungen hinterher zu laufen.
Rene K. schrieb: > Nein du verdrehst da irgendwie völlig etwas... die Kubernetes Cluster > laufen auf reiner Hardware und stellen die Virtuellen zur Verfügung. DAS > ist der Sinn hinter KN Clustern. Achso. Und weil das so ist bietet Amazon sein EKS erst seit Juni 2022 in allen Regionen als Bare Metal an? https://aws.amazon.com/about-aws/whats-new/2022/06/bare-metal-support-amazon-eks-anywhere/ Dann erklär mir doch mal, auf was für Hardware ECS läuft. Sorry, du hast mal überhaupt keine Ahnung.
Hans schrieb: > Dann erklär mir doch mal, auf was für Hardware ECS läuft. Sorry, du hast > mal überhaupt keine Ahnung. Auf Annapurna ASICs - solltest du eigentlich wissen.
Rene K. schrieb: > Auf Annapurna ASICs - solltest du eigentlich wissen. Das ändert überhaupts nichts daran, dass EC2 Ressourcen und damit ECS virtualisiert sind - solltest du eigentlich wissen.
Micha schrieb: > Ihr macht hier einen ganz schönen Kindergarten. +1 > Der Behauptung, dass Docker häufig, wenn nicht sogar überwiegend auf > virtuellen Servern betrieben wird, kann ich nur beipflichten. Geht es hier denn um eine demokratische Entscheidung? Das glaube ich nicht, und solange nicht Einer von Euch es schafft, reale Belege dafür zu liefern, daß Docker vornehmlich auf virtualisierter Hardware betrieben wird, ist und bleibt das nur eine unbewiesene Behauptung. Daß AWS und meinetwegen auch Azure und GCP das so machen mögen, wird wohl sein, aber Public Clouds sind ja nicht die Welt und allein mir persönlich sind schon mehrere Anbieter bekannt, die Containerlösungen auf Bare Metal betreiben. In derartigen Umgebungen spielt die Containerisierung natürlich dann auch ihre Performancevorteile aus. Obendrein ist "Performance" ja ein Wieselwort, das unterschiedliche Aspekte beschreiben kann -- da geht es mitunter nicht nur um die Geschwindigkeit der Ausführung, wie Interessierte gerne in den betreffenden Artikel der Wikipedia (als Einstieg) [1,2] nachlesen können. Vor diesem Hintergrund kann die Containerisierung auch in virtualisierten Umgebungen einen Performancevorteil erzielen. Denn es ist ein signifikanter Unterschied, ob ich jetzt n Applikationen in Containern in einer VM, oder dieselben n Applikationen in n VMs auf derselben Hardware betreibe. Denn in den n VMs laufen n vollständige Betriebssysteme, jedes einzelne davon mit etlichen Kernelthreads, mehreren Schedulern, einem mitunter komplexen Init-System, und so weiter, und so fort. Das heißt: bei zwanzig VMs laufen viel mehr Prozesse und Threads auf der Hardware, die jeweils alle miteinander um die vorhandenen Ressourcen konkurrieren. Sobald die Resourcen ein bisschen unter Druck geraten, sind die Container dann auch schneller. [1] https://de.wikipedia.org/wiki/Rechenleistung [2] https://en.wikipedia.org/wiki/Computer_performance > Die meisten heutzutage gemieteten Server sind nun mal vServer und VPS. > Und auf denen laufen dann ein, zwei oder mal mehrere Projekete in ihren > jeweiligen Docker Containern. Wenngleich vor allem Docker primär Themen wie Deployment und Lifecycle-Management betrifft, ist der Betrieb auf Servern ja nur ein Teil dessen, wofür es genutzt wird. Die Entwickler, die ihre Tools in Docker laufen lassen, die Anwender, die containerisierte Anwendungen nutzen, die CI- und CD-Umgebungen, die Docker fürs Testing und Deployment nutzen, und natürlich die vielen kleinen und mittelgroßen Cloud-Anbieter, die Containerlösungen auf Bare Metal anbieten: all das sind ja ebenfalls valide und häufige Anwendungsfälle. Vielleicht kommen diese Anwendungsfälle zusammengenommen sogar viel häufiger vor als die Nutzung in den großen Public Clouds. Wer etwas anderes behauptet, möge es entweder mit seriösen Quellen belegen, wie das unter Erwachsenen in seriösen Diskussionen üblich ist, oder bitte endlich damit aufhören, unbelegte Behauptungen zu äußern, nur um irgendwie auf irgendeine Art und Weise so etwas wie "Recht" behalten zu können. > Besonders viele Vorteile bietet das dann oft nicht, gegenüber > klassischen Strukturen. Doch, der Betrieb von Containern ist wesentlich ressourcenschonender als der von VMs, die dasselbe leisten. > Insbesondere im Webbereich, wenn auf den > Containern dann irgendeine alte Version von irgendeinem Framework, etc > läuft ist das nicht unbedingt ein Plus an Sicherheit. Das kommt darauf an, wie man es macht. Wenn man es wirklich richtig macht, nämlich mit minimierten Containern unter AppArmor / SELinux, Seccomp und Co stellt es wahrscheinlich nurmehr ein kosmetisches Problem dar, veraltete Software mit Sicherheitslücken in Containern zu betreiben. Denn dann kann ein Angreifer vielleicht in einen Container eindringen, dort aber rein gar nichts mehr ausnutzen, um seine Privilegien zu erweitern oder gar den Host zu kapern. Proaktiv verstandene Sicherheit geht davon aus, daß Software mit hoher Wahrschenlichkeit Sicherheitslücken haben wird, auch wenn sie noch nicht entdeckt worden sind. Erschwerend kommt hinzu, daß dasselbe Problem auch für Bare Metal und VMs gilt: wenn sie gehärtet und nicht gepflegt werden, dann hat die Sicherheit genau dieselben Probleme wie bei ungepflegten Dockercontainern. Es ist im höchsten Maße unseriös, perfekt gepflegte Software auf VMs und Bare Metal zu vergleichen, Containern allerdings gleichzeitig immer schlechte Pflege und veraltete Software zu unterstellen. > Statt ein > Basissystem aktuell zu halten und den Projektcode nachzuziehen, muss man > dann ein Basisystem, x-Container und den Projektcode aktuell halten. Es ist -- vor allem, wenn die betreffende Software und Abhängigkeiten nicht vom Distributor paketiert sind -- häufig wesentlich schwieriger, Software auf Bare Metal und in VMs zu pflegen. > Es verschieben sich oft nur die Zuständigkeiten, was für viele > Verantwortliche die Sache attraktiver macht... Genau, die blöden Verantwortlichen... möchtest Du uns etwas sagen, oder soll das nur irgendwelche blöden Vorurteile bedienen?
Beitrag #7349690 wurde von einem Moderator gelöscht.
Ein T. schrieb: > Geht es hier denn um eine demokratische Entscheidung? Das glaube ich > nicht, und solange nicht Einer von Euch es schafft, reale Belege dafür > zu liefern, daß Docker vornehmlich auf virtualisierter Hardware > betrieben wird, ist und bleibt das nur eine unbewiesene Behauptung. Ich habe nur aus meinem Alltag als Entwickler berichtet und dort treffe ich diesen Anwendungsfall einfach häufig an. Ausnahme bilden natürlich lokale Testumgebungen der Entwickler. Oder auch einige die spezielle Docker Clouds nutzen, dort werden die Container mit Sicherheit auf dedizierter Hardware aufgeführt. Viele Kunden möchten und bestehen auf "mein eigener Server". Denen ist dann egal ob virtuell oder dediziert, aber es muss eben ein eigener Server sein und keine reiner Docker Cloud. Ist wohl noch so in den Köpfen verankert. > Doch, der Betrieb von Containern ist wesentlich ressourcenschonender als > der von VMs, die dasselbe leisten. Mit Vorteilen meinte ich in diesem Zusammenhang menschlicher Natur. Also Wartungsaufwand, etc. > Denn dann kann ein Angreifer vielleicht in einen Container > eindringen, dort aber rein gar nichts mehr ausnutzen, um seine > Privilegien zu erweitern oder gar den Host zu kapern. Genau das ist ja schon ein worst case. Er kommt zwar vielleicht nicht auf den Host oder andere Projekte, aber bekommt Zugriff auf sensible (personenbezogene) Daten und kann diese im schlimmsten Fall auch noch verändern. > Es ist im höchsten Maße unseriös, perfekt gepflegte > Software auf VMs und Bare Metal zu vergleichen, Containern allerdings > gleichzeitig immer schlechte Pflege und veraltete Software zu > unterstellen. Richtig, unterstelle ich auch nicht. Es ist aber oft mehr Aufwand (v.a. bei heterogener Umgebung) bestimmte Bibliotheken auf x Containern zu aktualisieren, als 1-mal auf einem Host der x Projekte hält. > Es ist -- vor allem, wenn die betreffende Software und Abhängigkeiten > nicht vom Distributor paketiert sind -- häufig wesentlich schwieriger, > Software auf Bare Metal und in VMs zu pflegen. Genau das ist doch das Problem der Container. Stammen diese von einem externen Dienstleister rührt die niemand an, sofern der Dienstleister diese nicht neu paketiert und versioniert hat. D.h. diese Container vegetieren dann vor sich hin, egal wie alt die Bibliotheken innerhalb des Containers sind. > Genau, die blöden Verantwortlichen... möchtest Du uns etwas sagen, oder > soll das nur irgendwelche blöden Vorurteile bedienen? Nein, aber genau so wird das gerne gemacht. Eine eh schon knapp besetzte IT Abteilung führt genau das gerne als Vorteil an. Hersteller XY liefert das Produkt im fertigen Container, wir müssen uns um nichts mehr kümmern. Nachdem der Wartungsvertrag dann nach einem Jahr ausgelaufen ist, passiert was mit den Containern? Und wer ist daran dann schuld?
Beitrag #7349798 wurde von einem Moderator gelöscht.
Ein T. schrieb: > Micha schrieb: >> Der Behauptung, dass Docker häufig, wenn nicht sogar überwiegend auf >> virtuellen Servern betrieben wird, kann ich nur beipflichten. > > Geht es hier denn um eine demokratische Entscheidung? Das glaube ich > nicht, und solange nicht Einer von Euch es schafft, reale Belege dafür > zu liefern, daß Docker vornehmlich auf virtualisierter Hardware > betrieben wird, ist und bleibt das nur eine unbewiesene Behauptung. Ein paar Statistiken hatte ich verlinkt. Da lässt sich schon ein erster Eindruck gewinnen. Siehe Beitrag "Re: Vorteile von Docker?" Im zweiten Link wird darauf eingegangen, wann Docker Sinn macht. Und daraus lässt sich schon einmal ableiten, dass der konkrete Anwendungsfall entscheidend über Erfolg oder Verschlimmbesserung. Persönliche Meinungen und Präferenzen sind unerheblich.
Micha schrieb: > Ich habe nur aus meinem Alltag als Entwickler berichtet und dort treffe > ich diesen Anwendungsfall einfach häufig an. > > Ausnahme bilden natürlich lokale Testumgebungen der Entwickler. Oder > auch einige die spezielle Docker Clouds nutzen, dort werden die > Container mit Sicherheit auf dedizierter Hardware aufgeführt. Viele > Kunden möchten und bestehen auf "mein eigener Server". Denen ist dann > egal ob virtuell oder dediziert, aber es muss eben ein eigener Server > sein und keine reiner Docker Cloud. Ist wohl noch so in den Köpfen > verankert. Ja nun, so ist das, und all diese Anwendungsfälle sind doch nicht weg, nur weil AWS, Azure und GCP die großen Anbieter von Public Clouds sind. Auch wenn sie es gerne wären, sind sie doch nicht das Zentrum des Universums. > Mit Vorteilen meinte ich in diesem Zusammenhang menschlicher Natur. Also > Wartungsaufwand, etc. Doch, das sehe ich sehr wohl so. Die Wartung selbst, also Aktualisieren von Bibliotheken und Frameworks und die Anpassung des eigenen Code -- mithin: das, was ein Entwickler gemeinhin tut und sieht -- das ist in allen Fällen weitestgehend dieselbe. Aber daraus dann ein hübsches einzelnes Artefakt zu machen, das zuerst getestet und dann direkt so deployt werden kann, wie es getestet wurde, das erleichtert vieles, sowohl gegenüber VMs als auch im Vergleich zu Installationen auf Bare Metal. Wenn dazwischen noch Staging und Acceptance nötig sind, gilt das erst Recht. Ich denke allerdings, daß Docker das Entwicklerleben nicht sehr deutlich erleichtert: Softwareentwicklung und -Pflege sind immer noch schwierige, komplexe und hie und da auch fehleranfällige Tätigkeiten. Aber das, was danach kommt, nämlich Deployment, Betrieb, eventuell Debugging und diese Dinge, die erleichtert Docker dann doch sehr deutlich. >> Denn dann kann ein Angreifer vielleicht in einen Container >> eindringen, dort aber rein gar nichts mehr ausnutzen, um seine >> Privilegien zu erweitern oder gar den Host zu kapern. > > Genau das ist ja schon ein worst case. Er kommt zwar vielleicht nicht > auf den Host oder andere Projekte, aber bekommt Zugriff auf sensible > (personenbezogene) Daten und kann diese im schlimmsten Fall auch noch > verändern. Auch das ist... ein Beispiel: meine Apache-Container enthalten nur genau ein einziges Binary, /usr/sbin/apache2, ansonsten kein Perl (apache2ctl), keine Shell, keinen Datenbankclient... also nichts außer dem, was apache2 unbedingt braucht. Alle schreibbaren Volumes und temporären Verzeichnisse werden mit noexec gemounted und die Container mit --read-only und mit sehr restriktiven Sicherheitsprofilen (AppArmor / SELinux, seccomp) gestartet. Selbst wenn es ein Angreifer es schafft, den Container zu kompromittieren, sind seine Möglichkeiten, damit etwas anzustellen, eng begrenzt. > Richtig, unterstelle ich auch nicht. Es ist aber oft mehr Aufwand (v.a. > bei heterogener Umgebung) bestimmte Bibliotheken auf x Containern zu > aktualisieren, als 1-mal auf einem Host der x Projekte hält. Das sehe ich nicht, ehrlich gesagt, aber ich vertrete auch die Ansicht, daß zu einem produktiven Einsatz von Docker zwingend eine CI- und CD-Pipeline, ein halbwegs intelligentes Stacking der eigenen Images und natürlich immer eine intensive Härtung der Hosts und der Images gehört. Auf einem Host, der n Projekte hält, kann es dagegen sehr viel schlimmere Probleme geben. Kunde1 will unbedingt Version 1 des Projekts behalten, die von Framework X in der Version 1 abhängt. Kunde2 will dagegen die aktuelle Version 2 des Projekts erhalten, die aber von demselben Framework Version 2 abhängt... das kann unter Umständen zu sehr unschönen Kompromissen führen. > Genau das ist doch das Problem der Container. Stammen diese von einem > externen Dienstleister rührt die niemand an, sofern der Dienstleister > diese nicht neu paketiert und versioniert hat. D.h. diese Container > vegetieren dann vor sich hin, egal wie alt die Bibliotheken innerhalb > des Containers sind. Bitte, übertrag' das doch einfach auf dieselbe Situation auf Bare Metal oder mit VMs. Wenn Dein Dienstleister Mist ist, dann hast Du ein Problem, unabhängig davon, wie Du seine Software benutzt und deployst. > Nein, aber genau so wird das gerne gemacht. Eine eh schon knapp besetzte > IT Abteilung führt genau das gerne als Vorteil an. Hersteller XY liefert > das Produkt im fertigen Container, wir müssen uns um nichts mehr > kümmern. Es ist viel weniger Aufwand, einen Docker-Container zu installieren, zu pflegen und zu betreiben als dieselbe Software auf einem nativen Host oder in einer VM. Aber "sich um nichts mehr kümmern"? Wenn einem ITler nicht klar ist, daß Software gepflegt werden muß, hat er seinen Beruf verfehlt. Dasselbe ist allerdings von Docker völlig unabhängig und kann Dir auch mit Software passieren, die auf andere Weise ausgeliefert wird. > Nachdem der Wartungsvertrag dann nach einem Jahr ausgelaufen ist, > passiert was mit den Containern? Und wer ist daran dann schuld? Der Idiot, der den Wartungsvertrag hat auslaufen lassen. Aber was machst Du auf Bare Metal oder in einer VM in einem solchen Fall? Richtig: Du schaust ganz exakt haargenau so in die Röhre, und kannst diese Software im Prinzip nicht mehr weiter nutzen. Aber auch dieses Thema hat ja im Grunde genommen keinerlei Bezug zu Docker.
Beitrag #7349971 wurde von einem Moderator gelöscht.
Beitrag #7350029 wurde von einem Moderator gelöscht.
Beitrag #7350048 wurde von einem Moderator gelöscht.
Beitrag #7350097 wurde von einem Moderator gelöscht.
Beitrag #7350132 wurde von einem Moderator gelöscht.
Uwe D. schrieb: > Ein paar Statistiken hatte ich verlinkt. Da lässt sich schon ein erster > Eindruck gewinnen. Siehe > Beitrag "Re: Vorteile von Docker?" > > Im zweiten Link wird darauf eingegangen, wann Docker Sinn macht. Und > daraus lässt sich schon einmal ableiten, dass der konkrete > Anwendungsfall entscheidend über Erfolg oder Verschlimmbesserung. Also irgendwie... sehe ich bei den beiden Links keine Statistiken über Anwendungsfälle, in denen Docker genutzt wird. Im ersten der beiden dort verlinkten Artikel geht es darum, in welchen Fällen Kubernetes besser auf VMs und in welchen besser auf nacktem Eisen betrieben wird. Der zweite der verlinkten Artikel fragt nicht, wann Docker Sinn macht, sondern nur, wann Kubernetes Sinn macht. Das ist nicht dasselbe, zumal es mit OpenStack, Apache Mesos / Marathon, HashiCorp Nomad und Docker Swarm auch noch einige Container-Orchestratoren verfügbar sind und es obendrein etliche Anwendungsfälle gibt, in denen Docker auch abseits von Server- und Clusterdeployments sehr sinnvoll genutzt werden kann.
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.