Container in mehreren Netzwerken (host+VLANs)

[Oekel]

Moin,

ich habe mich nun durch einige gute und auch einige völlig irreführende Dokumentationen und Tutorials gequält.

Das erste, was funktionierte, war die Erstellung eines neuen Interfaces (mit belibigen Namen) mittels systemd-networkd auf meinem Host und dann die Verwendung des gleichnamigen innerhalb docker-compose.

Nach weiterem Lesen fand ich dann heraus, dass ich gar keine Einstellungen am Host-Interface vornehmen muss, solange ich innerhalb von docker die Namenskonvention eth0.50 beibehalte.
Danach lief es auch gleich mit mehreren VLANs. Zuerst habe ich macvlan als Treiber verwendet und nun ipvlan (einen wirklichen Unterschied konnte ich nicht feststellen)

(Der Trunk mit ALLEN Vlans war natürlich die ganze Zeit vom Router/Switch hin zum Host aktiv)

Final habe ich zwei Konfigurationen, die beide funktionieren:

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

    ports:
      - 8080:80
    #networks:
      #ipvlan_network_20:
        #ipv4_address: 192.168.2.202
      #ipvlan_network_iot:
        #ipv4_address: 192.168.5.202
    restart: unless-stopped

#networks:
  #ipvlan_network_20:
    #driver: ipvlan
    #driver_opts:
      #parent: eth0.20  # Specify the host interface with automatic vlan attachment
    #ipam:
      #driver: default
      #config:
        #- subnet: 192.168.2.0/24
  #ipvlan_network_iot:
    #driver: ipvlan
    #driver_opts:
      #parent: vlan-iot  # Specify the vlan interface (previously manually created on host)
    #ipam:
      #driver: default
      #config:
        #- subnet: 192.168.5.0/24

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

    #ports:
      #- 8080:80
    networks:
      ipvlan_network_20:
        ipv4_address: 192.168.2.202
      ipvlan_network_iot:
        ipv4_address: 192.168.5.202
    restart: unless-stopped

networks:
  ipvlan_network_20:
    driver: ipvlan
    driver_opts:
      parent: eth0.20  # Specify the host interface with automatic vlan attachment
    ipam:
      driver: default
      config:
        - subnet: 192.168.2.0/24
  ipvlan_network_iot:
    driver: ipvlan
    driver_opts:
      parent: vlan-iot  # Specify the vlan interface (previously manually created on host)
    ipam:
      driver: default
      config:
        - subnet: 192.168.5.0/24

Eigentlich ist es 2x das gleiche, wollte der Übersichtshalber die nicht gebrauchten Commentare drin lassen.
DENN was ich NICHT hinbekomme ist, dass ich den Container in 3 Netzen erreiche (2x direkt über die IP und 1x über den host 192.168.1.111:8080)

Alle Anleitungen und auch die künstliche Intelligenz behaupten, dass die Konfiguration funktionieren müsste (sobald ich alles einkommentiere)
Doch es sind immer nur die VLANs erreichbar und wenn ich explizit "host" hinzufüge, dann meckert er, dass es nur einen host Treiber geben darf.

Hat Jemand eine Idee?
Der Praktische Nutzen sei erstmal dahingestellt, aber ich möchte es verstehen. Wenn beides gleichzeitig einfach technisch nicht geht, bin ich auch zufrieden

LG Oekel

 

[Confluencer]

macvlan: das Child Interface hat eine eigene MAC-Adresse und ip
ipvlan: das Child Interface verwendet dieselbe MAC-Adresse wie das Parent-Interface, hat aber seine eigene IP.

In beiden Fällen verhindern Sicherheitsfeatures des Linux-Kernel eine direkte Kommunikation zwischen einem Child- (=Container) und Parent-Interface (=Host) und umgekehrt, erlauben aber Kommunikation von Child- zu anderem Child-Interface, sowie kommunikationen zu allen anderen Geräten im Netzwerk mit Ausnahme des Parent-Interface.

Wenn du die Container IPs nicht händisch vergeben willst, sondern den DHCP-Server vom Internet Protocol Address Management (IPAM) es Docker Netzwerks verwenden willst, solltest Du bei ipvlan/macvlan noch auf folgendes achten:

- Du solltest auch immer die IP-Range im CIDR-Format mit angeben. Diese MUSS außerhalb der DCHP-Range Deines LAN DHCP-Server liegen. Die IP-Range kann so groß sein, wie die DHCP freie Range, kann natürlich auch kleiner sein, sollte sich aber nie am Ende des Subnets befinden.

Portmapping ergibt keinen Sinn mit ipvlan/macvlan, da hier der Container über diese ip erreicht wird. Früher wurde ein zusätzlich angegebgen Portmapping ignoriert. Mittlerweile wirft es korrekterweise einen Fehler.

DENN was ich NICHT hinbekomme ist, dass ich den Container in 3 Netzen erreiche (2x direkt über die IP und 1x über den host 192.168.1.111:8080)

Hier wäre interessant, wie es sich verhält, wenn die Container zusätzlich an einem bridge Netzwerk hängen. Letzteres ist auch nötig, damit ein Container mit ipvlan/macvlan interface mit einem Container kommunizieren können soll, der nur ein bridge Netzwerk besitzt.

Doch es sind immer nur die VLANs erreichbar und wenn ich explizit "host" hinzufüge, dann meckert er, dass es nur einen host Treiber geben darf.

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.

 

[Oekel]

Hier wäre interessant, wie es sich verhält, wenn die Container zusätzlich an einem bridge Netzwerk hängen. Letzteres ist auch nötig, damit ein Container mit ipvlan/macvlan interface mit einem Container kommunizieren können soll, der nur ein bridge Netzwerk besitzt.

Danke für die ausführlichen Antworten.
Tatsälich ist es mir möglich (ich arbeite mit Portainer) im Nachgang an die Kontainer ein Bridge-Netzwerk über die GUI anzuhängen. Und dort werden dann die PortMappings verwendet, die weiter oben als zu ignorieren (bzw. Fehler werfend) deklariert wurden.

PS: Es gab immer schon macvlan und ipvlan? Hatte es in einigen Beiträgen so verstanden, dass ipvaln das "neuere" "bessere" sei und ma macvlan seltener verwenden braucht.

 

[Confluencer]

Ich wusste das bridge+*vlan Netze gleichzeitig von einem Container verwendet werden können. Ich war mir nur nicht sicher, ob gepublishte Ports dann supportet werden. Danke für die Rückmeldung. Ich hoffe ich erinnere mich da noch dran wenn in Jahren der nächste danach fragt

Sagen wir mal so: ich mache seit 10 Jahren Docker und seit einigen Jahren Kubernetes im Firmen-Kontext: ich hab dort noch nie erlebt das macvlan oder ipvlan eingesetzt wurde.

macvlan und ipvlan Leben gefüht schon seit Ewigkeit im Linux Kernel. Docker selbst ist ja primär "nur" schlauer Kleber und Koordinator von Kernel, Bibliothek und Binaries mit dem es seine Magie auf die Beine stellt. Gefühlt ist in Docker der Support von macvlan und ipvlan auch schon ein paar Jahre aus dem Experimentellen Stadium raus. Davon konnte man es aber auch schon etliche Jahre vorher über die Konfiguration anschalten. Ich kann Dir nicht sagen was besser oder neuer ist. Ich beschäftige mich mit beiden nicht und verwende auch kein macvlan oder ipvlan. Bei mir ist alles https traffic, den ich durch einen reverse proxy jage, damit bei richtiger Domain der richtige Container angesprochen wird.