Das Team stellte es in der Produktion mit „docker compose up -d“ auf einem virtuellen privaten Server bereit: Anwendung, Worker, Cache, Reverse-Proxy. Es läuft. Sechs Monate später kam es zum ersten echten Vorfall – volle Festplatte auf dem einzelnen Knoten –, der alles lahmlegte: Web, Warteschlangen, Überwachung. Im Wiederherstellungsplan ist von einem „Failover auf den zweiten Server“ die Rede, Compose wurde jedoch nie für die Orchestrierung von zwei Hosts konfiguriert.
Docker Compose zeichnet sich durch die Beschreibung mehrerer Container und ihrer Links aus. Er ist kein Rechenzentrums-Orchestrator. Die Verwechslung von „Ich habe eine funktionierende Yaml-Datei“ mit „Ich habe eine belastbare Infrastruktur“ ist beim ersten Single Point of Failure kostspielig.
Was Compose gut macht – und wo es aufhört
Compose v2 verwaltet Abhängigkeiten, Zustandsprüfungen, Volumes und Overlay-Netzwerke auf derselben Docker-Engine. Ideal, um die Produktion lokal zu reproduzieren und einen kohärenten Stapel zu starten.
| Brauchen | Verfassen | Orchestrator (Kubernetes, Nomad) |
|---|---|---|
| Multi-Container auf 1 Host | ✅ | ✅ (übergroß) |
| Nahtloses fortlaufendes Update | ⚠️ Handbuch/Skript | ✅ nativ |
| Multi-Node / Anti-Single-Point | ❌ | ✅ |
| Horizontale Autoskalierung | ❌ | ✅ |
| Rotationsgeheimnisse | ⚠️ begrenzt | ✅ integriert |
Auf einem einzelnen Server mit einem europäischen Host bleibt Compose ehrlich, wenn man Wartung und Backups außerhalb von Compose übernimmt.
Stellen Sie Dokumente in Ihrem Stapel zusammen; es macht es nicht auf magische Weise verfügbar.
Einzelner Host, vergessene Volumes und Backups
Benannte Volumes überstehen das Herunterfahren ohne Löschung – praktisch, aber gefährlich, wenn niemand einen Snapshot der Datenbank erstellt. Ein Image-Update aktualisiert die Anwendung, aktualisiert aber nicht automatisch die PostgreSQL-Volume-Backup-Richtlinie.
Prüfen: Off-Node-getestete Backups, Festplattenüberwachung und Warnungen, zentralisierte Protokolle – nicht nur lokale Containerprotokolle. Die Auslagerung der Datenbank reduziert das Risiko, ohne gleich auf Kubernetes umzusteigen.
Bereitstellung, Nichtverfügbarkeit und Gesundheitsprüfung
Ohne Gesundheitsprüfung leitet der Proxy möglicherweise an einen Container weiter, der noch gestartet wird – vorübergehende Serverfehler. Muster: HTTP-Steuerung am Anwendungsendpunkt, Proxy, der Datenverkehr nur an fehlerfreie Backends sendet, Bereitstellungsskript mit Integritätswartezeit.
Die nahtlose Aktualisierung mehrerer Instanzen auf einem einzelnen Host bleibt handwerklich. Hier werden die Grenzen konkret: Sie erfinden neu, was Orchestratoren nativ tun.
Netzwerk-, TLS- und Port-Exposition
Durch die Veröffentlichung des Datenbankports wird PostgreSQL dem Internet zugänglich gemacht, wenn die Host-Firewall lax ist. Bevorzugen Sie interne Netzwerkeinwahlen und einen einzelnen Reverse-Proxy an einem sicheren Port.
Beobachtbarkeit und nächtliche Einschränkung
Compose bietet kein Cluster-Dashboard. Containermetriken durchlaufen einen dedizierten Agenten, Protokolle einen Collector – und müssen explizit hinzugefügt werden. Dokumentieren Sie, wer auf den Server zugreift, wie ein Dienst neu gestartet wird, wo sich die Umgebungsdateien befinden und wer um 3 Uhr morgens auf eine Warnung reagiert.
Der Gipfel: Als aufgeschobene Schulden verfassen
Entscheide dich und gehe ohne blinden Fleck voran
Wenn Sie bei Compose bleiben, behandeln Sie diese Punkte als Prüfung vor dem nächsten Vorfall:
- Outsourcen Sie die Datenbank zu einem verwalteten Angebot oder zu getesteten Off-Node-Backups – das Docker-Volume allein schützt Ihre Daten nicht.
- Fügen Sie Integritätsprüfungen für jeden bereitgestellten Dienst hinzu und konfigurieren Sie den Proxy so, dass er Datenverkehr nur an fehlerfreie Backends sendet.
- Testen Sie Backups mit einer zeitgesteuerten Wiederherstellung, nicht nur mit dem Vorhandensein eines Cron-Skripts.
- Skript für die Bereitstellung mit Gesundheitserwartung und dokumentiertem Wartungsfenster.
- **Stellen Sie eine zentrale Festplatten-, Container- und Protokollüberwachung bereit – Compose führt dies nicht nativ durch.
- Planen Sie den Migrationsschwellenwert basierend auf Datenverkehr, Teamgröße und dem den Kunden versprochenen Serviceniveau.
- Simulieren Sie einen Festplattenausfall: Wie lange dauert die Wiederherstellung von Diensten und Daten? Wenn die Antwort unklar ist, ist Compose noch nicht für Sie bereit.
Vergleichen Sie geeignete Hosts über das Verzeichnis und den Vergleich.
Häufig gestellte Fragen
Ist Docker Compose für die Produktion geplant?
Compose zielt in erster Linie auf einfache Entwicklung und Bereitstellung auf einem oder mehreren Hosts ab. In der Massenproduktion fehlen native Grundelemente für die fortlaufende Aktualisierung mehrerer Knoten, die automatische Skalierung und die feinkörnige geheime Rotation. Das verbietet es nicht – setzt aber seine Grenzen.
Wann bleibt Compose eine gute Wahl?
Auf einem einzelnen Server, mit einem kleinen Team, einem stabilen Stack und Toleranz gegenüber einem kurzen Wartungsfenster. Interne Tools, MVPs und SaaS im Frühstadium finden oft ihren Platz – solange der Single Point of Failure angenommen und dokumentiert wird.
Wie verwalte ich Geheimnisse mit Compose?
Verwenden Sie Umgebungsvariablen über eine nicht versionierte Datei, Docker-Geheimnisse im Schwarmmodus oder Injektion von der kontinuierlichen Integration bis zur Bereitstellung. Übertragen Sie niemals Passwörter an das Repository. Spüren Sie die Geheimnisse nach verdächtigen Lecks auf.
Wie kann man ohne großen Knall auf Kubernetes migrieren?
Externalisieren Sie zunächst den Status (verwaltete Datenbank, verwalteter Cache), Containerisieren Sie ihn ordnungsgemäß und übertragen Sie dann Dienst für Dienst. Compose und Kubernetes können während einer Übergangsphase nebeneinander existieren – es ist nicht nötig, alles an einem Freitagabend umzustellen.
Compose hält durch, solange Sie Ihren Single Point of Failure benennen – und erklären können, wie Sie ihn überstehen.