Hi, findet ihr die Leistungswerte für oben genannte Verwendung angebracht. Was schätzut ihr, wo wir preislich liegen? Viele Grüße
Angehängte Dateien:
-
Daten.PNG
42 KB
absolutes Budget-System. Für Einsteiger geeignet, zum Geldverdienen ist das mit der SATA SSD nix, zu wenige IOPS. Außerdem ist die nicht spezifiziert, also das billigste was noch so rumliegt. Genauso wie das Netzteil. Was denn genau programmieren?? Welche Sprachen, was für Projekte? Nur alleine oder zum Geld verdienen? Preis geschätzt 783,90, Wert eher 600€.
:
Bearbeitet durch User
Ich weiß nicht was du programmieren willst, aber im Allgemeinen sind heutige Rechner schnell genug. So lange du nicht irgendwelche riesigen Sachen machen willst, sollte das System schnell genug sein. Auch um mal kleinere VMs zu starten. Die SSD könnte recht schnell zu klein werden. Entwicklungsumgebungen sind oft recht groß. Vielleicht brauchst du mehrere, diverse Tools kommen vielleicht dazu. Auch die Images von VMs brauchen recht viel Platz. NVMe-SSDs sind deutlich schneller als über SATA angebundene.
> die Leistungswerte Spielzeugsystem. Fuer mehrere VMs voellig unterdimensioniert. Vom Betriebssystem gar nicht zu reden. > NVMe-SSDs sind deutlich schneller Nochmal deutlich schneller sind gestripte NVMe-SSD. Z.B. 4 x 2 TB als Stripe Set. Das waere dann auch Platz genug fuer VMs. Die 32 GB RAM reichen da auch hinten und vorne nicht.
Frage schrieb: > Hi, findet ihr die Leistungswerte für oben genannte Verwendung > angebracht. Keine Angaben was du eigentlich vorhast...wie soll man da antworten? Das ist wie: ich will autofahren, passt ein Fiat zu mir? Und was kostet der?
Was willst du machen? Danach richtet sich was du brauchst. Willst du Arduino programmieren oder schreibst du eine neue officesuite? Welche Programme, welche (wieviele) VM's? Üblicherweise geben Softwarehersteller Anforderungen an ihre Software bekannt - das kann / sollte ein Anhaltspunkt sein. Ansonsten musst du mit Preisen zwischen 300 und 50000 EUR rechnen.
virtualizer schrieb: > Nochmal deutlich schneller sind gestripte NVMe-SSD. > Z.B. 4 x 2 TB als Stripe Set. Man kann es auch übertreiben.
virtualizer schrieb: > Fuer mehrere VMs voellig unterdimensioniert. Man kann es auch völlig übertreiben. Die Dimensionierung eines Virtualisierungshosts hängt maßgeblich von der Anzahl und Dimensionierung parallel aktiver VMs und deren Lastanforderungen ab. Eine VM für Arduino-Entwicklung fällt ganz anders aus, als eine für Simulation dicker FPGAs. Und ob da wohl alle VMs parallel auf Vollast laufen? Eine qualifizierte Aussage ist daher auf Basis der bestehenden Information nicht möglich. Die Disk könnte aber sicherlich mehr Spielraum benötigen. VM Images benötigen Platz, besonders wenn darin Windows laufen sollte und man jeweils 50GB allein dafür rechnet.
:
Bearbeitet durch User
(prx) A. K. schrieb: > virtualizer schrieb: >> Nochmal deutlich schneller sind gestripte NVMe-SSD. >> Z.B. 4 x 2 TB als Stripe Set. > > Man kann es auch übertreiben. Irgendwann stellt sich auch die Frage, wie schnell der Rechner die Daten überhaupt verarbeiten kann. (prx) A. K. schrieb: > Die Disk könnte aber sicherlich mehr Spielraum benötigen. VM Images > benötigen Platz, besonders wenn darin Windows laufen sollte und man > jeweils 50GB allein dafür rechnet. Was mich an dieser Spec verwirrt: In der Überschrift steht was von 1 TB Festplatte, unten steht aber, dass keine Festplatte verbaut ist. Dann wäre da nur die 256GB-SSD drin, was mit Sicherheit zu wenig ist. Das wäre ja schon ohne VMs im Prinzip das absolute Minimum.
Rolf M. schrieb: > In der Überschrift steht was von 1 TB Festplatte War mir nicht aufgefallen. Nur sind VM-Images auf HDD noch hässlicher als das Basis-System auf HDD. Mehrere parallele VMs mit hochaktiver Disk-I/O auf SATA-HDD machen in VMware ebensowenig Spass, wie eine einzige derart aktive VM bei parallelem Arbeiten auf dem Hosts selbst. Eine HDD taugt als Archivspeicher, aber heutzutage sollte als Speicher für aktiv genutzte VM-Images eine SSD genutzt werden. > Irgendwann stellt sich auch die Frage, wie schnell der Rechner die Daten > überhaupt verarbeiten kann. Erst recht mit nur einer aktiven VM. Denn wahrscheinlich geht es hier überhaupt nicht um parallel aktive VMs. Aber als Beispiel dafür: Je nach Anwendungsart kriegt man die Images von 100 aktiven VMs über ein einziges 10 Gb/s Ethernet auf einen NFS-Store kanalisiert, ohne dass es in Schwitzen kommt oder die VMs spürbar warten müssen. Das ist ein Bruchteil dessen, was allein eine NVMe im älteren PCIe3 hergibt. Die einzige Ressource, bei der man nicht mit einem ausgeprägten Skaleneffekt bei paralleler Nutzung rechnen sollte, ist das RAM. CPU-Cores teilen VMs sich gut, Diskzugriffe auf SSD ebenso, aber RAM-Bits aufzuteilen ist schwieriger. Das RAM des Hosts sollte sich (in dieser Dimension) also an der Summe des RAMs aller parallel aktiver VMs orientieren.
:
Bearbeitet durch User
Ich würde, wie schon weiter oben geschrieben worden ist eine größere SSD nehmen und eventuell eine Festplatte als Datengrab hinzufügen. Brauchst du wirklich noch eine zusätzliche Grafikkarte? Die CPU-Grafik sollte für deine Beschriebenen Anwendungsfälle ausreichen Grüße tr0ll
Warum brauche ich für ein Produktionssystem ein Gehäuse mit LED "Mäusekino"? Als Netzteil würde ich auch was Besseres als den Knallfrosch von der Liste nehmen. Sockel 1151 gibts langsam nur noch auf der Resterampe. Ich würde da auf den Sockel 1200 und einen gescheiten Chipsatz ausweichen, um was halbwegs Aktuelles zu haben, was sich in absehbarer Zeit ohne "Exotenzuschlag" erweitern lässt. Das statt einer SATA SSD eine mit M2 Schnittstelle und 1 TB Größe Sinn macht, wurde ja zuvor schon erörtert.
> Das ist ein > Bruchteil dessen, was allein eine NVMe im älteren PCIe3 hergibt. Falsch. Die Daten kommen aus dem Cache (RAM) des NFS-Stores. Und solange der gross genug ist, mit der Geschwindigkeit des RAM. Ich glaube du hast keine Ahnung.
(prx) A. K. schrieb: > Die einzige Ressource, bei der man nicht mit einem ausgeprägten > Skaleneffekt bei paralleler Nutzung rechnen sollte, ist das RAM. > CPU-Cores teilen VMs sich gut, Diskzugriffe auf SSD ebenso, aber > RAM-Bits aufzuteilen ist schwieriger. Das RAM des Hosts sollte sich (in > dieser Dimension) also an der Summe des RAMs aller parallel aktiver VMs > orientieren. Das ist doch Geschwurble. Vor Allem, wer redet hier von 100 aktiven VMs? Das hast Du Dir doch nur ausgedacht. Kein Mensch macht so etwas.
(prx) A. K. schrieb: >> Kein Mensch macht so etwas. > Privat nicht. Unternehmen schon. Da will man nicht irgendeinen Bastelrechner haben, sondern eine Server-Hardware eines etablierten Herstellers. Ich kenne noch die Heulerei der Vertriebskollegen, dass Server und Workstation-PCs zu teuer sind. Dann hat man billigere Hardware beschafft und hatte anschließend Freude, dass der Kram im Dauerbetrieb 24/7 regelmäßig verreckt ist. Für den Betrieb mehrerer VMs will ich möglichst viele CPU-Kerne haben und beliebig viel RAM, vor allem letzteres wird schnell zur Bremse. Wenn ich auf meine ehemalige Testumgebung gucke, da liefen nur 3..4 VMs, war auch viel Plattenspeicher notwendig. Einfach aus dem Grunde, dass diverse verschiedene Softwareversionen wahlweise startbar sein mussten. Da sind wir direkt wieder bei den bereits gestellten Fragen: Soeren K. schrieb: > Was denn genau programmieren?? Welche Sprachen, was für Projekte? Nur > alleine oder zum Geld verdienen? nunja schrieb: > Keine Angaben was du eigentlich vorhast...wie soll man da antworten? ------- Geht das nur mir so, oder nimmt im Forum die Anzahl der Kasper, die eine Frage stellen und sich danach nicht mehr beteiligen, drastisch zu?
Wer in Zeiten von docker und k8 noch 100VMs laufen hat, gehört sowieso geteert und gefedert. Auch Unternehmen...
Manfred schrieb: > Da will man nicht irgendeinen Bastelrechner haben, sondern eine > Server-Hardware eines etablierten Herstellers. Ja. Ich hatte das nur als Beispiel für Ressourcenkalkulation bei Virtualisierung erwähnt.
Manfred schrieb: > Geht das nur mir so, oder nimmt im Forum die Anzahl der Kasper, die eine > Frage stellen und sich danach nicht mehr beteiligen, drastisch zu? Geht das nur mir so, oder nimmt im Forum die Anzahl der Kasper, die mit Unfug um sich werfen, in letzter Zeit drastisch zu?
:
Bearbeitet durch User
Manfred schrieb: > Für den Betrieb mehrerer VMs will ich möglichst viele CPU-Kerne haben > und beliebig viel RAM, vor allem letzteres wird schnell zur Bremse. Hochgefahrene aber im Leerlauf befindliche VMs schlucken RAM, aber keine Cores. Runtergefahrene VMs schlucken nur Diskspace. Deshalb ist sehr relevant, wie man sie einzusetzen gedenkt. Wenn man VMs beispielsweise dafür verwendet, verschiedene Entwicklungsumgebungen getrennt zu halten, werden die typischerweise nicht gleichzeitig genutzt.
:
Bearbeitet durch User
Ein Stripeset für die VM ist aber absolut geil. Wenn Du 2X NVMe PCIe4 darin hast, laufen die VM's sogar etwas schneller als das Hostsystem, genug RAM vorausgesetzt. Geiles Spielzeug. :-P Matlab etwa ist in 4 Sekunden gestartet (im Hostsystem), Rad-Studio in etwa 5 Sekunden in ner VM. Man kann zig Proggys im Hostsystem offenhaben und ne VM, es zuckt nix, Du hast keine Lade/Umschaltzeiten. Mein System: AMD Threadripper, 16 Kerne, 32 Threads, 4,2 GHZ Takt 128 GB RAM, 2X jeweils 2TB NVMe Raid. 16TB Festplatten als Datengrab, 10GB Netzanbindung (Intranet). Das eizig eklige an dem Ding ist das BMC, das macht einen gläsern. :-( bitte, OM's, meckert nicht, Vater hatte mir das Teil so hingestellt, als ich aus dem Internat nach Haus kam. :-P mfg
Draconix schrieb: > Wer in Zeiten von docker und k8 noch 100VMs laufen hat, gehört > sowieso > geteert und gefedert. Auch Unternehmen... Wer für jeden Mist docker und k8 einsetzt ebenfalls. Diese Lösungen haben sehr spezifische anwendungsfälle, bringen sehr spezifische Probleme mit und eignen sich bisher nicht, um eine generische IT Umgebung zu betreiben. Sie spielen ihre Stärken erst beim Skalieren einheitlicher Container aus. Wer 100 unterschiedliche VMs betreibt, der wird mit Docker nicht glücklicher. Die Komplexität und Betriebsrisiken stehen in keinem Verhältnis zu den möglichen Einsparungen von Ressourcen. Außerdem sind viele Dinge mit docker schlicht nicht möglich. Teilweise, weil einfach grauenhaft konzipiert. Wenn ich mir nur dieses widerliche NAT, Port Binding und den gruseligen v6 Support ansehe, weiß ich, warum auch heute noch so viele Services v4 only sind.
Ein Entwicklungsrechner braucht mindestens 2 Monitore und umschaltbare Desktops. Damit du Debugger, Quelltexte, Doku und Testsystem gleichzeitig auf den Bildschirmen behalten kannst. Ob das System schnell genug ist? Wenn du auf ein schnelleres System umsteigst, bemerkst du die Geschwindigkeit gar nicht. Aber wenn du wieder ein altes langsames System benutzen musst, wunderst du dich, wie du damals auf dieser lahmen Krücke arbeiten konntest.
> Ein Stripeset für die VM ist aber absolut geil.
Wenigstens eine(r) mit gutem Geschmack.
Hans schrieb: > Wer für jeden Mist docker und k8 einsetzt ebenfalls. Diese Lösungen > haben sehr spezifische anwendungsfälle, bringen sehr spezifische > Probleme mit und eignen sich bisher nicht, um eine generische IT > Umgebung zu betreiben. Sie spielen ihre Stärken erst beim Skalieren > einheitlicher Container aus. Wer 100 unterschiedliche VMs betreibt, der > wird mit Docker nicht glücklicher. Die Komplexität und Betriebsrisiken > stehen in keinem Verhältnis zu den möglichen Einsparungen von > Ressourcen. Außerdem sind viele Dinge mit docker schlicht nicht möglich. > Teilweise, weil einfach grauenhaft konzipiert. Wenn ich mir nur dieses > widerliche NAT, Port Binding und den gruseligen v6 Support ansehe, weiß > ich, warum auch heute noch so viele Services v4 only sind. Nun habe ich in diesem Forum wirklich schon sehr viel Hahnebüchenes gelesen, aber jene Ausführungen gehören definitiv zu den Top Ten. Herzlichen Glückwunsch!
Wie wärs mit nem Lenovo P720? Darauf lässt sich prima entwickeln :-) Und genug Cores/RAM für Docker / VM sind auch vorhanden.
Beitrag #6895132 wurde vom Autor gelöscht.
Nur_ein_Typ schrieb: > Nun habe ich in diesem Forum wirklich schon sehr viel Hahnebüchenes > gelesen, aber jene Ausführungen gehören definitiv zu den Top Ten. > Herzlichen Glückwunsch! Und deshalb genau Null Argumente deinerseits. Herzlichen Glückwunsch. Magst du mal ein bis zwei Stündchen mit mir telefonieren und mir erklären, wie man es richtig macht?
Hans schrieb: > Nur_ein_Typ schrieb: >> Nun habe ich in diesem Forum wirklich schon sehr viel Hahnebüchenes >> gelesen, aber jene Ausführungen gehören definitiv zu den Top Ten. >> Herzlichen Glückwunsch! > > Und deshalb genau Null Argumente deinerseits. Herzlichen Glückwunsch. Vielen Dank für den Glückwunsch, aber da nicht für -- das habe ich mir ja lediglich bei Dir abgeschaut und möchte mich ungerne mit fremden Federn schmücken. > Magst du mal ein bis zwei Stündchen mit mir telefonieren und mir > erklären, wie man es richtig macht? Ach, ich schätze meine Privatsphäre anscheinend ähnlich wie Du und verzichte daher einstweilen auf Dein freundliches Angebot. Aber wenn Du magst, kannst Du natürlich gerne einen neuen Thread eröffnen -- wir wollen diesen ja nicht hijacken, oder? -- und hier verlinken, und dann in Deinem neuen Thread mal damit anfangen, zu sagen, welche Komponenten einer Infrastruktur sich Deiner Meinung nicht mit Docker und / oder K8s vertragen, so als Anfang. Ich hab' da zwar was im Hinterkopf, aber unter Erwachsenen fängt ja üblicherweise erstmal der Behauptende an, seine Behauptungen substanziell zu unterfüttern. Viel Erfolg! ;-)
Nur_ein_Typ schrieb: > Ach, ich schätze meine Privatsphäre anscheinend ähnlich wie Du und > verzichte daher einstweilen auf Dein freundliches Angebot. Schade. Wohl doch nur ein Schaumschläger. Du hättest gerne mit unterdrückter Nummer anrufen können.
Hans schrieb: > Nur_ein_Typ schrieb: >> Ach, ich schätze meine Privatsphäre anscheinend ähnlich wie Du und >> verzichte daher einstweilen auf Dein freundliches Angebot. > > Schade. Wohl doch nur ein Schaumschläger. Im Gegenteil hatte ich Dir einen einfachen und gangbaren Weg aufgezeigt, der zudem verschiedene charmante Vorzüge gehabt hätte. Dabei hätten sich nämlich auch andere Nutzer einbringen können und alles bliebe der interessierten Nachwelt erhalten. Am Ende ist das ja auch Sinn und Zweck eines Forums wie diesem hier. > Du hättest gerne mit unterdrückter Nummer anrufen können. Leider nein. Nun, da Du unseren interessierten Lesern den von mir vorgeschlagenen Austausch von Informationen lieber vorenthalten möchtest, empfehle den Youtube-Kanal "TechWorld with Nana" von Nana Janashia [1], um sich ein eigenes Bild zu machen. [1] https://www.youtube.com/channel/UCdngmbVKX1Tgre699-XLlUA
Nur_ein_Typ schrieb: >> Du hättest gerne mit unterdrückter Nummer anrufen können. > > Leider nein. Warum nicht? Du solltest dringend dein Telefon dockern! Nur_ein_Typ schrieb: > Im Gegenteil hatte ich Dir einen einfachen und gangbaren Weg aufgezeigt, > der zudem verschiedene charmante Vorzüge gehabt hätte. Dabei hätten sich > nämlich auch andere Nutzer einbringen können und alles bliebe der > interessierten Nachwelt erhalten. Am Ende ist das ja auch Sinn und Zweck > eines Forums wie diesem hier. Und in diesem Thread lieferst du dann genauso wenig Argumente. Ich verzichte aus gutem Grund darauf in diesem Forum Threads zu eröffnen.
Nur_ein_Typ schrieb: > Nun, da Du unseren interessierten Lesern den von mir vorgeschlagenen > Austausch von Informationen lieber vorenthalten möchtest, empfehle den > Youtube-Kanal "TechWorld with Nana" von Nana Janashia [1], um sich ein > eigenes Bild zu machen. > > [1] https://www.youtube.com/channel/UCdngmbVKX1Tgre699-XLlUA Ich brauche übrigens auch kein Beginners Tutorial für Docker und K8. Als Betreiber eines Clusters im AWS mit einer einer dynamischen Größe zwischen 150 und 300 Nodes je nach Auslastung gehöre ich sowohl zu denjenigen, die als Firma geteert und gefedert gehören, als auch zu denen, die die Grenzen kennen. Daher kann ich auch ganz entspannt sagen, dass ich Dinge wie AD Controller, DNS Resolver, Datev oder Mailstore ganz gewiss nicht Dockern werde. Auch weiterer Kleinkram wie 3CX, Pleasant Password Server, Backup Server oder Monitoring sind schlichtweg inkompatibel oder möchte ich nicht im Cluster haben. Wenn das Cluster brennt, will ich wenigstens noch ohne den Recovery Stick an die Passwörter kommen und im Monitoring eine Auflistung der aktuellen Probleme sehen können. Auch Telefonie, Mail und ein funktionierender DNS Resolver sind mir dann wichtig. Dagegen bringt die Orchestrierung dieser Systeme kaum Vorteile, da sie ohnehin nicht dynamisch skalieren müssen und auch nicht in vielen Instanzen für unterschiedliche Kunden vorliegen müssen. Unser Fokus liegt im Angebot sehr spezifischer SaaS Lösungen. Dem gegenüber steht jedoch ein erheblicher administrativer Aufwand. Wer das System Docker verstanden hat, der weiß nämlich, dass es mit docker pull nicht getan ist. Ebenfalls werden Systeme im Kundenauftrag betrieben, die einen Virenschutz erfordern. Über den Sinn von Virenscannern brauchen wir nicht zu diskutieren. Abseits des Homelabs gibt es aber Normen für bestimmte Anwendungen, die der Auditor umgesetzt sehen will. Folge ich dem Dogma 1 Container = 1 Service, kann ich in einem Container aber gar keinen Virenscanner betreiben. Dazu gibt es Anforderungen an physische Trennungen der Hostsysteme einzelner Kunden aufgrund von Sicherheitsaspekten. Stichwort Ausbruch aus Containern und VMs. Kann ich in der Cloud nicht umsetzen. Betreibe ich nun aber für jeden Kunden ein winziges Cluster, geht ein Teil der Skaleneffekte wieder verloren. Gleichzeitig geht der Administrative Aufwand weiter nach oben. So kommt eben doch eine ganze Reihe von etwa 220+ zusätzlichen VMs zusammen, ohne dass irgendjemand dafür geteert und gefedert gehört.
Nur_ein_Typ schrieb: > Hans schrieb: >> Wer für jeden Mist docker und k8 einsetzt ebenfalls. Diese Lösungen >> haben sehr spezifische anwendungsfälle, bringen sehr spezifische >> Probleme mit und eignen sich bisher nicht, um eine generische IT >> Umgebung zu betreiben. Sie spielen ihre Stärken erst beim Skalieren >> einheitlicher Container aus. Wer 100 unterschiedliche VMs betreibt, der >> wird mit Docker nicht glücklicher. Die Komplexität und Betriebsrisiken >> stehen in keinem Verhältnis zu den möglichen Einsparungen von >> Ressourcen. Außerdem sind viele Dinge mit docker schlicht nicht möglich. >> Teilweise, weil einfach grauenhaft konzipiert. Wenn ich mir nur dieses >> widerliche NAT, Port Binding und den gruseligen v6 Support ansehe, weiß >> ich, warum auch heute noch so viele Services v4 only sind. > > Nun habe ich in diesem Forum wirklich schon sehr viel Hahnebüchenes > gelesen, aber jene Ausführungen gehören definitiv zu den Top Ten. > Herzlichen Glückwunsch! Mir persönlich würde auch nur ein einzigster Anwendungsfall für 100 aktive VMs einfallen, sonst wüsste ich wirklich nicht wozu dies dienen sollten. Und zwar sind dies Webhoster mit ded. Serverangeboten. Und da sehe ich wieder rum das Problem, das dort 99,9% der Ressourcen ungebraucht / ungenutzt verschwendet werden. Bei Docker, NIX oder dergleichen ist (Und egal welcher Swarm Manager da eingesetzt wird, sei es K3, K8 oder Docker-Swarm) es egal auf welcher Host-Hardware ich dies einsetze, da es bis in die unendlichkeit skalierbar ist, die Resourcen teilbar oder dedicated genutzt werden können. Sollte ich dann zu den 100 Container / Systemen noch 20 benötigen, ja da stelle ich mir einfach noch einen Server daneben - an das Netz und betriebsbereit, mit den geladenen 20 Betriebsystemen dauert es keine 5 min. Das man natürlich seine Container clever aufbauen sollte, stellt sich ohne Frage, aber dies muss man bei einer VM welche extern verteilt werden soll auch. Auf Portbinding oder NAT bist du doch garnicht angewiesen bei Docker? Aber warum sollte man darauf verzichten wollen? Auch bei einer VM bist du auf das Netzwerk und Portweiterleitung des Host-Systems angewiesen. Das größte Problem ist, und das ist in vielen Bereichen so: Viele haben sich so dermaßen auf VMs eingeschossen, das sie es nicht wagen über den Tellerrand zu schauen und die Vor- und Nachteile von Containern zu erkennen. Da gab es mal ein Sprichwort: "Was der Bauer nicht kennt, frisst er nicht!"
Hans schrieb: > Ich brauche übrigens auch kein Beginners Tutorial für Docker und K8. Als > Betreiber eines Clusters im AWS ... und schon geht es gar nicht mehr um eine, zumal "generische" Infrastruktur mit Docker und / oder K8s, sondern um ganz genau Deine (anscheinend ziemlich Windows-zentrierte) Infrastruktur und AWS. Das ist plötzlich eine ganz andere Geschichte als das, was Du oben behauptet hattest, und betrifft nicht einmal den Kernpunkt meiner Kritik an Deinen Behauptungen. > Dazu gibt es Anforderungen an physische Trennungen der Hostsysteme > einzelner Kunden aufgrund von Sicherheitsaspekten. Stichwort Ausbruch > aus Containern und VMs. Kann ich in der Cloud nicht umsetzen. Wie gesagt, jetzt ist es auf einmal "die Cloud", und pötzlich spielen jetzt auch noch Deine spezifischen vertraglichen Vereinbarungen eine Rolle. Das hat allerdings nichts mehr mit dem zu tun, womit Du in diese Diskussion eingestiegen bist, und auf einmal gehen auch VMs nicht mehr. Unter diesen Umständen ist es sicher besser, daß Du keinen neuen Thread eröffnet hast, denn auf einmal entpuppen sich Deine ersten forschen Behauptungen als frei bewegliches und sehr spezifisches Ziel. Bei uns und mehreren unserer Kunden funktionieren allerdings etliche der Dinge, die Du aufführst, ganz wunderbar in lokalen Kubernetes-Installationen und hie und dort auch in Azure und AWS. Mail, Backup, Monitoring, Password Management... um nur einige zu nennen. Hie und da ist es allerdings schon aus lizenzrechtlichen Grunden notwendig, andere Werkzeuge zu benutzen... aber das steht dem grundsätzlichen Betrieb einer generischen Infrastruktur ja nicht zwangsläufig im Wege. Mein eigentlicher Kritikpunkt an Deinen Ausführungen ist allerdings, daß Du die Vorzüge von Docker -- ein einheitliches Deployment -- und von Kubernetes -- die Selbstheilung und die Vorteile bei Skalierung, Loadbalancing und Verfügbarkeit -- ganz einfach mal ignorierst. Aber Deine Wortwahl im ersten Beitrag läßt schon vermuten, daß da auch reichlich Emotionen im Spiel zu sein scheinen... EOD, hab' einen schönen und entspannten Abend.
In dem Zusammenhang, echte Frage: Wie siehts aus, wenn man beispielsweise 100 Homeuser mit jeweils einem im Unternehmen laufenden 08/15-Windows versehen will? Also typischer Citrix-Fall. Geht das auch mit Docker?
Draconix schrieb: > "Was der Bauer nicht kennt, frisst er nicht!" Das gibt es ganz sicher. Aber nicht nur Gewohnheit und Unkenntnis ist dabei relevant, auch Umstellungskosten spielen eine erhebliche Rolle. Etwa, wenn man ein passabel funktionierendes automatisches System zur PC-Installation hat. Sowas setzt halt PC-Strukturen voraus, von PXE angefangen. Mit VMs funktioniert das out-of-the-box.
Draconix schrieb: > Mir persönlich würde auch nur ein einzigster Anwendungsfall für 100 > aktive VMs einfallen, sonst wüsste ich wirklich nicht wozu dies dienen > sollten. Und zwar sind dies Webhoster mit ded. Serverangeboten. Und da > sehe ich wieder rum das Problem, das dort 99,9% der Ressourcen > ungebraucht / ungenutzt verschwendet werden. Habe ich ja oben schon ausgeführt. Draconix schrieb: > Bei Docker, NIX oder dergleichen ist (Und egal welcher Swarm Manager da > eingesetzt wird, sei es K3, K8 oder Docker-Swarm) es egal auf welcher > Host-Hardware ich dies einsetze, da es bis in die unendlichkeit > skalierbar ist, die Resourcen teilbar oder dedicated genutzt werden > können. Absolut. Das ist auch genau der Anwendungsfall, der sinnvoll ist. Erfordert aber auch, dass man sich vorher ein paar Gedanken zu seinem Service macht. Mehr dazu unten. Draconix schrieb: > Auf Portbinding oder NAT bist du doch garnicht angewiesen bei Docker? > Aber warum sollte man darauf verzichten wollen? Auch bei einer VM bist > du auf das Netzwerk und Portweiterleitung des Host-Systems angewiesen. NAT ist für viele Anwendungen gar kein Problem. Wenn ich Webservices habe, dann kann ich die sogar sehr elegant per Traefik exposen. Einfacher geht es nicht und ich muss die IP Adressen in meinem Cluster nicht kennen. Jetzt kommt aber der komplizierte Teil. Dazu mehrere Beispiele: - Ein Mailserver ist darauf angewiesen, dass er die IP Adresse des sendenden Hosts (Spamschutz) sieht. Hinter dem NAT ist das bei Docker nicht mehr der Fall. Spätentens, wenn ich den Port nach außen auf v4 und v6 expose, ist die reale IPv6 nach Innen nicht mehr darstellbar. Daher benötige ich zusätzliche Proxykonfigurationen. - Ich habe bestimmte Ports, die ich ausgehend in der Firewall gar nicht zulasse. So gibt es z.B. nur bestimmte Hosts, die auf Port 25 oder 53 ausgehend kommunizieren dürfen. Eine Frage der Sicherheit. So kann ich erschweren, dass kompromittierte Hosts zu Spamschleudern oder für DNS amplification attacks missbraucht werden. Docker Container stehen aber hinter einem NAT. Ich kann einzelnen Containern keine Ausnahme in der Firewall geben, da ich deren IP gar nicht sehe. - Ich betreibe ein Netz aus Honeypots. Sehe ich einen Zugriff von einem Dockerhost, kann ich keine Zuordnung zum Container treffen. Die Frühwarnung ist praktisch nutzlos. Gleiches Problem bei DPI. - Ich möchte mehrere MQTT Server für unterschiedliche Kunden im Cluster bereitstellen. Irgendwie muss ich Port 1883 daher mehrfach nach außen führen. Ein Reverse Proxy scheidet hier aus. - Eine Reihe von Applikationen geht bei NAT komplett kaputt. SIP hinter NAT funktioniert nur per SBC/STUN/TURN. Der entsprechende Service muss auch irgendwo laufen. - Meine Applikation bietet einen Webhook an. Dieser kann keine IPv6 only Hosts erreichen, wenn der Aufruf von einem Container hinter dem NAT erfolgt. Ebenso könnte ein Mailserver keine Mails über IPv6 versenden, sondern nur empfangen. Eine VM kann ich auf eine Bridge legen. Gleichzeitig beschränke ich zulässige MAC- und IP-Adressen. Jedes dieser Probleme tritt damit gar nicht erst auf. Das Äquivalent dazu wäre unter Docker die Nutzung von macvlan/ipvlan. Das bringt aber neue Probleme mit: - Aus Sicherheitsgründen erhält jede VM eine lokale Firewall. Ein kompromittierter Host in der DMZ (echter Public IPv4 Space, daher knapp) kann damit noch nicht einfach auf andere Hosts im selben Subnetz zugreifen. Die Regeln werden zentral verwaltet und ausgerollt. Somit sind sie immer auf ein Minimum begrenzt. Im Container selbst kann ich keine Firewall laufen lassen. Der Host filtert die Pakete in dieser Konfiguration nicht. Entsprechend können alle anderen Teilnehmer im selben Netz auf alle Ports zugreifen. Habe ich ein Problem mit SSRF in irgendeinem Container, habe ich ein Problem. - Es sind plötzlich alle Ports in die DMZ exposed. Auch die, die eigentlich nur intern zur Kommunikation mit anderen Containern genutzt werden sollen. Eine Beschränkung der Bind address im Container ist schwierig. Nutze ich 0.0.0.0 erhalte ich das beschriebene Problem. Möchte ich eine Adresse spezifizieren, stehe ich vor dem Problem das ich sie vielleicht gar nicht kenne. Denn die Zuweisung der Adressen für interne Netze nimmt Docker oder der Orchestrator automatisch vor. Sobald ich diese hart codiere, kann ich nicht mehr skalieren. Alternativ kann ich ein Subnetz anlegen und zu den Containern routen. Die Probleme bleiben aber bestehen. Firewalling macht der Host weiterhin nicht. Davon abgesehen sind öffentliche IPv4 Adressen knapp und für jeden Service müsste ich ein neues Netz einschließlich Gateway und Broadcast Adresse opfern. Draconix schrieb: > Das größte Problem ist, und das ist in vielen Bereichen so: Viele haben > sich so dermaßen auf VMs eingeschossen, das sie es nicht wagen über den > Tellerrand zu schauen und die Vor- und Nachteile von Containern zu > erkennen. Da gab es mal ein Sprichwort: "Was der Bauer nicht kennt, > frisst er nicht!" Diese Abneigung gegen Docker sehe ich auch immer wieder. Ich gehöre nicht zu denen, sehe aber derzeit auch Grenzen. Docker ist sehr stark, wenn ich einen ganzen Softwarestack skalieren muss, der von Anfang an dafür konzipiert wurde. Webservices lassen sich gut betreiben. Was darüber hinaus geht, wird schnell kompliziert aber machbar. Manchmal aber nicht sinnvoll. Auch der Betrieb extrem unterschiedlicher Container in einem Cluster ist aufgrund der beschriebenen Sicherheitsthemen problematisch. Wenn du Lösungen für diese Probleme hast, dann immer her damit! Die gängigen Dokumentation und Antworten in der Community hören aber an diesen Stellen auf.
(prx) A. K. schrieb: > Draconix schrieb: >> "Was der Bauer nicht kennt, frisst er nicht!" > > Das gibt es ganz sicher. Aber nicht nur Gewohnheit und Unkenntnis ist > dabei relevant, auch Umstellungskosten spielen eine erhebliche Rolle. > Etwa, wenn man ein passabel funktionierendes automatisches System zur > PC-Installation hat. Sowas setzt halt PC-Strukturen voraus, von PXE > angefangen. Mit VMs funktioniert das out-of-the-box. Ganz wichtiger Punkt. Eine bestehende Infrastruktur wirft niemand über Nacht um, nur weil man ein paar Server oder VMs einsparen kann. Was man bei Migrationen und neuen Projekten macht, steht auf einem anderen Blatt Papier. Da ist es eben eine Frage, ob sich der Aufwand dann wirklich lohnt. Denn auch Arbeitszeit ist Geld. Wartung und Monitoring von Containern funktioniert grundlegend anders. Benötigt also auch neue Strukturen.
Nur_ein_Typ schrieb: > ... und schon geht es gar nicht mehr um eine, zumal "generische" > Infrastruktur mit Docker und / oder K8s, sondern um ganz genau Deine > (anscheinend ziemlich Windows-zentrierte) Infrastruktur und AWS. Das ist > plötzlich eine ganz andere Geschichte als das, was Du oben behauptet > hattest, und betrifft nicht einmal den Kernpunkt meiner Kritik an Deinen > Behauptungen. Immerhin kritisierst du jetzt überhaupt mal und legst deine sinnfreie Polemik ab. Das von dir beschriebene ist der Teil, in dem ich Docker stark sehe und einsetze. Da gibt es kein Windows. Die Container sind vereinheitlicht und Orchestrierung funktioniert hier wunderbar. Auch ignoriere ich da nicht die von dir vorgebrachten Vorteile. Ganz im Gegenteil. Es gibt Gründe für den Betrieb in dieser Form. Diese liegen genau in den Vorteilen dieser Infrastruktur: Nur_ein_Typ schrieb: > -- ein einheitliches Deployment -- und von > Kubernetes -- die Selbstheilung und die Vorteile bei Skalierung, > Loadbalancing und Verfügbarkeit -- Das sind aber alles Vorteile, die ich für die von mir Vorgebrachten Anwendungen entweder nicht brauche oder für den Aspekt der Verfügbarkeit auch über ein Cluster aus VMs hinreichend erreiche. Nur_ein_Typ schrieb: > Bei uns und mehreren unserer Kunden funktionieren allerdings etliche der > Dinge, die Du aufführst, ganz wunderbar in lokalen > Kubernetes-Installationen und hie und dort auch in Azure und AWS. Mail, > Backup, Monitoring, Password Management... um nur einige zu nennen. Hie > und da ist es allerdings schon aus lizenzrechtlichen Grunden notwendig, > andere Werkzeuge zu benutzen... aber das steht dem grundsätzlichen > Betrieb einer generischen Infrastruktur ja nicht zwangsläufig im Wege. Was du völlig ignorierst ist die Tatsache, dass es Firmen mit Bestandsinfrastruktur gibt. Nur, weil da jemand daher kommt und Docker schreit, werden die Lösungen nicht über Nacht umgeworfen. Das Problem der Betriebssicherheit bleibt ebenfalls bestehen. Nur_ein_Typ schrieb: > Das hat allerdings nichts mehr mit dem zu tun, womit Du in diese > Diskussion eingestiegen bist, und auf einmal gehen auch VMs nicht mehr. VMs gehen durchaus. Sind sogar zur Gewährleistung der Verfügbarkeit erforderlich. Was nicht geht, sind Container. Eine dedizierte VM pro Container wäre vielleicht noch machbar aber im konkreten Fall reichlich sinnfrei. VMs haben in diesem Fall auf dedizierter Hardware in einem abgeschotteten Netzsgement zu laufen. Nur_ein_Typ schrieb: > Unter diesen Umständen ist es sicher besser, daß Du keinen neuen Thread > eröffnet hast, denn auf einmal entpuppen sich Deine ersten forschen > Behauptungen als frei bewegliches und sehr spezifisches Ziel. Wagen wir doch mal einen Blick zurück. Mein erster Post in diesem Thread bezog sich auf die wenig differenzierten Ausführungen: Draconix schrieb: > Wer in Zeiten von docker und k8 noch 100VMs laufen hat, gehört sowieso > geteert und gefedert. Auch Unternehmen... Da antworte ich nicht gleich mit einem sinnstiftenden Roman, obgleich es mir, wie du siehst, möglich ist. Es gibt durchaus gute Gründe eine Vielzahl von VMs zu betreiben. Die genannten Beispiele waren nur einige wenige. Nur_ein_Typ schrieb: > Deine Wortwahl im ersten Beitrag läßt schon vermuten, daß da auch > reichlich Emotionen im Spiel zu sein scheinen... Wie es in den Wald hineinruft... Sachlich hast DU zumindest ja immer noch nichts beizutragen. Inhaltlich bist DU nach wie vor auf keines der Argumente eingegangen.
Ehrlich gesagt habe ich das Gefühl daß hier gerade sehr viel an einander vorbei geredet wird weil die Fachbegriffe ungenau benutzt werden. Vielleicht müssen wir diesbezüglich mal präziser werden. Ich weiß daß die Profis genervt sind wenn ich hier kurz die Begriffe klären möchte. Trotzdem halte ich das für eine sinnvolle Idee. Aber Docker ist erst einmal nur eine Containerisierungstechnik (von mehreren). Docker-Images und -Container können auf mehrere Weisen verteilt und gestartet werden: die eher manuellen Methoden mit docker(1), docker-compose(1) oder mit Automatisierungswerkzeugen wie Ansible, Puppet, Saltstack... genau. Nennen wir dies mal Fall "A". Die nächste Stufe sind Cluster. Das können einfache Systeme sein wie Swarm oder komplexere wie K3s oder K8s. Da kann man mit den genannten Automatisierungstools manchmal noch ein bisschen tricksen. Fall "B". Wieder etwas anderes sind Clouds. Im Endeffekt sind das "anderer Leute Server" oder kurz gesagt: Du hast keinerlei Zugriff auf die Hardware oder die Infra und Tricksereien gehen so ziemlich gar nicht. Fall "C". Hans schrieb: > - Ein Mailserver ist darauf angewiesen, dass er die IP Adresse des > sendenden Hosts (Spamschutz) sieht. Hinter dem NAT ist das bei Docker > nicht mehr der Fall. [...] > Eine VM kann ich auf eine Bridge legen. Mit Docker (Fall "A") kannst Du das auch. Mit einem Cluster (Fall "B") ist das schon extrem schwierig und in einer Cloud (Fall "C") geht es gar nicht. (Nebenbei denke ich hier auch über die TPROXY / DIVERT-Targets von iptables(8) oder netfilter nach. Das braucht aber Änderungen an der Software und ist daher allenfalls für Eigenentwicklungen interessant.) > Diese Abneigung gegen Docker sehe ich auch immer wieder. Es ist halt was Neues. Wie tief die Abneigungen gegen Neues in unserer noch aus der Steinzeit geerbten DNA sind kannst Du an tausenden Stellen beobachten. Eine herausragende Stelle ist dieses Forum -- das der (gefühlt) einzige Ort der Welt ist wo immer noch über Assembler, C, C++ und Python gestritten wird. Am Ende sind das aber dieselben Widerstände wie damals gegen die VMs und Varianten von "aber das haben wir schon immer so gemacht". > Auch der Betrieb extrem unterschiedlicher Container > in einem Cluster ist aufgrund der beschriebenen Sicherheitsthemen > problematisch. Das wiederum sehe ich etwas anders. Das liegt einerseits an den Mechanismen die aktuelle Linux-Kernel bieten wie SE-Linux, AppArmor oder (äh) grsecurity. Und andererseits liegt das daran daß ich bei verschiedenen Kunden an den Audits von Behörden und Unternehmen teilgenommen habe die den Cloudbetrieb unter einigen Prämissen als unproblematisch befunden haben. Daher können wir lange reden und kommen am Ende zu demselben Ergebnis: es spielt keine Rolle ob Dein Systemkern, Dein Securityframework, oder Dein Hypervisor ein Sicherheitsproblem hat. :)
Hans schrieb: > Eine bestehende Infrastruktur wirft niemand über > Nacht um, nur weil man ein paar Server oder VMs einsparen kann. Was man > bei Migrationen und neuen Projekten macht, steht auf einem anderen Blatt > Papier. Das stimmt. Aber davon hat doch auch keiner geredet?!
Sheeva P. schrieb: > Mit Docker (Fall "A") kannst Du das auch. Richtig. Möchte ich aber nicht, da ich dann jegliche Möglichkeiten des Firewallings verliere. Ich möchte auch gar nicht die Bridge, aber ein sauberes, NAT freies Routing mit definierbaren Firewallregeln. Das ist mit reinem Docker nicht möglich. Im Kubernetes Cluster nur mit entsprechend komplexen CNI. IPv6 leidet ebenfalls darunter. Mir erscheint das irgendwie wenig durchdacht. Sheeva P. schrieb: > Daher können wir lange reden und kommen > am Ende zu demselben Ergebnis: es spielt keine Rolle ob Dein Systemkern, > Dein Securityframework, oder Dein Hypervisor ein Sicherheitsproblem hat. > :) Stimme grundsätzlich zu. Habe ich aber netzwerkseitig keine saubere Trennung mehr, brauche ich über den Worst-Case gar nicht erst nachzudenken. Wer die implementiert, versteht, was er tut. Die meisten Admins sind dagegen immer noch stolz auf NAT und halten es für ein Feature. Muss ich aber NAT verwenden, versagen meine weiteren Sicherheitsmaßnahmen (Firewalls, Honeypots und DPI). Auch gibt es z.B. in KRITIS Umgebungen Anforderungen, dass unterschiedliche Netzsegmente mit unterschiedlicher Sicherheitsstufe nicht über einen Hypervisor zusammengeführt werden dürfen. Ist kein direkter Aspekt pro/contra Docker. Für jedes Segment aber noch zusätzlich auf dem Hypervisor ein Cluster zu betreiben, macht aber irgendwann keinen Sinn mehr. Für mich ist bei der ganzen Diskussion der folgende Punkt wichtig: Docker, Kubernetes oder was auch immer sind an einem Nachmittag funktionsfähig aufgesetzt. Infrastruktur aber sicher, langfristig wartbar und sauber überwacht zu betreiben eine wesentlich schwierigere Aufgabe. Leider wird oft nur irgendwas schnell aufgesetzt, ohne sich groß Gedanken darüber zu machen. Das geht dann irgendwann Produktiv und alle sind erstmal glücklich. Es ist mir oft genug passiert, dass ich solche Schnellschüsse anderer wieder reparieren dürfte. Warum das eben lange dauert, versteht oft niemand. Aus dem Grund bin ich aber auch der Meinung, dass VMs für die meisten Anwendungsfälle besser geeignet sind. Docker, Cluster oder Clouds fügen gegenüber Virtualisierung eine ganze Reihe zusätzlicher Komplexitätsebenen ein. Wer aber keine Zeit oder Lust hat sich damit auseinander zu setzen, sollte lieber weiter VMs nutzen. Denn ein halbfertiges, undurchdachtes Kubernetes Cluster hilft auf lange Sicht auch niemandem und der Aufwand viele individuelle Services zu orchestrieren ist dann einfach zu groß. Nutze ich viele gleiche Container, dann kann irgendwas mit Docker gebasteltes dagegen je nach Applikation noch Sinn machen. Ich hatte bei meinem früheren Arbeitgeber mal an einer rudimentären Dockerlösung für eine spezifische Applikation gearbeitet. Kunden konnten dort eine VM mit einer bestimmten Software gegen viel Geld mieten. Über die Zeit kam eine Reihe dieser VMs mit unterschiedlichsten Konfigurationen zusammen. KnowHow zu dieser Software war weder bei mir noch bei meinen Kollegen vorhanden. Auch war das ganze eigentlich kein Produkt, wie es der Kunde erwarten würde. Anforderungen von Kunden zu selbstverständlichen Features mussten immer individuell umgesetzt werden. Über die Rechnungen dazu gab es einige Male Streit. Letztlich war es eine Standardinstallation mit ein paar drangebastelten, kostenlosen Plugins ohne jegliche Garantie auf Updates. Niemand in der Firma hätte diese Plugins bei Bedarf weiterentwickeln können. Über Wartung hatte sich im Vorfeld ebenfalls niemand Gedanken gemacht. So hat keine der VMs nach dem Setup jemals ein Update gesehen. Ein typischer Schnellschuss eben. Nachdem ich das Projekt übernommen hatte, habe ich die VMs erstmal auf einen einigermaßen identischen Stand gebracht. Ab dann übernahm Ansible vorerst die Wartung. Technisch war das alles andere als Ideal. Ein paar Wochen, nachdem ich begonnen hatte einen Prototypen in einer Dockerumgebung zu bauen, habe ich dann gekündigt. Da klar war, dass Docker außer mir niemand weiterführen wollen und können würde, war es besser bei den alten VMs zu bleiben. Mit Docker wäre dort heute keiner mehr im Stande irgendwas an den Systemen zu tun.
> Letztlich > war es eine Standardinstallation mit ein paar drangebastelten, > kostenlosen Plugins ohne jegliche Garantie auf Updates. Das ist auch mein Eindruck von "typischen" Dockerloesungen. Richtige Buildsysteme wollen oder koennen die Dockerfrickler nicht. Verteilt wird "zusammenkopiertes" Zeug. Sowas wuerde ich als Kunde nicht in meine IT lassen wenn mir die Sicherheit wirklich am Herzen liegt. Keiner weiss genau was dieses Dockerzeug im Detail treibt.
Hans schrieb: > Richtig. Möchte ich aber nicht, da ich dann jegliche Möglichkeiten des > Firewallings verliere. "Nicht können" und "nicht wollen" sind aber immer noch zwei verschiedene Dinge. > Ich möchte auch gar nicht die Bridge, aber ein > sauberes, NAT freies Routing mit definierbaren Firewallregeln. Das ist > mit reinem Docker nicht möglich. --network=host existiert, obwohl es natürlich nicht die Idee ist. > Für mich ist bei der ganzen Diskussion der folgende Punkt wichtig: > Docker, Kubernetes oder was auch immer sind an einem Nachmittag > funktionsfähig aufgesetzt. Infrastruktur aber sicher, langfristig > wartbar und sauber überwacht zu betreiben eine wesentlich schwierigere > Aufgabe. Leider wird oft nur irgendwas schnell aufgesetzt, ohne sich > groß Gedanken darüber zu machen. Das geht dann irgendwann Produktiv und > alle sind erstmal glücklich. Es ist mir oft genug passiert, dass ich > solche Schnellschüsse anderer wieder reparieren dürfte. Warum das eben > lange dauert, versteht oft niemand. Das hat aber ganz nichts mit der Betriebsinfrastruktur zu tun, sondern gilt für Software ganz allgemein. Auch auf Baremetal und VMs habe ich schon häufig genug solche Schnellschüsse reparieren dürfen. > Aus dem Grund bin ich aber auch der Meinung, dass VMs für die meisten > Anwendungsfälle besser geeignet sind. Docker, Cluster oder Clouds fügen > gegenüber Virtualisierung eine ganze Reihe zusätzlicher > Komplexitätsebenen ein. Das sehe ich anders: die Komplexitätsebenen sind nämlich ohnehin vorhanden, wenn Linux als Betriebssystem eingesetzt wird. Control groups, namespaces, SE-Linux... das ist in jedem üblich konfigurierten Kernels bereits vorhanden, und Docker macht nicht viel mehr als diese Dinge zu konfigurieren. Und wenn Du Linux-Systeme in einer VM benutzt, dann sind diese Sachen sogar in jeder einzelnen VM-Instanz enthalten. Was Du stattdessen vielleicht meinst, ist nicht zusätzliche Komplexität, sondern der zusätzliche Lernaufwand, sich mit Docker, K8s, Public Clouds auseinanderzusetzen und ihre Möglichkeiten und Grenzen, Konfiguration und Bedienung zu erlernen. Das ist ein Thema, keine Frage, aber dasselbe gilt ja ebenfalls für jede Software: wenn ich sie produktiv und sicher nutzen will, muß ich ein mindestes Fachwissen darüber haben. > Wer aber keine Zeit oder Lust hat sich damit > auseinander zu setzen, sollte lieber weiter VMs nutzen. D'accord, aber das war ja nicht der Punkt. > Ich hatte bei meinem früheren Arbeitgeber mal an einer rudimentären > Dockerlösung für eine spezifische Applikation gearbeitet. Dein Beispiel aus der Praxis demonstriert aber primär, wie man es eben nicht machen sollte. Und zwar gänzlich unabhängig davon, auf welcher Infrastruktur die Software betrieben wird. Sorry, eine Software in verschiedenen Konfigurationen zu betreiben und deren Betrieb sogar als ein womöglich SLA-behaftetes Produkt anzubieten, wenn keiner der Mitarbeiter sich mit der Software auch nur ansatzweise auskennt, ist ein hervorragendes Rezept für ein komplettes Desaster -- egal, ob mit Docker, Kubernetes oder in einer Public Compute Cloud. Und wenn die Mitarbeiter sich zudem auch nicht mit der Betriebsumgebung auskennen, potenziert das die Probleme noch einmal, völlig unabhängig von der konkreten Betriebsumgebung. Wenn es zum Beispiel in einer Firma niemanden gäbe, der sich mit Linux und dessen Betrieb auskennt, wäre es unsinnig und bisweilen sogar gefährlich, ausgerechnet auf dieser Plattform irgendeine Software zu betreiben. Insofern sehe ich Dein Beispiel nicht als sonderlich zielführend an, denn im Kern hat es überhaupt nichts mit Docker, Kubernetes, oder etwas anderem zu tun als den Wünschen von Vertrieblern und Betriebswirten, etwas anzubieten, von dem niemand im Unternehmen eine Ahnung hat. Docker, Kubernetes und Public Clouds sind nun einmal nichts, was man "mal eben" auf die Schnelle im Unternehmen umsetzen kann. Dabei geht es mittel- und langfristige strategische Entscheidungen, die zwar von der Technik angestoßen und vorangetrieben werden können, aber letztlich einen wesentlich größeren und umfangreicheren Fokus haben. Dazu gehören unter anderem eine gründliche Einarbeitung aller betroffenen Mitarbeiter, gegebenenfalls Anpassungen in der eigenen Individualsoftware, sowie langfristig auch die Ablösung von inkompatibler Bestandsinfrastruktur durch neue, mit der gewünschten Laufzeitumgebung kompatibler Infrastrukturen und natürlich auch die Schulung und Einarbeitung aller betroffenen Mitarbeiter sowie die Migration der jeweiligen Softwarepakete. Wer diesen Aufwand nicht leisten kann oder will, ist mit seiner bestehenden Infrastruktur vermutlich besser bedient, aber das war ja schon früher so, als die Software weiland etwa von Baremetal auf VMs umgezogen wurde.
Gretel schrieb: >> Letztlich >> war es eine Standardinstallation mit ein paar drangebastelten, >> kostenlosen Plugins ohne jegliche Garantie auf Updates. > > Das ist auch mein Eindruck von "typischen" Dockerloesungen. > Richtige Buildsysteme wollen oder koennen die Dockerfrickler nicht. > Verteilt wird "zusammenkopiertes" Zeug. Das spricht aber nicht gegen Docker & Co., sondern gegen die "Techniker", die so etwas machen. Solche Frickeleien gibt es ja auch ohne Docker & Co. zuhauf, das hat also rein gar nichts mit Docker & Co. zu tun. > Sowas wuerde ich als Kunde nicht in meine IT lassen wenn mir > die Sicherheit wirklich am Herzen liegt. Keiner weiss genau > was dieses Dockerzeug im Detail treibt. Das ist keine Raketenwissenschaft, und meist größtenteils gut dokumentiert. Wovor Kunden sich in Acht nehmen sollten, sind also nicht Docker & Co., sondern jene Art von Fricklern, die irgendwelches unbekantes und unverstandenes Zeug zusammenkopieren und dann produktiv betreiben zu können glauben.
Draconix schrieb: > Mir persönlich würde auch nur ein einzigster Anwendungsfall für 100 > aktive VMs einfallen, sonst wüsste ich wirklich nicht wozu dies dienen > sollten. Da habe ich noch einen für Dich: VDI* HyperV-Server unter Win2k19 Datacenter. Tatsächlich sind das RAM (benötigt wird die Summe aller aktiven VMs) und auch die Plattenkapazität ein Problem. * = virtual desktop infrastucture. Also virtualisierte Clients.
Nur_ein_Typ schrieb: > --network=host existiert, obwohl es natürlich nicht die Idee ist. Nicht was ich will. Der Container hat dann immer noch keine eigene, netzwerkweit sichtbare IP Adresse. Nur_ein_Typ schrieb: > Das hat aber ganz nichts mit der Betriebsinfrastruktur zu tun, sondern > gilt für Software ganz allgemein. Auch auf Baremetal und VMs habe ich > schon häufig genug solche Schnellschüsse reparieren dürfen. Stimmt. Ich gehe aber mal davon aus, dass das Wissen um einen halbwegs stabilen Betrieb von ESX oder anderen Hypervisorn breiter gestreut ist. Fast jede Firma hat irgendwo ein paar VMs und Admins dafür kriegst du an jeder Ecke. Ein guter Grund für kleine Firmen eben nicht auf Docker zu setzen. Nur_ein_Typ schrieb: > Dein Beispiel aus der Praxis demonstriert aber primär, wie man es eben > nicht machen sollte. Und zwar gänzlich unabhängig davon, auf welcher > Infrastruktur die Software betrieben wird. Nun, die Software so zu betreiben war nicht meine Idee. Die ersten Instanzen gab es schon, bevor ich da angefangen habe. Wenn du Tage damit plattgemacht hast, dich um diese Software zu kümmern, siehst du dich zwangsläufig irgendwann nach brauchbaren Alternativen für den Betrieb um. Da Docker dort bis dahin nicht nur ungenutzt war, sondern ohne Argumentation auf Abneigung stieß, machte es keinen Sinn direkt ein Kubernetes Cluster zu bauen. Es ging um einen Prototypen und für mehr hätte ich die Bastelumgebung auch nicht genutzt. Dinge wie guck mal: "Du wolltest eine neue Instanz, kannst du nach 5 Minuten statt einem Tag haben" oder "Moment ich rolle nur schnell das automatisch getestete Update aus" wären gute Argumente gewesen, um auch das kompliziertere Setup eines Clusters zu rechtfertigen. Nur_ein_Typ schrieb: > Sorry, eine Software in > verschiedenen Konfigurationen zu betreiben und deren Betrieb sogar als > ein womöglich SLA-behaftetes Produkt anzubieten, wenn keiner der > Mitarbeiter sich mit der Software auch nur ansatzweise auskennt, ist ein > hervorragendes Rezept für ein komplettes Desaster -- egal, ob mit > Docker, Kubernetes oder in einer Public Compute Cloud. Oft genug passiert. Der Laden verstand er aber hervorragend seine Verantwortung als Dienstleister abzustreiten. Irgendeinen absurden Grund, warum der Kunde dafür verantwortlich war, gab es immer. Oft wurde die eigene Unfähigkeit gegenüber dem Kunden noch nichtmal verborgen. Jeder mit nur etwas Ahnung, der diesen Leuten beim telefonieren zuhörte, musste sich an den Kopf fassen. Aber wenn du also Kunde natürlich noch weniger Ahnung hast, dann fühlst du dich gut beraten. Nur_ein_Typ schrieb: > Wenn es zum Beispiel in einer Firma niemanden gäbe, der sich mit Linux > und dessen Betrieb auskennt, wäre es unsinnig und bisweilen sogar > gefährlich, ausgerechnet auf dieser Plattform irgendeine Software zu > betreiben. Volle Zustimmung. Die existieren Linux Systeme waren nach zusammenkopierten Tutorials konfiguriert. Bei Updates (Debian) ging regelmäßig etwas kaputt. Klar, wer unzählige Paketquellen ohne Not und nachzudenken hinzufügt, darf sich nicht wundern. Weil das nachdem ich da weg bin keiner mehr reparieren könnte, sehen die Systeme halt keine Updates mehr. Nur_ein_Typ schrieb: > Wer diesen Aufwand nicht > leisten kann oder will, ist mit seiner bestehenden Infrastruktur > vermutlich besser bedient, aber das war ja schon früher so, als die > Software weiland etwa von Baremetal auf VMs umgezogen wurde. Genau deshalb gibt es immer noch gute Gründe für eine ganze Reihe von VMs. Wer hat schon Ressourcen eine komplette Systemlandschaft auf Docker kompatible Lösungen umzustellen? Wer auf der grünen Wiese, vielleicht mit einem Dienstleister, anfängt, hat da leicht reden. Nur_ein_Typ schrieb: > Das spricht aber nicht gegen Docker & Co., sondern gegen die > "Techniker", die so etwas machen. Solche Frickeleien gibt es ja auch > ohne Docker & Co. zuhauf, das hat also rein gar nichts mit Docker & Co. > zu tun. Ich muss schlichtweg weniger Wissen haben, um eine VM oder Bare Metal Maschine zu administrieren. Docker als zusätzliche Schicht führt immer Raum für noch viel mehr und noch viel desaströsere Frickeleien ein, als es mit den älteren Lösungen jemals möglich war. Ich denke da an ein Galera Cluster, dessen Datenbanken nach dem Reboot des Kubernetes Clusters leider nicht mehr da waren. Man dachte immer, Backups der Nodes würden reichen. Dass VMs bei Unfähigkeit der Admins unter völliger Amnesie litten, ist mir dagegen noch nicht untergekommen.
Hans schrieb: > Ich muss schlichtweg weniger Wissen haben, um eine VM oder Bare Metal > Maschine zu administrieren. Docker als zusätzliche Schicht Wenn man gelegentlich mit Azubis Fachinformatik/Systemadministration zu tun hat, bekommt man es mit individuellen Unterschieden in Abstraktionfähigkeit zu tun (*). Von konkreten Servern in Blech zu virtuellen Systemen ist schon ein deutlicher Schritt. Wenn dann noch Docker&Co mitspielt, kommt noch eine erhebliche Abstraktion hinzu. Umso wichtiger wird es, dass nicht nur derjenige durchblickt, der es eingerichtet hat. Soll heissen: Dokumentation, Dokumentation, Dokumentation. Nicht immer die stärkste Seite einer eingespielten IT. *: Eine Doktortitel in Physik ist allerdings auch keine Gewähr für Affinität zu IT.
:
Bearbeitet durch User
Hans schrieb: > Nur_ein_Typ schrieb: >> --network=host existiert, obwohl es natürlich nicht die Idee ist. > > Nicht was ich will. Der Container hat dann immer noch keine eigene, > netzwerkweit sichtbare IP Adresse. Die Parameter --ip sowie die Netzwerktreiber macvlan und ipvlan existieren. Zudem befürchte ich, daß das Prinzip "ichwillichwillichwill" im Realen Leben (TM) noch nie besonders gut funktioniert hat. Du kannst natürlich etwas wollen, etwa daß Du mit Deinem Formel1-Rennwagen auch Deine Felder pflügen kannst, aber das heißt ja noch nicht zwangsläufig, daß so etwas ökonomisch oder wenigstens möglich wäre. Außerdem beschleicht mich gerade irgendwie das unbestimmte Gefühl, daß Du Deine Anforderungen dynamisch immer weiter anpaßt, so daß -- und, wohlgemerkt: noch unterstelle ich kein "damit" -- sie am Ende nurmehr mit mit VMs umsetzbar sind. Vielleicht bist Du einfach noch zu sehr in dieser gewohnten VM-Denke gefangen und möglicherweise noch nicht wirklich bereit für eine Veränderung -- das wäre ja nicht schlimm und kommt in den besten Familien vor. > Nur_ein_Typ schrieb: >> Das hat aber ganz nichts mit der Betriebsinfrastruktur zu tun, sondern >> gilt für Software ganz allgemein. Auch auf Baremetal und VMs habe ich >> schon häufig genug solche Schnellschüsse reparieren dürfen. > > Stimmt. Ich gehe aber mal davon aus, dass das Wissen um einen halbwegs > stabilen Betrieb von ESX oder anderen Hypervisorn breiter gestreut ist. > Fast jede Firma hat irgendwo ein paar VMs und Admins dafür kriegst du an > jeder Ecke. Ein guter Grund für kleine Firmen eben nicht auf Docker zu > setzen. So ist das nunmal bei Neuerungen, am Anfang kennen sich nur wenige damit aus und noch viel weniger haben sogar schon Erfahrungen. Du hingegen hattest in Deinem ersten Beitrag in diesem Thread über die Technologie und nicht über die Kenntnisse und Erfahrungen damit gerantet, insofern entweder Dein erster Rant oder dieser Beitrag irgendwie am Thema vorbei gehen. Tatsache ist auch, daß ich etliche insbesondere kleine Firmen kenne, bei denen es keine einzige VM gibt, just gestern wieder eine Arztpraxis mit ~40 MA. Denen würde ich dann natürlich auch nicht empfehlen, ihre Bestandsinfrastruktur von jetzt auf gleich auf VMs umzustellen. Und das würdest Du doch auch nicht, oder? Admins gibt es auch längst nicht mehr "an jeder Ecke". Mein Arbeitgeber sucht seit ungefähr vier Jahren nach einer fähigen Verstärkung für unser Adminteam und hat in dieser Zeit gerade mal einen (erfreulicherweise sehr pfiffigen und hochmotivierten) Auszubildenden finden können. > Nun, die Software so zu betreiben war nicht meine Idee. Die ersten > Instanzen gab es schon, bevor ich da angefangen habe. Wenn du Tage damit > plattgemacht hast, dich um diese Software zu kümmern, siehst du dich > zwangsläufig irgendwann nach brauchbaren Alternativen für den Betrieb > um. Da Docker dort bis dahin nicht nur ungenutzt war, sondern ohne > Argumentation auf Abneigung stieß, machte es keinen Sinn direkt ein > Kubernetes Cluster zu bauen. Es ging um einen Prototypen und für mehr > hätte ich die Bastelumgebung auch nicht genutzt. räusper Verzeihung, aber... Du kommst in ein Unternehmen, das sich bei einem bestimmten Produkt offenbar ohnehin schon verrannt hat, willst die entstandenen Probleme dann mit einer Technologie lösen, die bei den Kollegen auf breite und nichtmal begründete Ablehnung stößt (unbegründet heißt ja: sie haben sich diese Technologie nicht einmal genau genug angesehen, um sachliche Argumente dagegen vorbringen zu können) und erwartest dann noch, daß Du mit ebendieser Technologie gegen den Widerstand Deiner Kollegen erfolgreich sein kannst? > Oft genug passiert. Der Laden verstand er aber hervorragend seine > Verantwortung als Dienstleister abzustreiten. Irgendeinen absurden > Grund, warum der Kunde dafür verantwortlich war, gab es immer. Oft wurde > die eigene Unfähigkeit gegenüber dem Kunden noch nichtmal verborgen. > Jeder mit nur etwas Ahnung, der diesen Leuten beim telefonieren zuhörte, > musste sich an den Kopf fassen. Aber wenn du also Kunde natürlich noch > weniger Ahnung hast, dann fühlst du dich gut beraten. Dann ist es sicherlich besser so, daß Du Deinen Hut genommen hast. Aber daß es obskure Anbieter mit windigen Geschäftsmodellen gibt, hat mit Docker, K8s und Public Clouds doch auch nichts zu tun. > Nur_ein_Typ schrieb: >> Wer diesen Aufwand nicht >> leisten kann oder will, ist mit seiner bestehenden Infrastruktur >> vermutlich besser bedient, aber das war ja schon früher so, als die >> Software weiland etwa von Baremetal auf VMs umgezogen wurde. > > Genau deshalb gibt es immer noch gute Gründe für eine ganze Reihe von > VMs. Wer hat schon Ressourcen eine komplette Systemlandschaft auf Docker > kompatible Lösungen umzustellen? Wer auf der grünen Wiese, vielleicht > mit einem Dienstleister, anfängt, hat da leicht reden. Ach, IT-Systeme werden ja im Laufe der Zeit ohnehin immer mal wieder getauscht, sei es, weil sie kaputt gehen, sei es, weil sie aus dem Herstellersupport herausfallen, so ist nun einmal der Lauf der Welt. Bei uns haben wir es so gemacht, daß wir mit aus dem Herstellersupport gefallenen Systemen erst einmal einen Kubernetescluster aufgesetzt und einige Jahre lang Erfahrungen damit gesammelt haben, bevor wir dann unseren ersten Produktionscluster mit nagelneuer Hardware installiert haben. Zu dem Zeitpunkt waren unsere Softwareprodukte allerdings fast ausnahmslos aufgrund der Erfahrungen mit dem Testsystem entsprechend vorbereitet und angepaßt. > Ich muss schlichtweg weniger Wissen haben, um eine VM oder Bare Metal > Maschine zu administrieren. Das sehe ich zwiegespalten. Klar, um ein Linux aufzusetzen und es sicher zu härten und in Betrieb zu nehmen, ist kein so großer Akt, aber damit ist die Arbeit ja noch lange nicht getan. Aber das Detailwissen muß dann an anderer Stelle geschaffen und kodifiziert werden, nämlich individuell beim Betrieb. Und da kommen dann die sehr unangenehmen Dinge: wo liegen die Konfigurationsdateien unserer virtuellen Hosts? Wird die kommerzielle Software X jetzt unter /usr/local/ oder lieber unter opt installiert? Welche Parameter und Optionen muß ich der Software Y denn jetzt beim Start mitgeben? Wo liegen die Konfigurationsdateien und die Daten von Software Z? Das sind all diese kleinen Detailfragen, die eine Containerlösung ziemlich sauber abstrahieren, vereinheitlichen, und vereinfachen kann. > Docker als zusätzliche Schicht führt immer > Raum für noch viel mehr und noch viel desaströsere Frickeleien ein, als > es mit den älteren Lösungen jemals möglich war. Auch das halte ich, ehrlich gesagt, nicht ganz für richtig. Basteleien habe ich in den letzten Jahren immer wieder und überall gesehen, von kleinen Firmen bis hin zu internationalen Konzernen, und völlig unabhängig vom Betriebsmodell. Soetwas geht auf Bare Metal genau so gut wie auf VMs und auf Docker, K8s oder Public Clouds. > Ich denke da an ein > Galera Cluster, dessen Datenbanken nach dem Reboot des Kubernetes > Clusters leider nicht mehr da waren. Man dachte immer, Backups der Nodes > würden reichen. Dass VMs bei Unfähigkeit der Admins unter völliger > Amnesie litten, ist mir dagegen noch nicht untergekommen. Und wieder lastest Du die Unfähigkeit der Admins der von ihnen ganz offensichtlich unverstandenen Technologie an. Das erinnert mich ein bisschen an die hier im Forum beliebten Programmiersprachendiskussionen, aber Du kannst Fortran in jeder Sprache schreiben. Hinsichtlich einer Diskussion über Technologien geht das jedoch komplett am Thema vorbei: wenn jemand in C nur Spaghetticode mit "goto" schreibt, dann ist das nicht die Sprache schuld, sondern der Schreibende und seine Unkenntnis. Übrigens erinnern mich solche Argumente in Diskussionen über Docker, K8s und Public Clouds auch noch in einem anderen Punkt an die Softwareentwicklung, namentlich die Objektorientierung. Das war ja auch mal so ein Hype, der zeitweise für Modernität stand und den viele, insbesondere auch Vertriebler, BWLler und Manager, unbedingt mitmachen wollten. Das hat dann einerseits dazu geführt, daß einige ihre Structs zu Klassen umbenannt, das Ergebnis als "objektorientiert" verkauft und damit der ganzen Technologie in vielen Kreisen einen schlechten Ruf beschert haben, der auch in den hier im Forum darum geführten Diskussionen gebetsmühlenartig wiederholt wird. Und andererseits hat es dazu geführt, daß plötzlich Entwickler zur "Objektorientierung" gezwungen wurden, die das weder gebraucht noch gewollt haben und deshalb überhaupt keine Lust hatten, das neue Paradigma zu lernen und korrekt anzuwenden. Das ist leider der Nachteil von Hypes, wenn sie den technischen Kreisen entwachsen und plötzlich "die Entscheider" Wind davon bekommen. Aber derartige Probleme haben glücklicherweise meistens nur die windigen Geschäftemacher, denen Profit über Sinn und Verstand geht und die sich gerne mit vermeintlich modernen Federn schmücken. Leider sterben solche Unternehmen entgegen meiner früheren Prognosen (auch ich war mal jung und naiv) noch nicht aus und solche Entscheider werden leider immer noch häufiger befördert als entlassen... aber auch daran ist nicht die Technik schuld. Wie in diesem Thread schon gesagt wurde: die Entscheidung für Containerlösungen ist eine strategische, die über die reine Technik hinaus geht. Und so einer derartigen strategischen Entscheidung gehört eben immer auch, die Mitarbeiter mitzunehmen, zu überzeugen und zu schulen. Das kostet natürlich Geld und ist deswegen unbeliebt, nichtsdestotrotz bleibt es aber unabdingbar.
Nur_ein_Typ schrieb: > Die Parameter --ip sowie die Netzwerktreiber macvlan und ipvlan > existieren. Nicht das was ich will. Nochmal für dich, da du meine Posts anscheinend inhaltlich nicht ganz erfasst: Ich will KEIN NAT und ich will per Policy festlegen können, von welchen IP Adressen der Port eines Containers erreichbar ist. Warum ich das möchte, habe ich zu genüge ausgeführt. Hier aber für dich nochmal: - Früherkennung von Angriffen per Honeypot und Zuordnung auf den betroffenen Container -> Mit NAT nicht möglich - Früherkennung von Angriffen per DPI und Zuordnung auf den betroffenen Container -> Mit NAT nicht möglich - Beschränkung ausgehender Ports in der vorgeschalteten Firewall (z.B. 25 und 53 zu) außer für bestimmte Container -> Mit NAT nicht möglich - Container sollen untereinander nur kommunizieren dürfen, wenn ich es zulasse. Eine Webapplikation z.B. mit einer SSRF Schwachstelle darf nicht andere Applikationen in der DMZ auch noch angreifen können. Nur_ein_Typ schrieb: > Zudem befürchte ich, daß das Prinzip "ichwillichwillichwill" im Realen > Leben (TM) noch nie besonders gut funktioniert hat. Du kannst natürlich > etwas wollen, etwa daß Du mit Deinem Formel1-Rennwagen auch Deine Felder > pflügen kannst, aber das heißt ja noch nicht zwangsläufig, daß so etwas > ökonomisch oder wenigstens möglich wäre. Mit "ichwillichwillichwill" hat das reichlich wenig zu tun. Ich habe bestimmte Anforderung an IT Sicherheit, die ich umsetzen MUSS. Mit VMs waren die schon vor der Einführung von Docker umgesetzt. Aus beschriebenen Gründen funktioniert das aber nicht genauso einfach. Mir ist auch klar, dass die meisten diese Anforderungen nicht haben. Offenbar gehörst auch du zu disen Bastlern. Nur_ein_Typ schrieb: > Außerdem beschleicht mich gerade irgendwie das unbestimmte Gefühl, daß > Du Deine Anforderungen dynamisch immer weiter anpaßt, so daß -- und, > wohlgemerkt: noch unterstelle ich kein "damit" -- sie am Ende nurmehr > mit mit VMs umsetzbar sind. Vielleicht bist Du einfach noch zu sehr in > dieser gewohnten VM-Denke gefangen und möglicherweise noch nicht > wirklich bereit für eine Veränderung -- das wäre ja nicht schlimm und > kommt in den besten Familien vor. Gut, welche Denke muss ich denn an den Tag legen? Muss mir Security am Allerwertesten vorbei gehen? Muss ich jetzt auf eindeutige IP Adressen und Firewalls verzichten, um Docker einsetzen zu können? Akzeptieren, dass ich IPv6 nicht sicher nutzen kann? Das hat auch nichts mit dynamischer Anpassung meiner Anforderungen zu tun. Ich habe in Post 0 geschrieben, dass ich auf keinen Fall NAT will. Die Gründe dafür habe ich kurz darauf erläutert. Sieh mir bitte nach, dass ich nicht gleich im ersten Post jedes Detail dieser durchaus komplexen Umgebung erläutern kann und will. Du präsentierst hier dagegen laufend Lösungen, die die genannten Anforderungen nicht erfüllen, ohne das eigentliche Problem zu erfassen. Vielleicht gibt es ja eine echte Alternative, die diese Probleme löst. Verraten hast DU sie bislang aber nicht. DU erscheinst hier eher als Google Guru ohne eigene Analyse- und Bewertungskompetenz. Im übrigen habe ich im Gegensatz zu dir schon lange eine Lösung dafür produktiv im Einsatz. Mit ihr geht aber auch eine erhebliche Komplexität einher. Genau das, was ich hier als Problem anmerke. Docker und Kubernetes sind sehr cool. Wer es richtig machen will, bemerkt aber die Komplexität. Dann kommt man je nach Anforderung eben an einen Punkt, an dem sich der Einsatz nicht mehr unbedingt lohnt. VMs sind genauso wenig die allgemeine Lösung für ein Problem wie Docker. DU scheinst dagegen aber mit deiner Denke nur noch mit fragwürdiger Kompetenz im Bereich Docker und Kubernetes fest zuhängen und bloß keinen Blick über den Tellerrand hinaus zu riskieren. Dass du bislang keine Lösung findest und Anforderung nicht korrekt erfasst, zeigt mir jedoch, dass du wohl wirklich nur ein Schaumschläger bist, der bestenfalls mal docker pull benutzt hat. Aber wie gesagt: Erklär mir gerne, warum meine Anforderungen Schwachsinn sind. Ich freue mich schon auf die Diskussion dazu. Nur_ein_Typ schrieb: > So ist das nunmal bei Neuerungen, am Anfang kennen sich nur wenige damit > aus und noch viel weniger haben sogar schon Erfahrungen. Du hingegen > hattest in Deinem ersten Beitrag in diesem Thread über die Technologie > und nicht über die Kenntnisse und Erfahrungen damit gerantet, insofern > entweder Dein erster Rant oder dieser Beitrag irgendwie am Thema vorbei > gehen. Und, wie viele Instanzen von Docker/Kubernetes kennst du, in denen IPv6 sauber bis ins letzte Detail implementiert wurde? Sieh dir doch einfach mal die großen Plattformen des Internets an. Wenn es IPv6 Unterstützung gibt, dann eher rudimentär. Google ist da eine erfreuliche Ausnahme. Insofern ist meine Kritik völlig berechtigt: Das saubere Setup einer NAT freien, sicheren Dualstackumgebung mit Docker ist viel zu kompliziert. Nicht unmöglich, aber von einer Lösung, die die Zukunft sein will und wird erwarte ich schon etwas mehr. Nur_ein_Typ schrieb: > Tatsache ist auch, daß ich etliche insbesondere kleine Firmen kenne, bei > denen es keine einzige VM gibt, just gestern wieder eine Arztpraxis mit > ~40 MA. Denen würde ich dann natürlich auch nicht empfehlen, ihre > Bestandsinfrastruktur von jetzt auf gleich auf VMs umzustellen. Und das > würdest Du doch auch nicht, oder? Das wollen wir jetzt wirklich nicht diskutieren. Ich hatte oft genug mit der Infrastruktur von Arztpraxen im Rahmen forensischer Untersuchungen nach Angriffen zu tun. Vor Ort arbeitet genau niemand, der versteht, wie die Infrastruktur arbeitet. Die zuständigen Dienstleister sind auch eher weniger hilfreich. Da läuft irgendein unsupportetes Gebastel ohne Sinn und Verstand. Wenn wir hier über professionelle Lösungen diskutieren wollen, dann sollten wir das nun wirklich außen vor lassen. Nur_ein_Typ schrieb: > räusper Verzeihung, aber... Du kommst in ein Unternehmen, das sich bei > einem bestimmten Produkt offenbar ohnehin schon verrannt hat, willst die > entstandenen Probleme dann mit einer Technologie lösen, die bei den > Kollegen auf breite und nichtmal begründete Ablehnung stößt (unbegründet > heißt ja: sie haben sich diese Technologie nicht einmal genau genug > angesehen, um sachliche Argumente dagegen vorbringen zu können) und > erwartest dann noch, daß Du mit ebendieser Technologie gegen den > Widerstand Deiner Kollegen erfolgreich sein kannst? Weißt du, da bin ich egoistisch. Wenn man mir einen verbastelten Haufen Müll hinschmeißt und sagt: "Ab sofort machst du das", dann mache ich das. Das heißt aber auch, dass ich mir die Arbeit erleichtere. Ob diejenigen, die mir den Brocken hinwerfen damit noch klarkommen, falls sie es irgendwann wieder müssen, ist mir ziemlich egal. Nur_ein_Typ schrieb: > Dann ist es sicherlich besser so, daß Du Deinen Hut genommen hast. Aber > daß es obskure Anbieter mit windigen Geschäftsmodellen gibt, hat mit > Docker, K8s und Public Clouds doch auch nichts zu tun. Stimmt. Die Geschichte ist auch als Anekdote am Rande zu verstehen. Zeigt aber genau das Klientel, dass mir einem sauberen Betrieb einer Dockerumgenung überfordert wäre. Nur_ein_Typ schrieb: > Das sind all diese kleinen Detailfragen, die eine Containerlösung > ziemlich sauber abstrahieren, vereinheitlichen, und vereinfachen kann. Stimmt. Wir müssen aber auch über die Vorteile gar nicht diskutieren. Da gehe ich mit. Nur_ein_Typ schrieb: > Und wieder lastest Du die Unfähigkeit der Admins der von ihnen ganz > offensichtlich unverstandenen Technologie an. Das erinnert mich ein > bisschen an die hier im Forum beliebten Programmiersprachendiskussionen, > aber Du kannst Fortran in jeder Sprache schreiben. Hinsichtlich einer > Diskussion über Technologien geht das jedoch komplett am Thema vorbei: > wenn jemand in C nur Spaghetticode mit "goto" schreibt, dann ist das > nicht die Sprache schuld, sondern der Schreibende und seine Unkenntnis. Nö. Die Technologie ist klasse, aber komplex. Wer sie nicht beherrscht merkt es nicht. Du hast es ja selbst offenbar auch noch nicht bemerkt. Und diese Leute lasse ich lieber VMs administrieren als Docker Umgebungen. Zumal ja unter den meisten Clustern ohnehin kein Blech liegt. Denk mal drüber nach. So obsolet sind VMs noch lange nicht. Ich glaube ich habe hier nun wirklich alles gesagt, was es zu sagen gab. Ich wiederhole mich nur noch. Insofern klinke ich mich jetzt hier aus. Es gibt nur wenige, die sich wirklich mit den Problemen aktueller Containerlösungen auskennen. Du gehörst leider nicht dazu.
Hans schrieb: > Nur_ein_Typ schrieb: >> Die Parameter --ip sowie die Netzwerktreiber macvlan und ipvlan >> existieren. > > Ich will KEIN NAT und ich will per Policy > festlegen können, von welchen IP Adressen der Port eines Containers > erreichbar ist. Das habe ich verstaden. Deswegen rede ich ja ganz genau davon. Docker ohne NAT. > Ich habe bestimmte Anforderung an IT Sicherheit, die ich umsetzen MUSS. Dann mach' das doch einfach. Die kannst Du auf nacktem Blech, mit VMs, und eben auch mit Containern umsetzen, ganz wie Du magst, kannst, und darfst. Du hingegen behauptest, daß Du sie nicht mit Containern umsetzen könntest, was ich wiederum bestreite und Dir zeige, wie das sehr wohl möglich ist. Und während ich Dir erkläre, wie das geht, fängst Du wieder von vorne an und verklickerst mir wieder, daß Du "bestimmte Anforderung an IT-Sicherheit" hast. Geht's noch? Ja, Hans, Du hast spezifische Anforderungen und ja, tatsächlich, das habe ich doch verstanden. Ich selbst habe ja durchaus ähnliche Anforderungen an IT-Sicherheit zu erfüllen und erkläre Dir deswegen nicht nur daß, sondern sogar, wie sie auch mit Docker umgesetzt werden können. Ganz ohne NAT, genau wie gefordert. > Mit VMs waren die schon vor der Einführung von Docker umgesetzt. Ja, natürlich, das hat ja auch niemand bestritten. Und wenn man will, kann man sie auch mit Docker umsetzen. Ich habe Dir sogar aufgezeigt, wie das geht. > Aus beschriebenen Gründen funktioniert das aber nicht genauso einfach. Es funktioniert anders. Was einfacher ist, ist eine reine Geschmacksfrage. > Mir ist auch klar, dass die meisten diese Anforderungen nicht haben. Tja, ich schon. Und ich erfülle sie (auch) mit Containern. > Gut, welche Denke muss ich denn an den Tag legen? Die Frage ist doch: kann man Deine Anforderungen mit Docker umsetzen? Diese Frage beantwortest Du aber gar nicht, weil Du Deine Anforderungen bereits mit VMs erfüllt und deswegen keinen Bedarf hast. Daß Du keinen Bedarf hast, spricht aber tatsächlich nicht gegen Docker & Co., sondern nur dagegen, daß Du einen Bedarf hast. Das ist ja völlig okay, daß Du eine Lösung hast und sie nicht nochmal auf einer anderen Basis umsetzen möchtest. Und auch ich sage nicht mehr, als daß Deine Anforderungen auch auf der Basis von Docker umgesetzt werden können -- was Du immer noch bestreitest, obwohl ich Dir sogar ausdrücklich gezeigt habe, wie das geht. > Muss mir Security am Allerwertesten vorbei gehen? Pardon, findest Du solche blöden Strohpuppen wirklich zielführend? > Muss ich jetzt auf eindeutige IP Adressen und Firewalls verzichten, > um Docker einsetzen zu können? Nein. Nutze sie einfach mit Docker, wenn Du willst und / oder einen Bedarf hast. Wenn nicht, dann laß' es. Aber Deine Behauptung, daß sie mit Docker nicht umgesetzt werden könnten, ist schlicht und ergreifend falsch und daher auch kein valides Argument gegen die Verwendung von Docker. > Ich habe in Post 0 geschrieben, dass ich auf keinen Fall NAT will. ...und ich habe Dir dazu dann sogar mehrere Möglichkeiten aufgezeigt, wie man Docker auch ohne NAT benutzen kann. Ja, das erfordert ein wenig zusätzlichen Aufwand bei der Verwaltung und Konfiguration Deiner IP-Adressen, aber diesen Aufwand mußt Du bei VM-basierten Infrastrukturen ja ganz genauso betreiben. Und sogar die Möglichkeiten sind bei VMs ziemlich ähnlich, zumindest wenn wir mal auf das unter Linux beliebte KVM betrachten -- da ist User Networking mit (sic!) NAT übrigens der Default und der Aufwand, Deine VMs extern erreichbar zu machen, deutlich größer als unter Docker. > Vielleicht gibt es ja eine echte Alternative, die diese Probleme löst. > Verraten hast DU sie bislang aber nicht. DU erscheinst hier eher als > Google Guru ohne eigene Analyse- und Bewertungskompetenz. Bitte schau noch einmal nach oben, da habe ich Dir diese Alternativen genannt. Möglicherweise möchtest Du Dich einmal Deinerseits als Google-Guru betätigen und nachsehen, was es mit den von mir genannten Lösungen auf sich hat. > Im übrigen habe ich im Gegensatz zu dir schon lange eine Lösung dafür > produktiv im Einsatz. Mit ihr geht aber auch eine erhebliche Komplexität > einher. Genau das, was ich hier als Problem anmerke. Docker und > Kubernetes sind sehr cool. Wer es richtig machen will, bemerkt aber die > Komplexität. Dann kommt man je nach Anforderung eben an einen Punkt, an > dem sich der Einsatz nicht mehr unbedingt lohnt. VMs sind genauso wenig > die allgemeine Lösung für ein Problem wie Docker. DU scheinst dagegen > aber mit deiner Denke nur noch mit fragwürdiger Kompetenz im Bereich > Docker und Kubernetes fest zuhängen und bloß keinen Blick über den > Tellerrand hinaus zu riskieren. Tja, wer hätte das gedacht: manchmal ist es kompliziert, bestimmte Anforderungen zu erfüllen. Die Umsetzung mit Docker & Co. ist komplex, die mit VMs aber auch. Im Westen nichts Neues also, wer hätte das gedacht. Mich deucht, wir reden an einander vorbei, weil Du mir mal implizit, mal explizit etwas unterstellst, das ich weder gedacht noch gesagt habe. Ich habe gar nichts gegen VMs. Im Gegensatz zu Dir habe ich aber auch nichts gegen Docker. Bitte nicht vergessen: dieser Unterfaden ist entstanden, weil Du Docker in Bausch und Bogen verdammt hat, Deine VMs als allein seligmachende Lösung propagiert und behauptet hat, daß sich Deine (nicht einmal so speziellen) Anforderungen nicht mit Docker umsetzen ließen. Daraufhin habe ich Dir entsprechende Möglichkeiten gezeigt, wie das mit Docker sehr wohl geht -- und jetzt versuchst ausgerechnet Du, mich als inkompetent hin- und mir implizit zu unterstellen, ich sei irgendwie ideologisch fixiert. Janeeisklaa. > Dass du bislang keine Lösung findest und Anforderung nicht korrekt > erfasst, zeigt mir jedoch, dass du wohl wirklich nur ein Schaumschläger > bist, der bestenfalls mal docker pull benutzt hat. Aber wie gesagt: > Erklär mir gerne, warum meine Anforderungen Schwachsinn sind. Ich freue > mich schon auf die Diskussion dazu. Bitte was soll ich Dir erklären, bist Du noch ganz bei Dir? Warum sollte ich Dir etwas erklären, das ich für Unsinn und falsch halte? Ich erkläre Dir stattdessen etwas ganz anderes. Nämlich, wie Du Deine Anforderungen mit Docker umsetzen könntest, wenn Du wolltest. Ob Du das willst, steht wieder auf einem anderen Blatt und ist für die Frage, ob Du es könntest, völlig irrelevant. > Weißt du, da bin ich egoistisch. Wenn man mir einen verbastelten Haufen > Müll hinschmeißt und sagt: "Ab sofort machst du das", dann mache ich > das. Das heißt aber auch, dass ich mir die Arbeit erleichtere. Ob > diejenigen, die mir den Brocken hinwerfen damit noch klarkommen, falls > sie es irgendwann wieder müssen, ist mir ziemlich egal. Tja, da habe ich einen etwas anderen Ansatz, übrigens auch wegen Anforderungen wie Business Continuity, Risk Management, Disaster Recovery und so weiter. Darum gehe ich die -- ja, durchaus manchmal aufwändige und hie und da sogar schmerzhafte -- Extrameile, meine Kollegen und Vorgesetzten bei allen von mir gewählten Lösungen mitzunehmen, also: sie zu schulen, womöglich gar zu überzeugen, und dazu natürlich alles umfangreich, strukturiert und sauber zu dokumentieren. Es erscheint mir auch durchaus widersprüchlich, wenn Du hier einerseits gehobene Anforderungen und Ansprüche für Dich reklamierst, die Dir dann aber andererseits wiederum "ziemlich egal" sind. Bei dem von Dir genannten Anforderungen nach KRITIS geht es im Wesentlichen darum, daß kritische Infrastrukturen nicht nur sicher sind, sondern vor allem, daß ihr Fortbetrieb auch im Falle von Störungen, Angriffen und anderen auftretenden Schwierigkeiten sichergestellt ist. Dazu gehört zwingend (!) auch, daß der Betreiber dieser Infrastrukturen die Fähigkeiten und entsprechend geschultes Personal hat, das diesen Fortbetrieb gewährleisten kann. Kurz gesagt: wenn Du die Anforderungen nach KRITIS, die Du reklamierst, wirklich ernst nehmen würdest, kann und darf es Dir eben nicht "ziemlich egal" sein, wenn Deine Kollegen Deine Lösungen nicht mehr weiterbetreiben können, wenn Du -- warum auch immer -- einmal nicht (mehr) verfügbar bist. Natürlich bist da nicht nur Du alleine Du in der Pflicht, aber auch Dein Teil gehört zu KRITIS inhärent dazu. > Stimmt. Die Geschichte ist auch als Anekdote am Rande zu verstehen. > Zeigt aber genau das Klientel, dass mir einem sauberen Betrieb einer > Dockerumgenung überfordert wäre. So, wie Du das beschrieben hast, bin ich allerdings geneigt, dieses Klientel auch mit den Betrieb beliebiger anderer Infrastrukturen für überfordert zu halten. > Nö. Die Technologie ist klasse, aber komplex. Wer sie nicht beherrscht > merkt es nicht. Du hast es ja selbst offenbar auch noch nicht bemerkt. > Und diese Leute lasse ich lieber VMs administrieren als Docker > Umgebungen. Anscheinend nicht, sonst hättest Du Deine Kollegen ja nicht auf Deiner Lösung, die sie nicht weiterbetreiben können, sitzenlassen. > Zumal ja unter den meisten Clustern ohnehin kein Blech > liegt. Denk mal drüber nach. So obsolet sind VMs noch lange nicht. Hat denn jemand behauptet, daß VMs obsolet seien? Ich war das jedenfalls nicht. Diese Unterdiskussion hat sich doch nur deshalb entsponnen, weil Du über Docker gerantet hast und nicht, weil ich etwas gegen VMs gesagt hätte. > Ich glaube ich habe hier nun wirklich alles gesagt, was es zu sagen gab. > Ich wiederhole mich nur noch. Insofern klinke ich mich jetzt hier aus. > Es gibt nur wenige, die sich wirklich mit den Problemen aktueller > Containerlösungen auskennen. Du gehörst leider nicht dazu. Immerhin weiß ich im Gegensatz zu Dir, wie sich Deine Anforderungen mit Docker realisieren lassen. Daß Du das nicht verstehen oder meinethalben vielleicht auch nicht wahrhaben willst, ändert daran nichts. Insofern ist es schon lustig, wenn ausgerechnet Du_ _mir Inkompetenz unterstellst -- und das ausgerechnet deswegen, weil ich Deinem undifferenzierten Rant über Docker widersprochen und Dir mehrere Dir bislang anscheinend unbekannte Lösungen für die von Dir reklamierten Anforderungen aufgezeigt habe, die Dir ansonsten aber "ziemlich egal" sind. Kann es sein, daß Du im Wesentlichen darauf aus bist, auf irgendwas oder irgendwen einzudreschen? Es scheint beinahe so. Erst prügelst Du mit harten Worten auf Docker ein und behauptest hahnebüchenen Unsinn, und als ich Dir widerspreche und erkläre, warum Deine Behauptungen unsinnig waren, fängst Du an, auf mich einzudreschen. Es hätte die ganze überflüssige Unterdiskussion aber gar nicht gegeben, wenn Du Dich von vorneherein etwas kompetenter und gemäßigter geäußert hättest.
32GB RAM und 256GB SSD ist zu wenig, wenn man mit VMs spielen möchte. Ja, es geht, aber in der Praxis will man ein sorgenfreies Leben. Und wenn man mal eben zwei VMs laufen hat, denen jeweils nur 8GB RAM zugewiesen ist, was will man mit diesen VMs machen? Auf jeden Fall nichts vernünftiges. Und für das Host-System bleiben dann auch nur noch 16GB übrig. Und ja, man hat ganz ruck-zuck mehrere VMs am laufen. Denn man experimentiert ja damit. Und so ist es auch mit der SSD. Ein paar Images rumliegen haben, ein paar Snapshots, ein paar VMs erzeugt, schon ist der Platz weg. Also: 64GB RAM, und min. 1TB SSD. Wenn man wirklich ernsthaft programmieren möchte, kann man getrost 2TB reinstecken. Schaut euch doch mal an, wie fett irgendwelche IDEs oder Distributionen sind, bis sie komplett sind, oder wieviel Package-Tools irgendwelcher Sprachen cachen wollen etc. Wenn man programmiert, will man eins genau nicht haben: Knappe Ressourcen.
Ach ist dieser komische Typ geil. Wenn er doch nur mal lesen würde. Inhaltlich von Minute Null an nichts zu sagen. Nicht schlecht
virtualizer schrieb: >> NVMe-SSDs sind deutlich schneller > Nochmal deutlich schneller sind gestripte NVMe-SSD. > Z.B. 4 x 2 TB als Stripe Set. Das waere dann auch Platz genug fuer VMs. Viel Spaß beim Backup. > Die 32 GB RAM reichen da auch hinten und vorne nicht. Pro-Tip: Verzichte auf die SSD und die HDD und kauf dir ein System, was einfach genug RAM für alles hat. Ich persönlich "programmiere" auf einem Notebook mit Core i5-6xxx und lass da auch ab und an eine VM laufen.
Reinhard S. schrieb: > Verzichte auf die SSD und die HDD und kauf dir ein System, was > einfach genug RAM für alles hat. RAM als Ersatz für Massenspeicher? ;-) Aber die ganzen Tipps für Ressourcen leiden immer noch daran, dass die Anforderungen völlig offen sind. Ich habe privat etliche VMs auf einem 15W 1kg Laptop mit einer 1TB m.2 SSD und 40GB RAM - weil es den mit 32GB nicht gab. Für das, was ich damit mache, reicht er völlig.
:
Bearbeitet durch User
Frage ist gleich nach seiner Frage abgetaucht und freut sich jetzt riesig, wie ihr euch eure Nasen blutig boxt!
(prx) A. K. schrieb: > Reinhard S. schrieb: >> Verzichte auf die SSD und die HDD und kauf dir ein System, was >> einfach genug RAM für alles hat. > > RAM als Ersatz für Massenspeicher? ;-) Man lernt sehr schnell, ordentliche Backups zu machen ;) Das OS und die VMs kann er ja dann entweder von einem USB-Stick seiner Wahl oder einem 2x10G-NAS rüberziehen. :)
:
Bearbeitet durch User
michael_ schrieb: > Frage ist gleich nach seiner Frage abgetaucht und freut sich jetzt > riesig, wie ihr euch eure Nasen blutig boxt! Ach komm. Bei der Lesekompetenz holt sich nur_ein_typ doch an jeder Ecke eine blutige Nase. Ein "Vorsicht Stufe" reicht bei dem schon aus.
Hans schrieb: > michael_ schrieb: >> Frage ist gleich nach seiner Frage abgetaucht und freut sich jetzt >> riesig, wie ihr euch eure Nasen blutig boxt! > > Ach komm. Bei der Lesekompetenz holt sich nur_ein_typ doch an jeder Ecke > eine blutige Nase. Ein "Vorsicht Stufe" reicht bei dem schon aus. Also bisher fand ich ihn überzeugender und sachlicher als Dich.
Sheeva P. schrieb: > Also bisher fand ich ihn überzeugender und sachlicher als Dich. Dann werde ich deine Meinung wohl nicht mehr ändern können, denn das Thema hatte ich ja schon für beendet erklärt. Zum Glück ist es aber auch nicht Ziel eines Forums dich von mir zu überzeugen. Fakt ist, dass er meine Beiträge offenbar entweder nicht gelesen oder nicht verstanden hat. Denn viele seiner vermeintlichen Lösungen funktionieren aus verschiedenen Gründen nicht. Lange bevor er macvlan & co vorgeschlagen hat, hatte ich schon erklärt welche Probleme das mitbringt. Ich habe nur wenig Interesse daran mich ständig zu wiederholen und werde dann gegenüber jemanden, der sich überheblich als allwissender Experte darstellt, auch irgendwann mal unsachlich. Nehmen wir mal an, dass er die Probleme nicht versteht, dann ist er wohl schlichtweg jemand, der sich hier reichlich aufspielt. Also wenig überzeugend. Nehmen wir dagegen an, dass er einfach nur nicht lesen will, fände ich auch das nicht wahnsinnig überzeugend. Auch hat er mich offenbar als Dockerfeind auserkoren. Der bin ich definitiv nicht. Wie auch in einem meiner ersten Beträge beschrieben administriere ich selbst eine große Kubernetes Umgebung. Auch das hat er permanent dezent ignoriert. Ich sehe aber auch die Schwächen und eben auch die Komplexität, die mit einem soliden Betrieb einhergehen. Wenn ihm das nicht passt, dann ist das sein Problem. Ja, es gibt Lösungen für all die Probleme, die ich hier beschrieben habe. Teilweise machen sie die Lösung Docker & Kubernetes aber leider viel weniger elegant, als sie sein könnte. Von einer Technologie, die die Zukunft sein soll und wird, erwarte ich nunmal etwas mehr. Sieh dir doch mal diese ganzen Cloud native services an. Die meisten davon sind nicht Dualstack fähig. Warum nicht? Eine ganze Reihe von CNI für Kubernetes ist bis heute nicht IPv6 ready und standalone Docker ist mit IPv6 absolut gruselig (Probleme bereits oben beschrieben). Selbst die Einrichtung IPv6 fähiger CNIs wie Calico bereitet mehr Probleme als Dualstackumgebung. Und wenn wir schon über Sachlichkeit sprechen, sei nochmal der Beitrag erwähnt, auf den ich hier inital reagiert habe: Draconix schrieb: > Wer in Zeiten von docker und k8 noch 100VMs laufen hat, gehört sowieso > geteert und gefedert. Auch Unternehmen... War der sachlich? Nein! Warum nicht, habe ich im Nachgang zu genüge ausgeführt. Ist es erforderlich auf Polemik übermäßig sachlich zu reagieren? Im Geschäftsumfeld auf jeden Fall und hat Mitbewerbern schon den Auftrag gekostet. In einem Forum, das zu über 50% nur aus Polemik besteht dagegen mit sicherheit nicht. Mein erster Post Hans schrieb: > Wer für jeden Mist docker und k8 einsetzt ebenfalls. Diese Lösungen > haben sehr spezifische anwendungsfälle, bringen sehr spezifische > Probleme mit und eignen sich bisher nicht, um eine generische IT > Umgebung zu betreiben. Sie spielen ihre Stärken erst beim Skalieren > einheitlicher Container aus. Wer 100 unterschiedliche VMs betreibt, der > wird mit Docker nicht glücklicher. Die Komplexität und Betriebsrisiken > stehen in keinem Verhältnis zu den möglichen Einsparungen von > Ressourcen. Außerdem sind viele Dinge mit docker schlicht nicht möglich. > Teilweise, weil einfach grauenhaft konzipiert. Wenn ich mir nur dieses > widerliche NAT, Port Binding und den gruseligen v6 Support ansehe, weiß > ich, warum auch heute noch so viele Services v4 only sind. war übrigens auch nicht sachlich. Warum auch? Ich stehe aber trotzdem hinter jedem der genannten Punkte. Ein wesentlicher Punkt: Das was ich da schreibe ist berechtigte Kritik an der der Lösung Docker/k8. Nun ist aber auch die Reaktion des komischen Typen auf meinen ersten Post noch weit weniger sachlich: Nur_ein_Typ schrieb: > Nun habe ich in diesem Forum wirklich schon sehr viel Hahnebüchenes > gelesen, aber jene Ausführungen gehören definitiv zu den Top Ten. > Herzlichen Glückwunsch! Tut mir leid, aber er hat das von Anfang an persönlich genommen. Inhaltlich noch viel weniger zu sagen als mein Post, dafür aber direkt persönlich werden. Das soll überzeugend sein?
Sheeva P. schrieb: > Also bisher fand ich ihn überzeugender und sachlicher als Dich. Und um dazu nochmal nachzutreten, einfach, weil mir irgendwelche Schaumschläger hier in diesem Forum inzwischen reichlich auf den Keks gehen, benenne ich an dieser Stelle mal die Lösungen für die von mir beschriebenen Probleme. Problem Durch NAT kein Routing, dadurch keine Nachvollziehbarkeit in IDS/Firewalls/DPI Lösung Nutzung eines CNI mit entsprechender Funktion. Calico kann Routen dynamisch an BGP Peers (z.B. ToR Router) announcen. Gilt sowohl für Pod IPs, als auch für Services. Spart Traffic und dadurch Last, indem unnötiges Routing über das Overlay Netzwerk des Clusters vermieden werden kann. Problem am Rande Möchte ich skalieren und eine Applikation dann sinnvollerweise als Service nach außen öffnen, komme ich erneut in das NAT Thema. Lösung Externer Loadbalancer auf Layer 7 spricht mit dem Service. Läuft entsprechend außerhalb des Clusters und profitiert nicht von dessen Vorteilen. Bedeutet in On-Premise Installationen zusätzlichen Aufwand, der sich erstmal lohnen muss. Alternative Pod(s) mit statische(r/n) IP(s) für Loadbalancer anlegen und Routing zum Pod verwenden. Ist aber leider etwas hacky. Eigentlich ein Antipattern. Problem Firewalling im Cluster / Container bzw. Pods können sich untereinander erreichen. Inkompatibilität mit manuellen Änderungen an iptables. Kein Support von nftables. Showstopper für Cluster mit unterschiedlichen Applikationen, erst recht bei mehreren Kunden. Lösung Definition passender Ingress/Egress Policies. Erfordert Anpassungen bei zentralisierter Regelerstellung, aber machbar. Problem IPv6 Support Lösung Kümmer dich von Anfang an. IPv4 only CNIs auszutauschen ist kein großer Spaß. Aber auch die verfügbaren Dokus zum Dualstack setup sind leider eher schlecht. Problem Betriebsrisiko. Unschönes Beispiel: Administration des Cluster hängt von einer Plattform ab, die innerhalb des Clusters betrieben wird. Ein Admin macht bei der Netzwerkkonfiguration einen Fehler. Nun sind Pods und Services nicht mehr erreichbar. Lösung Hoffentlich habe ich Urlaub. Ach Mist, der Laden gehört ja mir. Dann: Vielleicht betreibe ich den ein oder anderen Service doch lieber außerhalb des (selben) Clusters. Huch, jetzt brauche ich ja doch noch VMs. Von jemandem, der wirklich Erfahrung im Betrieb von Kubernetes Clustern hat, erwarte ich, dass er diese Lösungen und deren Implikationen kennt. Wer die nicht kennt, ist entweder im organisatorischen Bereich tätig (völlig legitim) oder hat das Cluster als Admin einfach mal so hingerotzt. Die Bastellösungen von nur_ein_typ waren nicht dabei. Hätte er mal gelesen, dann hätte er sogar gemerkt, dass ich die schon vor ihm benannt hatte. Damit habt ihr praktisch selbst meine anfängliche Kritik bestätigt. Kaum jemand betreibt solche Umgebungen auf einer zukunftsfähigen und sicheren Basis. Herzlichen Glückwunsch. Problem Virenscanner? Gesucht ist kein Scan von Dateien, sondern des eigentlichen Containers (Was ich davon halte hatte ich ja schon erwähnt) Irgendeine Idee? Scheinbar ja nicht. Ich auch nicht. Ich bleibe also bei meinem Kommentar zum Einstieg: nur_ein_typ ist ein nur_ein_schaumschläger und Docker und Kubernetes sind nicht die Eierlegende Wollmilchsau, die den Betrieb sämtlicher VMs überflüssig macht. Es ist eine schöne Ergänzung, die ihre Stärken in bestimmten Bereichen mit wenig Aufwand ausspielen kann. Betreibe ich aber viele verschiedene Workloads, muss ich mir plötzlich Gedanken um eine ganze Menge Dinge machen, die eben nicht trivial sind. Je nach Umgebung lohnt sich das eben nicht. Eine Frage hätte ich dann aber noch an die "Profis" hier. Lohnt es sich für euch eine Applikation zu Containern, von der ihr genau eine Instanz braucht? Also eine Applikation, die einmalig aufgesetzt wird und nicht skalieren muss. Ich gehe davon aus, dass kein fertiges Image zur Verfügung steht, denn selbst offizielle Images müssen angepasst werden. Installationsaufwand zählt nicht wirklich, da das OS automatisch installiert wird und ich die Installationsschritte so oder so durchgehen muss. Sei es im Dockerfile oder manuell auf der Kommandozeile. Ich bin da etwas hin und hergerissen. Prämisse: Monitoring, Wartung und Sicherheitsrichtlinien sind sowohl für klassische VMs, als auch für Container vorhanden. Konfigurationsanpassungen sind in einem Container wesentliche aufwendiger, wenn ich einmal durch die CI/CD Pipeline muss, dafür aber auch sicherer, wenn sauber implementiert. Lohnt sich das für euch?
Ja, dachte ich es mir doch. Da waren die "Profis" hier wirklich nur Schaumschläger. Die Stille ist entlarvend, meine Lieben.
Ach seht mal hier: Beitrag "Re: DynDNS und Fritzbox Fragen" Da will jemand 30 Rechner zuhause betreiben. Erklärt dem doch mal was von Docker und Kubernetes.
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.