Docker Swarm produktiv einsetzen und richtig planen

Wenn aus einem einzelnen Docker-Host eine verlässliche Plattform für mehrere Anwendungen werden soll, tauchen schnell Fragen zu Ausfallsicherheit, Skalierung und Updates auf. Docker Swarm bündelt mehrere Docker-Server zu einem Cluster und übernimmt die Verteilung, Überwachung und Wiederherstellung containerisierter Dienste. Ich zeige, wie das Modell funktioniert, wie ein produktiver Aufbau aussieht, welche Befehle wichtig sind und wann Kubernetes die bessere Wahl ist.

Was der Swarm-Modus im Betrieb tatsächlich leistet

Ein Swarm ist ein Verbund aus mehreren Rechnern oder virtuellen Servern, auf denen Docker Engine läuft. Jeder Rechner ist ein Node. Manager verwalten den Cluster und planen Aufgaben, während Worker die Container ausführen. Ein Node kann beide Rollen gleichzeitig übernehmen, in produktiven Umgebungen trenne ich sie jedoch möglichst klar.

Der zentrale Gedanke ist der sogenannte gewünschte Zustand. Definiere ich beispielsweise fünf Replikate eines Webservers, versucht der Manager dauerhaft, genau fünf laufende Instanzen bereitzustellen. Fällt ein Worker aus, startet der Cluster die fehlenden Aufgaben auf verfügbaren Nodes neu.

Manager, Worker, Services und Tasks

Ein Service beschreibt, was laufen soll. Dazu gehören das Container-Image, die Anzahl der Replikate, Ports, Netzwerke, Ressourcenlimits und Update-Regeln. Ein Task ist die konkrete Ausführung dieses Services auf einem Node, normalerweise als Docker-Container.

Manager speichern den Clusterzustand über das Raft-Konsensverfahren. Deshalb ist die Anzahl der Manager nicht nur eine Frage der Leistung, sondern vor allem der Ausfallsicherheit. Ein Cluster mit drei Managern toleriert den Ausfall eines Managers, ein Cluster mit fünf Managern den Ausfall von zwei. Vier Manager bringen gegenüber drei keinen zusätzlichen Quorum-Vorteil.

Replizierte und globale Services

Bei einem replizierten Service legst du eine konkrete Anzahl von Instanzen fest. Das eignet sich für Webserver, APIs oder Worker-Prozesse. Ein globaler Service läuft dagegen genau einmal auf jedem passenden Node und ist deshalb praktisch für Monitoring-Agenten, Logsammler oder Sicherheitssoftware.

Ich sehe häufig, dass Swarm nur als „Docker mit mehreren Servern“ verstanden wird. Das greift zu kurz. Die eigentliche Stärke liegt in der Kombination aus Zustandsverwaltung, Scheduling, Service Discovery und internem Load-Balancing.

So richtest du einen kleinen Cluster sauber ein

Für einen ersten Test genügt ein einzelner Linux-Server. Für produktive Hosting-Szenarien empfehle ich mindestens drei Manager und zusätzlich Worker-Nodes für die eigentliche Last. Die Server sollten stabile, untereinander erreichbare IP-Adressen besitzen. Bei mehreren Netzwerkkarten muss die verwendete Adresse ausdrücklich angegeben werden.

Cluster initialisieren

Auf dem ersten Manager startest du den Swarm-Modus mit der Adresse, über die andere Nodes ihn erreichen:

docker swarm init --advertise-addr 10.0.0.10

Docker erzeugt dabei Zertifikate, Join-Tokens und ein internes Overlay-Netzwerk. Mit den folgenden Befehlen werden die Beitrittsinformationen angezeigt:

docker swarm join-token worker
docker swarm join-token manager

Den ausgegebenen Join-Befehl führst du auf den jeweiligen Servern aus. Tokens gehören wie Passwörter behandelt und sollten nicht in Tickets, Git-Repositories oder öffentlich sichtbaren CI-Logs landen.

Firewall und Netzwerk prüfen

Zwischen allen Nodes müssen die Cluster-Ports erreichbar sein. Für die Administration nutzt Swarm 2377/TCP, für Node-Erkennung und Steuerkommunikation 7946/TCP und UDP. Das Overlay-Netzwerk verwendet standardmäßig 4789/UDP.

• 2377/TCP für Manager-Kommunikation
• 7946/TCP und UDP für Node-Kommunikation
• 4789/UDP für Overlay-Netzwerke

Den UDP-Port 4789 würde ich niemals offen am Internet betreiben. Er gehört in ein vertrauenswürdiges internes Netzwerk. Wenn Daten über unsichere Netzwerke laufen, kann ein verschlüsseltes Overlay-Netzwerk sinnvoll sein. Zusätzlich müssen natürlich die veröffentlichten Anwendungsports wie 80 oder 443 erreichbar sein.

Den Zustand kontrollieren

