Verbindung DB-Container funktioniert nicht

[chris080]

Hallo ich habe leider keine Kategorie "Docker" gefunden und habe es erstmal hier rein getan, weil ich auch mit Gradle arbeite.

Das Problem ist eigentlich trivial, aber es will nicht funktionieren.:
Ich will in meiner docker-compose.yml einen weiteren Container erzeugen. Das hat auch geklappt:

version: '2.4'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - PORT=8080
    volumes:
      - ../../:/workspaces:cached
   
    command: sleep infinity
  db:
       image: mariadb:11.1
       restart: always
       environment:
         MARIADB_DATABASE: ****
         MARIADB_USER: ****
         MARIADB_PASSWORD: ****
         MARIADB_ROOT_PASSWORD: ****
       volumes:
         - ****DevDB:/var/lib/mysql
  db-testing:
       image: mariadb:11.1
       restart: always
       environment:
         MARIADB_DATABASE: ****-testing
         MARIADB_USER: ****
         MARIADB_PASSWORD: ****
         MARIADB_ROOT_PASSWORD: ****
       volumes:
         - ****TestDB:/var/lib/mysql
       ports:
         - "3309:3306"
volumes:
  ****DevDB:
  ****TestDB:

Der Container wurde erzeugt, wenn ich die Container rebuilde und im Terminal docker ps ausführe. Dann werden dort 3 Container aufgeführt. Meine Anwendung, meine Datenbank und meine neue Datenbank für Tests. Je ein Container. Will ich mich aber in VSCode mit dem Container verbinden, wie ich es für meinen anderen DB-Container getan habe, dann bekomme ich "Connection error! connect ECONNREFUSED 172.18.0.2:3309".

Und das verstehe ich nicht. Ich kann sogar in den Container rein mit "docker exec -it dockername bash". Das klappt alles. Aber ich kann mich einfach nicht mit dem Container per IDE verbinden.

Dazu muss man sagen:
Alles läuft auf einem Server auf dem ich mich per SSH geschaltet habe. Sowohl im Terminal als auch in der IDE. Dort laufen dann meine Container. Aber da ich mich per SSH auf diesen Host geschaltet habe, dürfte es keine Probleme zum Beispiel bzgl der Firewall geben. Aber ich verstehe einfach nicht, wieso ich mich nicht verbinden kann. Vielleicht übersehe ich was absolut triviales.

 

[LimDul]

Sicher das die IP Adresse stimmt? 172.18.0.2 hört sich nach einer IP von Docker an. Da wird nix auf 3309 lauschen. Der Host Server lauscht auf Port 3309 und leitet das an den Container weiter.

 

[mihe7]

Wie @LimDul schreibt: das ist eine private IP-Adresse und damit von Deinem Rechner aus nicht erreichbar.

Durch das Port-Mapping 3309:3306 wird auf allen Netzwerkinterfaces auf dem Port 3309 gelauscht und an den Container Port 3306 weitergeleitet. Heißt: Du musst die öffentliche IP-Adresse des Servers verwenden, dann kommen die Pakete am Netzwerkadapter des Servers an und sollten dann auch weitergeleitet werden.

Problem: der MySQL-Server ist damit natürlich für "jedermann" im Internet erreichbar.

Lösung 1: Ignorieren. Kann man m. E. durchaus machen, wenn es eine Test-DB ist, die nur fiktive Daten enthält und auch nur kurz läuft.

Lösung 2: SSH-Tunnel. Dazu bindet man den Port z. B. über eine IP-Adresse (localhost) an das loopback-Interface via 127.0.0.1:3309:3306. Damit ist der MySQL-Server von außen nicht mehr erreichbar. Anschließend richtet man sich auf dem Client einen Tunnel von einem lokalen Port (sagen wir mal ebenfalls 3309) zum Server 127.0.0.1:3309 ein. Anschließend sollte man auf dem Client via localhost:3309 (bzw. 127.0.0.1:3309) die DB erreichen können.

 

[EinsamerKämpfer]

Nutze hostname: entsprechender-dienst und dann entsprechender-dienst:entsprechender-port, um auf den entsprechenden Dienst zuzugreifen.

Des Weiteren ist depends_on: db auch nicht verkehrt.

 

[chris080]

Okay ich guck mir das mit dem SSH-Tunnel mal an. Klingt auch alles super logisch. Was mich aber ein wenig irritiert ist, dass es für den anderen Datenbank-Container "db" klappt.

 

[LimDul]

Weil du dich da direkt auf den Docker Container verbindest. Du hast drei "Server"

Server A - der Server auf dem du dich per SSH einloggst. Der hat (mal als Beispiel) die IP-Adresse 192.168.178.20
Server B - Auf dem die normale DB läuft. Der bekommt von Docker eine IP, hier anscheinend 172.18.0.2
Server C - Auf dem die Test-DB läuft. Der bekommt von Docker eine IP, hier evtl. 172.18.0.3 (müsste man aber im Detail schauen)

Server B & C sind Docker Container die auf Server A laufen.

Auf B und C läuft läuft jeweils MariaDB und lauscht auf Port 3306 (Standard-Port).

