Docker Compose vs Docker Swarm: Welches für AI?
Tools · 6 min
Docker Compose = ein Rechner, schnelles Setup, ideal zum Lernen. Docker Swarm = mehrere Rechner, Rolling Updates, High Availability. Für Homelab mit einer GPU: Compose. Für Production mit 3+ Nodes: Swarm.
Du willst Ollama, n8n, Grafana und Team-Chat aufsetzen. Jetzt die Frage: Docker Compose oder Docker Swarm? Die Antwort bestimmt, wie dein Stack skaliert — und ob er 2026 noch funktioniert.
So nutzen wir es bei AI Engineering
Wir nutzen Docker Swarm mit 31 Services auf 6 Nodes inklusive GPU Workloads, Monitoring und Automatisierung.
Docker Compose in 60 Sekunden
Docker Compose ist der beste Freund jedes Entwicklers. Du schreibst einedocker-compose.yml, definierst deine Services (Ollama, PostgreSQL, Redis, Grafana) und startest mit docker compose up. Alles läuft auf deinem lokalen Rechner oder einem einzelnen Server.
Wann Compose perfekt ist:
- Ein-Maschine-Setups (Laptop, ein physischer Server)
- Entwicklungsumgebungen
- Kleine Hobby-Projekte
- Infrastruktur lernen
- GPU-intensive Workloads (Ollama mit A100 oder 3090)
Die Limitation:
Es lebt und stirbt mit deinem einen Host. Wenn deine Maschine abstürzt, geht alles offline. Wenn du Ollama ohne Downtime updaten willst, stoppst du den gesamten Stack. Und wenn du Services über mehrere Maschinen verteilen willst... geht nicht.
Docker Swarm in 60 Sekunden
Docker Swarm ist die eingebaute Orchestrierungsplattform von Docker. Du clusterst 3+ Maschinen, definierst Manager und Worker, und der Cluster übernimmt den Rest: Service-Scheduling, Load Balancing, Rolling Updates, Service Discovery, High Availability.
Wann Swarm sinnvoll ist:
- Mehrere Server (3+ Maschinen)
- Production-Grade Uptime-Anforderungen
- Rolling Updates ohne Downtime
- Service-Skalierung und Load Balancing
- Infrastruktur, die Node-Ausfälle überlebt
Der direkte Vergleich
| Feature | Docker Compose | Docker Swarm |
|---|---|---|
| Setup-Komplexität | 5 Minuten | 30 Minuten (einmalig) |
| Multi-Host Support | Nein | Ja (3+ Nodes) |
| High Availability | Nein (Single Point of Failure) | Ja (Replicas, Manager Quorum) |
| Rolling Updates | Manuell stop/start | Eingebaut (Zero-Downtime) |
| Load Balancing | Nein | Ja (Ingress) |
| Service Discovery | Docker Network | DNS-basiert, Cluster-weit |
| GPU Passthrough | Einfach | Node Constraints/Labels nötig |
Unser Setup: 3-Node Swarm für AI
So läuft unser Stack in Production:
Infrastruktur
- • 3 Proxmox VMs (je 8 CPU Kerne, 16GB RAM)
- • 3 Manager Nodes (Quorum von 3 — jeder 2. kann ausfallen)
- • Verschlüsseltes Overlay-Netzwerk über alle Nodes
Service Placement
- • Ollama gepinnt auf
docker-swarm3(GPU Node) - • n8n verteilt über alle Nodes (mit PostgreSQL)
- • Grafana + Prometheus auf dem Swarm
- • PostgreSQL + Redis auf dedizierten Nodes
- • Portainer für visuelle Cluster-Verwaltung
Was wir gelernt haben
- GPU-Pinning ist Pflicht. Ollama muss auf der Maschine mit GPU-Zugang laufen. In Swarm pinnst du den Service:
deploy.placement.constraints: [node.hostname == docker-swarm3] - Quorum von 3 ist Minimum. Mit 3 Managern kannst du 1 verlieren und der Cluster lebt. Mit 2 kannst du keine Ausfälle tolerieren.
- Overlay-Netzwerke brauchen Verständnis. Jeder Service bekommt seinen eigenen DNS-Namen (z.B.
ollama:11434). - Persistent Storage ist der harte Teil. Docker Volumes funktionieren über Nodes nur mit NFS oder distributed Treibern.
- Monitoring wird essentiell. Mit 3 Nodes brauchst du Prometheus + Grafana für Sichtbarkeit.
Wann was nutzen?
Docker Compose nutzen wenn:
- • Eine Maschine. Mehr nicht geplant.
- • Experimentierst. Lernst Ollama, n8n.
- • GPU-nur. Ganzer Stack auf einer 3090.
- • Kein Uptime nötig. Hobby-Projekt.
- • Schnelle Iteration. Wöchentlich Änderungen.
Docker Swarm nutzen wenn:
- • 3+ VMs/Servers. Proxmox Cluster.
- • Production. Replicas, Rolling Updates.
- • Komplexer Stack. 9+ Services.
- • Team-Infrastruktur. Mehrere Nutzer.
- • Langfristig. Läuft für Jahre.
Ollama muss auf der Node mit GPU laufen. Nutze deploy.placement.constraints: [node.hostname == gpu-node] in deiner Swarm-Konfiguration. Ohne Pinning landet der Service auf einem zufaelligen Node — ohne GPU.
Fazit
Für Self-hosted AI über eine Maschine hinaus ist Docker Swarm die minimale viable Orchestrierungsschicht. Es ist nicht Kubernetes (was bei 3-20 Nodes Overkill wäre), aber es ist weit besser als manuelles Management mit Shell-Skripten.
Quellen
Weiterfuehrende Artikel: Docker Grundlagen · AI Stack Setup · Grafana Monitoring
Fuer die Umsetzung gibt es Ressourcen auf ai-engineering.at.
War dieser Artikel hilfreich?
Nächster Schritt: Workflows sauber in Betrieb bringen
Nutze bewährte n8n-Patterns, Templates und Integrationen für Workflows, die lokal, dokumentiert und auditierbar bleiben.
- Lokal und self-hosted gedacht
- Dokumentiert und auditierbar
- Aus eigener Runtime entwickelt
- Made in Austria