Forum: PC Hard- und Software PC für virtuelle Maschinen & Programmieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frage (Gast)


Angehängte Dateien:

Lesenswert?

Hi, findet ihr die Leistungswerte für oben genannte Verwendung 
angebracht.
Was schätzut ihr, wo wir preislich liegen?
Viele Grüße

von Soeren K. (srkeingast)


Lesenswert?

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
von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von virtualizer (Gast)


Lesenswert?

> 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.

von nunja (Gast)


Lesenswert?

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?

von ja (Gast)


Lesenswert?

ja das passt

von no (Gast)


Lesenswert?

nein, ungeeignet

von Ratloser Schlaumeier (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

virtualizer schrieb:
> Nochmal deutlich schneller sind gestripte NVMe-SSD.
> Z.B. 4 x 2 TB als Stripe Set.

Man kann es auch übertreiben.

von (prx) A. K. (prx)


Lesenswert?

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
von Rolf M. (rmagnus)


Lesenswert?

(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.

von (prx) A. K. (prx)


Lesenswert?

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
von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

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

von Gerald B. (gerald_b)


Lesenswert?

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.

von virtualizer (Gast)


Lesenswert?

> 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.

von Schwurbler (Gast)


Lesenswert?

(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.

von (prx) A. K. (prx)


Lesenswert?

Schwurbler schrieb:
> Kein Mensch macht so etwas.

Privat nicht. Unternehmen schon.

von virtualizer (Gast)


Lesenswert?

Schwurbler schrieb:

> wer redet hier von 100 aktiven VMs?

Schlaumaier bist du es?

von Manfred (Gast)


Lesenswert?

(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?

von Draconix (Gast)


Lesenswert?

Wer in Zeiten von docker und k8 noch 100VMs laufen hat, gehört sowieso 
geteert und gefedert. Auch Unternehmen...

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Lotta  . (mercedes)


Lesenswert?

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

von Hans (Gast)


Lesenswert?

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.

von Noch ein Kommentar (Gast)


Lesenswert?

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.

von virtualizer (Gast)


Lesenswert?

> Ein Stripeset für die VM ist aber absolut geil.

Wenigstens eine(r) mit gutem Geschmack.

von Nur_ein_Typ (Gast)


Lesenswert?

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!

von Random .. (thorstendb) Benutzerseite


Lesenswert?

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.
von Hans (Gast)


Lesenswert?

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?

von Nur_ein_Typ (Gast)


Lesenswert?

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! ;-)

von Hans (Gast)


Lesenswert?

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.

von Nur_ein_Typ (Gast)


Lesenswert?

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

von Hans (Gast)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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.

von Draconix (Gast)


Lesenswert?

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!"

von Nur_ein_Typ (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

(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.

von Hans (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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. 
:)

von Sheeva P. (sheevaplug)


Lesenswert?

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?!

von Hans (Gast)


Lesenswert?

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.

von Gretel (Gast)


Lesenswert?

> 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.

von Nur_ein_Typ (Gast)


Lesenswert?

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.

von Nur_ein_Typ (Gast)


Lesenswert?

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.

von kleiner Admin (Gast)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Nur_ein_Typ (Gast)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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.

von Nur_ein_Typ (Gast)


Lesenswert?

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.

von Einer (Gast)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

Ach ist dieser komische Typ geil. Wenn er doch nur mal lesen würde. 
Inhaltlich von Minute Null an nichts zu sagen. Nicht schlecht

von Reinhard S. (rezz)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von michael_ (Gast)


Lesenswert?

Frage ist gleich nach seiner Frage abgetaucht und freut sich jetzt 
riesig, wie ihr euch eure Nasen blutig boxt!

von Reinhard S. (rezz)


Lesenswert?

(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
von Hans (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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?

von Hans (Gast)


Lesenswert?

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?

von Hans (Gast)


Lesenswert?

Ja, dachte ich es mir doch. Da waren die "Profis" hier wirklich nur 
Schaumschläger. Die Stille ist entlarvend, meine Lieben.

von Hans (Gast)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.