2 Docker-Container "richtig" verbinden

[Wehc (Gast)]

Ich habe gelesen, dass man --link nicht mehr verwenden soll, um 
Docker-Container zu "verbinden" - vielleicht brauche ich das auch nicht, 
aber wie mache ich das:

Ich habe schon einen funktionierenden mysql-Container, der Port 3306 
publiziert, da kann ich mich vom Host aus auch mit mysql hin verbinden.

Jetzt baue ich einen zweiten Container (node.js), und aus diesem heraus 
möchte ich auch in die Datenbank vom mysql-Container greifen können - 
möglichst auch noch nach einem Neustart der beiden Container.

Wie macht man das jetzt? Nur weil der Host Zugriff hat, hat man das vom 
Container innerhalb ja nicht, oder?

[Εrnst B. (ernst)]

ist "docker-compose" o.Ä. eine Option?

[Wehc (Gast)]

Na wenn es sein muss, wie geht das da? Ich habe den Container sonst 
immer mit einem Kommando in einer Batch-datei gestartet.

[Rolf M. (rmagnus)]

Wehc schrieb:
> Na wenn es sein muss, wie geht das da? Ich habe den Container sonst
> immer mit einem Kommando in einer Batch-datei gestartet.

Du schreibst eine docker-compose.yml, die die beiden Container und deren 
Verbindungen und abhängigkeiten beschreibt, und dann startest du deinen 
Container-Verbund einfach per "docker-compose up". Das ist genau für 
solche Anwendungsfälle gedacht.

https://docs.docker.com/compose/

[Wehc (Gast)]

Jetzt bin ich weiter, und teilweise funktioniert es schon - meine 
docker-compose.yml sieht so aus:

version: "3.7"
services:
  s_node:
    image: "node"
    depends_on:
      - s_db
    networks: 
      - the-shared-network
    user: "node"
    working_dir: /home/node/app
    environment:
      - NODE_ENV=production
    volumes:
      - ./:/home/node/app
    expose:
      - "8081"
    command: "node server.js"

  s_db:
    image: mariadb
    ports:
      - "3306:3306"
    networks: 
      - the-shared-network
    volumes: 
      - mysql-storage:/var/lib/mysql
    environment:
      MARIADB_ROOT_PASSWORD: XXXXXX
      
volumes:
  mysql-storage:
    external: true

networks:
  the-shared-network: {}

Im gleichen loklaen Verzeichnis wie die docker-compose.yml Verzeichnis 
(was als volume gemountet wird nach /home/node/app im container) liegt 
eine Datei server.js, die das modul express benutzt. Dieses wird aber 
nicht gefunden, obwohl ich der Meinung war, es ist im node-image 
enthalten. Was fehlt?

die Fehlerzeile lautet:

s_node_1  | Error: Cannot find module 'express'

[Εrnst B. (ernst)]

Wehc schrieb:
> Dieses wird aber
> nicht gefunden, obwohl ich der Meinung war, es ist im node-image
> enthalten. Was fehlt?

Dann wird es wohl nicht enthalten sein. Hast du im Ordner, der da nach 
/home/node/app reingezogen wird, einen "node_modules" Unterordner incl. 
express?

Falls nicht, fehlt ein npm install. Quick-n-dirty:
command: "node server.js"
durch
command: "npm install"
ersetzen, einmal docker-compose up, und dann wieder zurückstellen.

[Moskito (Gast)]

Geht auch zuverlässig ohne compose:

Option 1: Zugriff über die Gateway IP. Wenn du die Default Bridge 
verwendest, ist das 172.17.0.1. der entsprechende Port muss forwarded 
werden (-p 3306:3306).

Option 2: beide Container dem gleichen Network zuweisen (Bridge, aber 
nicht die Default bridge).
Dann kann der name des MySQL Containers verwendet werden, um sich aus 
anderen Containern damit zu verbinden. Kein portforwarding erforderlich.

[Rolf M. (rmagnus)]

