Docker Netzwerke wiederverwenden

[Oekel]

Ich hatte gerade folgende funktionierende compose in einem anderen Thread gepostet:

version: "3"
services:
  nginx-test:
    image: docker.io/nginx
    container_name: nginx-test

    networks:
      ipvlan_network_50:
        ipv4_address: 192.168.5.202
    restart: unless-stopped

networks:
  ipvlan_network_50:
    driver: ipvlan
    driver_opts:
      parent: eth0.50  # Specify the host interface with automatic vlan attachment
    ipam:
      driver: default
      config:
        - subnet: 192.168.5.0/24

(In realität besteht diese aus 3 containern, die zusammen arbeiten und 2 davon zwingend über einen Router/VPN erreichbar sein sollen)

Da ich gerne mit compose up/down arbeiten würde sind meine compose-files immer vollständig.
Nun Hoste ich dieseses Dreigestirn an containern 1x für mich (smart home) und 1x für meinen Vater.

Daher sind die beiden compose fast identisch (mindestns das ipvlan_network_50)
Es wird jedoch gemeckert, dass das Netzwerk bereits existiert.

Kann ich meine 192.168.5.201, 202, 203
Und seine 192.168.5.211, 212, 213

Nur erreichen, wenn ich jeweils ganz kleine subnet: 192.168.5.201/32 aufbaue? Oder geht das auch etwas flexibler?

LG
Oekel

 

[Confluencer]

Ein Gateway kann genau von einem Netzwerk verwendet werden.

Dein Netzwerk ist unter docker network ls als ${project name}_ipvlan_network_50 aufgelistet. Wenn ${project name} nicht mittels -p or --project-name oder Umgebungsvariable COMPOSE_PROJECT_NAME angegeben wird, dann wird immer der Verzeichnisname verwendet.

Deswegen legen die meisten Netzwerke die von mehreren Compose Projekten zu nutzen sind auch über die cli an und referenzieren sie dann in der Compose Datei wie folgt:

Anlegen:

docker network create .... mynetwork

Verwenden:

networks:            
  mynetwork:           # kann identisch sein, muss es aber nicht. Muss identisch mit dem verwendeten Netzwerknamen in der Service Netzwerkkonfiguration sein
    name: mynetwork    # hierüber wird das Netzwerk erkannt und muss identisch wie der über die cli angelegte Netzwerkname sein
    external: true

Das external: true entkoppelt das Netzwerk vom Lebenszyklus von Compose, sodass es auch stehen bleibt, wenn kein Compose Projekt es verwendet.

 

[Oekel]

networks:
mynetwork: # kann identisch sein, muss es aber nicht. Muss identisch mit dem verwendeten Netzwerknamen in der Service Netzwerkkonfiguration sein
name: mynetwork # hierüber wird das Netzwerk erkannt und muss identisch wie der über die cli angelegte Netzwerkname sein
external: true
[/code]

Das external: true entkoppelt das Netzwerk vom Lebenszyklus von Compose, sodass es auch stehen bleibt, wenn kein Compose Projekt es verwendet.

Die derzeitige Lösung verwendet external: true auf ein 192.168.5.0/24 Netzwerk in dem schon anderer "reale" Hardware hängt (mit festen IPs) und ich nun tunlichst versuche doppelte IPs zu vermeiden.

Ist das ein persee schlechtes Vorgehen? Sollte ich auf /29 oder /32 runter gehen? In dem Fall verstehe ich es aber nicht mit dem Gateway, welcher ja vom Ipam automatisch vergeben wird bzw. in diesen Ranges sitzen muss.
Ergo es wäre unmöglich jenes == mit meinem im Router eingestellten 192.168.5.1 (vlan) zu nutzen.
(Ich denke es gibt genügend Fälle, wo ich den Gateway meines Routers brauche??)

 

[Confluencer]

Ich hab damals (ist jetzt auch schon 5 Jahre her) beim Anlegen die Gateways immer selbst mit angegeben.

In Gewisser weise sich das Parent Interface wie ein Upstream Link der an einen Switch angeschlossen ist. Die Child-Interfaces sind dann weitere Geräte an diesem logischen Switch. Du betreibst im Grunde ein Container-Netzwerk das in ein physikalisches Netzwerk gebrückt ist.. Afaik spielt IPAM bei macvlan/ipvlan nur den DHCP Server für seine iprange im Subnet eine Rolle. Der Router wird außerhalb der ip range, aber innerhalb des Subnets erwartet.

Ist das ein persee schlechtes Vorgehen? Sollte ich auf /29 oder /32 runter gehen?

Bezieht sich das auf den Satz davor? Oder auf die macvlan/ipvlan Konfiguration?

 

[Oekel]

Bezieht sich das auf den Satz davor? Oder auf die macvlan/ipvlan Konfiguration?

Bezieht sich auf das *.*.*.0/24

 

[Confluencer]

