7
Docker auf tagged-Server - je Container flexibel VLAN wählen
Hallo,
Ausgangspunkt:
br.b 192.168.20.100
br.c 192.168.30.100
Ziel:
192.168.20.100:8884
192.168.30.100:8885
um sie nur dem jeweiligen VLAN zur Verfügung zu stellen
Derzeit: die Apps sind immer nur erreichbar via 192.168.10.100:8883 | 192.168.10.100:8884 | 192.168.10.100:8885, also zur IP des Docker Hosts.
Frage: Wie kann ich docker (daemon.json?)/docker network vorbereitend einrichten, um letztlich für jede App nur im docker-compose.yml (wie?) fest zu legen, dass sich die compose-bridge einer gestarteten Applikation mit einer definierten netplan-bridge verbindet (oder zur Not direkt in der netplan-bridge arbeitet), OHNE eine feste IP zu wählen. Die soll ja zentral vom Router kommen.
Danke!
Ausgangspunkt:
- Tagged ubuntu-Server hinter Router mt x VLAN
- IP-Adressen per DHCP vom Router (auf dem Server sollen keinerlei IP-Adressen feste vergeben werden)
- Netplan: 1x NIC, 3x VLAN (vlanb.a|vlan.b|vlan.c), 3x bridge mit IP via DHCP z.B.:
br.b 192.168.20.100
br.c 192.168.30.100
- Docker in daemeon.json bereits auf Subnetz 172.17.0.0/16 festgelegt
Ziel:
- z.B. drei Applikationen zu starten, je eine in jedem VLAN:
192.168.20.100:8884
192.168.30.100:8885
um sie nur dem jeweiligen VLAN zur Verfügung zu stellen
- es ist NICHT Ziel, die Container (vielmehr: App/Pods via docker-compose) mit je einer IP zu versehen, sondern wie üblich via Port anzusprechen.
- Daher scheint mir macvlan und ipvlan der falsche Lösungsansatz, richtig? Hierzu gibt es einen Haufen Doku/Beispiel, aber es geht in die falsche Richtung. Und arbeiten stets mit hier festgelegten IP-Adressen - was neben dem Port-statt-IP--Ansatz dem zentralen DHCP-Ansatz widerspricht.
Derzeit: die Apps sind immer nur erreichbar via 192.168.10.100:8883 | 192.168.10.100:8884 | 192.168.10.100:8885, also zur IP des Docker Hosts.
Frage: Wie kann ich docker (daemon.json?)/docker network vorbereitend einrichten, um letztlich für jede App nur im docker-compose.yml (wie?) fest zu legen, dass sich die compose-bridge einer gestarteten Applikation mit einer definierten netplan-bridge verbindet (oder zur Not direkt in der netplan-bridge arbeitet), OHNE eine feste IP zu wählen. Die soll ja zentral vom Router kommen.
Danke!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 529324
Url: https://administrator.de/forum/docker-auf-tagged-server-je-container-flexibel-vlan-waehlen-529324.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
7 Kommentare
Neuester Kommentar
Ich glaube du hast einen gravierenden Denkfehler. Nicht nur wegen vlanb.a sondern auch bei der vlan config der Container per se...Mal dir Mal einen Plan. Die internen Ports interessieren so doch gar nicht
1
Ein Denkfehler meinerseits wäre prima (weil schnell zu lösen)... 
... aber ich sehe ihn noch nicht...
Docker Standard: untagged Server: Docker mit x Diensten --> 1x IP (=Subnetz) mit x Ports
Mein Ziel: tagged Server: Docker mit x Diensten --> verteilt auf 3 VLAN (via 3 IP aus 3 Subnetzen) mit diversen Ports
Die Ports waren bei mir nur irgend welche als Beispiel - welche sind hier natürlich völlig unerheblich.
Wie ich dahin komme (ob mit vlan-bridge oder was auch immer), ist Kern meiner Frage und lasse mich sehr gerne auf einen besseren Pfad bringen. Was ich nicht möchte, sind IP-Adressen auf einem Server festzulegen und ich möchte für jeden Dienst im compose.yml nur das VLAN festlegen können. Zum Wie bin ich völlig frei. Ich kann an Netplan und an Docker noch alles anpassen, was erforderlich ist.
... aber ich sehe ihn noch nicht...Docker Standard: untagged Server: Docker mit x Diensten --> 1x IP (=Subnetz) mit x Ports
Mein Ziel: tagged Server: Docker mit x Diensten --> verteilt auf 3 VLAN (via 3 IP aus 3 Subnetzen) mit diversen Ports
Die Ports waren bei mir nur irgend welche als Beispiel - welche sind hier natürlich völlig unerheblich.
Wie ich dahin komme (ob mit vlan-bridge oder was auch immer), ist Kern meiner Frage und lasse mich sehr gerne auf einen besseren Pfad bringen. Was ich nicht möchte, sind IP-Adressen auf einem Server festzulegen und ich möchte für jeden Dienst im compose.yml nur das VLAN festlegen können. Zum Wie bin ich völlig frei. Ich kann an Netplan und an Docker noch alles anpassen, was erforderlich ist.
Ich glaube, das Konzept an sich ist bereits das Problem (mal so eine Vermutung.) Was hast du denn vor (gerne PM, ggf Mail wenn was größeres).
Netzwerk mit diversen VLAN-Schichten. Server stand mit diversen Diensten in einem mittleren VLAN/SUbnetz, damit das FW-Konzept "nur von innen nach außen" passt. Doch spätestens bei Multicast-Diensten wurde das unglücklich und kompliziert bis hin zu "funktioniert nicht" bzw. waren viel zu viele FW-Regeln nötig.
Daher neuer Ansatz: tagged Server, der Docker-Dienste im jeweils erforderlichen VLAN anbietet - sauber/hart getrennt. Dazu gehören auch Multicast-Themen. Da die Dienste dann bereits im richtigen Subnet bereits stehen, wird die FW erheblich einfacher.
Aus den Erfahrungen der Vergangenheit sah ich Handlungsoptionen:
Neben Docker sollen künftig auch LXD (ebenfalls VLAN-flexibel) zum Einsatz kommen, weil Docker ganz sicher nicht die Antwort auf alle Fragen ist, sondern nur für manche. Aber LXD ist noch ein anderes Thema und hier nicht relevant
Hose Runter... Im Router habe ich hinreichend viel VLAN-Erfahrung, aber einen tagged Server habe ich noch nie aufgesetzt.
Daher...Denkfehler-Modus: Offen für frische Gedanken...
Daher neuer Ansatz: tagged Server, der Docker-Dienste im jeweils erforderlichen VLAN anbietet - sauber/hart getrennt. Dazu gehören auch Multicast-Themen. Da die Dienste dann bereits im richtigen Subnet bereits stehen, wird die FW erheblich einfacher.
Aus den Erfahrungen der Vergangenheit sah ich Handlungsoptionen:
- 3 Server (HW), je untagged und dediziert je VLAN. Teuer, schlechte HW-Auslastung, aber banal/einfach/bekannt.
- 1 Server tagged, 1x Docker und die Dienste (üblicherweise ja Port-differenziert - das kenne/beherrsche ich seit Jahren mit Router und RevProxy) kann ich simpel auf die VLAN verteilen. Das schien mir die beste Optionen. Netplan mit NIC, VLAN war schnell gemacht. An Docker saß ich viele Stunden erfolglos - vermutlich wegen eines Denkfehlers... Ich kann auch mit macvlan/ipvlan und vielen IP-Adressen leben, aber das Problem scheint ähnlich: IP sollen immer vom Router kommen, weil wer will schon dezentral in den Servern IP-Adressen festlegen.
- 1 Server tagged, 3x Docker parallel (je 1 pro VLAN) - ob das geht?
Neben Docker sollen künftig auch LXD (ebenfalls VLAN-flexibel) zum Einsatz kommen, weil Docker ganz sicher nicht die Antwort auf alle Fragen ist, sondern nur für manche. Aber LXD ist noch ein anderes Thema und hier nicht relevant
Hose Runter...
Im Router habe ich hinreichend viel VLAN-Erfahrung, aber einen tagged Server habe ich noch nie aufgesetzt.Daher...Denkfehler-Modus: Offen für frische Gedanken...
also entweder ich kann dir nicht mehr folgen (wirklich nicht), es fehlt eine essentielle Information, oder das ist so ein "gegenwandrenn,weilsoschön" Projekt.
Was hast du denn mit den Multicast Paketen vor bzw wohin oder wovon sollen die kommen? Bzw, sicher, dass die überhaupt durch container und dockerhost kommen? (vermute, das funktioniert "so" - per forum - schlicht nicht...)
Was hast du denn mit den Multicast Paketen vor bzw wohin oder wovon sollen die kommen? Bzw, sicher, dass die überhaupt durch container und dockerhost kommen? (vermute, das funktioniert "so" - per forum - schlicht nicht...)
Die Mulitcast-Dinge sind kein Docker-Themen (wird im LXD wichtig), aber für mich ein wichtiger Baustein, warum ich das aktuelle Konzept nicht weiter so fahren möchte und alternativ mir sonst nur mit weiteren Server/HW in weiteren Subnets zu helfen wüsste?
Dann lass mein Ziel mal gegen "gegenwandrenn,weilsoschön" prüfen. Sollte es ein solches Projekt sein, gehe ich gerne eine anderen Weg und bin Dankbar für Deine Gedanken dazu:
Wenn jede der Antworten "sinnvoll" lautet, dann stellt sich die Frage: Wie macht man das? Am besten richtig?
Dann lass mein Ziel mal gegen "gegenwandrenn,weilsoschön" prüfen. Sollte es ein solches Projekt sein, gehe ich gerne eine anderen Weg und bin Dankbar für Deine Gedanken dazu:
- Docker auf Server ist ein sinnvolles Kontrukt für Dienste"
- In einem VLAN-segmentierten Netz ergibt es Sinn, Dienste im richtigen Subnet laufen zu lassen und nicht per FW aus anderen VLAN heraus"
- Eine Lösung: Tagged-Server bietet Docker-Dienste im jeweils erforderlichen/richtigen Subnet an
Wenn jede der Antworten "sinnvoll" lautet, dann stellt sich die Frage: Wie macht man das? Am besten richtig?
Hallo,
Gerade das wage ich mal zu bezweifeln.
Den Server und den Client im selben Netz zu betreiben würde ich aus Sicherheitsgründen gar nicht machen.
Der Server braucht für das Update Quellen die der Client nicht benötigt. Der Server stellt evtl. noch andere Dienste zur Verfügung.
Für mich gehört ein Server immer in ein eigenes Vlan.
Brammer
Zitat von @natuerlich:
- In einem VLAN-segmentierten Netz ergibt es Sinn, Dienste im richtigen Subnet laufen zu lassen und nicht per FW aus anderen VLAN heraus"
Gerade das wage ich mal zu bezweifeln.
Den Server und den Client im selben Netz zu betreiben würde ich aus Sicherheitsgründen gar nicht machen.
Der Server braucht für das Update Quellen die der Client nicht benötigt. Der Server stellt evtl. noch andere Dienste zur Verfügung.
Für mich gehört ein Server immer in ein eigenes Vlan.
Brammer
