Docker-Orchestrierung für KMU: docker-compose ohne Kubernetes-Overkill

Was ist Docker-Orchestrierung?

Docker-Orchestrierung beschreibt das Verfahren, mehrere Container-Prozesse auf einem oder mehreren Hosts deklarativ zu beschreiben, zu starten, zu überwachen und neu zu starten. Für Schweizer KMU-Setups ist „Orchestrierung" oft falsch verstanden: viele lesen das Wort und denken sofort an Kubernetes – und damit an einen Cluster mit drei Mastern, etcd, einem Ingress-Controller, einem CNI und einem CSI-Plugin. Für die typische Treuhand- oder KMU-Infrastruktur mit zehn bis dreissig Containern ist dieser Stack überdimensioniert und teuer.

Die ruhige Alternative heisst Docker Engine plus docker-compose. Compose ist seit Mai 2026 in Version 2.27 stabil, wird von Docker selbst gepflegt und beschreibt einen kompletten Anwendungsstapel in einer einzigen YAML-Datei. Auf einem Hetzner-Dedicated-Server mit 64 GB RAM laufen damit problemlos 25 Container produktiv. Der Fairlane-Server selbst betreibt exakt dieses Muster: 25 produktive Container, eine zentrale docker-compose.yml pro logische Gruppe (Monitoring, KI, Datenbanken, Workflow), gesteuert über systemd-Unit-Files für Boot-Reihenfolge und Restart-Verhalten. Die Komplexität bleibt damit auf einem Niveau, das eine einzelne Person warten kann.

Warum es zählt

Schlecht aufgesetzte Container fressen Speicher, öffnen unnötige Ports und verlieren Logs nach dem ersten Neustart. Ein Treuhandbüro hat keine Kapazität, jede Woche einen vergurkten Container zu reparieren. Sauber orchestrierte Container verhalten sich dagegen wie verschraubte Schubladen: jede läuft mit definierten Limits, jede startet nach einem Stromausfall ohne Eingriff, jede schreibt strukturierte Logs an einen zentralen Empfänger.

Konkret bedeutet das für den Betrieb: Die Anwendung lässt sich auf einen neuen Server in unter einer Stunde umziehen, weil die compose.yml plus drei Volumes der vollständige Zustand ist. Sicherheits-Updates für das Basis-Image lassen sich pro Container nachvollziehen und ausrollen. Bei einem Audit nach Art. 957a OR oder nach VDSG/revDSG ist nachweisbar, welche Software-Version wann gelaufen ist. Und die Hosting-Kosten bleiben planbar – keine versteckten Cluster-Gebühren, kein Load-Balancer pro Service, kein Egress-Traffic-Schock am Monatsende.

Wie es funktioniert

Ein produktionsreifes Compose-Setup folgt sechs Regeln, die jede für sich klein wirken und zusammen den Unterschied zwischen „läuft" und „läuft seit zwei Jahren ohne Eingriff" ausmachen.

Image-Pinning per Digest. Statt `image: postgres:16` schreibt man `image: postgres:16@sha256:abc123...`. Das verhindert, dass ein Re-Pull eine andere Version zieht. Renovate oder Watchtower-mit-Stop-Mode aktualisieren den Digest dann kontrolliert.

Healthchecks pro Container. Jeder Container hat einen `healthcheck:`-Block, der den eigenen Service prüft – für Postgres `pg_isready`, für einen HTTP-Service ein `curl --fail`. Compose startet abhängige Container erst, wenn der Healthcheck `healthy` meldet (`depends_on: condition: service_healthy`).

Restart-Policies. Für langlaufende Services `restart: unless-stopped`. Für Cron-ähnliche Container `restart: no`. Niemals `restart: always` ohne Healthcheck – sonst respawnt ein kaputter Container in einer Schleife und brennt CPU.

