Caddy in optionales Profil, damit belegte Ports 80/443 nicht blockieren

Auf dem Zielserver haelt bereits ein anderer Dienst Port 443, der Start des
Caddy-Containers scheiterte deshalb mit "port is already allocated". Zwei
Prozesse koennen sich einen Port nicht teilen.

- caddy laeuft nur noch mit "--profile edge"
- web veroeffentlicht 127.0.0.1:4321, damit ein vorhandener Reverse-Proxy
  darauf zugreifen kann, ohne dass der Port oeffentlich erreichbar wird
- README beschreibt beide Varianten inklusive vhost-Beispielen und dem
  Hinweis, dass Security-Header und IP-Maskierung dann im vorhandenen
  Proxy nachgezogen werden muessen

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -138,9 +138,68 @@ meldet, ist normal und kein Fehler.
 ```bash
 git clone git@github-djnizz:nizzgruber/djnizz_website.git
 cd djnizz_website
+```
+
+Jetzt kommt es darauf an, ob auf dem Server **schon** etwas auf Port 80/443 hört
+(z. B. ein Vault-Container oder ein vorhandener nginx). Prüfen mit:
+
+```bash
+sudo ss -tulpn | grep -E ':(80|443)\s'
+```
+
+**Variante A – Ports sind frei:** Caddy dieses Projekts übernimmt sie.
+
+```bash
+docker compose --profile edge up -d --build
+```
+
+**Variante B – Ports sind belegt:** Zwei Prozesse können sich einen Port nicht
+teilen. Dann läuft nur der Web-Container, gebunden an `127.0.0.1:4321`, und der
+bereits vorhandene Reverse-Proxy leitet dorthin weiter.
+
+```bash
 docker compose up -d --build
 ```
 
+Passender vhost, wenn der vorhandene Proxy **Caddy auf dem Host** ist:
+
+```caddy
+djnizz.at {
+	encode zstd gzip
+	reverse_proxy 127.0.0.1:4321
+}
+```
+
+Wenn es **nginx** ist:
+
+```nginx
+server {
+    server_name djnizz.at;
+    location / {
+        proxy_pass http://127.0.0.1:4321;
+        proxy_set_header Host $host;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header X-Forwarded-Proto $scheme;
+    }
+}
+```
+
+Zertifikat danach mit `sudo certbot --nginx -d djnizz.at`.
+
+Läuft der vorhandene Proxy selbst **in einem Container**, ist es sauberer, ihn
+ins Netz dieses Projekts zu hängen statt über Loopback zu gehen – dann kann er
+direkt `web:4321` ansprechen:
+
+```bash
+docker network connect djnizz_website_djnizz <name-des-proxy-containers>
+```
+
+> In Variante B sind die Security-Header, das `immutable`-Caching und die
+> IP-Maskierung aus dem [`Caddyfile`](Caddyfile) **nicht** aktiv – die stecken in
+> der Caddy-Konfiguration dieses Projekts. Übernimm die entsprechenden Blöcke in
+> die Konfiguration deines vorhandenen Proxys, sonst stimmt auch die Aussage in
+> der Datenschutzerklärung zu gekürzten IP-Adressen nicht mehr.
+
 Caddy holt sich das Let's-Encrypt-Zertifikat automatisch, sobald die Domain auf
 den Server zeigt. Fortschritt prüfen:
 

docker-compose.yml

@@ -4,16 +4,22 @@ services:
     image: djnizz-website:latest
     container_name: djnizz-web
     restart: unless-stopped
-    # Kein ports-Mapping: der Node-Prozess ist nur im internen Netz
+    # Nur auf Loopback veroeffentlicht: aus dem Internet nicht erreichbar,
-    # erreichbar, nach aussen geht ausschliesslich Caddy.
+    # aber ein bereits vorhandener Reverse-Proxy auf dem Host kann darauf
-    expose:
+    # zugreifen. Mit eigenem Caddy (Profil "edge") laeuft der Verkehr
-      - '4321'
+    # stattdessen ueber das interne Docker-Netz.
+    ports:
+      - '${WEB_BIND:-127.0.0.1:4321}:4321'
     networks:
       - djnizz
     security_opt:
       - no-new-privileges:true
 
   caddy:
+    # Startet nur mit: docker compose --profile edge up -d
+    # Weglassen, wenn auf dem Server bereits ein Reverse-Proxy die Ports
+    # 80/443 belegt - zwei Prozesse koennen sich einen Port nicht teilen.
+    profiles: ['edge']
     image: caddy:2-alpine
     container_name: djnizz-caddy
     restart: unless-stopped