diff --git a/README.md b/README.md index 1a68fc4..e8d6f5c 100644 --- a/README.md +++ b/README.md @@ -44,43 +44,12 @@ Die Werte gehören **in die Stack-Variablen**, nicht in eine Datei im Repo. ### Wie der Reverse Proxy die Dienste erreicht -`docker-compose.yml` allein ist von außen **nicht erreichbar** — das ist -Absicht. Wie der Proxy die Dienste findet, hängt am Aufbau, also wählst du eine -Ergänzung dazu. In Portainer beide Pfade unter *Compose path*, mit Komma: - -**A · Der Proxy hängt im selben Docker-Netz** — der sauberere Weg, kein Port -muss offen sein. +Über den **Host**, und das steht fertig in `docker-compose.yml`. Genauso laufen +`d4rkbot` auf 3080 und `cdn-files` auf 8090 schon. ``` -docker-compose.yml,docker-compose.proxynet.yml -``` - -Dazu `PROXY_NETWORK` auf den Namen des Netzes setzen, in dem der Proxy hängt. -Welches das ist, zeigt Portainer unter *Networks* oder: - -```bash -docker network ls -docker network inspect # zeigt die Mitglieder -``` - -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** — *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:9100 - -> http://host.docker.internal:9101 +fivecdn.d4rkst3r.de -> http://host.docker.internal:9100 +fivemanage.d4rkst3r.de -> http://host.docker.internal:9101 ``` **Nicht 9000 und 8080** — die sind auf diesem Server vergeben (Portainer und @@ -88,6 +57,27 @@ 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 **alle** Adressen gebunden, nicht an `127.0.0.1`. Das ist +kein Versehen: NPM liegt im Standard-Bridge-Netz (`172.17.0.3`) und kommt über +die Docker-Brücke herein, nicht über Loopback — ein an `127.0.0.1` gebundener +Port nimmt diese Anfrage nicht an. **Zu macht sie die Firewall**, nicht die +Bindung. 9100 und 9101 gehören von außen dicht; öffentlich soll nur NPM auf +80/443 sein. + +#### Wenn der Proxy im selben Docker-Netz hängt + +Dann geht es sauberer, ganz ohne offene Ports — dafür liegt +`docker-compose.proxynet.yml` bereit. **Portainer nimmt unter *Compose path* +aber nur eine Datei**; eine Ergänzung wird dort stillschweigend ignoriert. Wer +diesen Weg will, führt die beiden Dateien zusammen oder startet den Stack von +Hand: + +```bash +docker compose -f docker-compose.yml -f docker-compose.proxynet.yml up -d +``` + +Auf **diesem** Server trifft das nicht zu. + Die Ports sind an **alle Adressen** gebunden, weil `host.docker.internal` auf diesem Server über die Docker-Brücke kommt und ein `127.0.0.1`-Port die Anfrage nicht annähme — dieselbe Bindung, mit der `d4rkbot` und `cdn-files` diff --git a/docker-compose.hostports.yml b/docker-compose.hostports.yml deleted file mode 100644 index d0a84ba..0000000 --- a/docker-compose.hostports.yml +++ /dev/null @@ -1,59 +0,0 @@ -# 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:` — -# 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) -# -> 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" diff --git a/docker-compose.proxynet.yml b/docker-compose.proxynet.yml index da801fa..56a51ba 100644 --- a/docker-compose.proxynet.yml +++ b/docker-compose.proxynet.yml @@ -5,8 +5,9 @@ # # docker compose -f docker-compose.yml -f docker-compose.proxynet.yml up -d # -# In Portainer unter "Compose path", durch Komma getrennt: -# docker-compose.yml,docker-compose.proxynet.yml +# NICHT ueber Portainer aus dem Repo: dort nimmt "Compose path" nur EINE +# Datei, und eine Ergaenzung wird stillschweigend ignoriert. Wer diesen Weg +# will, fuehrt die beiden Dateien zusammen oder startet von Hand. # # VORAUSSETZUNG: das Netz muss es schon geben, und der Proxy muss darin # haengen. Nachsehen: @@ -15,8 +16,9 @@ # docker network inspect zeigt die Mitglieder # # Haengt der Proxy nirgends mit drin, ist das hier der falsche Weg — dann -# docker-compose.hostports.yml nehmen. Ein Netz anzulegen, in dem nur diese -# Container sitzen, bringt nichts: der Proxy muesste mit hinein. +# bleibt es bei den Host-Ports aus docker-compose.yml, die dann auch offen +# bleiben duerfen. Ein Netz anzulegen, in dem nur diese Container sitzen, +# bringt nichts: der Proxy muesste mit hinein. # # Danach in NPM: # fivecdn.d4rkst3r.de -> http://minio:9000 diff --git a/docker-compose.yml b/docker-compose.yml index 7d7da2b..09f1828 100644 --- a/docker-compose.yml +++ b/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: