Was ist Docker Swarm? Container-Orchestrierung mit Bordmitteln

Docker Swarm ist die native Clustering- und Orchestrierungslösung von Docker. Sie ist direkt in die Docker Engine integriert und ermöglicht es, mehrere Docker-Hosts zu einem Cluster zusammenzuschließen, ohne separate Tools installieren zu müssen. Wer Container auf mehr als einem Server betreiben will, bekommt mit Docker Swarm ein solides Fundament: einfach einzurichten, mit vertrautem Docker-Tooling, und für viele Setups vollkommen ausreichend.

Swarm Mode. Was steckt dahinter?

Seit Docker 1.12 ist Swarm kein eigenständiges Projekt mehr, sondern ein eingebauter Betriebsmodus der Docker Engine, bekannt als Swarm Mode. Das bedeutet: Jede aktuelle Docker-Installation kann einen Swarm-Cluster betreiben, ohne dass zusätzliche Pakete oder externe Abhängigkeiten nötig wären.

Der konzeptuelle Unterschied zu docker run oder docker-compose liegt im Abstraktionsniveau. Swarm denkt nicht in einzelnen Containern, die auf einem bestimmten Host laufen, es denkt in Services, die auf dem Cluster als Ganzes ausgeführt werden. Wo genau ein Container landet, entscheidet der Scheduler.

Manager- und Worker-Nodes im Überblick

Ein Swarm-Cluster besteht aus zwei Typen von Nodes:

Manager-Nodes sind für die Clusterverwaltung zuständig. Sie nehmen API-Anfragen entgegen, verteilen Aufgaben (sogenannte Tasks) an Worker-Nodes und überwachen den Zustand des Clusters. Manager-Nodes nutzen das Raft-Konsensusprotokoll, um untereinander einen konsistenten Cluster-Zustand zu halten. Fällt ein Manager aus, übernimmt ein anderer, vorausgesetzt, die Mehrheit der Manager ist noch erreichbar.

Daraus ergibt sich eine praktische Faustformel: Wer Hochverfügbarkeit will, sollte 3 oder 5 Manager-Nodes betreiben. Bei 3 Managern darf einer ausfallen, bei 5 Managern dürfen es zwei sein.

Worker-Nodes führen die Container aus. Sie empfangen Tasks vom Manager und melden deren Status zurück – mehr nicht. Worker-Nodes haben keinen Zugriff auf den Cluster-Zustand und können keine Management-Operationen ausführen.

Services, Tasks und der Desired State

Das zentrale Konzept in Docker Swarm ist der Service. Anstatt einen Container manuell zu starten, definiert man einen Service mit einer gewünschten Anzahl von Replicas.

Swarm stellt sicher, dass zu jedem Zeitpunkt genau 3 Instanzen des Nginx-Containers laufen, verteilt über die verfügbaren Worker-Nodes. Fällt einer aus, erkennt das der Manager und startet einen neuen Task. Dieses Prinzip nennt sich Desired State Reconciliation: Swarm gleicht kontinuierlich den gewünschten Zustand mit dem tatsächlichen Zustand ab.

Tasks sind die kleinsten Einheiten in Swarm, jeder Task entspricht einem Container auf einem bestimmten Node. Der Service ist das Objekt, das man beschreibt und verwaltet; die Tasks entstehen daraus automatisch.

Rolling Updates und Rollbacks

Ein häufiges Problem bei manuellen Deployments: entweder kurze Downtime beim Austausch des Containers oder komplizierte Blue/Green-Setups. Swarm löst das mit eingebauten Rolling Updates.

Swarm merkt sich den vorherigen Zustand des Service und kann ihn ohne manuelle Intervention wiederherstellen.

Overlay-Netzwerke und Service Discovery

Wenn mehrere Services auf unterschiedlichen Nodes kommunizieren sollen, etwa ein Backend-Service, der eine Datenbank anspricht, braucht man ein Netzwerk, das Hostgrenzen überbrückt. Docker Swarm bringt dafür Overlay-Netzwerke mit.

Services, die demselben Overlay-Netzwerk zugeordnet sind, können sich gegenseitig über ihren Servicenamen ansprechen, unabhängig davon, auf welchem Node die Container gerade laufen. Der integrierte DNS-Resolver übernimmt die Service Discovery automatisch.

Das erspart die manuelle Pflege von IP-Adressen und macht Service-Kommunikation innerhalb des Clusters transparent.

Docker Stack und Compose-Integration

Teams, die bereits mit docker-compose arbeiten, können ihr vorhandenes Wissen direkt in Swarm einbringen. Mit docker stack deploy lassen sich Compose-Files im Format v3 direkt in Swarm deployen.

Ein Stack ist im Wesentlichen eine Gruppe von Services, die gemeinsam deployt und verwaltet werden. Das Compose-File bleibt weitgehend unverändert, lediglich Swarm-spezifische Einstellungen wie Replica-Anzahl oder Update-Konfiguration kommen unter dem deploy-Schlüssel hinzu:

Dieser Weg macht den Einstieg in Swarm für Compose-Nutzer besonders niedrigschwellig.

Docker Swarm vs. Kubernetes. Wann was?

Der direkte Vergleich zwischen Docker Swarm und Kubernetes taucht regelmäßig auf, und die Antwort ist weniger binär als oft dargestellt. Wer zusätzlich Docker, Compose, Swarm und Kubernetes direkt gegenüber stellen möchte, findet dort die Entscheidungshilfe im Überblick.

Kubernetes hat ein deutlich größeres Feature-Set: natives Horizontal Pod Autoscaling, detailliertes RBAC, Custom Resource Definitions, ein riesiges Ökosystem an Operatoren und Tools. Dafür ist der Einstieg aufwendiger, der Betrieb anspruchsvoller und die Lernkurve steiler.

Docker Swarm ist konzeptionell einfacher, schneller eingerichtet und für viele Anwendungsfälle ausreichend. Wer kein dediziertes DevOps-Team hat oder Kubernetes nicht braucht, fährt mit Swarm oft pragmatischer.

Entscheidende Unterschiede auf einen Blick:

Wann Swarm die richtige Wahl ist

Swarm macht dann Sinn, wenn:

• Das Team Docker kennt, aber Kubernetes noch nicht eingeführt hat
• Die Infrastruktur überschaubar ist und kein automatisches Scaling benötigt wird
• Bare-Metal-Server oder kleine VMs ohne Cloud-Managed-Kubernetes eingesetzt werden
• Die Betriebskomplexität bewusst niedrig gehalten werden soll

Sobald die Anforderungen wachsen – mehr Teams, komplexere Netzwerktopologien, feingranulare Zugriffssteuerung, Skalierungsautomatisierung, stößt Swarm an Grenzen.

Docker Swarm ist ein solider Einstiegspunkt in die Container-Orchestrierung, ohne den operativen Overhead, den Kubernetes mit sich bringt. Wer aber merkt, dass die Anforderungen wachsen und ein vollständiges Kubernetes-Setup sinnvoll wäre, muss das nicht selbst aufbauen und betreiben. lowcloud bietet eine DevOps-as-a-Service-Plattform mit Kubernetes im Kern, die den Betrieb von Kubernetes-Clustern auf souveräner Infrastruktur vereinfacht, ohne Cloud, Vendor-Lock-in und mit dem Fokus auf das, was zählt: die eigene Anwendung.