Verständnisproblem Docker Networks / NGINX Proxy Manager & andere Container des selben Docker Hosts

[dtm3000]

Liebe Leute,

als Docker Anfänger wende ich mich hoffnungsvoll an Euch. Im Großen und Ganzen komm ich bisher ganz gut zurecht. An einer Stelle komm ich aber partout nicht weiter. Vielleicht seid Ihr ja so nett und gebt mir einen Tipp.

Auf einer Proxmox VE habe ich bisher NGINX Proxy Manager auf einer eigenen VM (Debian Server) als Docker Container laufen. Alle Instanzen, die darüber aufgerufen werden, laufen als Docker Container auf einer zweiten VM mit derselben Struktur und haben dementsprechend eine andere IP-Adresse. Es gibt auch noch andere VM ohne Docker und mehrere LXC. Das Setup funktioniert einwandfrei.

Ich hab mir jetzt in den Kopf gesetzt, den NPM auf denselben Docker Host zu bringen, wie die restlichen Container. Sodass nur der NPM von außen erreichbar ist und die restlichen Container nicht mehr über den Host erreichbar sind, sondern nur noch über ein Docker Netzwerk in dem sich alle Container befinden. ich hoffe ich habe mich an der Stelle nachvollziehbar ausdrücken können.

Inzwischen habe ich verschiedenes probiert. Die Instanzen mit eigenen IP-Adressen, die nicht auf dem Docker Host laufen, lassen sich problemlos über die grafische NPM Oberfläche einbinden und sind auch aus dem WAN erreichbar. Das funktioniert also alles. Lediglich die Container bekomme ich nicht verbunden. Sie sind dann schlicht nicht erreichbar. Wenn ich die IP des Hosts im Browser aufrufe und der Port stimmt, lande ich auf der jeweiligen Weboberfläche.

Wie muss ich vorgehen, um das beschriebene Szenario umzusetzen. Wenn ich extra ein eigenes Netzwerk erstelle und versuche alle die docker-compose Dateien so anzupassen, dass sämtliche Container im selben jetzt (Bridge) landen, will das nicht funktionieren. Teilweise werden wieder andere Netzwerke erstellt, die gar nicht in der docker-compose Datei enthalten sind.

Vielleicht seid Ihr ja so nett und könnt mir sagen, wo mein Denkfehler liegt, wie ich es am besten strukturiert angehe o.Ä.

Viele Grüße

Dennis

 

[blurrrr]

Hi,

ich bin jetzt kein Docker-Profi, aber es wäre vermutlich sinnvoll, wenn Du mal Deine docker-compose.yaml posten würdest (sofern notwendig auch div. Dinge anonymisieren).

Vielleicht wirfst Du auch mal einen Blick in die Doku: https://docs.docker.com/engine/network/drivers/bridge/.

 

[dtm3000]

...wäre vermutlich sinnvoll, wenn Du mal Deine docker-compose.yaml posten würdest (sofern notwendig auch div. Dinge anonymisieren).

Vielen Dank für Deine Antwort. Es ist aber mit allen Containern dasselbe Phänomen. Und das docker-compose File für den NPM ist ganz einfach gehalten. Da sind keine zusätzlichen Parameter angegeben. Hier mal der Inhalt:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # These ports are in format <host-port>:<container-port>
      - '80:80' # Public HTTP Port
      - '443:443' # Public HTTPS Port
      - '81:81' # Admin Web Port
      # Add any other Stream port you want to expose
      # - '21:21' # FTP
    environment:
      # Mysql/Maria connection parameters:
      DB_MYSQL_HOST: "db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "npm"
      DB_MYSQL_NAME: "npm"
      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - db

  db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: 'npm'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'npm'
      MARIADB_AUTO_UPGRADE: '1'
    volumes:
      - ./mysql:/var/lib/mysql

Vielleicht interessanter, zwei Screenshots der Portaineroberfläche, die die Netzwerksituation gut übersichtlich zeigen. Vielleicht bringt das ja was..

 

[blurrrr]

zwei Screenshots

Ich sehe irgendwie nur einen? Wie dem auch sei...

