name: omsorg

# Zieht fertig gebaute Images aus der Gitea-Registry (siehe .gitea/workflows/docker-build.yml),
# baut hier bewusst NICHT lokal - die Dockerfiles in omsorgCore/, omsorgapp/, omsorgWeb/ sind
# weiterhin da, werden aber nur noch von der CI verwendet. Vor `docker compose pull`/`up` einmal
# `docker login git.omsorg-pflegedienste.de` auf dem Server ausführen, falls die Images/Packages
# nicht öffentlich lesbar sind. Über OMSORG_IMAGE_TAG lässt sich ein bestimmter Versions-Tag
# pinnen (z.B. `OMSORG_IMAGE_TAG=v0.1.0 docker compose up -d`), Default ist `latest`.
#
# omsorgCore bekommt eine eigene Subdomain (core.omsorg-pflegedienste.de), nicht denselben
# Hostnamen wie omsorgapp - Begründung: omsorgWeb (beide mitarbeiter-app*-Apps) braucht ohnehin nie
# Browser-Zugriff auf omsorgCore (PHP ruft serverseitig per cURL auf, siehe
# omsorgWeb/docker/bootstrap-config.php/OMSORG_CORE_URL unten), nur omsorgapp tut das - eine eigene
# Subdomain macht die API trotzdem unabhängig von omsorgapps Hosting adressierbar (künftige
# Clients, Doku, Swagger) und ist nicht unsicherer als Pfad-basiertes Proxying: in beiden Fällen
# ist omsorgCore nur über 127.0.0.1 erreichbar (Port-Mapping unten), nie direkt öffentlich.
# Browser-seitiges Cross-Origin läuft über CORS + HttpOnly-Cookie mit credentials:"include" (siehe
# omsorgCore/CLAUDE.md, Abschnitt "Auth-Flow") - dafür muss Cors__AllowedOrigins__0 unten exakt
# der Origin von omsorgapp entsprechen (https://app.omsorg-pflegedienste.de).
#
# Nginx-Server-Block für die neue Subdomain (analog zum bestehenden app.omsorg-pflegedienste.de-
# Block, eigenes Zertifikat z.B. per `certbot --nginx -d core.omsorg-pflegedienste.de`):
#
#   server {
#       server_name core.omsorg-pflegedienste.de;
#       location / {
#           proxy_pass http://127.0.0.1:8080;
#           proxy_http_version 1.1;
#           proxy_set_header Host $host;
#           proxy_set_header X-Real-IP $remote_addr;
#           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#           proxy_set_header X-Forwarded-Proto $scheme;
#       }
#       listen 443 ssl; # managed by Certbot
#       ssl_certificate /etc/letsencrypt/live/core.omsorg-pflegedienste.de/fullchain.pem;
#       ssl_certificate_key /etc/letsencrypt/live/core.omsorg-pflegedienste.de/privkey.pem;
#       include /etc/letsencrypt/options-ssl-nginx.conf;
#       ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
#   }
#
# Alle persistenten Daten liegen bewusst als Bind-Mounts unter /root/data/ auf der Platte (keine
# benannten Docker-Volumes) - vor dem ersten `docker compose up` einmalig anlegen:
#   mkdir -p /root/data/postgres /root/data/omsorgcore/documents \
#     /root/data/omsorgweb/{uploads,downloads,fortbildung-materials,avatars,data}
# Postgres läuft im Container als uid 999 (nicht root) - /root/data/postgres muss dieser uid
# gehören, sonst schlägt der Start mit einem Permission-Fehler fehl:
#   chown -R 999:999 /root/data/postgres
#
# mitarbeiter-app-legacy (Teil des omsorgweb-Images) ist Legacy-Code und braucht eigentlich MySQL -
# bewusst kein MySQL-Dienst mehr hier, die Legacy-App bleibt dadurch ohne DB-Anbindung (siehe
# omsorgWeb/CLAUDE.md - mitarbeiter-app-legacy wird nicht mehr weiterentwickelt).

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: omsorg_core
      POSTGRES_USER: omsorg_core
      POSTGRES_PASSWORD: omsorg_core_dev_password
    volumes:
      - /root/data/postgres:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U omsorg_core"]
      interval: 5s
      timeout: 5s
      retries: 10

  omsorgcore:
    image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgcore:${OMSORG_IMAGE_TAG:-latest}
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      ASPNETCORE_ENVIRONMENT: Development
      ConnectionStrings__OmsorgCore: "Host=postgres;Port=5432;Database=omsorg_core;Username=omsorg_core;Password=omsorg_core_dev_password"
      Jwt__Secret: "CHANGE_ME_LOCAL_DEV_SECRET_MIN_32_CHARS_LONG"
      Cors__AllowedOrigins__0: "https://app.omsorg-pflegedienste.de"
    ports:
      # Nur auf dem Host erreichbar (für den Reverse-Proxy oben), nie auf der öffentlichen
      # Schnittstelle - matcht das 127.0.0.1:5173-Muster im bestehenden Host-nginx.
      - "127.0.0.1:8080:8080"
    volumes:
      - /root/data/omsorgcore/documents:/app/App_Data/documents

  omsorgapp:
    image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgapp:${OMSORG_IMAGE_TAG:-latest}
    environment:
      # Vom BROWSER erreichbare Adresse von omsorgCore - der Container-Entrypoint schreibt das
      # zur Laufzeit in env-config.js (siehe omsorgapp/docker-entrypoint.sh/src/api/config.js),
      # kein Rebuild bei einer geänderten Backend-URL nötig.
      OMSORG_CORE_URL: "https://core.omsorg-pflegedienste.de"
    ports:
      # Nur auf dem Host, wie omsorgcore oben - der Host-nginx proxied bereits 127.0.0.1:5173.
      - "127.0.0.1:5173:80"
    depends_on:
      - omsorgcore

  omsorgweb:
    image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgweb:${OMSORG_IMAGE_TAG:-latest}
    depends_on:
      omsorgcore:
        condition: service_started
    environment:
      OMSORG_CORE_URL: "http://omsorgcore:8080"
    ports:
      - "8081:80"
    volumes:
      - /root/data/omsorgweb/uploads:/var/www/html/mitarbeiter-app-legacy/uploads
      - /root/data/omsorgweb/downloads:/var/www/html/mitarbeiter-app-legacy/downloads
      - /root/data/omsorgweb/fortbildung-materials:/var/www/html/mitarbeiter-app-legacy/fortbildung-materials
      - /root/data/omsorgweb/avatars:/var/www/html/mitarbeiter-app-legacy/assets/avatars
      - /root/data/omsorgweb/data:/var/www/html/mitarbeiter-app-legacy/data