Ergaenzung fuer einen Reverse Proxy ausserhalb des Docker-Netzes

Die Compose war fuer den sauberen Weg gebaut: NPM im selben Netz, kein Port
offen. Auf diesem Server laeuft NPM aber anders — Bot und Hub haengen dort an
`http://host.docker.internal:3080`, also ueber den Host. So wie sie war, haette
NPM `minio` gar nicht gefunden.

docker-compose.hostports.yml legt deshalb die beiden noetigen Ports offen, und
zwar an 127.0.0.1 gebunden: damit ist der Port vom Internet aus zu, und nur der
Host kommt heran.

Mit einem Vorbehalt, der in der Datei steht: ob `host.docker.internal` eine
Bindung an 127.0.0.1 ueberhaupt erreicht, haengt an der Docker-Fassung. Unter
Linux fuehrt der Weg ueber die Docker-Bruecke statt ueber Loopback, dann muss
die Bindung 0.0.0.0 lauten und die Firewall den Port zumachen. Klappt es nicht,
ist die Bindung nicht der Fehler, sondern der Weg.

Sauberer bleibt Weg A — NPM ins Netz `proxy` haengen. Dann braucht es diese
Datei gar nicht.

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

README.md

@@ -42,10 +42,37 @@ Portainer kann einen Stack direkt aus diesem Repo ziehen:
 Die Werte gehören **in die Stack-Variablen**, nicht in eine Datei im Repo.
 `.env` steht deshalb in `.gitignore`.
 
-Davor brauchst du auf dem Reverse Proxy, der schon `cdn.d4rkst3r.de` bedient:
+### Wie der Reverse Proxy die Dienste erreicht
 
-- `fivecdn.d4rkst3r.de` → `minio:9000` (die Dateien)
+Zwei Wege, und welcher gilt, hängt daran, wie dein NPM aufgesetzt ist.
-- eine zweite Adresse → `lite:8080` (die Oberfläche), oder gar nicht öffentlich
+
+**A · NPM hängt im selben Docker-Netz** — der saubere Weg. Kein Port muss
+offen sein.
+
+```
+fivecdn.d4rkst3r.de  ->  http://minio:9000
+<oberfläche>         ->  http://lite:8080
+```
+
+Dafür muss NPM im Netz aus `PROXY_NETWORK` hängen. `docker network ls` zeigt
+die Namen, `docker network inspect <name>` die Mitglieder.
+
+**B · NPM erreicht die Dienste über den Host** — so laufen Bot und Hub hier
+schon, mit `http://host.docker.internal:3080`. Dann braucht es offene Ports,
+und dafür gibt es die Ergänzung:
+
+```
+Compose path:  docker-compose.yml,docker-compose.hostports.yml
+```
+
+```
+fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9000
+<oberfläche>         ->  http://host.docker.internal:8080
+```
+
+Die Ports sind an `127.0.0.1` gebunden, also vom Internet aus zu. Ob
+`host.docker.internal` das erreicht, hängt an der Docker-Fassung — steht in
+`docker-compose.hostports.yml` erklärt.
 
 ---
 

docker-compose.hostports.yml

@@ -0,0 +1,39 @@
+# Ergaenzung fuer einen Reverse Proxy, der NICHT im selben Docker-Netz haengt.
+#
+# Der Nginx Proxy Manager auf diesem Server erreicht seine Ziele ueber
+# `host.docker.internal:<port>` — so laufen dort schon Bot und Hub. Dieses
+# Muster braucht offene Ports auf dem Host, denn ueber den Host geht der Weg.
+#
+# Zusammen benutzen:
+#
+#   docker compose -f docker-compose.yml -f docker-compose.hostports.yml up -d
+#
+# In Portainer: unter "Compose path" beide Dateien angeben, durch Komma
+# getrennt.
+#
+# Danach in NPM:
+#
+#   fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9000   (die Dateien)
+#   <oberflaeche>        ->  http://host.docker.internal:8080   (Lite)
+#
+# GEBUNDEN AN 127.0.0.1, nicht an alle Adressen. Damit ist der Port vom
+# Internet aus zu, und nur der Host — und damit NPM — kommt heran.
+#
+# Ein Vorbehalt dazu: ob `host.docker.internal` eine Bindung an 127.0.0.1
+# erreicht, haengt an der Docker-Fassung. Unter Linux braucht der
+# NPM-Container dafuer `extra_hosts: ["host.docker.internal:host-gateway"]`,
+# und der Weg fuehrt dann ueber die Docker-Bruecke statt ueber Loopback — dann
+# muss die Bindung `0.0.0.0` lauten und die FIREWALL den Port zumachen.
+#
+# Kurz: klappt es mit 127.0.0.1 nicht, ist die Bindung nicht der Fehler,
+# sondern der Weg. Sauberer waere es ohnehin, NPM ins Netz `proxy` zu haengen
+# — dann braucht es diese Datei gar nicht und keinen offenen Port.
+
+services:
+  minio:
+    ports:
+      - "127.0.0.1:9000:9000"
+
+  lite:
+    ports:
+      - "127.0.0.1:8080:8080"