Zu ipvlan/macvlan hatte ich ja in deinem anderen Topic schon geschrieben wie man es machen sollte: https://forum.heimnetz.de/threads/container-in-mehreren-netzwerken-host-vlans.4196/#post-43836.

Ein Bridge Network kann es aber auch nicht sein, weil ein bridge Container-Netzwerk genattet ist und nicht das Subnet des Host-Netzwerk sein kann.

Ich stehe immer noch auf dem Schlauch, da bei macvlan/ipvlan die Frage durch meinen Post im anderen Topic beantwortet sein sollte , oder im Fall von einem bridge Netzwerk keinen Sinn ergibt.

Ich fürchte Du musst weiter ausholen...

 

[Oekel]

Ich nehme hierfür noch mal eine andere Konfiguration:

version: '3.7'

services:

  zwave-js-ui:
    container_name: zwave-js-ui-test
    image: zwavejs/zwave-js-ui:latest
    restart: unless-stopped
    tty: true
    stop_signal: SIGINT
    environment:
      - SESSION_SECRET=mysupersecretkey
      - ZWAVEJS_EXTERNAL_CONFIG=/usr/src/app/store/.config-db
      - TZ=Europe/Berlin
    networks:
      vlan50:
        ipv4_address: 192.168.5.213
    devices:

      - /dev/ttyAMA0:/dev/ttyAMA0
    volumes:
      - zwave-config:/usr/src/app/store
    ports:
      - '8091:8091' # port for web interface
      - '3000:3000' # port for Z-Wave JS websocket server

volumes:
  zwave-config:
    name: zwave-config

networks:
  vlan50:
    external: true

Da wir das vlan50 mit konreter IP verwenden ist die Portangabe eigentlich obsolet....
ABER (innerhalb von Portainer):


kann ich dem gestartetem Container ein weiteres Netzwerk hinzufügen:

Und nun kann ich auf 192.168.1.111 (DockerServer) mittels Port 8091 auf das Webinterface von zwave-js-ui zugreifen.

Da es "irgendwie" funktioniert hätte ich gerne gewusst was nötig wäre um auf gleiches Endergebis direkt mittels docker-compose zu gelangen.

LG

PS: Die gleiche GUI-Klickerei mit "add host" Netzwork wirft nebenbei bemerkt einen Fehler:
Failure
container cannot be disconnected from host network or connected to host network

 

[Confluencer]

Mir fehlt immer noch Kontext wissen. Ich vermute, dass Du hier Details für irrelevant oder selbstverständlich betrachtest und sie deshalb nicht teilst, aber sie für das Verständnis anderer hilfreich wären.

Ich wüsste nicht mal was mir der letzte Post sagen soll und was ich darauf antworten soll. Sprich: ich stehe nach wie vor auf dem Schlauch.

Bitte teil alles, was notwendig ist, damit ein Außenstehender den Kontext und das Zielbild versteht und eine Chance hat Deinen Gedanken zu folgen. Idealweise mit verwendeten Befehlen und Compose-Dateien (letzteres hast Du ja schonmal).

Zu Portainer kann ich nichts sagen: Ich verwende es nicht, da es mir zu umständlich ist. Ich verwende nur compose files mit docker compose bzw. docker stack (bei Swarm deployments), und verwalte diese Dateien und evtl. Hilfsskripte in Git.

 

[Oekel]