Nach dem Beitritt helfen drei Befehle bei der ersten Kontrolle:

docker node ls
docker info
docker service ls

In docker node ls erkennst du Rollen und Erreichbarkeit. Ein Node mit dem Status „Down“ oder „Unreachable“ ist nicht nur ein Schönheitsfehler, sondern kann die Verteilung und bei Managern sogar das Quorum gefährden.

Anwendungen mit Services und Stacks ausrollen

Ein einzelner Service ist schnell erstellt. Für einen Webserver mit drei Replikaten und einem veröffentlichten Port reicht beispielsweise:

docker service create \
  --name web \
  --publish published=8080,target=80 \
  --replicas 3 \
  nginx:stable

Mit docker service ls siehst du die gewünschte und aktuelle Anzahl der Replikate. Details zu einzelnen Aufgaben liefert:

docker service ps web
docker service logs web

Der Scheduler berücksichtigt dabei verfügbare Ressourcen, Platzierungsregeln und Node-Tags. Über Constraints kannst du zum Beispiel festlegen, dass ein Service nur auf Nodes mit SSD-Speicher oder einer bestimmten Rolle läuft.

Warum Stacks für reale Projekte besser passen

Eine Anwendung besteht selten aus nur einem Container. Webserver, API, Datenbank, Cache und Hintergrund-Worker sollten in einer Compose-Datei beschrieben werden. Diese Datei wird als Stack auf dem Cluster ausgerollt:

docker stack deploy -c compose.yml shop
docker stack services shop
docker stack ps shop

Das macht Deployments nachvollziehbar und wiederholbar. Allerdings unterstützt der Swarm-Modus nicht jede moderne Compose-Funktion. Felder, die nur für lokale Docker-Umgebungen gedacht sind, können beim Stack-Deployment ignoriert werden. Ich prüfe deshalb vor jedem produktiven Rollout, welche Compose-Schlüssel tatsächlich ausgewertet werden.

Updates ohne unnötige Unterbrechung

Rolling Updates ersetzen Replikate schrittweise. Du kannst festlegen, wie viele Instanzen gleichzeitig aktualisiert werden und was bei einem Fehler passieren soll:

docker service update \
  --image example/api:2.4 \
  --update-parallelism 1 \
  --update-delay 10s \
  --update-failure-action rollback \
  shop_api

Wichtig ist ein unveränderliches Image-Tag. Ein Tag wie „latest“ kann auf verschiedenen Nodes unterschiedliche Versionen bedeuten, wenn der Registry-Inhalt zwischenzeitlich geändert wurde. Für reproduzierbare Deployments sind feste Versionsnummern oder Image-Digests deutlich zuverlässiger.

Netzwerk, Routing und Speicher richtig planen

Swarm bringt mit Overlay-Netzwerken eine eigene Kommunikation zwischen Services mit. Container können sich über Servicenamen erreichen, auch wenn sie auf unterschiedlichen Nodes laufen. Ein Backend kann dadurch beispielsweise die Datenbank unter ihrem internen Namen ansprechen, ohne die konkrete Serveradresse zu kennen.

Routing Mesh und veröffentlichte Ports

Veröffentlichst du einen Service-Port im Standardmodus, kann eine Anfrage grundsätzlich an jedem Node ankommen. Die Routing Mesh leitet sie intern an eine passende Service-Instanz weiter. Das ist bequem und für viele Webanwendungen ausreichend.

Bei spezialisierten Setups kann der Host-Modus besser passen. Dann wird der Port nur auf dem Node geöffnet, auf dem die Aufgabe läuft. Du musst dich in diesem Fall selbst um externe Lastverteilung und die Zuordnung der Nodes kümmern. Mehr Kontrolle bedeutet hier auch mehr Betriebsaufwand.

Datenbanken sind kein gewöhnlicher Service

Replizierte Webserver sind unkompliziert, replizierte Datenbanken nicht. Container sind grundsätzlich austauschbar, Daten aber nicht. Für PostgreSQL, MariaDB oder Elasticsearch brauchst du ein belastbares Speicherkonzept, Backups, Recovery-Tests und klare Regeln für Leader, Replikation und Failover.

Lokale Volumes bleiben zunächst an den jeweiligen Nodes gebunden. Wird ein Container nach einem Ausfall auf einem anderen Server gestartet, ist sein lokaler Datenbestand dort nicht automatisch vorhanden. Für zustandsbehaftete Anwendungen kommen daher meist externer Storage, ein eigener Datenbankdienst oder eine bewusst geplante Replikationslösung infrage.

Secrets und Konfigurationen

Passwörter und API-Schlüssel gehören nicht in die Compose-Datei und schon gar nicht in ein Image. Swarm-Secrets werden verschlüsselt im Cluster verwaltet und nur den Services zugänglich gemacht, die sie benötigen. Für nicht geheime Einstellungen sind Configs gedacht, etwa für Nginx-Konfigurationen oder Feature-Flags.