LAN <-Reverse-Proxy-> user-definied network <-Container mit Zugriff-> div. einzelne Netze (je Stack) <-sonstige Container (je Stack)->

So sollte es meinem Verständnis nach aussen, als Beispiel:

<LAN> <-> NPM <-> <RP-Netz> <-> MediaWiki (Web) <-> <MediaWiki-Netz> <-> MediaWiki (DB)

Heisst, dass sämtliche Container, welche die gewünschte Funktionalität bereitstellen (z.B. eben das Webinterface von MediaWiki), "müssen" in das RP-Netz (oder wie auch immer Du Dein benutzerdefiniertes Netz nennen willst) bzw. ein Bein im RP-Netz haben und das andere halt eben im Stack-eigenen (für den Zugriff auf die jeweilige DB, etc.).

Der Reverse-Proxy seinerseits muss eben von extern erreichbar sein und nach intern eben auch einen Fuss im RP-Netz haben, damit der Reverse-Proxy auch die "App"-Container mit den gewünschten Funktionalitäten erreichen kann. Der Reverse-Proxy braucht allerdings keinen Zugriff auf die Container dahinter (z.B. DB-Container).

Dazu wirst Du aber bei allen Containern das benutzerdefinierte Netzwerk zusätzlich angeben müssen, welches Du vorher z.B. in Portainer erstellt hast (brauchste einfach nur einen Namen vergeben und gut ist).

EDIT: Hier noch ein Link zur passenden Docker-Doku: https://docs.docker.com/compose/how-tos/networking/#specify-custom-networks. Da sieht man eigentlich recht schön, dass der DB-Container eben nur das Backend-Netzwerk hat und der App-Container eben Front- und Backend.

 

[dtm3000]

Es sind zwei Sceenshots. Einmal die Containerübersicht und einmal die Netzwerke. Aber vielen Dank. Super. Mit den Informationen kann ich auf jeden Fall was anfangen. Werde mich asap weiter einarbeiten.

 

[blurrrr]

Es sind zwei Sceenshots.

Jetzt wo Du es nochmal explizit erwähnt hast... einmal inline und einmal angehängt, alles klar

Bevor Du Dir alles zerschiesst, probier es ggf. mal mit einem eigenen Konstrukt (ggf. eine eigene docker-compose.yaml) bzw. ggf. einfach eine neue VM hochziehen, Docker installieren und dann damit testen

 

[the other]

Moinsen,
wenn du KEIN network in der compose angibst, dann wird je nach containernname ein default netzwerk angelegt durch portainer.
Also Beispiel:

version: '3.3'

services:
  uptime-kuma:
    image: elestio/uptime-kuma:${SOFTWARE_VERSION_TAG}
    container_name: uptimekuma
    restart: always

    healthcheck:
      disable: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/docker/uptimekuma/data:/app/data
    ports:
      - 8020:3001

legt ein Netzwerk uptimekuma_default an.

Hier laufen alle Container auf einem Host in einer VM bisher, da kann ngnix trotz unterschiedlicher Netzwerkzugehörigkeiten (also auch x_default Netzwerke) alles bedienen.

Wenn du ein spezielles Netzwerk schon bei Erstellung des Stacks angeben willst, dann muss erst unter services definiert werden welches und dann am Ende auf der ersten Ebene auch ggf, dass ein bestehendes genutzt werden soll.
Beispiel:

version: '3.3'

services:
  uptime-kuma:
    image: elestio/uptime-kuma:${SOFTWARE_VERSION_TAG}
    container_name: uptimekuma
    restart: always
    
    healthcheck:
      disable: true
    volumes:

      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/docker/uptimekuma/data:/app/data
    ports:
      - 8020:3001
    networks:
     - test

networks:
  test:
    external: true

Das erstellt dann KEIN default Netz, sondern baut uptime kuma direkt ins bestehende test Netz ein.

Mehr dazu auch hier: https://docs.docker.com/compose/how-tos/networking/
Viel Erfolg!

 

[dtm3000]

Hier laufen alle Container auf einem Host in einer VM bisher, da kann ngnix trotz unterschiedlicher Netzwerkzugehörigkeiten (also auch x_default Netzwerke) alles bedienen.

