From d0f173d67d3d897270cf0d61c5f9f70668ee039a Mon Sep 17 00:00:00 2001 From: D4rkst3r Date: Tue, 11 Aug 2026 14:34:32 +0200 Subject: [PATCH] fix: freie Host-Ports, und der Weg ist jetzt belegt statt vermutet MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- README.md | 18 +++++++++------ docker-compose.hostports.yml | 44 +++++++++++++++++++++--------------- 2 files changed, 37 insertions(+), 25 deletions(-) diff --git a/README.md b/README.md index c84b95c..66a6049 100644 --- a/README.md +++ b/README.md @@ -63,27 +63,31 @@ docker network ls docker network inspect # zeigt die Mitglieder ``` -Auf diesem Server heißt es aller Wahrscheinlichkeit nach **`web`** — ein -Bridge-Netz ohne Stack. Nachsehen lohnt trotzdem: steht der Proxy nicht drin, -ist es der falsche Weg. +Auf **diesem** Server ist es nicht so: der NPM-Container hat `172.17.0.3` und +liegt damit im Standard-Bridge-Netz, nicht in `web`. Hier gilt Weg B. ``` fivecdn.d4rkst3r.de -> http://minio:9000 -> http://lite:8080 ``` -**B · Der Proxy erreicht die Dienste über den Host** — so laufen Bot und Hub -hier schon, mit `http://host.docker.internal:3080`. +**B · Der Proxy erreicht die Dienste über den Host** — *das ist hier der Fall.* +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 - -> http://host.docker.internal:8080 +fivecdn.d4rkst3r.de -> http://host.docker.internal:9100 + -> 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. diff --git a/docker-compose.hostports.yml b/docker-compose.hostports.yml index 4831463..3eeb29e 100644 --- a/docker-compose.hostports.yml +++ b/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 -# `host.docker.internal:` — so laufen dort schon Bot und Hub. Dieses -# Muster braucht offene Ports auf dem Host, denn ueber den Host geht der Weg. +# Der Nginx Proxy Manager auf diesem Server liegt im Standard-Bridge-Netz +# (172.17.0.3) und erreicht seine Ziele ueber `host.docker.internal:` — +# 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 -# getrennt. +# In Portainer unter "Compose path", durch Komma getrennt: +# docker-compose.yml,docker-compose.hostports.yml # # Danach in NPM: # -# fivecdn.d4rkst3r.de -> http://host.docker.internal:9000 (die Dateien) -# -> http://host.docker.internal:8080 (Lite) +# fivecdn.d4rkst3r.de -> http://host.docker.internal:9100 (die Dateien) +# -> 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 -# 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. +# Ein Vorbehalt: ob `host.docker.internal` eine Bindung an 127.0.0.1 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. Bei d4rkbot auf 3080 funktioniert es — wie es +# dort gebunden ist, sagt `docker port d4rkbot`. 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"