Wir haben compose.yaml aus allen Projekten verbannt
Warum wir projektlokale compose.yaml-Dateien abgeschafft haben und wie zentrale Service-Orchestrierung Alltag und Sicherheit verbessert.
Wenn wir Entwicklungsteams erzählen, dass in keinem unserer Projekte mehr eine compose.yaml liegt, ernten wir zwei Reaktionen: Zustimmung von denen, die den Schmerz kennen, und Stirnrunzeln von denen, die sie noch für Teil der Lösung halten. Beides ist nachvollziehbar. Wir wollen in diesem Beitrag ehrlich beschreiben, warum wir diese Entscheidung getroffen haben, was sie uns gebracht hat und was sie für unsere Kundinnen und Kunden konkret bedeutet.
Früher war das bei uns wie fast überall. In jedem Projekt lag eine eigene compose.yaml. Sie beschrieb, welche Datenbank gebraucht wurde, welcher Cache, welcher Search-Service, welche Entwicklerports belegt waren. Das fühlte sich gut an, weil es sichtbar war. Es war aber auch die Quelle vieler kleiner Dauerbaustellen, die sich im Alltag zu echten Kosten summierten.
Warum projektlokale Compose-Dateien so teuer werden
Das Grundproblem ist nicht Docker Compose als Werkzeug. Das Grundproblem ist das, was in der Praxis damit passiert. Jedes Team pflegt irgendwann seine eigene Version, jede Version weicht leicht von der nächsten ab. Es entstehen Projekte mit PostgreSQL in Version 14 neben Projekten in Version 16, Redis in vier verschiedenen Konfigurationen, ein Projekt bindet den Port 5432 lokal, das andere 5433, ein drittes 54321. Wer zwischen zwei Projekten wechselt, verbringt eine Stunde damit, seine Developer-Maschine wieder lauffähig zu machen.
Dazu kommt die Sicherheitsseite. Secret-Handling in projektlokalen Compose-Dateien ist anfällig. Entwickler kopieren Konfigurationen, vergessen, dass dort ein echtes Token steckt, pushen Branches, rotieren nichts. Die Services selbst werden selten gehärtet, weil jede Projekt-Compose ihre eigene Baustelle ist und Änderungen 40 Mal gepflegt werden müssten.
Und schließlich kostet die Fragmentierung Zeit im Betrieb. Wenn jede Anwendung ihre eigene lokale Dependency-Landschaft mitbringt, ist die Differenz zwischen Dev- und Produktionsumgebungen schwer zu beherrschen.
Was wir stattdessen tun
Wir betreiben zentral eine Entwicklungs-Service-Plattform, die in Form von vorkonfigurierten, versionierten Services all das abdeckt, was unsere Projekte als Infrastruktur brauchen. Datenbanken, Caches, Suchindizes, Message-Queues, Object-Storage-Emulationen. Diese Services laufen in einer gemeinsamen, von uns gepflegten Orchestrierung, nicht in 40 einzelnen compose.yaml-Dateien, die in 40 Projekten leben.
Die Projekte selbst enthalten keine Infrastrukturdefinition mehr, sondern nur noch eine deklarative Beschreibung dessen, was sie benötigen. Welche Datenbank-Engine in welcher Version, welcher Cache-Typ, welche Ports über eine zentrale Vergabe, welche Secrets über den zentralen Secret-Manager. Die Zuteilung und das Starten erledigt unser Plattform-Layer. Das Entwicklungsteam startet sein Projekt und bekommt einen funktionierenden, gehärteten Satz an Services dazu, ohne sich je wieder mit Port-Konflikten oder YAML-Drift zu beschäftigen.
Drei konkrete Verbesserungen, die wir messen
1. Onboarding in Stunden statt Tagen
Neue Teammitglieder oder externe Entwickler, die mit uns an einem Projekt arbeiten, haben ihre Umgebung in unter einer Stunde lauffähig. Früher waren ein bis zwei Tage Standard, oft auch mehr.
2. Sicherheit als Produkt der Plattform
Härtungen an unseren Services müssen wir nur einmal umsetzen. TLS, Authentifizierung, Netzwerksegmentierung, Update-Pfade. Das greift dann für alle Projekte gleichzeitig. Die Angriffsfläche in den Projekten selbst sinkt, weil dort einfach viel weniger Konfiguration lebt.
3. Dev-Prod-Parität ohne Handarbeit
Weil die Service-Versionen zentral gepflegt werden, ist der Unterschied zwischen Entwicklungs-, Staging- und Produktionsumgebung klein und dokumentiert. „Bei mir läuft es aber“-Diskussionen werden seltener, und wenn sie auftauchen, finden wir die Abweichung schneller.
Was das für unsere Kundinnen und Kunden bedeutet
Für Sie als Auftraggeber ist diese Entscheidung zunächst unsichtbar, und das ist gut so. Sie merken den Unterschied nicht in einer YAML-Datei, Sie merken ihn an der Geschwindigkeit, mit der neue Entwicklungen bei uns anlaufen, an der Zuverlässigkeit, mit der Releases funktionieren, und an der Tatsache, dass Sicherheitsupdates an Basisdiensten bei uns kein Projekt auslösen, sondern ein Plattform-Routinevorgang sind.
Der Ansatz ist ein weiterer Baustein in unserem Prinzip „Standardisierte Individualität“. Wir reduzieren die Varianz dort, wo sie keinen Wert schafft, um Kapazität für echte Individualität zu gewinnen: für Ihre Inhalte, Ihre Integrationen, Ihre Geschäftslogik.
Wenn Sie gerade in YAML-Drift feststecken
Wenn Ihr Entwicklungs-Setup aus einer Reihe projekt-lokaler Konfigurationsdateien besteht, die niemand mehr konsolidieren möchte, weil der Aufwand zu groß wirkt, sprechen wir gern darüber. Wir haben diesen Umbau selbst gemacht und wissen, welche Schritte sich wirtschaftlich lohnen und welche nicht.
30 Minuten, kein Pitch. Wir hören uns Ihren Stack an und skizzieren, welche Vereinheitlichung als Erstes Wirkung zeigt.
Häufige Fragen
Was uns Kundinnen und Kunden zu diesem Thema am häufigsten fragen — offen beantwortet.
Funktioniert das auch für Projekte, die wir intern weiterentwickeln?+
Ja. Das Modell ist nicht an unsere Betriebsmodelle gebunden. Sie können die Plattform-Services auch nutzen, wenn Ihr Team eigenständig weiterentwickelt. Wir liefern die Orchestrierung, Ihr Team liefert die Anwendung.
Was passiert, wenn ein Projekt eine Sonderversion einer Datenbank braucht?+
Das kommt vor und ist ausdrücklich vorgesehen. Unsere Plattform unterstützt mehrere Versionen parallel. Was wir vermeiden, ist ungeplanter Wildwuchs. Jede Sonderversion wird bewusst aufgenommen und gepflegt, nicht irgendwann vergessen.
Wie funktioniert das mit Secrets in der zentralen Plattform?+
Wir arbeiten mit einem zentralen Secret-Manager und kurzen TTLs. Projekte deklarieren, welche Zugangsdaten sie benötigen; das eigentliche Secret liegt nie im Projekt-Repository. Rotation ist automatisiert und nachvollziehbar.
Was kostet der Umbau auf eine zentrale Service-Plattform?+
Das hängt davon ab, wie groß Ihre bestehende Compose-Landschaft ist und wie einheitlich Ihre Service-Versionen sind. In der Regel amortisiert sich der Umbau binnen weniger Monate über reduzierte Onboarding- und Betriebszeiten. Wir rechnen das vorher transparent durch.
Heißt das, unsere Entwickler dürfen kein Docker Compose mehr nutzen?+
Nein. Docker Compose als Werkzeug ist nicht das Problem. Wir schaffen lediglich die 40 einzelnen, driftenden Projektdateien ab. Wer lokal etwas Experimentelles braucht, kann das weiterhin tun. Der produktive Pfad läuft über die zentrale Plattform.