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>
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>
D4rkst3randClaude Opus 5