fix: freie Host-Ports, und der Weg ist jetzt belegt statt vermutet

Die Containerliste des Servers beantwortet beides.

Der NPM-Container hat 172.17.0.3 und liegt damit im Standard-Bridge-Netz,
nicht in "web". Meine Vermutung, "web" sei das Proxy-Netz, war falsch — es
gilt Weg B ueber den Host, so wie d4rkbot auf 3080 und cdn-files auf 8090
schon laufen. Im README steht das jetzt als Feststellung und nicht mehr als
Wahrscheinlichkeit.

Und die Ergaenzung wollte ausgerechnet 9000 und 8080 oeffnen — beide vergeben,
an Portainer und an nextcloud-aio. Jetzt 9100 und 9101, und ueber
MINIO_HOST_PORT und LITE_HOST_PORT einstellbar: die naechste Kollision ist dann
eine Variable und keine Dateiaenderung. Im Container bleibt es bei 9000 und
8080; nur die Seite zum Host wandert.

Belegt waren: 80, 81, 443, 2224, 3000, 3080, 3478, 8000, 8080, 8090, 8443,
9000, 9443, 11000.

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

README.md

@@ -63,27 +63,31 @@ docker network ls
 docker network inspect <name>      # zeigt die Mitglieder
 ```
 
-Auf diesem Server heißt es aller Wahrscheinlichkeit nach **`web`** — ein
+Auf **diesem** Server ist es nicht so: der NPM-Container hat `172.17.0.3` und
-Bridge-Netz ohne Stack. Nachsehen lohnt trotzdem: steht der Proxy nicht drin,
+liegt damit im Standard-Bridge-Netz, nicht in `web`. Hier gilt Weg B.
-ist es der falsche Weg.
 
 ```
 fivecdn.d4rkst3r.de  ->  http://minio:9000
 <oberfläche>         ->  http://lite:8080
 ```
 
-**B · Der Proxy erreicht die Dienste über den Host** — so laufen Bot und Hub
+**B · Der Proxy erreicht die Dienste über den Host** — *das ist hier der Fall.*
-hier schon, mit `http://host.docker.internal:3080`.
+So laufen `d4rkbot` auf 3080 und `cdn-files` auf 8090 schon.
 
 ```
 docker-compose.yml,docker-compose.hostports.yml
 ```
 
 ```
-fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9000
+fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9100
-<oberfläche>         ->  http://host.docker.internal:8080
+<oberfläche>         ->  http://host.docker.internal:9101
 ```
 
+**Nicht 9000 und 8080** — die sind auf diesem Server vergeben (Portainer und
+nextcloud-aio). Im Container bleibt es bei 9000 und 8080; nur die Seite zum
+Host wandert. Kollidiert später noch etwas, sind es zwei Variablen:
+`MINIO_HOST_PORT` und `LITE_HOST_PORT`.
+
 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 — in
 `docker-compose.hostports.yml` steht, was dann zu tun ist.

docker-compose.hostports.yml

@@ -1,39 +1,47 @@
 # Ergaenzung fuer einen Reverse Proxy, der NICHT im selben Docker-Netz haengt.
 #
-# Der Nginx Proxy Manager auf diesem Server erreicht seine Ziele ueber
+# Der Nginx Proxy Manager auf diesem Server liegt im Standard-Bridge-Netz
-# `host.docker.internal:<port>` — so laufen dort schon Bot und Hub. Dieses
+# (172.17.0.3) und erreicht seine Ziele ueber `host.docker.internal:<port>` —
-# Muster braucht offene Ports auf dem Host, denn ueber den Host geht der Weg.
+# so laufen dort schon d4rkbot auf 3080 und cdn-files auf 8090. 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
+# In Portainer unter "Compose path", durch Komma getrennt:
-# getrennt.
+#   docker-compose.yml,docker-compose.hostports.yml
 #
 # Danach in NPM:
 #
-#   fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9000   (die Dateien)
+#   fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9100   (die Dateien)
-#   <oberflaeche>        ->  http://host.docker.internal:8080   (Lite)
+#   <oberflaeche>        ->  http://host.docker.internal:9101   (Lite)
+#
+# WARUM 9100 UND 9101 und nicht die naheliegenden 9000 und 8080: beide sind auf
+# diesem Server vergeben — 9000 an Portainer, 8080 an nextcloud-aio. Im
+# Container bleibt es bei 9000 und 8080; nur die Seite zum Host wandert.
+#
+# Kollidiert spaeter noch etwas, sind es zwei Variablen und keine Dateiaenderung:
+#   MINIO_HOST_PORT   Standard 9100
+#   LITE_HOST_PORT    Standard 9101
+#
+# Belegt waren beim Anlegen: 80, 81, 443, 2224, 3000, 3080, 3478, 8000, 8080,
+# 8090, 8443, 9000, 9443, 11000.
 #
 # 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
+# Ein Vorbehalt: ob `host.docker.internal` eine Bindung an 127.0.0.1 erreicht,
-# erreicht, haengt an der Docker-Fassung. Unter Linux braucht der
+# haengt an der Docker-Fassung. Unter Linux fuehrt der Weg ueber die
-# NPM-Container dafuer `extra_hosts: ["host.docker.internal:host-gateway"]`,
+# Docker-Bruecke statt ueber Loopback; dann muss die Bindung 0.0.0.0 lauten und
-# und der Weg fuehrt dann ueber die Docker-Bruecke statt ueber Loopback — dann
+# die FIREWALL den Port zumachen. Bei d4rkbot auf 3080 funktioniert es — wie es
-# muss die Bindung `0.0.0.0` lauten und die FIREWALL den Port zumachen.
+# dort gebunden ist, sagt `docker port d4rkbot`.
-#
-# 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"
+      - "127.0.0.1:${MINIO_HOST_PORT:-9100}:9000"
 
   lite:
     ports:
-      - "127.0.0.1:8080:8080"
+      - "127.0.0.1:${LITE_HOST_PORT:-9101}:8080"