Eine Webanwendung läuft zunächst problemlos auf einem Server, doch mit wachsendem Traffic werden Ausfälle, Updates und die Verteilung mehrerer Container schnell unübersichtlich. Docker Swarm bündelt mehrere Docker-Hosts zu einem Cluster und übernimmt Aufgaben wie Scheduling, Skalierung, Service-Discovery und Rolling Updates. Ich zeige hier den kompletten Weg von der ersten Initialisierung über das Deployment bis zu Sicherheit, Fehlersuche und den Grenzen im produktiven Hosting.
Docker Swarm in wenigen Sätzen verstanden
- Manager speichern den Clusterzustand und verteilen Aufgaben.
- Worker führen Container als sogenannte Tasks aus.
- Für ein stabiles Produktiv-Cluster sind meist 3 oder 5 Manager sinnvoll.
- Die Kommunikation zwischen Hosts benötigt die Ports 2377, 7946 und 4789.
- Mit docker stack deploy lassen sich mehrere Services aus einer Compose-Datei ausrollen.
Was Docker Swarm im Hosting wirklich übernimmt
Docker Swarm ist der in Docker Engine integrierte Orchestrator. Er macht aus mehreren einzelnen Docker-Installationen ein gemeinsames System, in dem ein gewünschter Zustand beschrieben wird. Läuft ein Service mit drei Replikas, versucht Swarm dauerhaft, genau drei laufende Instanzen bereitzustellen.
Ein Manager verwaltet den Cluster, führt den Raft-Zustand und entscheidet, auf welchem Host ein Container gestartet wird. Ein Worker führt diese Aufgaben aus. Manager können standardmäßig ebenfalls Workloads ausführen, in einem getrennten Produktions-Cluster würde ich sie für eine bessere Ausfallsicherheit jedoch oft mit drain von Anwendungstasks freihalten.
Der praktische Vorteil liegt weniger darin, dass Swarm Container starten kann. Das kann Docker Compose ebenfalls. Die Stärke zeigt sich bei automatischer Verteilung, Skalierung und Wiederherstellung. Fällt ein Worker aus, plant der Manager die betroffenen Tasks auf verfügbaren Knoten neu ein.
| Komponente | Aufgabe | Typischer Einsatz |
|---|---|---|
| Manager | Clusterzustand, Scheduling und Verwaltung | 3 oder 5 Hosts für Hochverfügbarkeit |
| Worker | Ausführung der Container-Tasks | Beliebig viele Hosts je nach Last |
| Service | Definition eines gewünschten Container-Zustands | Webserver, API, Worker-Prozess |
| Stack | Mehrere abhängige Services als Anwendung | Webserver, API und Cache gemeinsam |
Swarm passt besonders gut zu **kleinen und mittleren Plattformen**, die Docker-native Deployments, eine überschaubare Betriebsumgebung und schnelle Rollouts benötigen. Kubernetes bietet ein deutlich größeres Ökosystem, bringt aber auch mehr Komplexität mit. Für zwei bis zehn gut kontrollierte Server ist Swarm aus meiner Sicht oft angenehm pragmatisch.
Welche Voraussetzungen das Cluster braucht
Für einen lokalen Test reicht ein einzelner Linux-Host. Ein echtes Mehrknoten-Setup benötigt mindestens einen Manager und einen Worker, besser aber drei Manager für Quorum und mehrere Worker für die Anwendung. Alle Hosts sollten eine feste, intern erreichbare IP-Adresse besitzen und eine kompatible Docker-Engine-Version verwenden.
Für ein Labor reichen je Host beispielsweise 1 bis 2 vCPU und 2 GB RAM, sofern nur Nginx und kleine Testservices laufen. Im produktiven Betrieb bestimmt nicht Swarm die Größe, sondern die Anwendung. Datenbank, Build-Prozesse, Logging und Spitzenlast müssen separat kalkuliert werden.
Firewall und Netzwerk vorbereiten
Zwischen den Docker-Hosts müssen bestimmte Ports erreichbar sein. Ich öffne sie ausschließlich im privaten Cluster-Netz und niemals pauschal für das gesamte Internet.
| Port | Protokoll | Funktion |
|---|---|---|
| 2377 | TCP | Swarm-Management und Beitritt von Nodes |
| 7946 | TCP und UDP | Node-Discovery und Kommunikation zwischen Nodes |
| 4789 | UDP | Overlay-Netzwerk und VXLAN-Datenverkehr |
| 80 und 443 | TCP | Öffentliche Webanwendungen, falls benötigt |
Port 4789 sollte niemals offen am Perimeter eines Servers hängen. Bei untrusted Netzwerken kann ein verschlüsseltes Overlay-Netzwerk mit --opt encrypted sinnvoll sein, wobei zusätzlicher Netzwerk-Overhead entsteht. Die Management-Kommunikation ist standardmäßig durch gegenseitige TLS-Authentifizierung geschützt, die Anwendungsebene muss trotzdem separat abgesichert werden.
Ein Swarm-Cluster Schritt für Schritt aufsetzen
Den ersten Manager initialisieren
Auf dem ersten Host starte ich den Cluster mit einer privaten oder intern gerouteten Adresse. Die Option --advertise-addr ist wichtig, weil andere Nodes genau diese Adresse verwenden.
docker swarm init --advertise-addr 10.0.0.10Die Ausgabe enthält einen Worker-Token und den passenden Join-Befehl. Tokens gehören wie Passwörter behandelt und sollten nicht in Tickets, öffentliche Repositories oder Chatverläufe kopiert werden. Bei Bedarf kann ich sie später erneut anzeigen lassen.
docker swarm join-token worker
docker swarm join-token managerWorker und weitere Manager hinzufügen
Auf jedem Worker führe ich den ausgegebenen Befehl aus. Die Adresse muss auf den Manager zeigen, nicht auf eine öffentliche Reverse-Proxy-Adresse.
docker swarm join \
--token SWMTKN-REPLACE_ME \
10.0.0.10:2377Weitere Manager treten mit dem Manager-Token bei. Für Hochverfügbarkeit bevorzuge ich 3 Manager. Damit darf einer ausfallen, ohne dass die Mehrheit des Raft-Clusters verloren geht. Fünf Manager können zwei Ausfälle verkraften, verursachen aber mehr Verwaltungsaufwand.
docker swarm join \
--token SWMTKN-MANAGER-REPLACE_ME \
10.0.0.10:2377Den Zustand prüfe ich immer vom Manager aus.
docker node ls
docker infoEin häufiger Fehler besteht darin, eine öffentliche Cloud-IP als Advertise-Adresse zu verwenden, obwohl die Hosts über ein privates Netzwerk kommunizieren sollen. Das führt später zu schwer verständlichen Join- oder Overlay-Problemen. Ich prüfe deshalb zuerst Routing, DNS und Firewall und erst danach Docker.
Services testen, skalieren und aktualisieren
Ein Service beschreibt ein gewünschtes Ergebnis. Der folgende Befehl startet drei Nginx-Replikas und veröffentlicht Port 8080 auf dem Swarm.
docker service create \
--name web \
--publish published=8080,target=80 \
--replicas 3 \
nginx:alpineSwarm verteilt die Tasks nach seinen Scheduling-Regeln. Durch die Routing Mesh kann eine Anfrage an einem beliebigen Node-Port an einen passenden Task weitergeleitet werden, selbst wenn dort nicht direkt die betreffende Replika läuft.
docker service ls
docker service ps web
docker service inspect web
docker service logs -f webDie Anzahl der Replikas lässt sich ohne Container-Handarbeit ändern.
docker service scale web=5Für ein Update verwende ich möglichst eine unveränderliche Image-Version oder einen Digest. Ein bewegliches Tag wie latest macht Rollbacks und Fehleranalysen unnötig schwierig.
docker service update \
--image nginx:1.27-alpine \
--update-parallelism 1 \
--update-delay 10s \
webWenn das neue Image Probleme verursacht, kann der Service zurückgerollt werden.
docker service rollback webIch setze bei kritischen Services zusätzlich Update- und Rollback-Parameter in der Stack-Datei. Ein kontrolliertes Update mit einer Replika nach der anderen ist meistens sicherer als ein gleichzeitiger Austausch aller Container.
Eine Anwendung als Stack deployen
Für mehrere Services ist eine Compose-Datei übersichtlicher als eine lange Folge von CLI-Befehlen. Dabei gibt es eine wichtige Einschränkung. docker stack deploy arbeitet mit dem älteren Compose-Dateiformat für Swarm und unterstützt nicht automatisch alle Funktionen der aktuellen Compose-Spezifikation.
Außerdem baut der Manager keine Images aus einem lokalen Dockerfile. Die Images müssen bereits in einer Registry liegen und von allen Nodes erreichbar sein. Genau dieser Punkt wird bei ersten Deployments besonders häufig übersehen.
version: "3.9"
services:
web:
image: nginx:1.27-alpine
ports:
- target: 80
published: 8080
protocol: tcp
mode: ingress
networks:
- frontend
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
order: start-first
rollback_config:
parallelism: 1
restart_policy:
condition: on-failure
placement:
max_replicas_per_node: 1
redis:
image: redis:7-alpine
networks:
- backend
deploy:
replicas: 1
networks:
frontend:
driver: overlay
backend:
driver: overlayDen Stack spiele ich vom Manager aus ein.
docker stack deploy -c stack.yml demo
docker stack services demo
docker stack ps demoEin Stack erzeugt eigene Service- und Netzwerknamen. Der Webservice heißt in diesem Beispiel demo_web. Für eine private Registry kann --with-registry-auth erforderlich sein, damit die Nodes die Zugangsdaten für das Image erhalten.
docker stack deploy \
--with-registry-auth \
-c stack.yml \
demoFür die Platzierung kann ich Nodes labeln. So landet beispielsweise ein Service nur auf Hosts mit SSD-Speicher oder in einer bestimmten Availability Zone.
docker node update --label-add zone=de1 worker1In der Compose-Datei würde die passende Einschränkung so aussehen.
placement:
constraints:
- node.labels.zone == de1Netzwerke und Replikas verteilen sich automatisch, aber persistente Daten werden nicht magisch repliziert. Eine lokale Volume-Datei liegt weiterhin auf einem bestimmten Host. Für Datenbanken brauche ich deshalb externen Storage, Replikation auf Anwendungsebene oder eine bewusste Node-Bindung.
Sicherheit, Secrets und Fehlersuche im Betrieb
Passwörter nicht in Compose-Dateien speichern
Swarm Secrets sind für Kennwörter, API-Schlüssel und Zertifikate gedacht. Ich lege sensible Werte nicht als Klartext in eine Stack-Datei und nicht in gewöhnliche Environment-Variablen, wenn sich das vermeiden lässt.
printf 'change-this-password' | docker secret create db_password -Ein Service erhält nur die Secrets, die er tatsächlich benötigt. Docker stellt sie im Container als Datei unter /run/secrets/ bereit. Zusätzlich können Configs für nicht geheime Konfigurationsdateien verwendet werden.
Lesen Sie auch: Social Intranet planen - Funktionen, Hosting und DevOps
Die wichtigsten Diagnosebefehle
Wenn ein Deployment nicht stabil wird, beginne ich mit dem Clusterzustand und arbeite mich zum einzelnen Task vor. Das ist schneller, als sofort die gesamte Compose-Datei umzuschreiben.
docker node ls
docker service ls
docker service ps --no-trunc demo_web
docker service logs demo_web
docker inspect $(docker ps -q)- Pending deutet häufig auf fehlende Ressourcen oder eine nicht erfüllte Placement-Constraint hin.
- Rejected weist oft auf ein nicht verfügbares Image, falsche Mounts oder ungültige Service-Optionen hin.
- Fehlt ein Service auf einem Worker, prüfe ich zuerst den Node-Status und danach die Ports für Overlay-Traffic.
- Funktioniert ein Container lokal, aber nicht im Stack, liegt die Ursache oft an fehlenden Registry-Zugängen oder nicht unterstützten Compose-Optionen.
Die Docker-Dokumentation bestätigt, dass Overlay-Netzwerke, Service-Discovery und Rolling Updates zentrale Bestandteile des Swarm-Modus sind. Für den Anfang reicht eine einfache Topologie, für den produktiven Betrieb kommen Backups des Manager-Zustands, Monitoring, Log-Rotation und ein getesteter Wiederanlauf hinzu.
Den Raft-Zustand sichere ich regelmäßig und schütze besonders die Manager. Ein Backup allein ist jedoch kein Notfallplan. Ich teste auch, ob Images, Secrets, Volumes und DNS nach einem Ausfall tatsächlich wieder verfügbar sind.
Wann Swarm die richtige Entscheidung bleibt
Docker Swarm ist eine gute Wahl, wenn ein Team wenige Betriebsbausteine, schnelle Deployments und eine geringe Lernkurve bevorzugt. Für einfache Webanwendungen, interne APIs und klassische Hosting-Setups liefert es viel Nutzen mit vergleichbar wenig Konfiguration.
Ich würde Swarm nicht als Ersatz für jedes Kubernetes-Cluster verkaufen. Sehr große Plattformen, komplexe Operator-Ökosysteme, serviceübergreifende Policies oder stark standardisierte Cloud-Native-Prozesse sprechen eher für Kubernetes. Auch bei zustandsbehafteten Anwendungen bleibt die Storage-Frage unabhängig vom Orchestrator anspruchsvoll.
Mein sinnvoller Startpunkt für 2026 ist ein kleines Testcluster mit einem Manager und zwei Workern. Danach kommen private Netzwerke, eine Registry, feste Image-Versionen, Secrets und ein bewusst getestetes Rollback. Erst wenn diese Grundlagen funktionieren, lohnt es sich, Replikas und zusätzliche Nodes zu erhöhen.
Wer diese Reihenfolge einhält, erhält kein undurchsichtiges Container-Lab, sondern eine nachvollziehbare Hosting-Plattform. Der eigentliche Gewinn liegt nicht in möglichst vielen Nodes, sondern in einem System, dessen Zustand sich prüfen, aktualisieren und im Fehlerfall zuverlässig wiederherstellen lässt.
