[Frage] [V4.0.1] Einrichtung von MacVLAN - Detailfragen

[speckenbuettel]

Hallo,

angeregt durch diesen Beitrag viewtopic.php?f=25&t=1669&p=56593&hilit=macvlan#p56564 habe ich mich heute daran gemacht, MacVLAN einzurichten.

Die gute Nachricht: die Umstellung des TWS ist einfach und es geht dabei nichts "kaputt" - anders als man es hinsichtlich der Warnung, die nach dem Aktivieren von MacVLAN im TWS erscheint vermuten würde

Also habe ich zunächst den TWS umgestellt, dann hat er von meiner FritzBox erwartungsgemäß eine neue IP-Adresse zugewiesen gekommen.
Anschließend habe ich in der FritzBox dem TWS wieder die alte IP-Adresse zugewiesen, damit alle Links weiterhin funktionieren. Dann erst TWS und danach die FritzBox neu gestartet. Soweit, so gut. Alles funktioniert, vor allem die diversen MQTT-Verbindungen, die ich inzwischen angesammelt habe.

Anschließend wollte ich gem. KB-Artikel app.php/kb/viewarticle?a=19 und Beitrag viewtopic.php?f=25&t=203#p12829 das Netzwerk im Portainer anlegen. Allerdings ist dabei die erste Frage aufgetreten, denn in der KB im Screenshot ist "Access Control" aktiviert, in diesem Artikel viewtopic.php?f=25&t=1669&p=56593&hilit=macvlan#p56564 hingegen nicht. Was ist richtig? Macht es einen Unterschied? Wenn ja, was sind die Auswirkungen?

Die nächste Frage kam auf bei der Erstellung eines neuen Containers. Was genau muss man unter "Advanced Container Settings/Network" eintragen?
In diesem Artikel app.php/kb/viewarticle?a=69 ist zwar anhand des Beispiels Unifi detailliert beschrieben, wie man einen Container mit MacVLAN einrichtet, woher die einzelnen Daten kommen ist mir jedoch nicht klar:



Network: ist klar, hier wählt man aus dem Dropdown-Menü das zuvor erstellte MacVLAN aus
Hostname: ein frei zu vergebender Name für diesen Container (der dann z. B. in der FritzBox als Gerätename angezeigt würde)?
Domain: keine Ahnung ...
Mac Address: gibt man hier eine beliebige (gültige) Mac-Adresse ein?
IPv4 Address: das ist klar, es sollte die gewünschte feste IP-Adresse des Containers im Adressbereich des Heimnetzes sein.

Ich danke euch für weitere Hinweise zur Einrichtung.

Vielen Dank und viele Grüße
Falk

[AndererStefan]

Hallo Falk,

ich wusste auch nicht, was ich eintragen soll und habe die Felder Domain Name und MAC leer gelassen.
Die MAC-Adresse wird beim Erstellen automatisch (durch einen Zufallswert?) gefüllt. Domain bleibt leer. Beim Hostnamen habe ich einen gewählt, aber die Fritzbox kennt den Namen nicht und die Namensauflösung funktioniert nicht. Der Container ist nur über die IP erreichbar.
Evtl. liegt das aber auch einen Konfigurationsfehler....

[starwarsfan]

Hallo miteinander

Beim Hostnamen habe ich einen gewählt, aber die Fritzbox kennt den Namen nicht und die Namensauflösung funktioniert nicht. Der Container ist nur über die IP erreichbar.

Alles andere hätte mich auch sehr gewundert.

Etwas provokant gesagt: MacVLAN ist eine Krücke, welche über Docker-Container gestülpt wird, wenn das Prinzip von Docker entweder nicht verstanden wurde oder aus irgendwelchen anderen mehr oder weniger fadenscheinigen Gründen umgangen werden soll. Der Klassiker ist hier das Argument mit der festen IP für den Container aber das will ich gar nicht weiter ausbreiten...

Ein Docker-Image resp. der daraus erzeugte Container macht normalerweise keinen entsprechenden Eintrag im jeweiligen DHCP um sich dort zu registrieren, da es das nicht braucht. Docker spannt für die Container ein eigenes Netz auf (per Default AFAIK im 172.17.0.0/24-Range), innerhalb dessen sich die Container mit ihrem Namen finden und ansprechen können. Die Verbindung "nach draussen" macht dabei der Docker-Daemon, weshalb sich ein Container eben nicht um die Registrierung im Netzwerk kümmern muss.

In die andere Richtung routet entweder der Docker-Daemon gezielt die Ports zu den entsprechenden Containern oder aber es läuft ein ReverseProxy im gleichen Docker-Netz, welcher dann seinerseits auf die Container resp. die dortigen Ports weiterleitet. Somit braucht ein Container im Normalfall keine eigene IP sondern das läuft genau so, wie es der ReverseProxy im TW macht. Der Zugriff auf <timberwolf-url>/<pfad> leitet zum entsprechenden Container weiter.

"Das ist der Weg!"

[gbglace]

Hi Yves,

Bei mir scheitert es allerdings einfach daran die Orchestrierung vom Port-Mapping nicht haben zu wollen und mit der Konfiguration von Proxy komme ich gleich gar nicht zu recht. Da fehlt mir leider jedwedes technische Verständnis.
Daher habe ich mich für den MAC-VLAN Weg entschieden.
Das es da eine statische IP-gibt ist nebensächlich. Angenehm ist nur das es damit je Container eine Repräsentanz in der Fritze gibt.