Für Server C hast du ein Port-Forwarding angeben: 3309 => 3306.
Das heißt, dein Server A (192.168.178.20) lauscht nun auf Port 3309 und leitet alles, was er an Anfragen bekommen, an Server C, Port 3306 weiter.

Das heißt, um dich mit deiner TEst-DB zu verbinden, kannst du dich entweder auf der IP von Server A mit Port 3309 verbinden oder auf der IP von Server C mit Port 3306.

Allerdings sind die IPs von Server B & C nur von Server A aus erreichbar.


Hat das was Licht ins Dunkel gebracht?

 

[chris080]

Ich glaube ich hatte vergessen zu sagen, dass ich mit der IDE (VSCode) nicht nur per SSH auf dem Host bin, sondern dann das Projekt im Devcontainer geöffnet habe. Also mit der IDE befinde ich mich in dem Devcontainer.
Das müsste dann ja der Service "app" sein. Und wenn ich den Container vom Service "app" via Terminal mit "docker stop container-name" stoppe, fliegt auch meine IDE aus dem Devcontainer raus und signalisiert, dass die Verbindung unterbrochen wurde bzw. versucht sie wieder aufzubauen.

Und da die Services "db" und "db-testing" auf der gleichen Ebene in der docker-compose wie "app" sind, bin ich davon ausgegangen, dass alle 3 gleichberechtigte Container in einem Docker-Netzwerk sind, die miteinander allein über ihre Servicenamen Verbindungen aufbauen können.
Und da sich meine IDE (und damit auch das Database-Plugin) in dem einen Container befindet, dachte ich, dass es reicht, die Servicenamen des Test-DB-Containers anzugeben.

Das würde auch erklären, warum die Verbindung mit "db" funktioniert, wenn ich "db" als Host angebe. Nur warum sich alles für "db-testing" anders verhalten soll, erklärt sich mir nicht.

Ich dachte auch, dass das Portforwarding nur für den Container gilt. Also eine Schnittstelle, die von außerhalb des Containers nach innen leitet. Sprich, wenn ich einen Docker-Container mit dem mariaDB-Image erzeuge, lässt es innerhalb des Containers einen Service mariaDB laufen, der standardmäßig auf 3306 horcht. Wenn ich nun für diesen Container Portforwarding 3309:3306 einrichte, muss der Container von außen mit 3309 angesprochen werden, damit dieser dann intern diese Anfrage an 3306, also mariaDB weiterleitet.

Ein Freund meinte auch gerade, dass Portforwarding ganz raus kann, da es zwei Container sind. Zwei Services. Zwei unabhängige Hosts innerhalb des Docker-Netzwerkes. Daher können sie auch gleiche Ports haben. Also: db:3306 und db-testing:3306.

 

[LimDul]

Ich glaube ich hatte vergessen zu sagen, dass ich mit der IDE (VSCode) nicht nur per SSH auf dem Host bin, sondern dann das Projekt im Devcontainer geöffnet habe. Also mit der IDE befinde ich mich in dem Devcontainer.
Das müsste dann ja der Service "app" sein. Und wenn ich den Container vom Service "app" via Terminal mit "docker stop container-name" stoppe, fliegt auch meine IDE aus dem Devcontainer raus und signalisiert, dass die Verbindung unterbrochen wurde bzw. versucht sie wieder aufzubauen.

Und da die Services "db" und "db-testing" auf der gleichen Ebene in der docker-compose wie "app" sind, bin ich davon ausgegangen, dass alle 3 gleichberechtigte Container in einem Docker-Netzwerk sind, die miteinander allein über ihre Servicenamen Verbindungen aufbauen können.
Und da sich meine IDE (und damit auch das Database-Plugin) in dem einen Container befindet, dachte ich, dass es reicht, die Servicenamen des Test-DB-Containers anzugeben.

Japp sollte auch reichen. Vom App-Container solltest du mit db-testing:3306 auf den die DB des Test-Containers zugreifen können.

Das würde auch erklären, warum die Verbindung mit "db" funktioniert, wenn ich "db" als Host angebe. Nur warum sich alles für "db-testing" anders verhalten soll, erklärt sich mir nicht.

Ich dachte auch, dass das Portforwarding nur für den Container gilt. Also eine Schnittstelle, die von außerhalb des Containers nach innen leitet. Sprich, wenn ich einen Docker-Container mit dem mariaDB-Image erzeuge, lässt es innerhalb des Containers einen Service mariaDB laufen, der standardmäßig auf 3306 horcht. Wenn ich nun für diesen Container Portforwarding 3309:3306 einrichte, muss der Container von außen mit 3309 angesprochen werden, damit dieser dann intern diese Anfrage an 3306, also mariaDB weiterleitet.

Nein, der Container selber öffnet den Port 3306. Auf dem Server, wo der Docker Container läuft, wird der der Port weitergeleitet. Der Container selber bekommt davon quasi nix mit.

Ein Freund meinte auch gerade, dass Portforwarding ganz raus kann, da es zwei Container sind. Zwei Services. Zwei unabhängige Hosts innerhalb des Docker-Netzwerkes. Daher können sie auch gleiche Ports haben. Also: db:3306 und db-testing:3306.

Korrekt, Port-Forwarding brauchst du nur, wenn du außerhalb von Docker auf die Container zugreifen willst.