D4rkst3randClaude Opus 5
c5b66b466a
Ich hatte die Ports an 127.0.0.1 gebunden — enger und auf den ersten Blick richtiger. Nur erreicht host.docker.internal das auf diesem Server nicht: die Anfrage kommt aus dem NPM-Container ueber die Docker-Bruecke herein, nicht ueber Loopback, und ein an 127.0.0.1 gebundener Port nimmt sie nicht an. Der Beleg stand die ganze Zeit in der Containerliste: d4rkbot (3080), cdn-files (8090) und portainer sind alle ohne 127.0.0.1-Praefix veroeffentlicht, und NPM erreicht sie. So laeuft es hier, also laeuft es so. Damit macht die FIREWALL den Port zu und nicht die Bindung — das steht jetzt ausdruecklich in beiden Dateien, mitsamt den Befehlen zum Nachsehen. Wer weiss, dass Loopback bei ihm erreicht wird, setzt BIND_ADDR=127.0.0.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
60 lines
2.4 KiB
YAML
60 lines
2.4 KiB
YAML
# Ergaenzung fuer einen Reverse Proxy, der NICHT im selben Docker-Netz haengt.
|
|
#
|
|
# Der Nginx Proxy Manager auf diesem Server liegt im Standard-Bridge-Netz
|
|
# (172.17.0.3) und erreicht seine Ziele ueber `host.docker.internal:<port>` —
|
|
# 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", durch Komma getrennt:
|
|
# docker-compose.yml,docker-compose.hostports.yml
|
|
#
|
|
# Danach in NPM:
|
|
#
|
|
# fivecdn.d4rkst3r.de -> http://host.docker.internal:9100 (die Dateien)
|
|
# <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 ALLE ADRESSEN, und das ist hier kein Versehen.
|
|
#
|
|
# Zuerst stand hier 127.0.0.1 — enger und auf den ersten Blick richtiger. Nur
|
|
# erreicht `host.docker.internal` das auf diesem Server nicht: die Anfrage
|
|
# kommt aus dem NPM-Container ueber die Docker-Bruecke herein, nicht ueber
|
|
# Loopback, und ein an 127.0.0.1 gebundener Port nimmt sie nicht an.
|
|
#
|
|
# Der Beleg steht in der Containerliste: d4rkbot (3080), cdn-files (8090) und
|
|
# portainer sind alle ohne 127.0.0.1-Praefix veroeffentlicht, und NPM erreicht
|
|
# sie. So laeuft es hier, also laeuft es so.
|
|
#
|
|
# WAS DEN PORT DAMIT ZUMACHT, IST DIE FIREWALL, nicht die Bindung. 9100 und
|
|
# 9101 gehoeren von aussen dicht — oeffentlich erreichbar soll nur NPM auf 80
|
|
# und 443 sein. Pruefen:
|
|
#
|
|
# ufw status bzw. was auf diesem Server zustaendig ist
|
|
# ss -tlnp | grep -E '9100|9101'
|
|
#
|
|
# Wer es enger haben will und weiss, dass Loopback bei ihm erreicht wird:
|
|
# BIND_ADDR=127.0.0.1
|
|
|
|
services:
|
|
minio:
|
|
ports:
|
|
- "${BIND_ADDR:-0.0.0.0}:${MINIO_HOST_PORT:-9100}:9000"
|
|
|
|
lite:
|
|
ports:
|
|
- "${BIND_ADDR:-0.0.0.0}:${LITE_HOST_PORT:-9101}:8080"
|