Infos

Änderungsstand: 2023-09-04

2023-09-04: Spätestens Januar/Februar 2024 werde ich mich noch einmal hinsetzen und das Thema komplett neu aufrollen, ohne die schon geschriebenen Guides zu berücksichtigen. Diesmal mit „Docker Compose V2“, mit einer Samba-Freigabe und diversen Sicherheitsaspekten, die ich bisher außer Acht lies. Als Betriebssystem wird nur RaspiOS verwendet, da ich hierbei keine Kompromisse mehr eingehen werde. Jedenfalls sind das derzeit meine Gedanken dazu.

2023-03-26: Aktuell habe ich die Guides für RaspiOS Bullseye aktualisiert. Das Ganze kostete mich allerdings so viel Zeit und Nerven, dass ich auf die Guidreihe der VM’s verzichte. Dabei informierte ich mich im Vorfeld auch auf diversen Videoplattformen, um Fehler zu vermeiden. Leider sind die Guides dort nicht nur oberflächlich (Sicherheitsaspekte werden komplett ausgehebelt), es wird auch meist am super-Beispiel „NGINX“ gezeigt, dass alles funktioniert. Verwendet man dann andere Docker, steht man wieder im Regen. Hier war von mir sehr viel Feinarbeit notwendig.

Erster Eintrag:

Obwohl Docker Swarm, im direkten Vergleich zu Kubernetes, leider ein „Nieschenprodukt“ ist (seit ich mich mit Kubernetes beschäftige, kann ich das so behaupten und es ist keinesfalls abwertend gemeint), verwende ich ich es im privaten Umfeld sehr gern. Ich denke, dass ist auch das Haupteinsatzgebiet von Docker Swarm. Es ist ziemlich einfach einzurichten, einfach zu managen und es macht Spaß, damit zu arbeiten. Mit Kubernetes bekommt man definitiv schon bei der Einrichtung, jedenfalls wenn man damit noch nichts zu tun hatte, graue Haare. Der große Vorteil von Kubernetes ist hierbei, wenn man als Admin damit beschäftigt ist, dass es eine grafische Oberfläche besitzt, die im Nachhinein, wenn alles eingerichtet wurde, einen enormen Mehrwert bietet. Mit Docker Swarm hat man eigentlich nur Portainer, um das Ganze etwas grafisch darzustellen und/oder mit einer grafischen Oberfläche zu administrieren. Kubernetes kann alles, was auch Docker Swarm kann. Darüber hinaus bietet es allerdings noch viel, viel, viel mehr Möglichkeiten und Features, wovon Docker Swarm nur träumen kann. Im privaten Umfeld macht es, meiner Meinung nach, eigentlich keinen Sinn, Kubernetes zu verwenden, weil man dort Zeit investiert, die man eigentlich gar nicht hat. Ob man die zusätzlichen Features letzendes benötigt, muss jeder für sich selbst entscheiden.

In nun folgenden Guidreihen stelle ich Docker Swarm vor, in Verbindung mit mit einer kleinen Raspi-Farm und in Verbindung mit mehreren VM’s, als Cluster verbunden, inkl. Installation, Einbindung einer NFS-Freigabe für gemeinsame Daten (appdata) und einer gemeinsamen NFS-Freigabe für die eigentlichen Daten (data), z.b. für Nextcloud als Datenverzeichnis. Es werden mehrere Guides entstehen, damit die Übersichtlichkeit am Ende auch bestehen bleibt.

Im Raspi-Guide werden 4 RasperryPi 3 zusammengelegt. Der 5. bzw. weitere Raspis sind dann selbsterklärend, wenn man das Prinzip verstanden hat. Ich verwende für meinen Test 2x RaspperryPi 3B+ und 2 RaspberryPi B. Die beiden B+ Modelle besitzen GBit-Lan und die beiden B Modelle haben 100MBit/s LAN verfügbar. Aber für meine Testreihe sollte das reichen. Was ich wieder einmal feststellen konnte, dass es bei der Wahl der SD-Card gewaltige Unterschiede gibt. „Samsung Evo“ und, mit paar kleinen Abstrichen, „SanDisk Extreme“ sind derzeit meine Favoriten.

Im VM-Guide werden 4 Virtual Machines zusammengelegt. Dort arbeite ich allerdings nicht mit einer NFS-Freigabe, sondern gebe eine Direktverbindung, jeder einzelnen VM, zu einer gemeinsamen Freigabe an.

Was kann man mit dem Docker Swarm Cluster anfangen? Wer jetzt glaubt, eine Desktopversion von Raspi OS zu installieren um von dem Verbund mehrerer Raspis zu profitieren, liegt hier leider falsch. Wie es der Name schon sagt, werden Docker orchestriert, um einen reibungslosen Betrieb zu gewährleisten. Installiere ich z.B. 20 Docker, wird der Docker Swarm Cluster dafür sorgen, dass immer ein optimales Balancing für die Docker vorhanden ist. Die erstellten Docker werden den „Nodes“ (die einzelnen Raspis) optimal zugewiesen. Dafür sorgt ein Manager, der für den Betrieb eines Docker Swarm Clusters zwingend notwendig ist. Verwendet man eine kleine Raspi-Farm, können natürlich auch mehrere Manager eingerichtet werden. Das sorgt für mehr Sicherheit eines fortlaufenden Betriebes, falls der erste Manager ausfallen sollte.

