Docker und Docker Swarm waren meine ersten Gehversuche mit Container. Nach wie vor nutze ich privat insbesondere Docker Swarm für kleine Anwendungen. Einfach aus dem Grund weil es einfach zu deployen ist. Ein Docker Swarm cluster ist in wenigen Minuten erstellt. Das finde ich bei Kubernetes nach wie vor deutlich aufwenidger. Und bisher habe ich bei Docker Swarm nichts vermisst. Also zum Einstieg wie Container Cluster Orchestrierung funktioniert ist Docker Swarm nach wie vor mein Favorit. Aber aus den genannten Gründen und auch weil ich es beruflich brauche habe ich natürlich begonnen mir Kubernetes anzueignen.
[gr] Ich denke, der einfachste Weg, die Installation zu umgehen, ist, ein Managed-Cluster zu buchen - aber anders als ein Docker Swarm-Cluster funktioniert das natürlich nicht mehr auf eigener Hardware, sondern ausschließlich nur noch in der Cloud. Eventuell können hier auch Projekte wie k3s eine Alternative sein.
Apropos technologische Sackgassen: Das wär doch auch mal ein schönes Thema, wie erkennen, wie vermeiden, was tun wenn man merkt hineingeraten zu sein...
Wir nutzen Docker derzeit nur als "Notlösung" um unter Windows das Arbeiten mit 2 Linux-Servern zu simulieren. Das läuft in unserem Fall mehr schlecht als recht und wir haben sehr oft Probleme damit. Nun hatte ich mich schon etwas mit K8s beschäftigt und parallel angestoßen, dass wir auf unseren Entwicklungsrechnern weg von Windows und hin zu einem nativen Linux gehen. Dort planen wir dann langfristig K8s einzusetzen um auch lokal verteilte Dienste und ganze Cluster simulieren zu können. Aus diesem Grund wäre für uns ein Video interessant mit ausführlichen Informationen zu den verschiedenen von K8s unterstützten Containertypen mit ihren jeweiligen Vor- und Nachteilen. Ich hatte mir neben Docker auch mal etwas zu LXC durchgelesen und sehe da ein paar Vorteile. Ich gehe jedoch davon aus, dass ihr auf dem Gebiet deutlich mehr Erfahrung habt und würde mich über ein entsprechendes Video freuen :)
Für Docker-Swarm spricht, das es sehr niederschwellig ist. Dadurch das es a) schon integriert ist und b) einen überschaubaren Funktionsumfang hat, ist es eher was für Anfänger. "Die Cloud für den kleinen Mann." Und so würde ich das auch vermarkten.
Ja … wobei sich da - finde ich - die Frage stellt, ob man da nicht eher auf so etwas wie K3s & Co. setzen sollte: Das ist auch deutlich einfacher und leichtgewichtiger als das "große" Kubernetes, aber Du hast halt einen kompatiblen Upgrade-Pfad und bist nicht auf einer proprietären Plattform unterwegs, bei der von Anfang an absehbar ist, dass man nur bedingt weit kommt. Aber am Ende hängt das natürlich auch an den jeweiligen, individuellen Anforderungen.
Der initiale Aufbau von Kubernetes ist schon aufwendig, daher nutze ich privat auf meinem „Bastelserver“ docker Swarm, aber für alles andere Kubernetes auf der Google Cloud. Wenn es Kubernetes beim Aufbau nicht so aufwendig wäre dann würde ich nicht docker swarm verwenden oder vielleicht ist es sogar leichter geworden (hab es vor 1,5 Jahren mal probiert) … so ein Kubernetes Einrichten Tutorial wäre auch nice :)
Das Problem ist, dass wir sowieso auch auf eine Technologie nach k8s wechseln werden. Da können manche vielleicht direkt k8s überspringen. Docker hat ja jetzt fürs Hub das Abomodell ausgerollt und alle Standards von denen sind ja offen. So vorschnell würde ich das Thema nicht abschließen. Auf k8s setzen nach meiner Erfahrung immer noch nur sehr große Unternehmen, für alle anderen reicht Swarm dicke.
[gr] Mein Gegenargument wäre, dass Kubernetes einen gewissen De-Facto-Standard definiert, auf dem derzeit viele Systeme basieren und aufbauen. Im Gegensatz dazu ist Docker Swarm proprietär und im Vergleich eher auf dem absteigenden Ast. Natürlich wird auch Kubernetes nicht das letzte Wort sein, was jemals gesprochen wird, aber es ist zumindest derzeit nicht mal ansatzweise etwas in Sicht, was Kubernetes einmal beerben könnte. Insofern würde ich mir überlegen, ob es nicht sinnvoll wäre, auf etwas leichtgewichtiges wie K3S zu setzen, was kompatibel zu Kubernetes ist, aber eben viel einfacher gehalten - denn das wird mit sehr hoher Wahrscheinlichkeit länger stabil und kompatibel bleiben als das mit Swarm der Fall ist. Aber das muss am Ende natürlich jede und jeder für sich individuell entscheiden.
Docker Swarm ist die einzige Lösung für Spielsysteme mit 32 Bit Hardware. Mit dieser quasi kostenlosen Hardware und Debian, kann man sich noch einiges aufbauen. Rasbians sind dagegen schon richtig teuer. Angeblich, kann man sich ein passendes k3s-Image auch selbst bauen. Habe aber noch nicht weiter nachgeforscht.
[gr] Das kann ich nicht beurteilen, da ich mit 32-Bit-Systemen seit Jahren nicht mehr zu tun habe - wenn dem so ist, kann ich aber verstehen, warum man auf Docker Swarm setzt (wobei das langfristig trotzdem keine sinnvolle Option ist IMHO). Wobei ich einen aktuellen Raspberry Pi (der ja auf 64 Bit basiert) mit ungefähr 35 Euro nicht als "schon richtig teuer" bezeichnen würde. Nicht kostenlos, aber im Verhältnis zu einem "richtigen" Computer ja doch sehr überschaubar im Preis.
An der Stelle hätte ich mal noch ne Frage: Ergibt es eigentlich Sinn innerhalb des Containers noch einen Loadbalancer wie z.B. PM2 zu haben? Speziell für Node-Server würde mich das interessieren, da JS ja singlethreaded ist. Aus meiner Sicht ergibt es sinn, da dann nicht ständig ein neuer container komplett hochgefahren werden muss, sondern man startet einfach eine zweite Instanz des Node-Servers.
[gr] Ich persönlich halte nicht so viel davon, PM2 in Docker zu betreiben, aus einer Reihe von Gründen: Erst einmal gewinnt man IMHO nicht viel. Docker kümmert sich ja genauso wie PM2 auch um Restarts, um Überwachung, … man braucht aber mit PM2 auf einmal zwei Systeme und nicht nur eins, die konfiguriert, aktualisiert, gepflegt, und so weiter werden wollen. Außerdem steigt der Speicherverbrauch pro Container. Generell wird das Monitoring aber schwieriger, weil ich jetzt zwei Punkte habe, wo Health-Checks laufen - einmal in Docker, einmal in PM2. Das macht es schwieriger, das ganze zu überwachen. Insbesondere auch so Sachen wie RAM- und CPU-Auslastung pro Container lässt sich nicht mehr so gut tracken. Der Health-Check von Außen gegen den Container ist nicht mehr sehr aussagekräftig, weil ich gar nicht mitbekomme, ob alle Worker laufen, sondern nur, ob irgendein Worker-Prozess darin läuft. PM2 versteckt also abstürzende oder hängende Prozesse. Das gleiche gilt für das Load-Balancing, was ich jetzt auch an zwei Stellen brauche, was es schwieriger zu konfigurieren macht. Last but not least haben Container so wenig Overhead, dass sich der Aufwand mit PM2 IMHO nicht wirklich lohnt.
ich bleibe mal bei Docker Swarm Cluster funktioniert ☺️ mag Compose / Swarm und Kubernetes auch es ist wichtig alles anzutatschen 😉 reisse dan mal mein pi Cluster ein aber aus spass keine angst um die Daten ☺️ gesichert oder naja verloren 😅 gehe dann auf Kubernetes nur ich hoffe das die Community Edition stark ausgebaut wird das wenn man ein eigenes Cluster betreiben möchte nicht zahlen muss also Loadbalance etc. sollte ja in der community Edition vorhanden sein muss ja nur immer die Hardware selber kaufen fand das Video super 👍 danke für deine Meinung hoffe Swarm schafft den Merge mit Kuberneteseees 😉 dan kann man alles behalten aha ja noch eine Frage ? falls man keine Hardware zuhause hat für ein Cluster muss man dan bei Google , Microsoft oder sowas wie Amazon 🤮 ( Jeff ) antanzen und die Hardware zu Verfügung stellen lassen? Preise bei Google weiss ich schon aber das Hardware Thema ist meine Frage ! Weil eigentlich ist ja das Load Balancing im Kubernetes und Swarm vorhanden so viel ich weiss mit der Community Edition. Das heisst eigentlich die ganze Google Cluster Lösung braucht man ja eigentlich nicht wenn man die Hardware selber kauft ? Sorry für den langen Text hoffe das aber jemand mein Frage beantwortet hatte ein Durcheinander mit Google Cluster engine und Service und eigenes Cluster betreibung 😮💨😮💨 hoffe jemand kann mein durcheinander ein bisschen lösen ☺️ u
Docker und Docker Swarm waren meine ersten Gehversuche mit Container. Nach wie vor nutze ich privat insbesondere Docker Swarm für kleine Anwendungen. Einfach aus dem Grund weil es einfach zu deployen ist. Ein Docker Swarm cluster ist in wenigen Minuten erstellt. Das finde ich bei Kubernetes nach wie vor deutlich aufwenidger. Und bisher habe ich bei Docker Swarm nichts vermisst. Also zum Einstieg wie Container Cluster Orchestrierung funktioniert ist Docker Swarm nach wie vor mein Favorit. Aber aus den genannten Gründen und auch weil ich es beruflich brauche habe ich natürlich begonnen mir Kubernetes anzueignen.
[gr] Ich denke, der einfachste Weg, die Installation zu umgehen, ist, ein Managed-Cluster zu buchen - aber anders als ein Docker Swarm-Cluster funktioniert das natürlich nicht mehr auf eigener Hardware, sondern ausschließlich nur noch in der Cloud. Eventuell können hier auch Projekte wie k3s eine Alternative sein.
Die großen Cloud Provider saugen alles auf. Egal ob da ein Foundation aufkleber drauf ist. Mann muss dem wiederstand leisten.
Apropos technologische Sackgassen: Das wär doch auch mal ein schönes Thema, wie erkennen, wie vermeiden, was tun wenn man merkt hineingeraten zu sein...
[gr] Das ist eine sehr gute Idee - vielen Dank für die Anregung 😊
Super Video. Auch Video über andere Container Software ala Rkt (Rocket) fänd ich super. :-)
[gr] Vielen Dank 😊
Und das mit rkt ist eine gute Idee, danke!
Wir nutzen Docker derzeit nur als "Notlösung" um unter Windows das Arbeiten mit 2 Linux-Servern zu simulieren. Das läuft in unserem Fall mehr schlecht als recht und wir haben sehr oft Probleme damit. Nun hatte ich mich schon etwas mit K8s beschäftigt und parallel angestoßen, dass wir auf unseren Entwicklungsrechnern weg von Windows und hin zu einem nativen Linux gehen. Dort planen wir dann langfristig K8s einzusetzen um auch lokal verteilte Dienste und ganze Cluster simulieren zu können.
Aus diesem Grund wäre für uns ein Video interessant mit ausführlichen Informationen zu den verschiedenen von K8s unterstützten Containertypen mit ihren jeweiligen Vor- und Nachteilen. Ich hatte mir neben Docker auch mal etwas zu LXC durchgelesen und sehe da ein paar Vorteile. Ich gehe jedoch davon aus, dass ihr auf dem Gebiet deutlich mehr Erfahrung habt und würde mich über ein entsprechendes Video freuen :)
[gr] Danke für die Anregung - mal gucken, wie wir das einplanen 😊
Für Docker-Swarm spricht, das es sehr niederschwellig ist. Dadurch das es a) schon integriert ist und b) einen überschaubaren Funktionsumfang hat, ist es eher was für Anfänger. "Die Cloud für den kleinen Mann." Und so würde ich das auch vermarkten.
Ja … wobei sich da - finde ich - die Frage stellt, ob man da nicht eher auf so etwas wie K3s & Co. setzen sollte: Das ist auch deutlich einfacher und leichtgewichtiger als das "große" Kubernetes, aber Du hast halt einen kompatiblen Upgrade-Pfad und bist nicht auf einer proprietären Plattform unterwegs, bei der von Anfang an absehbar ist, dass man nur bedingt weit kommt. Aber am Ende hängt das natürlich auch an den jeweiligen, individuellen Anforderungen.
@@thenativeweb K3s hab ich mir noch nicht angeguckt. Das steht als nächstes an. ^^
@@thenativeweb Leichtgewichtig vielleicht, aber die Komplexität explodiert geradezu.
Der initiale Aufbau von Kubernetes ist schon aufwendig, daher nutze ich privat auf meinem „Bastelserver“ docker Swarm, aber für alles andere Kubernetes auf der Google Cloud.
Wenn es Kubernetes beim Aufbau nicht so aufwendig wäre dann würde ich nicht docker swarm verwenden oder vielleicht ist es sogar leichter geworden (hab es vor 1,5 Jahren mal probiert) … so ein Kubernetes Einrichten Tutorial wäre auch nice :)
[gr] 😊
Hast Du Dir schon mal k3s angeschaut?
@@thenativeweb danke, genial das kannte ich nicht…
@@qui-gonkenobi4574 [gr] Freut mich 😊
Das Problem ist, dass wir sowieso auch auf eine Technologie nach k8s wechseln werden. Da können manche vielleicht direkt k8s überspringen. Docker hat ja jetzt fürs Hub das Abomodell ausgerollt und alle Standards von denen sind ja offen. So vorschnell würde ich das Thema nicht abschließen. Auf k8s setzen nach meiner Erfahrung immer noch nur sehr große Unternehmen, für alle anderen reicht Swarm dicke.
[gr] Mein Gegenargument wäre, dass Kubernetes einen gewissen De-Facto-Standard definiert, auf dem derzeit viele Systeme basieren und aufbauen. Im Gegensatz dazu ist Docker Swarm proprietär und im Vergleich eher auf dem absteigenden Ast. Natürlich wird auch Kubernetes nicht das letzte Wort sein, was jemals gesprochen wird, aber es ist zumindest derzeit nicht mal ansatzweise etwas in Sicht, was Kubernetes einmal beerben könnte.
Insofern würde ich mir überlegen, ob es nicht sinnvoll wäre, auf etwas leichtgewichtiges wie K3S zu setzen, was kompatibel zu Kubernetes ist, aber eben viel einfacher gehalten - denn das wird mit sehr hoher Wahrscheinlichkeit länger stabil und kompatibel bleiben als das mit Swarm der Fall ist.
Aber das muss am Ende natürlich jede und jeder für sich individuell entscheiden.
Docker Swarm ist die einzige Lösung für Spielsysteme mit 32 Bit Hardware. Mit dieser quasi kostenlosen Hardware und Debian, kann man sich noch einiges aufbauen. Rasbians sind dagegen schon richtig teuer.
Angeblich, kann man sich ein passendes k3s-Image auch selbst bauen. Habe aber noch nicht weiter nachgeforscht.
[gr] Das kann ich nicht beurteilen, da ich mit 32-Bit-Systemen seit Jahren nicht mehr zu tun habe - wenn dem so ist, kann ich aber verstehen, warum man auf Docker Swarm setzt (wobei das langfristig trotzdem keine sinnvolle Option ist IMHO).
Wobei ich einen aktuellen Raspberry Pi (der ja auf 64 Bit basiert) mit ungefähr 35 Euro nicht als "schon richtig teuer" bezeichnen würde. Nicht kostenlos, aber im Verhältnis zu einem "richtigen" Computer ja doch sehr überschaubar im Preis.
An der Stelle hätte ich mal noch ne Frage: Ergibt es eigentlich Sinn innerhalb des Containers noch einen Loadbalancer wie z.B. PM2 zu haben? Speziell für Node-Server würde mich das interessieren, da JS ja singlethreaded ist. Aus meiner Sicht ergibt es sinn, da dann nicht ständig ein neuer container komplett hochgefahren werden muss, sondern man startet einfach eine zweite Instanz des Node-Servers.
[gr] Ich persönlich halte nicht so viel davon, PM2 in Docker zu betreiben, aus einer Reihe von Gründen:
Erst einmal gewinnt man IMHO nicht viel. Docker kümmert sich ja genauso wie PM2 auch um Restarts, um Überwachung, … man braucht aber mit PM2 auf einmal zwei Systeme und nicht nur eins, die konfiguriert, aktualisiert, gepflegt, und so weiter werden wollen. Außerdem steigt der Speicherverbrauch pro Container.
Generell wird das Monitoring aber schwieriger, weil ich jetzt zwei Punkte habe, wo Health-Checks laufen - einmal in Docker, einmal in PM2. Das macht es schwieriger, das ganze zu überwachen. Insbesondere auch so Sachen wie RAM- und CPU-Auslastung pro Container lässt sich nicht mehr so gut tracken.
Der Health-Check von Außen gegen den Container ist nicht mehr sehr aussagekräftig, weil ich gar nicht mitbekomme, ob alle Worker laufen, sondern nur, ob irgendein Worker-Prozess darin läuft. PM2 versteckt also abstürzende oder hängende Prozesse.
Das gleiche gilt für das Load-Balancing, was ich jetzt auch an zwei Stellen brauche, was es schwieriger zu konfigurieren macht.
Last but not least haben Container so wenig Overhead, dass sich der Aufwand mit PM2 IMHO nicht wirklich lohnt.
ich bleibe mal bei Docker Swarm Cluster funktioniert ☺️
mag
Compose / Swarm und Kubernetes auch
es ist wichtig alles anzutatschen 😉
reisse dan mal mein pi Cluster ein aber aus spass
keine angst um die Daten ☺️ gesichert oder naja verloren 😅
gehe dann auf Kubernetes nur ich hoffe das die Community Edition stark ausgebaut wird
das wenn man ein eigenes Cluster betreiben möchte nicht zahlen muss also
Loadbalance etc.
sollte ja in der community Edition vorhanden sein
muss ja nur immer die Hardware selber kaufen
fand das Video super 👍 danke für deine Meinung
hoffe Swarm schafft den Merge mit Kuberneteseees 😉
dan kann man alles behalten
aha ja noch eine Frage ?
falls man keine Hardware zuhause hat für ein Cluster
muss man dan bei Google , Microsoft oder sowas wie Amazon 🤮 ( Jeff ) antanzen und die Hardware zu Verfügung stellen lassen?
Preise bei Google weiss ich schon aber das Hardware Thema ist meine Frage !
Weil eigentlich ist ja das Load Balancing im Kubernetes und Swarm vorhanden
so viel ich weiss mit der Community Edition.
Das heisst eigentlich die ganze Google Cluster Lösung braucht man ja eigentlich nicht wenn man die Hardware
selber kauft ?
Sorry für den langen Text hoffe das aber jemand mein Frage beantwortet
hatte ein Durcheinander mit Google Cluster engine und Service
und eigenes Cluster betreibung
😮💨😮💨
hoffe jemand kann mein durcheinander ein bisschen lösen ☺️
u
Fa quello che promette ma non puó mettere le porte in namespace, quindi non scala come kubernetes.
Ist Docker Swarm = Docker Compose?
[gr] Nein. Swarm ist eine Clusterlösung, Compose ist ein Tool, um mehrere zusammengehörige Container gemeinsam zu verwalten (starten, stoppen, …).
@@thenativeweb Danke ;-)