🐙Docker Compose visualisiert
Eine docker-compose.yml beschreibt ein ganzes Projekt: Services, Netze, Volumes und ihre Abhängigkeiten. Wähle ein Beispiel oder füge deine eigene Datei ein – sie wird mit dem npm-Paket „yaml“ im Browser geparst, zusammengeführt, geprüft und gezeichnet.
So laufen die Apps der „Visuellen Erklärungen“ auf dem Server: App und Datenbank im Compose-Netz, die DB ohne Host-Port, die App nur auf 127.0.0.1 – nginx auf dem Host leitet weiter. Das Override legt ein festes Subnetz fest.
🔍 Prüfung0 Fehler0 Warnungen0 Hinweise
- ✅ Keine Auffälligkeiten gefunden.
Projekt „visualdemo“🌐 visualdemo_default · 10.89.51.0/24━ healthy━ fertig┅ gestartet
🚦 Startreihenfolge (topologisch sortiert)
- 1db
- 2app wartet auf db (healthy)
Stoppen (docker compose down) in umgekehrter Reihenfolge: app → db
▶ docker compose up -d
$ docker compose up -d
🧩Override-Dateien und Profile
💡 Automatisches Override
docker compose up liest docker-compose.yml und – falls vorhanden – docker-compose.override.yml. Einzelwerte werden ersetzt, environment/labels nach Schlüssel gemischt, ports angehängt, volumes nach Zielpfad ersetzt.✅ Muster dieser Sammlung
Im Repository liegt nur die Basisdatei (Port auf
127.0.0.1). Auf dem Server legt ein nicht versioniertes Override ein festes Subnetz 10.89.x.0/24 fest, weil die Adresspools von Docker dort erschöpft sind. nginx auf dem Host leitet die Domain an den lokalen Port weiter.💡 Mehrere Dateien explizit
docker compose -f compose.yml -f compose.prod.yml config zeigt das zusammengeführte Ergebnis – genau das, was dieser Visualizer berechnet.🗝️Die wichtigsten Schlüssel
| services | Die Container des Projekts. Name = DNS-Name im Projektnetz. |
| image / build | Fertiges Image laden oder aus einem Dockerfile bauen (beides: bauen und so benennen). |
| ports | Veröffentlichte Ports – [IP:]HOST:CONTAINER. Ohne ports ist ein Dienst nur im Netz erreichbar. |
| depends_on | Start-Reihenfolge, optional mit Bedingung: service_started, service_healthy, service_completed_successfully. |
| healthcheck | Prüfbefehl + interval/timeout/retries/start_period – Grundlage für service_healthy. |
| networks | Eigene Netze; ohne Angabe landet jeder Service im Netz <projekt>_default. |
| volumes | Benannte Volumes (oben deklariert) und Bind-Mounts (./pfad:/ziel). |
| restart | no · always · on-failure[:n] · unless-stopped |
| profiles | Service startet nur, wenn das Profil aktiv ist (--profile oder COMPOSE_PROFILES). |
| ${VAR:-std} | Variablen aus Umgebung und .env – mit Standardwert. |