1 Commits
Author SHA1 Message Date
Felix KemmlerandClaude Sonnet 5 dcc8ea1510 Make omsorgapp's backend URL runtime-configurable, use dedicated API subdomain
Docker-Images bauen und veröffentlichen / build (, omsorgCore/Dockerfile, omsorgcore) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgWeb/Dockerfile, omsorgweb) (push) Successful in 3s
Docker-Images bauen und veröffentlichen / build (, omsorgapp/Dockerfile, omsorgapp) (push) Successful in 3s
- omsorgapp now reads the omsorgCore URL from a runtime env-config.js
  generated by the container entrypoint from OMSORG_CORE_URL, instead of
  only baking it in at image build time - docker-compose.yml pulls
  pre-built images from the registry, so a build-time-only value couldn't
  be changed without a rebuild.
- docker-compose.yml: omsorgCore gets its own subdomain
  (core.omsorg-pflegedienste.de) rather than being proxied under the
  frontend's domain - omsorgWeb never needs browser-side access to it
  anyway (server-side cURL only), and a dedicated API host is more
  future-proof without being any less secure (backend still only bound to
  127.0.0.1). Includes the nginx server-block snippet needed for the new
  subdomain.
- Drop the now-unused OMSORG_CORE_PUBLIC_URL build-arg wiring from the
  Gitea Actions workflow.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-10 18:14:32 +02:00
