florian.wildeandClaude Opus 5
fc54c73791
CI / pruefen (push) Has been cancelled
Der letzte Anlauf hat das Problem nicht geloest. Die Freigabe stand weiter in der Basisdatei, nur mit anderem Vorgabewert -- und Vorgabewerte greifen nicht, wo die Variable schon gesetzt ist: in jeder .env, die aus der bisherigen .env.example entstanden ist, steht POSTGRES_PORT="5432". Postgres band also unveraendert auf 0.0.0.0 und kollidierte mit anderen Stacks auf demselben Host; der Container kam gar nicht erst hoch. Das Overlay half nicht, weil es erst greift, wenn man es dazunimmt. Jetzt hat der db-Dienst keinen ports-Block mehr. Gebraucht wird er nur, wenn die Anwendung ausserhalb des Containers laeuft, und dafuer gibt es docker-compose.dev.yml (npm run docker:db). Damit ist der sichere Fall die Vorgabe und der Sonderfall die Ausnahme, nicht umgekehrt. Der App-Port bindet aus demselben Grund auf 127.0.0.1: Docker traegt seine Freigaben direkt in iptables ein und umgeht dabei ufw. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
24 lines
1.1 KiB
YAML
24 lines
1.1 KiB
YAML
# ─────────────────────────────────────────────────────────────
|
||
# Overlay fuer die Entwicklung: macht die Datenbank auf dem Host erreichbar.
|
||
#
|
||
# Gebraucht wird das nur, wenn die Anwendung ausserhalb des Containers
|
||
# laeuft – "npm run dev" verbindet sich dann ueber localhost:5432. Im
|
||
# Vollbetrieb spricht die Anwendung "db:5432" im Docker-Netz an und braucht
|
||
# diese Datei nicht.
|
||
#
|
||
# Aufruf:
|
||
# docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d db
|
||
# npm run dev
|
||
#
|
||
# Kuerzer: npm run docker:db
|
||
#
|
||
# Gebunden wird auf 127.0.0.1, nicht auf 0.0.0.0. Docker traegt Freigaben
|
||
# direkt in iptables ein und umgeht dabei ufw – eine offene Bindung stuende
|
||
# also auch bei aktiver Firewall im Netz.
|
||
# ─────────────────────────────────────────────────────────────
|
||
|
||
services:
|
||
db:
|
||
ports:
|
||
- "${POSTGRES_PORT:-127.0.0.1:5432}:5432"
|