adminandClaude Sonnet 5
19f7be3575
Frontend laeuft jetzt ueber einen echten mehrstufigen next-build-Produktions- Build (output: standalone) statt next dev/Turbopack - vermutete Ursache fuer haengenbleibendes "Laedt..." unter iOS Safari (HMR-Websocket im Hintergrund). Ausserdem name-/autoComplete-Attribute auf praktisch allen Formularfeldern der eingeloggten App nachgeruestet: ohne diese Attribute trug iOS Safaris Autofill Werte teils direkt ins DOM ein, ohne das Event auszuloesen, auf das Reacts kontrollierte Inputs lauschen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
79 lines
3.0 KiB
YAML
79 lines
3.0 KiB
YAML
services:
|
|
db:
|
|
image: postgres:16
|
|
environment:
|
|
POSTGRES_USER: ${POSTGRES_USER}
|
|
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
|
|
POSTGRES_DB: ${POSTGRES_DB}
|
|
ports:
|
|
- "${POSTGRES_PORT:-5532}:5432"
|
|
volumes:
|
|
- pflegepilot_v3_db:/var/lib/postgresql/data
|
|
healthcheck:
|
|
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
|
|
interval: 5s
|
|
timeout: 5s
|
|
retries: 10
|
|
|
|
api:
|
|
build: ./backend
|
|
environment:
|
|
DATABASE_URL: ${DATABASE_URL}
|
|
SECRET_KEY: ${SECRET_KEY}
|
|
WEB_ORIGIN: ${WEB_ORIGIN}
|
|
SMTP_HOST: ${SMTP_HOST:-}
|
|
SMTP_PORT: ${SMTP_PORT:-587}
|
|
SMTP_USER: ${SMTP_USER:-}
|
|
SMTP_PASSWORD: ${SMTP_PASSWORD:-}
|
|
SMTP_FROM: ${SMTP_FROM:-MeinPflegeFuchs <no-reply@meinpflegefuchs.de>}
|
|
SMTP_USE_SSL: ${SMTP_USE_SSL:-false}
|
|
SMTP_USE_TLS: ${SMTP_USE_TLS:-true}
|
|
ports:
|
|
- "${API_PORT:-8100}:5050"
|
|
volumes:
|
|
# Bind-Mounts fuer schnelle Iteration ueber viele Phasen hinweg (kein
|
|
# Image-Rebuild noetig, nur "docker compose restart api" nach Aenderungen
|
|
# an app-Code - neue requirements.txt-Pakete brauchen weiterhin ein Rebuild).
|
|
- ./backend/app:/app/app
|
|
- ./backend/migrations:/app/migrations
|
|
- pflegepilot_v3_uploads:/app/app/uploads
|
|
- pflegepilot_v3_backups:/app/app/backups
|
|
depends_on:
|
|
db:
|
|
condition: service_healthy
|
|
|
|
web:
|
|
build:
|
|
context: ./frontend
|
|
args:
|
|
# NEXT_PUBLIC_*-Variablen werden beim Build ins Client-Bundle
|
|
# eingebacken (siehe Dockerfile) - muessen deshalb als Build-Arg,
|
|
# nicht nur als Laufzeit-"environment:", hereingereicht werden.
|
|
NEXT_PUBLIC_API_URL: ${NEXT_PUBLIC_API_URL}
|
|
NEXT_PUBLIC_SITE_URL: ${NEXT_PUBLIC_SITE_URL:-https://meinpflegefuchs.de}
|
|
environment:
|
|
# Fuer serverseitige (Next.js-Server-Prozess, nicht Browser) Aufrufe an
|
|
# die API, z.B. generateMetadata()/Server Components der Landingpage -
|
|
# der interne Docker-Compose-Servicename+Port, NICHT der oeffentliche/
|
|
# host-gemappte NEXT_PUBLIC_API_URL-Wert (der ist fuer den Browser
|
|
# gedacht und auf der NAS bewusst leer, siehe (marketing)/page.tsx).
|
|
# Als normale Laufzeit-Env-Variable ausreichend, da server-seitiger
|
|
# Code (kein "NEXT_PUBLIC_"-Praefix) zur Laufzeit gelesen wird, nicht
|
|
# beim Build eingebacken.
|
|
API_INTERNAL_URL: ${API_INTERNAL_URL:-http://api:5050}
|
|
ports:
|
|
- "${WEB_PORT:-3100}:3000"
|
|
# Kein Bind-Mount/keine anonymen Volumes mehr (anders als beim
|
|
# next-dev-Setup vorher): das Produktions-Image enthaelt das fertig
|
|
# gebaute, eigenstaendige Server-Bundle - jede Code-Aenderung braucht ab
|
|
# jetzt "docker compose build web" vor dem Sichtbarwerden, ein reiner
|
|
# Neustart des Containers reicht nicht mehr (das ist jetzt so gewollt,
|
|
# nicht mehr die Turbopack-Cache-Falle von vorher).
|
|
depends_on:
|
|
- api
|
|
|
|
volumes:
|
|
pflegepilot_v3_db:
|
|
pflegepilot_v3_uploads:
|
|
pflegepilot_v3_backups:
|