Vorbereitung Raspi-Guide: Ich benötige 4 SD-Cards oder 4 SSD’s, mind. eine HDD für die Daten und natürlich die 4 Raspis, alle mit Netzwerk- und Internetanschluss. Ich verwende einen Switch, der nur für die Raspis zuständig ist. Auf die SD-Card’s installiere ich in meiner ersten Testreihe Ubuntu-Server 20.04 LTS (64bit) und in meiner zweiten Testreihe Raspian OS (64bit) – Beta. Aktuell ist die Guidreihe für RaspiOs Bullseye veröffentlicht. Anschließend vergebe ich jeweils einen Hostnamen und erstelle den Cluster Swarm. Meine Hostnamen sind node1, node2, node3 und node4. Wichtig ist, dass auf allen SD-Cards der gleiche Versionsstand vorhanden ist, inkl. Updates und allen Einstellungen, außer IP-Adresse und Hostname, die bekanntlicher Weise, auf jedem einzelnen Gerät, unterschiedlich sein müssen!

Vorbereitung VM-Guide: Ich verwende einen Unraid-Server und erstelle 4 Virtual Machines im Cluster. Da mein Server 64GB Ram besitzt, kann ich ruhigen Gewissens, jeder VM, 2GB Ram zuweisen.

Zur Info: Der Swarm-Manager, wie vielleicht am Namen schon erkannt, ist quasi ein Vorarbeiter, der sagt, was, wann und wo abgearbeitet wird. Er übernimmt auch selbst Aufgaben, verteilt diese aber ebenfalls sinnvoll an die Worker, so dass immer eine Art Lastausgleich zwischen den Geräten stattfindet. Soll heißen, wenn ein Raspi im Moment einer Anfrage gerade zu tun hat, wird einfach ein anderer Raspi mit dieser Aufgabe beauftragt. Es wird mind. ein Manager benötigt. Sehr gut erklärt wird hier: https://www.computerweekly.com/de/definition/Docker-Swarm. Je größer man den Verbund wählt, kann es Sinn machen, mehrere Manager einzusetzen. Fällt nämlich der Manager aus und man hat keinen weiteren gewählt, fällt das ganze System aus. Im Falle eines weiteren Managers, übernimmt dieser dann die Aufgabe des ausgefallenen Managers und alles läuft normal weiter. Ich verwende für mich am Ende nur einen Manager und 4 Worker, zeige aber in diesem Guide die Verwendung von zwei Manager und zwei Worker. Somit ist das Hinzufügen oder Ändern der Konstellation quasi selbsterklärend.

Wozu benötigt man das Ganze? Nun, in erster Linie ist das (wieder einmal) ein Zeitvertreib. Doch gibt das auch einen Sinn, das Ganze produktiv zu verwenden? Natürlich JA. Nicht jeder hat einen dicken Server daheim stehen, der Unmengen an Kosten verursacht. Und für die Standardprogramme wie z.B. Nextcloud, Heimdall, Nginx Proxy Manager, Emby, Pihole, um nur einige zu nennen, kann man so einen Cluster wunderbar einsetzen. Je mehr Einsatzzwecke hinzukommen, kann es von Vorteil sein, den Cluster zu erweitern. Ich wählte absichtlich den Raspberry 3, weil ich von diesen Geräten ’ne ganze Schublade davon habe und keine Neuanschaffung nötig ist. Wer klein anfangen möchte, aber auf keinerlei Leistung verzichten möchte, kann theoretisch auch mit 2 RaspberryPi 4 anfangen. Einen als Manager und einen als Worker. Da der Manager ebenfalls Aufgaben übernimmt, ist das auch schon, für den Anfang, ausreichend.

Es sind viele Konsolenbefehle nötig, um das Ganze zu bewerkstelligen. Eine Grafische Oberfläche gibt es hierfür nur indirekt über den Portainer. Aber das soll mich nicht aufhalten. Die SD-Card’s sind vorbereitet und ich fange nun an, alles nach und nach zu konfigurieren. Dabei fange ich beim ersten Raspi an und arbeite mich bis zum vierten Raspi durch. Monitor und Tastatur benötige ich bei Ubuntu-Server nicht an den Raspis, da diese komplett HEADLESS arbeiten. Die Erstkonfiguration mit Raspi OS gestaltet sich etwas zeitaufwändiger.

Mein Tipp: Mit Ubuntu-Server (64bit) bin ich auf meinen Raspi 3 besser gefahren. Allein die Vorbereitung der SD-Cards ging bedeutend schneller, als es beim Raspi OS der Fall war. Auch die Auswahl an aktuellen Images, sind unter Verwendung von ARM64, vielfältiger.