Jetzt bin ich mir nicht sicher wie ich das interpretieren muss. Container die auf dem selben Docker Host in unterschiedlichen Netzen laufen, können sich doch gar erreichen ohne zusätzlichen Aufwand oder?

Nochmal zur Sicherheit. Ich hab es jetzt so verstanden, ich ergänze in allen compose files ein zusätzliches (immer das selbe) Netzwerk, über dass diese dann alle wie gewohnt über das NPM Webui als Proxy Hosts konfiguriert werden können.

Viele Grüße

 

[Confluencer]

wenn du KEIN network in der compose angibst, dann wird je nach containernname ein default netzwerk angelegt durch portainer.

Fast. Der Compose Projektname ist dafür entscheidend. In Portainer heissen die Compose Projekte (warum auch immer) einfach "Stack".
Wenn man in der Kommandozeile docker compose verwendet und der Projektname weder als Argument, noch als "name: <projektname>" in der Compose-Datei angegeben ist, dann wir der Name des Verzeichnisses verwendet, in dem die Compose-Datei liegt.

 

[Confluencer]

Jetzt bin ich mir nicht sicher wie ich das interpretieren muss. Container die auf dem selben Docker Host in unterschiedlichen Netzen laufen, können sich doch gar erreichen ohne zusätzlichen Aufwand oder?

Nope. Container im selben User Definied Network können sich direkt erreichen - und können dort auch dns-basiertes Service-Discovery verwenden, und Dienste eines anderen Containers im selben Netzwerk mit <service namen>:<container-port> zu erreichen.

ich ergänze in allen compose files ein zusätzliches (immer das selbe) Netzwerk, über dass diese dann alle wie gewohnt über das NPM Webui als Proxy Hosts konfiguriert werden können.

Jup.

 

[the other]

Moinsen,
um den Kollegen @blurrrr zu zitieren:

ich bin jetzt kein Docker-Profi

Ja, es läuft in einer VM, diese auf dem einen host (proxmox). Und ja: ich habe es auch so verstanden wie du. Ich dachte, dass ich erst alle Container in ein gemeinsames Netz bringen muss (ggf. zusätzlich zum eigenen), damit es mit dem ngnix läuft. Aber hier sind auch die Container erreichbar darüber, die gar nicht im gemeinsamen ngnix Netzwerk sind. Vielleicht kann ja @Confluencer zu diesem "gefühlten" Widerspruch etwas sagen, denn der Kollege kennt sich mit docker mal deutlich besser aus...
Ah, schon passiert. Danke @Confluencer

 

[the other]

Moinsen,
da nutze ich doch die Gunst der Stunde und frage auch nochmal:
also, wenn alles auf einem host in einer VM dann container untereinander auch ohne extra gemeinsames angelegtes Netzwerk erreichbar (alle in ihrem x_default)?
Wenn anderes setting (container in anderer VM / anderer host), dann gemeinsames Netzwerk (logo) anlegen nötig?
So ganz hab ich den Knoten im Kopf dazu auch noch nicht weg...

 

[Confluencer]

Die Container müssen mindestens in einem gemeinsamen Netzwerk stecken damit das klappt. Container, die nicht im selben Conatiner Netzwerk stecken, können höchstens über <host ip oder name>:<host port> mit Containern in anderen Netzwerken kommunizieren. Aber das will man eigentlich nicht. Auf dem selben Host könnte man als host-ip auch die ip 172.17.0.1 vom docker0 Interface verwenden.

Wenn die Container auf einem anderen Host laufen, dann kann man nur dessen <host ip oder name>:<host port> verwenden. So, als wenn die Anwendung/der Service direkt auf dem anderen Host laufen würde.

 

[blurrrr]

Ging es nicht darum, alles zusammen auf einem Host laufen zu lassen? Also ich - so ahnungslos wie ich nunmal bin - würde es so machen, wie ich es oben beschrieben habe: Ein Reverse-Proxy-Netz anlegen, da kommen alle App-Server mit ihren "erreichbaren" WebApps rein.

 

[Confluencer]

@blurrrr Deine Beschreibung ist "spot-on".