Log-Rotation. Default-Driver json-file mit `options: max-size: 10m, max-file: 5`. Ohne diese zwei Zeilen wachsen Logs unkontrolliert. Bei Fairlane laufen die Logs zusätzlich über den loki-docker-driver in Loki.

Resource-Limits. `mem_limit: 512m` und `cpus: "1.0"` verhindern, dass ein einzelner Container den Host erstickt. Ohne Limits hat ein Memory-Leak in einem n8n-Workflow das Potenzial, alle anderen Services mitzureissen.

Non-root User. Im Dockerfile `USER 1000:1000` setzen. Compose erlaubt zusätzlich `user: "1000:1000"` und `read_only: true` für Filesystem-Lockdown. Damit ist eine Container-Escape-Lücke nicht automatisch eine Root-Lücke auf dem Host.

Compose-Setup in 7 Schritten

1. 01Docker Engine + Compose-Plugin installieren (apt-get docker-ce docker-compose-plugin, Ubuntu 24.04 LTS).
2. 02Pro logische Gruppe eine compose.yml: monitoring, ai, data, workflow. Nicht alle 25 Container in eine Datei.
3. 03Jedes Image per Digest pinnen, Renovate-Bot für kontrollierte Updates anbinden.
4. 04Healthcheck-Block pro Container – pg_isready, curl --fail /healthz, redis-cli ping.
5. 05Resource-Limits setzen: mem_limit, cpus. Default 512m / 1 CPU, dann pro Service nachjustieren.
6. 06Log-Driver konfigurieren: json-file max-size 10m max-file 5, oder loki-driver für zentrales Logging.
7. 07systemd-Unit pro compose.yml: ExecStart=docker compose up, ExecStop=docker compose down. Damit überlebt der Stack jeden Reboot.

Wann Docker-Compose einsetzen

Docker-Compose ist die richtige Wahl, wenn (a) der gesamte Stack auf einem oder zwei Hosts läuft, (b) das Betriebsteam aus einer bis drei Personen besteht und (c) die Verfügbarkeitsanforderung bei „mehrere Minuten Downtime sind tolerierbar" liegt. Das umfasst praktisch jede Schweizer KMU-Umgebung unter 200 Mitarbeitenden.

Konkrete Anwendungsfälle: Selbst gehostetes n8n plus Postgres plus Redis für Workflow-Automation. Ein RAG-Setup aus Qdrant plus LiteLLM-Gateway plus Ollama. Monitoring-Stack aus Grafana, Prometheus, Loki und Promtail. Ein interner Tool-Server mit Gitea, Drone, Plausible. In allen diesen Fällen ist Kubernetes oder Nomad messbar mehr Aufwand bei null zusätzlichem Nutzen.

Wann NICHT

Docker-Compose stösst an Grenzen, wenn (a) der Stack über mehr als drei Hosts laufen muss und einzelne Services automatisch zwischen Knoten umziehen sollen, (b) ein einzelner Service hunderte Replikate braucht und ein Service-Mesh zur Pflicht wird, oder (c) ein Hyperscaler-managed-Kubernetes-Angebot (GKE, EKS) bereits intern Standard ist.

Weitere Anti-Patterns: docker-compose im Produktionsbetrieb ohne systemd-Wrapper – bei Reboot startet über Compose alleine kein Stack zuverlässig. Compose-Files mit hardgecodeten Secrets im Klartext – stattdessen .env mit `chmod 600` oder Docker Secrets. Privileged-Container ohne klaren Grund – `privileged: true` haebelt fast alle Linux-Sicherheitsmechanismen aus und ist in 95% der Fälle überflüssig (alternativ gezielte `cap_add:` einsetzen).

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Docker Documentation – Compose Specification v2.27 · 2026-05
2. OCI Image Specification – Digest-based pinning · 2026-02
3. Docker Security Best Practices – non-root, read_only, cap_drop · 2026-04
4. CNCF Annual Survey 2025 – Compose vs Kubernetes adoption in SMEs · 2025-12