Docker Swarm für lokale KI

Was dieser Artikel über Docker Swarm behandelt

• Was Docker Swarm ist und wann es sinnvoll ist.
• Wie ein Swarm-Cluster initialisiert wird.
• Wie Services, Tasks und Overlay-Netzwerke funktionieren.
• Praxisbeispiel für Ollama oder Open WebUI.
• Vor- und Nachteile gegenüber Kubernetes und Compose.

Einleitung: Docker Swarm für lokale KI

Docker Swarm ist die eingebaute Cluster-Funktion von Docker. Mehrere Docker-Hosts lassen sich zu einem Swarm zusammenschliessen, über den Services verteilt und skaliert werden. Für Homelabs ist Swarm oft einfacher als Kubernetes, aber leistungsfähiger als reines Docker Compose auf einem Rechner. Wer mehrere Server hat und KI-Dienste wie Ollama, Open WebUI oder Datenbanken verteilen möchte, kann Swarm als Einstieg in die Container-Orchestrierung nutzen.

Dieser Artikel zeigt, wie man Docker Swarm aufsetzt, Services definiert und wann es sich lohnt.

Wichtige Begriffe

• Swarm: Cluster aus mehreren Docker-Nodes.
• Manager: Steuernde Node im Swarm.
• Worker: Ausführende Node im Swarm.
• Service: Definierte Anwendung im Swarm.
• Task: Laufende Instanz eines Service.
• Replica: Anzahl der parallel laufenden Tasks.
• Overlay-Netzwerk: Netzwerk über mehrere Nodes.
• Stack: Gruppe von Services, definiert in einer Compose-Datei.

Wann Docker Swarm?

• Mehrere physische oder virtuelle Server vorhanden.
• Dienste sollen hochverfügbar sein.
• Lasten auf mehrere Nodes verteilt werden.
• Rolling Updates ohne Ausfall.
• Einfachere Einstieg als Kubernetes.

Wenn nur ein einzelner Server genutzt wird, reicht Docker Compose.

Swarm initialisieren

Auf dem ersten Manager:

docker swarm init --advertise-addr 192.168.1.10

Der Befehl gibt ein Join-Token aus. Worker- und weitere Manager-Nodes schliessen sich damit an:

docker swarm join --token <TOKEN> 192.168.1.10:2377

Status prüfen:

docker node ls

Service erstellen

docker service create --name ollama \
  --publish 11434:11434 \
  --replicas 1 \
  --mount type=volume,source=ollama-data,target=/root/.ollama \
  ollama/ollama

Stack aus Compose-Datei

Eine docker-compose.yml kann direkt als Stack deployt werden:

docker stack deploy -c docker-compose.yml ki-stack

Wichtig: Swarm unterstützt nicht alle Compose-Features. build wird beispielsweise nicht unterstützt, Images müssen vorher gebaut und in einer Registry liegen.

Compose-Datei für Swarm

version: "3.8"

services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama-data:/root/.ollama
    networks:
      - ki-net
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.labels.gpu == true

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "8080:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    networks:
      - ki-net
    deploy:
      replicas: 1

volumes:
  ollama-data:

networks:
  ki-net:
    driver: overlay

Placement und Constraints

Damit Ollama auf einem Node mit GPU läuft, können Labels verwendet werden:

docker node update --label-add gpu=true node1

Im Service:

deploy:
  placement:
    constraints:
      - node.labels.gpu == true

Skalierung

docker service scale ki-stack_open-webui=3

Oder in Compose:

deploy:
  replicas: 3

Rolling Updates

docker service update --image ollama/ollama:latest ki-stack_ollama

Updates können automatisch nacheinander auf den Nodes ausgerollt werden.

Secrets und Configs

Docker Swarm bietet integrierte Secrets:

echo "mein-passwort" | docker secret create db_password -

Im Service:

services:
  app:
    secrets:
      - db_password

secrets:
  db_password:
    external: true

Overlay-Netzwerke

Services im gleichen Overlay-Netzwerk können sich über den Service-Namen erreichen, egal auf welchem Node sie laufen.

docker network create --driver overlay ki-net

Vorteile gegenüber Compose

• Hochverfügbarkeit.
• Verteilung auf mehrere Nodes.
• Rolling Updates.
• Eingebaute Load Balancing.
• Overlay-Netzwerke.
• Secrets und Configs.

Nachteile gegenüber Kubernetes

• Weniger Ökosystem.
• Eingeschränkte Orchestrierungs-Features.
• Kein eingebautes Service Mesh.
• Weniger Monitoring- und Storage-Integrationen.

Für viele Homelabs reicht Swarm aus. Wer komplexe Anforderungen hat, wechselt später zu Kubernetes.

Typische Stolpersteine

• Images müssen in Registry liegen: build wird im Stack nicht ausgeführt.
• Volumes lokal an Node: Daten wandern nicht automatisch mit dem Container.
• Placement falsch: Service startet auf Node ohne GPU oder Ressourcen.
• Netzwerkprobleme: Firewall-Ports für Swarm-Kommunikation.
• Mehrere Manager: Ungerade Anzahl für Quorum, mindestens drei.
• Keine Persistenz-Strategie: Stateful-Dienste brauchen Shared Storage oder Bind Mounts.

Weiterführende Links und Infos

• BotServ.de Docker Befehle
• BotServ.de Docker Netzwerk
• BotServ.de Docker Compose
• BotServ.de Docker Registry
• BotServ.de Kubernetes

FAQ: Docker Swarm

Brauche ich Swarm für einen Server? Nein, reines Docker Compose reicht.

Ist Docker Swarm veraltet? Docker Swarm wird weiter gepflegt, hat aber weniger Community-Momentum als Kubernetes.

Kann ich GPU in Swarm nutzen? Ja, durch Placement-Constraints und Nvidia Runtime auf den jeweiligen Nodes.

Sind Swarm-Services hochverfügbar? Ja, wenn mehrere Replicas auf verschiedenen Nodes laufen.

Was ist besser: Swarm oder Kubernetes? Swarm ist einfacher, Kubernetes mächtiger. Für Homelabs ist Swarm oft ausreichend.

Quellen und weiterführende Literatur

• Docker Swarm Docs: https://docs.docker.com/engine/swarm/
• Docker Stack Deploy: https://docs.docker.com/engine/reference/commandline/stack_deploy/
• Docker Swarm Networking: https://docs.docker.com/network/overlay/

Zusammenfassung: Docker Swarm für lokale KI

Docker Swarm ist eine gute Möglichkeit, KI-Dienste über mehrere Server zu verteilen, ohne die Komplexität von Kubernetes. Mit einfachen Befehlen lassen sich Cluster initialisieren, Services deployen, skalieren und aktualisieren. Wichtig sind Placement-Constraints für GPU-Workloads, Overlay-Netzwerke für die Kommunikation und eine Persistenzstrategie für Daten. Für Homelabs mit mehreren Nodes bietet Swarm eine einfache Hochverfügbarkeit und Skalierung, während reine Einzelserver-Setups oft bei Docker Compose bleiben können.