Εrnst B. schrieb:
> Falls nicht, fehlt ein npm install. Quick-n-dirty:
> command: "node server.js"
> durch
> command: "npm install"
> ersetzen, einmal docker-compose up, und dann wieder zurückstellen.

Besser wäre es aber, das "npm install" ins Dockerfile per RUN 
einzutragen.

Moskito schrieb:
> Geht auch zuverlässig ohne compose:

Klar geht's auch ohne, nur eben umständlicher.

[Sheeva P. (sheevaplug)]

Εrnst B. schrieb:
> Falls nicht, fehlt ein npm install. Quick-n-dirty:
> command: "node server.js"
> durch
> command: "npm install"
> ersetzen, einmal docker-compose up, und dann wieder zurückstellen.

Was ist eigentlich ein Dockerfile? Genau: eine Vorschrift, um Images zu 
bauen. Womöglich könnte man "npm install" beim Bauen des Image...? Oder 
zur Not im Entrypoint?

[Εrnst B. (ernst)]

Sheeva P. schrieb:
> Was ist eigentlich ein Dockerfile? Genau: eine Vorschrift, um Images zu
> bauen. Womöglich könnte man "npm install" beim Bauen des Image...?

Natürlich ist das die schönere Lösung.
Er verwendet aber direkt das "node"-Image, und baut kein eigenes. Und er 
mountet direkt seinen gesamten Source-Tree als volume in den container.
d.H.: nur einen eigenen Container "FROM: node" mit "npm install" bauen 
reicht nicht, sein volume-mount macht die ganzen dadurch installierten 
Module wieder unsichtbar.

"von außen" einmal npm install laufen lassen könnte reichen, aber: Dafür 
muss auch außerhalb vom Docker ein nodejs installiert sein, in einer 
kompatiblen Version.

Der vorgeschlagene "Quick&Dirty"-Hack mit dem einmaligen "command: npm 
install" installiert die Packages ja nicht (nur) in den container, 
sondern in das volume. d.H: Das übersteht auch ein "recreate" und in 
gewissen Grenzen auch pull/updates.

Solange man noch am entwickeln ist und sich der Sourcecode oft ändert, 
halte ich das für eine durchaus brauchbare Lösung, weil man mit einem 
einfachen&schnellem restart statt einem langwierigerem build auskommt.

[Rolf M. (rmagnus)]

Εrnst B. schrieb:
> Sheeva P. schrieb:
>> Was ist eigentlich ein Dockerfile? Genau: eine Vorschrift, um Images zu
>> bauen. Womöglich könnte man "npm install" beim Bauen des Image...?
>
> Natürlich ist das die schönere Lösung.
> Er verwendet aber direkt das "node"-Image, und baut kein eigenes.

Was aber sehr einfach wäre.

> Und er mountet direkt seinen gesamten Source-Tree als volume in den
> container.

Was nicht nötig wäre.

> d.H.: nur einen eigenen Container "FROM: node" mit "npm install" bauen
> reicht nicht, sein volume-mount macht die ganzen dadurch installierten
> Module wieder unsichtbar.
>
> "von außen" einmal npm install laufen lassen könnte reichen, aber: Dafür
> muss auch außerhalb vom Docker ein nodejs installiert sein, in einer
> kompatiblen Version.

Was dann den Sinn von Docker irgendwie über den Haufen wirft.

[Sheeva P. (sheevaplug)]

Εrnst B. schrieb:
> Sheeva P. schrieb:
>> Was ist eigentlich ein Dockerfile? Genau: eine Vorschrift, um Images zu
>> bauen. Womöglich könnte man "npm install" beim Bauen des Image...?
>
> Natürlich ist das die schönere Lösung.

Ich wäre froh, wenn es "die schönere Lösung" wäre.

> Er verwendet aber direkt das "node"-Image, und baut kein eigenes. Und er
> mountet direkt seinen gesamten Source-Tree als volume in den container.

How to shoot yourself in the foot: Container nicht verstanden. ;-)