fix: Host-Ports in die Grunddatei, hostports.yml entfaellt

Der Stack lief, meldete alle Container gesund — und beide Adressen gaben 502.
Grund: kein einziger Port veroeffentlicht. Die standen in
docker-compose.hostports.yml, und Portainer hat die nicht angewandt.

Das war mein Anleitungsfehler. Ich hatte geschrieben, man koenne unter
"Compose path" zwei Pfade mit Komma angeben. Portainer nimmt dort EINE Datei.
Die Ergaenzung wurde nicht etwa abgelehnt, sondern stillschweigend ignoriert —
die schlechteste Art zu scheitern, weil danach alles gesund aussieht.

Eine Trennung, die man nicht anwenden kann, ist keine. Die Ports stehen jetzt
in docker-compose.yml, wo dieser Server sie ohnehin braucht.

docker-compose.proxynet.yml bleibt als der sauberere Weg fuer einen Proxy im
selben Docker-Netz, jetzt aber mit dem Hinweis, dass er ueber Portainer-aus-
Repo nicht zu haben ist. Hier trifft er nicht zu: NPM liegt auf 172.17.0.3 im
Standard-Bridge-Netz.

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

docker-compose.yml

@@ -12,17 +12,15 @@
 #   das Ablegen von Bildern braucht es sie nicht, und ClickHouse ist eine
 #   schwere Abhaengigkeit. Nachruesten geht spaeter.
 #
-#   Ein Weg nach aussen. Diese Datei allein ist von aussen NICHT erreichbar —
-#   das ist Absicht, denn wie der Reverse Proxy die Dienste findet,
-#   unterscheidet sich je Aufbau. Waehle eine Ergaenzung:
+# Der Weg nach aussen steht HIER DRIN und nicht in einer Ergaenzungsdatei.
+# Zuerst war er ausgelagert, weil sich je Aufbau unterscheidet, wie ein
+# Reverse Proxy seine Ziele findet. In Portainer nimmt "Compose path" aber
+# EINE Datei — die Ergaenzung wurde stillschweigend nicht angewandt, und das
+# Ergebnis war ein Stack, in dem jeder Container gesund meldet und trotzdem
+# alles 502 liefert. Eine Trennung, die man nicht anwenden kann, ist keine.
 #
-#     docker-compose.hostports.yml   Proxy erreicht die Dienste ueber den Host
-#                                    (http://host.docker.internal:9000)
-#     docker-compose.proxynet.yml    Proxy haengt im selben Docker-Netz
-#                                    (http://minio:9000) — der sauberere Weg
-#
-#   In Portainer beide Pfade angeben, durch Komma getrennt:
-#     docker-compose.yml,docker-compose.hostports.yml
+# Wer den Proxy im selben Docker-Netz hat, nimmt docker-compose.proxynet.yml
+# dazu — das ist der sauberere Weg, aber nicht der hier gegangene.
 
 services:
   db:
@@ -54,6 +52,23 @@ services:
     volumes:
       - minio:/data
     networks: [internal]
+    ports:
+      # Die Dateien, fuer den Reverse Proxy ueber den Host:
+      #   fivecdn.d4rkst3r.de -> http://host.docker.internal:9100
+      #
+      # 9100 statt 9000, weil 9000 auf diesem Server an Portainer geht. Im
+      # Container bleibt es 9000; nur die Seite zum Host wandert.
+      #
+      # An alle Adressen gebunden, und das ist kein Versehen: der Nginx Proxy
+      # Manager liegt im Standard-Bridge-Netz und kommt ueber die Docker-
+      # Bruecke herein, nicht ueber Loopback — ein an 127.0.0.1 gebundener
+      # Port nimmt diese Anfrage nicht an. Genauso laufen hier schon d4rkbot
+      # (3080) und cdn-files (8090).
+      #
+      # ZU IST DER PORT DURCH DIE FIREWALL, nicht durch die Bindung. 9100 und
+      # 9101 gehoeren von aussen dicht; oeffentlich soll nur NPM auf 80/443
+      # sein.  ss -tlnp | grep -E '9100|9101'
+      - "${BIND_ADDR:-0.0.0.0}:${MINIO_HOST_PORT:-9100}:9000"
     healthcheck:
       test: ["CMD", "mc", "ready", "local"]
       interval: 10s
@@ -100,6 +115,10 @@ services:
       # Endpunkt plus Bucket, wie in der Vorlage
       # (BUCKET_DOMAIN=http://localhost:9000/lite-dev).
       BUCKET_DOMAIN: ${PUBLIC_URL:?bitte setzen}/media
+    ports:
+      # Die Oberflaeche:  fivemanage.d4rkst3r.de -> http://host.docker.internal:9101
+      # 9101 statt 8080, weil 8080 an nextcloud-aio geht. Siehe minio oben.
+      - "${BIND_ADDR:-0.0.0.0}:${LITE_HOST_PORT:-9101}:8080"
     networks: [internal]
 
 networks: