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>
This commit is contained in:
Claude Opus 5
@@ -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 <name> # 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
|
||||
<oberfläche> -> 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
|
||||
<oberfläche> -> 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`
|
||||
|
||||
@@ -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:<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"
|
||||
@@ -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 <name> 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
|
||||
|
||||
+29
-10
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user