Ja die Anzahl Netzwerkteilnehmer erhöht sich damit um die Zahl der Container aber noch komme ich da mit den 256 Adressen hin.

[Eraser]

... noch komme ich da mit den 256 Adressen hin.

254 sind nur verwendbar...

[AndererStefan]

Ja, mir geht das ähnlich.
Bei nodered ist das mit dem proxy wohl auch nicht so einfach… Ich hatte da kurz recherchiert und war dabei geendet, dass Anpassungen im Container notwendig wären.

[speckenbuettel]

Hallo zusammen,

vielen Dank für eure Antworten.

@AndererStefan Danke Stefan, mit den Infos habe ich es jetzt hinbekommen, MacVLAN läuft.

@starwarsfan Ich mag deine knackigen Aussagen, Yves, um Dinge auf den Punkt zu bringen. Auch in diesem Fall hast du wohl recht: es ist eine Krücke, aber die Krücke hilft dem Lahmen zum Gehen, um im Bilde zu bleiben

@gbglace Genau das ist auch meine Intention, Göran. Ich habe es mit dem Reverse Proxy im Timberwolf nicht hinbekommen, einen Container direkt, ohne den Port, anzusprechen. Mit MacVLAN geht es über die eigene IP einwandfrei.
Und das Problem der Portbelegung, wie im Knowledge-Base-Artikel zu MacVLAN genannt, ist damit genauso umgangen wie die Pflege von Portlisten für diesen oder jenen Container.

Vielen Dank und viele Grüße
Falk

[starwarsfan]

Hallo Falk

@starwarsfan Ich mag deine knackigen Aussagen, Yves, um Dinge auf den Punkt zu bringen. Auch in diesem Fall hast du wohl recht: es ist eine Krücke, aber die Krücke hilft dem Lahmen zum Gehen, um im Bilde zu bleiben

Danke, damit hat Du zweifelsohne Recht.

Ich habe es mit dem Reverse Proxy im Timberwolf nicht hinbekommen, einen Container direkt, ohne den Port, anzusprechen.

Hm, interessant. Dann will ich mal kurz ein wenig ausholen.

Sofern man ein Image so verwendet, wie es von dessen Entwicklern vorgesehen ist, braucht es auf Seite TW nicht wirklich viele Settings. Zunächst ermittelt man die IP den Containers im Docker-Netz. Dazu die Portainer-Seite öffnen und die laufenden Container anzeigen lassen. Dort sieht man die IPs der Container. Das sieht dann bspw. so aus:



Mit diesen Angaben werden die gewünschten Forwardings eingerichtet. Das kann dann bspw. so aussehen:



Damit habe ich saubere sprechende URLs, welche vom TW an die jeweiligen Dienste weitergeleitet werden.

[starwarsfan]

Hallo nochmal

Ich habe es mit dem Reverse Proxy im Timberwolf nicht hinbekommen, einen Container direkt, ohne den Port, anzusprechen. Mit MacVLAN geht es über die eigene IP einwandfrei.

Was ich noch gar nicht erwähnt habe: Mit MacVLAN hat man mit so gut wie jedem Container das Problem, dass man den jeweiligen Port des Dienstes im Container explizit verwenden muss, sofern der Container nicht auf Port 80 lauscht! Von Port 443 aka https ganz zu schweigen.

Es ist zwar schön einfach, direkt auf die IP des Containers zuzugreifen aber wenn der Dienst dort drin auf Port 8080 läuft, dann muss man auch explizit Port 8080 angeben. Dieses Problem hat man bei Verwendung des ReverseProxy nicht, weil der eben auch auf den konfigurierten Port weiterleitet (und dabei gleich noch die https-Terminierung macht).

[jhaeberle]

Was ich noch gar nicht erwähnt habe: Mit MacVLAN hat man mit so gut wie jedem Container das Problem, dass man den jeweiligen Port des Dienstes im Container explizit verwenden muss, sofern der Container nicht auf Port 80 lauscht! Von Port 443 aka https ganz zu schweigen.

Es ist zwar schön einfach, direkt auf die IP des Containers zuzugreifen aber wenn der Dienst dort drin auf Port 8080 läuft, dann muss man auch explizit Port 8080 angeben. Dieses Problem hat man bei Verwendung des ReverseProxy nicht, weil der eben auch auf den konfigurierten Port weiterleitet (und dabei gleich noch die https-Terminierung macht).

Stimmt, aber dafür kann (oder besser: sollte) man ja den schon auf dem TWS vorhandenen Portainer nehmen, mit dem du für jeden Container ja auch einen RevProxy konfigurieren kannst.

Ich denke, es ist Geschmacksache. Der eine mag seine TWS-URL mit einem Verzeichnisanhang, den er (oder sie) sich merken und diese eintippen muss, der andere hat lieber einen weiteren Hostnamen.
Okay, Ausnahmen bestätigen die Regel, manche Dienste vertragen sich nicht gut mit einem ReverseProxy, da kommt man dann um den Port nicht rum.

Gruß
Jochen