7 changed files with 72 additions and 16 deletions
+1 -1
View File
@@ -20,7 +20,7 @@ jobs:
build_args: "" build_args: ""
- image: omsorgapp - image: omsorgapp
dockerfile: omsorgapp/Dockerfile dockerfile: omsorgapp/Dockerfile
build_args: "VITE_OMSORG_CORE_URL=${{ vars.OMSORG_CORE_PUBLIC_URL }}" build_args: ""
- image: omsorgweb - image: omsorgweb
dockerfile: omsorgWeb/Dockerfile dockerfile: omsorgWeb/Dockerfile
build_args: "" build_args: ""
+41 -8
View File
@@ -7,11 +7,36 @@ name: omsorg
# nicht öffentlich lesbar sind. Über OMSORG_IMAGE_TAG lässt sich ein bestimmter Versions-Tag # 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`. # pinnen (z.B. `OMSORG_IMAGE_TAG=v0.1.0 docker compose up -d`), Default ist `latest`.
# #
# WICHTIG: omsorgapp bäckt die omsorgCore-URL (VITE_OMSORG_CORE_URL) zur BUILD-Zeit in den # omsorgCore bekommt eine eigene Subdomain (core.omsorg-pflegedienste.de), nicht denselben
# JS-Bundle ein (siehe omsorgapp/src/api/config.js) - das passiert jetzt in der CI über die # Hostnamen wie omsorgapp - Begründung: omsorgWeb (beide mitarbeiter-app*-Apps) braucht ohnehin nie
# Repo-Variable OMSORG_CORE_PUBLIC_URL, nicht mehr hier. omsorgweb.environment.OMSORG_CORE_URL # Browser-Zugriff auf omsorgCore (PHP ruft serverseitig per cURL auf, siehe
# ist davon unabhängig und bleibt der interne Compose-Servicename, da PHP dort serverseitig per # omsorgWeb/docker/bootstrap-config.php/OMSORG_CORE_URL unten), nur omsorgapp tut das - eine eigene
# cURL aufruft (kein Browser-Kontext), siehe omsorgWeb/docker/bootstrap-config.php. # 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 # 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: # benannten Docker-Volumes) - vor dem ersten `docker compose up` einmalig anlegen:
@@ -49,16 +74,24 @@ services:
ASPNETCORE_ENVIRONMENT: Development ASPNETCORE_ENVIRONMENT: Development
ConnectionStrings__OmsorgCore: "Host=postgres;Port=5432;Database=omsorg_core;Username=omsorg_core;Password=omsorg_core_dev_password" 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" Jwt__Secret: "CHANGE_ME_LOCAL_DEV_SECRET_MIN_32_CHARS_LONG"
Cors__AllowedOrigins__0: "http://localhost:5173" Cors__AllowedOrigins__0: "https://app.omsorg-pflegedienste.de"
ports: ports:
- "8080:8080" # 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: volumes:
- /root/data/omsorgcore/documents:/app/App_Data/documents - /root/data/omsorgcore/documents:/app/App_Data/documents
omsorgapp: omsorgapp:
image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgapp:${OMSORG_IMAGE_TAG:-latest} 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: ports:
- "5173:80" # 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: depends_on:
- omsorgcore - omsorgcore
+7 -3
View File
@@ -13,9 +13,10 @@ RUN npm ci
COPY omsorgapp/ . COPY omsorgapp/ .
# Vite bäckt import.meta.env.VITE_OMSORG_CORE_URL (src/api/config.js) zur Build-Zeit ein - kein # Fallback für lokale/CI-Builds ohne Container (npm run dev/build) - im Container selbst
# Runtime-Wert. Default passt zum docker-compose.yml-Setup, für einen echten Deploy überschreibt # entscheidet ausschließlich die Laufzeit-Env-Var OMSORG_CORE_URL (siehe docker-entrypoint.sh),
# CI das per --build-arg mit der öffentlich erreichbaren omsorgCore-URL. # da dieses Image aus der Registry gezogen und per docker-compose.yml konfiguriert wird, nicht
# pro Zielumgebung neu gebaut (siehe src/api/config.js).
ARG VITE_OMSORG_CORE_URL=http://localhost:8080 ARG VITE_OMSORG_CORE_URL=http://localhost:8080
ENV VITE_OMSORG_CORE_URL=$VITE_OMSORG_CORE_URL ENV VITE_OMSORG_CORE_URL=$VITE_OMSORG_CORE_URL
RUN npm run build RUN npm run build
@@ -23,4 +24,7 @@ RUN npm run build
FROM nginx:1.27-alpine AS runtime FROM nginx:1.27-alpine AS runtime
COPY --from=build /app/dist /usr/share/nginx/html COPY --from=build /app/dist /usr/share/nginx/html
COPY omsorgapp/nginx.conf /etc/nginx/conf.d/default.conf COPY omsorgapp/nginx.conf /etc/nginx/conf.d/default.conf
COPY omsorgapp/docker-entrypoint.sh /docker-entrypoint.sh
RUN chmod +x /docker-entrypoint.sh
EXPOSE 80 EXPOSE 80
ENTRYPOINT ["/docker-entrypoint.sh"]
+11
View File
@@ -0,0 +1,11 @@
#!/bin/sh
set -eu
# Schreibt die Laufzeit-Backend-Adresse in env-config.js, bevor nginx startet - siehe
# src/api/config.js. OMSORG_CORE_URL kommt aus docker-compose.yml, muss vom BROWSER erreichbar
# sein (nicht der interne Compose-Servicename), z.B. https://core.omsorg-pflegedienste.de.
cat > /usr/share/nginx/html/env-config.js <<EOF
window.__OMSORG_ENV__ = { OMSORG_CORE_URL: "${OMSORG_CORE_URL:-}" };
EOF
exec nginx -g "daemon off;"
+1 -1
View File
@@ -1 +1 @@
<!doctype html><html lang="de"><head><meta charset="UTF-8"/><meta name="viewport" content="width=device-width, initial-scale=1.0"/><title>Omsorg Business Controls Pro</title></head><body><div id="root"></div><script type="module" src="/src/main.jsx"></script></body></html> <!doctype html><html lang="de"><head><meta charset="UTF-8"/><meta name="viewport" content="width=device-width, initial-scale=1.0"/><title>Omsorg Business Controls Pro</title></head><body><div id="root"></div><script src="/env-config.js"></script><script type="module" src="/src/main.jsx"></script></body></html>
+4
View File
@@ -0,0 +1,4 @@
// Dev-Default (Vite serviert alles unter public/ unverändert unter /) - im Docker-Image wird
// diese Datei vom Entrypoint (docker-entrypoint.sh) aus der OMSORG_CORE_URL-Env-Var überschrieben,
// siehe src/api/config.js.
window.__OMSORG_ENV__ = {};
+7 -3
View File
@@ -1,4 +1,8 @@
// Einzige Stelle im Projekt, die die Adresse von omsorgCore kennt. // Einzige Stelle im Projekt, die die Adresse von omsorgCore kennt.
// Default passt zum lokalen `dotnet run --project src/OmsorgCore.Api` (http-Profil, Port 5245), // Reihenfolge: 1) Laufzeit-Konfiguration (window.__OMSORG_ENV__, aus env-config.js - vom
// überschreibbar per Vite-Env-Variable (VITE_OMSORG_CORE_URL) für andere Umgebungen. // nginx-Entrypoint im Container aus der OMSORG_CORE_URL-Env-Var generiert, siehe
export const API_BASE = import.meta.env.VITE_OMSORG_CORE_URL || "http://localhost:5245"; // omsorgapp/docker-entrypoint.sh) - so lässt sich die Backend-Adresse rein über
// docker-compose.yml setzen, ohne das Image neu zu bauen. 2) Vite-Build-Zeit-Env
// (VITE_OMSORG_CORE_URL, für `npm run dev`/lokale Builds ohne Container). 3) localhost-Default.
export const API_BASE =
window.__OMSORG_ENV__?.OMSORG_CORE_URL || import.meta.env.VITE_OMSORG_CORE_URL || "http://localhost:5245";