Sicherheit und Betrieb entscheiden über die Qualität

Die Einrichtung dauert oft weniger als eine Stunde. Ein sicherer und dauerhaft stabiler Betrieb ist die anspruchsvollere Aufgabe. Jeder Node braucht regelmäßige Docker- und Betriebssystem-Updates, eingeschränkte Firewall-Regeln, SSH-Härtung sowie eine Überwachung von CPU, Speicher, Plattenplatz und Containerzuständen.

Manager sollten möglichst nicht direkt die gesamte öffentliche Anwendungslast tragen. Mit Rollen, Labels und Placement-Regeln kannst du administrative Nodes von öffentlich erreichbaren Workloads trennen. Besonders wichtig ist, dass Manager-Zertifikate, Join-Tokens und Backups des Raft-Zustands geschützt werden.

Quorum und Backups

Verliert ein Cluster die Mehrheit seiner Manager, laufen bestehende Aufgaben unter Umständen weiter. Neue Services lassen sich dann jedoch nicht zuverlässig planen, aktualisieren oder verschieben. Ein Backup des Swarm-Zustands ist deshalb Pflicht und sollte regelmäßig auf einem getrennten System landen.

Ein ungerades Manager-Set ist meistens die vernünftige Wahl. Drei Manager passen zu kleinen produktiven Clustern, fünf zu größeren Installationen mit höheren Verfügbarkeitsanforderungen. Mehr Manager erhöhen nicht automatisch die Leistung und können Schreibvorgänge im Cluster verlangsamen.

Lesen Sie auch: Staging-Umgebung im Hosting sicher und reproduzierbar planen

Typische Fehlerbilder

• Replikate bleiben auf 0: Image, Registry-Zugriff, Ressourcen oder Placement-Regeln prüfen.
• Service ist von außen nicht erreichbar: Firewall, veröffentlichter Port und Routing Mesh kontrollieren.
• Container startet ständig neu: Logs, Healthcheck, Umgebungsvariablen und Speicherlimits untersuchen.
• Node erscheint als Down: Erreichbarkeit, Docker-Daemon, DNS und Uhrzeit-Synchronisation prüfen.
• Daten fehlen nach einem Neustart: Volume-Bindung und Speicherstrategie überprüfen.

Meine Erfahrung ist, dass Healthchecks und Ressourcenlimits oft mehr bewirken als zusätzliche Monitoring-Dashboards. Ein Service, der seinen Zustand korrekt meldet und nicht unbegrenzt Speicher verbraucht, lässt sich deutlich leichter betreiben.

Docker Swarm oder Kubernetes für das eigene Hosting

Die Entscheidung hängt weniger von einem technischen Sieger ab als von Team, Größe und Betriebsmodell. Swarm ist direkt in Docker Engine integriert und nutzt eine vergleichsweise kleine Zahl an Konzepten. Kubernetes bietet dagegen ein viel größeres Ökosystem, mehr Erweiterungen und feinere Steuerungsmöglichkeiten.

Für ein kleines Hosting-Team, eine Agentur oder ein Unternehmen mit wenigen klaren Services kann Swarm die angenehmere Lösung sein. Wer viele Teams, komplexe Policies, Service Meshes, umfangreiche Operatoren oder Multi-Cloud-Betrieb plant, sollte Kubernetes früh prüfen.

Ich würde nicht allein wegen des Marktanteils wechseln. Ein gut verstandener kleiner Cluster ist oft wertvoller als eine große Plattform, deren Betrieb niemand im Team sicher beherrscht. Umgekehrt sollte ein Unternehmen mit absehbar starkem Wachstum nicht aus Bequemlichkeit eine Architektur wählen, die in zwei Jahren grundlegend ersetzt werden muss.

Die pragmatische Entscheidung für den eigenen Cluster

Der Swarm-Modus passt besonders gut, wenn Docker bereits gesetzt ist, wenige Betriebsrollen gebraucht werden und Deployments schnell reproduzierbar sein sollen. Ein sinnvoller Start besteht aus drei Managern, getrennten Workern, festen Image-Versionen, geschützten Secrets und getesteten Backups.

Für stateless Anwendungen wie Frontends, APIs und Worker ist die Plattform angenehm direkt. Bei Datenbanken, externem Storage, komplexen Netzwerkregeln und sehr großen Teams steigt der Planungsaufwand spürbar. Genau dort sollte die Entscheidung nicht nach Gewohnheit, sondern nach Betriebsrisiko und langfristiger Teamkompetenz fallen.

Mein wichtigster Rat lautet deshalb, den Cluster zuerst mit einer kleinen, nicht kritischen Anwendung zu testen. Wenn Updates, Ausfälle, Backups und Wiederherstellung nachvollziehbar funktionieren, ist die Basis für produktives Hosting gelegt.