Tut mir leid, ich bin zu neu, als dass ich sagen könnte was ich "übersprungen" hätte. Meine Konfiguration basiert zu 100% auf Portainer.
Dort habe ich primär einen "Stack" angelegt (nichts anderes als eine docker-compose) und möchte es genau auf diesem Level verstehen. (Vielleicht muss wirklich Jemand seine Expertiese dazu geben, der sich in beiden Welten (native + Portainer) auskennt und vor allem die Überschneidungunge/Alias dafür kennt.

Mein Ziel war es einen Container via zusätzlicher IP(s) (hier sogar vlan) + auf dem Host via PortMapping zu nutzen.
Zuerst dachte ich: geht nicht/nicht vorgesehen
Aber als ich es dann per Zufall via GUI genau wie oben in den Screens beschrieben geschafft habe, dachte ich mir dass es "unter der Haube" ja in der native Docker Welt die gleichen Befehle/Konfigurationen geben muss.

 

[Confluencer]

Am Ende verwenden Portainer, `docker compose` und die docker cli alle dieselbe API um die Ressourcen zu managen. Alle sind "nur" User Interfaces um die API zu treiben, nicht mehr nicht weniger.

Jeder docker cli Befehl und dessen Argumente für Container, Volumes und Netzwerk kann in compose-file Syntax übersetzt werden und umgekehrt. Die Konfigurationselemente heißen manchmal nur anders, oder sind verschachtelt anzugeben.

Teil doch mal den`docker-cli` Befehl, den Du in die compose-file Syntax übersetzt haben willst.

 

[blurrrr]

Ich glaub, es geht einfach nur darum, dass man den Container über 2 (oder mehrere) Schnittstellen erreichen kann. In dem Beispiel vermutlich über die Default-Bridge + VLAN50

 

[Confluencer]

Dann gibt es wohl keine docker-cli Befehle, die man transformieren kann.

Jetzt ergibt es Sinn:

Die Konfiguration in Portain kann nicht korrekt sein.

Das Default "bridge"-Netzwerk wird mittels network_mode: bridge am Service definiert.

Zum Host-Netzwerk hatte ich im anderen Topic das hier geschrieben:

Ist damit

network_mode: host

gemeint? falls ja: damit konfiguriert man das nicht Vorhandensein einer Isolation des Netzwerknamespaces vom Host OS für den Container. Der Container kann dann keine Docker Netzwerke (=bridge/macvlan/ipvlan) verwenden, da sie ohne Netzwerknamespace-Isolation nicht funktionieren.

Entweder verwendet man network_mode: bridge (=network namespace von der default bridge) oder network_mode: host (=keine Trennung vom network namespace des hosts ) oder andere Netzwerke (=geht nur, wenn network_mode NICHT verwendet wird).

Das Default-Bridge Netzwerk sollte man auch nicht verwenden. Es ist eine Altlast die irgendwann verschweindet.
Jedes Compose Deployment (egal, ob über docker compose oder als Portainer Stack) legen ein Benutzerdefiniertes contaienr Netzwerk an, dass man verwenden sollte. Nur dort steht bspw. die dns-basierte Namensauflösung von Containers über die Service oder Containernamen zur Verfügung.

Was Du brauchst könnte folgendermaßen aussehen:

version: '3.7'

services:

  zwave-js-ui:
    container_name: zwave-js-ui-test
    image: zwavejs/zwave-js-ui:latest
    restart: unless-stopped
    tty: true
    stop_signal: SIGINT
    environment:
      - SESSION_SECRET=mysupersecretkey
      - ZWAVEJS_EXTERNAL_CONFIG=/usr/src/app/store/.config-db
      - TZ=Europe/Berlin
    networks:
      vlan50:
        ipv4_address: 192.168.5.213
      default: {}
    devices:
      - /dev/ttyAMA0:/dev/ttyAMA0
    volumes:
      - zwave-config:/usr/src/app/store
    ports:
      - '8091:8091' # port for web interface
      - '3000:3000' # port for Z-Wave JS websocket server

volumes:
  zwave-config:
    name: zwave-config

networks:
  vlan50:
    external: true
  default:
    name: zwave-internal

Anmerkung: ich habe das Netzwerk "default" genannt, weil das IMMER mit angelegt wird, egal ob man es konfiguriert oder nicht. In diesem Fall sorgen wir nur dafür, dass auf Docker-Ebene das Netzwerk nicht default_{Verzeichnisname} heißt, sondern "zwave-internal"

 

[Confluencer]

tty: true

Das kann auch nicht gesund sein Ein Image das beim Container diese Einstellung benötigt, macht vermutlich etwas grob falsch... Normalerweise sollte ein Image ein ENTRYPOINT und/oder CMD definieren, dass einen im Vordergrund laufenden Prozess startet. Sobald dieser Prozess beendet wird, sollte auch der Container beendet werden. tty: true sorgt dafür das der Prozess im Container immer mit SIGKILL terminiert wird... je nach Anwendung kann das ziemlich ungesund sein für die Anwendung und zu korrupten Daten führen.... oder es kann ihm auch einfach nichts ausmachen.

 

[Oekel]

Dann gibt es wohl keine docker-cli Befehle, die man transformieren kann.

Jetzt ergibt es Sinn:

Genau mir ist kein cli-Befehl bekannt. (Schön dass ihr meinem Wirrwar nun halbwegs folgen könnt)

networks:
vlan50:
external: true
default:
name: zwave-internal

Das werde ich zeitnah testen.

Das kann auch nicht gesund sein .... tty: true sorgt dafür das der Prozess im Container immer mit SIGKILL terminiert wird...

Viele Programme / Konfigurationen nimmt man zum testen erst mal so wie sie als Bsp. gegeben sind. Aber ich werde das bei Gelegenheit noch mal hinterfragen. Danke

 

[Confluencer]

Kleiner Tipp noch:

Es gibt ein Image, dass erlaubt compose Dateien aus der Konfiguration aktueller Container zu erzeugen:

sudo docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/red5d/docker-autocompose <container-name-or-id> <additional-names-or-ids>...

Bei deinem Beispiel oben wäre es dann:

sudo docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/red5d/docker-autocompose zwave-js-ui-test > /pfad/wo/die/erzeugte/datei/liegen/soll/docker-compose.yaml

Ich bin mir nicht sicher, ob es die Netzwerke und Volume Erzeugung auch mit ausgibt... einfach mal probieren.