ElabNET Technik Forum

Bei vielen Themen ist das wirklich ein Klotz am Bein.
Container knxdmxd > KNX
Container Edomi > KNX
Container influx > TWS Grafana
Container2host Problem

Mit der Anleitung wie von @tger977 schon mal angehängt. Funktioniert bei mir einwandfrei auf meiner Entwicklungsumgebung.

War eigentlich ganz einfach zu lösen.

Zu Beispiel so.

1. macvlan0 über Portainer konfiguriert
2. Netzwerk konfiguration Der Ausschlaggebende Punkt ist, dass nicht eth1 die IP bekommt sondern das macvlan0

Ich könnte mir auch wie Andi vorstellen dass z.B. eth2 von euch mit dem macvlan vorkoniguriert wird.
Würde meinen Server dafür bereit stellen und testen.
Wie man das in die Oberfläche integriert ist wahrscheinlich der schwierigere weg.
Einfach einen hacken an der NW Konfiguration TWS-macvlan aktivieren.

Wie schaut es mit zwischen zeitlichen alternativen aus?

Würde es als übergang funktionieren mit zwei IP Adressen vom Heimnetzwerk eth0 und eth1 (zwei separate Ports vom Switch)?
Update > mit 2 IP Adressen funktioniert das ganze inzwischen. Die Lösung ist nich ganz so prikelnd

Wieso muss es immer macvlan sein? OK, es gibt manche Szenarien da ist funktioniert Bridging nicht (Multicast bei Sonos) aber das dürfte die Ausnahme sein. Teste doch mal Bridge.

Da hast du sicher recht, aber für mich macht es Sinn den wichtigen Containern eine eigene IP zuweisen bzw. die die einen Server ersetzen wie Edomi, iobroker, openhab usw.

Z.B. Ich informiere mich gerade über influxdb im Docker, der Standardport ist 8086 nun hat er Host den Port 8086 wahrscheinlich schon belegt.
Obwohl in der Knowledge Base - 4.4.3 Belegte IP Ports im TWS dieser nicht angegeben ist.

Bei diesem Container könnte ich ja bridged verwenden und den Port auf 8087 umbiegen, aber ich habe dann das selbe Problem mit dem macvlan dass ich keine Daten von Edomi zur influxdb bringe.

Wenn du von Container auf Container zugreifen willst, dann musst du den Port NICHT nach außen veröffentlichen. Nur dann halt nicht die IP des Docker Hosts angeben, sondern die des Containers (172.x.x.x) - die wird im Portainer angezeigt.

Der Docker Grundgedanke ist nicht die Container wie VMs mit eigener IP, Hostname usw zu betrachten. Es soll nur das veröffentlich werden, was auch benötigt ist. Der Host kümmert sich dann auch um Dinge wie Firewall usw, nicht der Container.

Für Webseiten hilft dann auch der in den TWS integrierte Reverse Proxy, sodass ein Container theoretisch keine Ports nach außen veröffentlichen müsste.

Danke für die Info bin auch noch recht neu in diesem Thema.

Wenn ich aber als Beispiel Edomi hernehme, dieser wird auch ständig um Funktionen und Logikbausteine erweitert die dann auch neue Ports benötigen.
Nicht von Container zu Container sondern z.B. RFID Lesegeräte, KWL, Homematic, PV,
Da habe ich einfach bedenken dass ich irgendwann ein Port-Monster habe

Für andere Sachen muss ich mich noch damit anfreunden ist halt schon ein umdenken von VM auf Docker.

Ist es also jetzt schon möglich von einem bridged Container auf die KNX-Schnittstelle des TWS zu zugreifen?
Dachte das funktioniert auch noch nicht.