Den Names des angelegten Netzwerks <projektname>_default (auch das ist aus Docker Sicht ein User Defined Network) kann man übrigens auch beeinflussen:

...
networks:
  default:
    name: mein-tooles-netzwerk
...

Wenn ein Container nur in dem Netzwerk ist (siehe Beispiele 1 von @the other ) dann muss man nichts weiter tun, weil es implizit konfiguriert ist, solange kein anderes Netzwerk am Service konfiguriert ist. Sobald ein Netzwerk konfiguriert ist, muss man das "default" Netzwerk zusätzlich mit auflisten.

 

[blurrrr]

Sorry, ich kann nicht anders, ich muss nochmal ein Bild hinterher werfen



Alternativ kann man aber auch hingehen und das Problem noch anderweitig lösen (Virtualisierung sei Dank)...:

Es wird eine zusätzliche Bridge angelegt (vmbr1, vmbr0 ist die Default-Bridge, welche automatisch bei der PVE-Installation angelegt wird). vmbr1 wird nun aber keiner NIC zugeordnet. Der Reverse-Proxy-Docker-Host bekommt nun beide Bridges zugewiesen und der andere Docker-Host bekommt als Interface nur vmbr1 zugewiesen. Das bedingt allerdings auch eine statische IP-Konfiguration auf beiden NICs in vmbr1 (Host1+2). Somit ist der Zugriff von aussen auf den 2. Docker-Host (den inneren) auch unterbunden, lediglich Hosts, welche mit der Bridge vmbr1 verbunden sind (und eine passende statische IP-Konfiguration haben) können mit den Hosts auf dieser Bridge reden. Ist im Prinzip fast das gleiche, nur mit dem Unterschied, dass es sich bei "Netz: Reverse-Proxy" nicht um ein Docker-Netzwerk handelt, sondern um eine Bridge auf dem PVE-Host (eben vmbr1).

Das aber auch nur mal so am Rande, es ist definitiv nicht verkehrt, wenn man sich Docker-technisch auch mal mit solchen Dingen beschäftigt. Allerdings sollte man dabei dann auch nicht vergessen, dass man auf div. Dinge keinerlei Zugriff mehr hat. Ein klassisches Beispiel (weil es viele gerne nutzen) wäre z.B. "phpmyadmin" für den Zugriff auf die Datenbanken. Da könnte man aber auch hingehen (und nun wird es auch etwas komplexer) und eigentlich nochmal ähnliches für die Datenbank-Container machen. Ein zusätzliches Netzwerk für die Datenbanken, der phpmyadmin-Container kommt eben in jenes (um auf die DB-Container zuzugreifen) und mit der anderen Seite halt auch in das Reverse-Proxy-Netz. Somit kann phpmyadmin auch alle DB-Container erreichen und auf der anderen Seite (über den Reverse-Proxy) auch den Zugriff über das Webinterface ermöglichen.

Ist jetzt ein bisschen gequetscht, aber würde dann z.B. so aussehen:



Wie Du es machst, ist natürlich Dir überlassen, sowas kann man ja ggf. später auch noch nachziehen (falls man es braucht), oder eben auch einfach nur "bei Bedarf" kurzfristig umstellen. Alternativ schwingt man sich in Sachen SQL halt eben direkt in den Container, aber es gibt ja durchaus Leute, welche den webbasierten Zugriff für div. Dinge bevorzugen, von daher... nur mal so am Rande

 

[the other]

Moinsen,
lieben Dank für den Input!
Aus dem Bauch mit paperless genau so gemacht: der web service ist in ngnix Netzerk UND paperless_default, denn da ist auch die db und redis enthalten. Die aber will (und brauche) ich ja nicht erreichbar haben für mich per RP...

 

[dtm3000]

Super. Vielen Dank euch. Konnte es jetzt so wie hier beschrieben lösen:
https://docs.docker.com/compose/how-tos/networking/#use-a-pre-existing-network
Eigentlich ganz simpel, wenn man es mal verstanden hat. Einen Knackpunkt gibt es aber. Man muss im NGINX anstatt der IP-Adressen den Namen des Containers eintragen. Da muss man erst mal drauf kommen (hier hat ChatGPT geholfen).