[HowTo] ioBroker unter Docker auf Synology DiskStation
-
Ich habe hier mal ein Beispiel. Nur mit ioBroker-Container und den Netzwerken (MACVLAN + internes Bridge Netzwerk). Werde dazu auch noch ein Tutorial schreiben. Dann aber gleich zusammen mit einem Redis-Container. Dazu muss die aktuelle Beta aber erst zum "latest" werden (wegen der Möglichkeit gleich beim Setup Redis zu konfigurieren).
version: "2" services: iobroker: container_name: iobroker image: buanet/iobroker:latest hostname: iobroker restart: always networks: macvlan: ipv4_address: 192.168.0.73 bridge: ipv4_address: 172.18.0.2 environment: - PACKAGES=nano volumes: - /volume1/docker/iobroker_data:/opt/iobroker networks: macvlan: driver: macvlan driver_opts: parent: eth0 ipam: config: - subnet: 192.168.0.0/24 gateway: 192.168.0.1 ip_range: 192.168.0.72/29 aux_addresses: net-address: 192.168.0.72 # Reservierte Adresse, damit Docker nicht die Netzadresse vergibt. bridge: driver: bridge ipam: config: - subnet: 172.18.0.0/16 gateway: 172.18.0.1 ip_range: 172.18.0.1/24MfG,
André -
@andr @Holzlenkrad Danke euch, das deckt sich fast mit meinen Versuchen.
-
Hallo,
André hat mich hierher verwiesen...ich hoffe, die Frage ist hier richtig, da zwar nicht Synologie, aber das Docker-Image von buanet auf dem Pi verwendet wird...Hakelig für Neulinge ist ja die Netzwerkkonfiguration des Containers. Ich habe folgendes Heimnetzwerk (FritzBox = 192.168.1.1):
Ich wollte (um möglichst nah an Andrés Anleitung zu bleiben) mit MACVLAN arbeiten. Wenn ich das richtig verstanden habe, dann sollte die ioBroker-Installation unter 192.168.1.250 ansprechbar sein für all die anderen Smart-Home-Geräte.
Die Konfiguration habe ich folglich (hoffentlich richtig) so erstellt:
Gegen Ende der Container-Erstellung habe ich von meiner Fritzbox dann auch die Mail bekommen mit der Heimnetzänderung:
Folgendes Problem nun: Ich kann .250 und .16 von meinem Windows-PC aus nicht anpingen (Zeitüberschreitung der Anforderung.) .16 verstehe ich auch nicht, da mein Raspi von der Fritzbox fix die 25 per DHCP zugewiesen bekommt (und darunter auch erreichbar ist). Nach einem Reboot des Raspis habe ich noch ne Mail bekommen, nun soll der Raspi auf .17 laufen, tut er aber nicht (fix auf 25 und ist dort erreichbar).
Hat jemand ne Idee, was ich da falsch mache? Habe ich das Konzept nicht verstanden? Die virtuelle IP von ioBroker (250) sollte doch im gleichen Netz wie alle anderen Geräte sein? Oder hätte ich da z.B. 192.168.2.x für alle Netzwerk-Angaben oben verwenden sollen? Aber dann würde ioBroker mit 192.168.2.250 ja nicht mit den Geräten in 192.168.1.x kommunizieren können, oder?
Viele Grüße, Steffen
-
@stevie77
Hast du gelesen, was "Holzlenkrad" diesbezüglich 14 Beiträge über deinem geschrieben hat?
Beitrag 1683 -
@stevie77 : was ist denn bei Deinem Raspi in den NEtzwerkeinstellungen eingestellt? Eine fixe IP-Adresse (z.B. die 192.168.1.16? ) oder dass er sich die IP von einem DHCP Server abholt?
Außerdem: Hängt Dein Raspi über WLAN oder LAN im Hausnetz?
Ich würde in Deinen Containereinstellungen auch für den iobroker Container mal eine fixe MAc-ADresse einstellen (z.B. die jetzt angezeigt). Bei mir war das z.B. sonst öfeters so, dass er bei ERstellung eines neuen Containers (z.B. wegen update) immer mal gern eine neue MAc-Adresse generiert hat und damit die Fritzbox-Einstellungen scheiterten.
Gruß,
Tim -
@FoodFighter Nee, ich bin irgendwie noch etwas überfordert mit der Erstellung und Darstellung der Beiträge in diesem Forum.
Werde mir das aber gleich mal ansehen und versuchen zu verstehen... 
-
@stevie77
Ansonsten einfach "sudo rpi-update" eingeben, Raspi neustarten und den Docker Container noch mal genau so erstellen (alten sicherheitshalber löschen; das macvlan-Netzwerk musst du nicht neu erstellen), wie du es bisher gemacht hast. Das war nämlich im Endeffekt sogar richtig. -
@ts020339 Der Raspi holt sich die IP per DHCP von der Fritzbox und bekommt dann immer die 25 zugewiesen. Er hängt per Kabel im Hausnetz. Die Fritzbox hat ja auch scheinbar erkannt, dass da jetzt ein neuer "PC" (vergebener Name PC-192-168-1-250) auf 250 liegt (zeigte ihn erst im Abschnitt Aktive Verbindungen an, danach irgendwann im Abschnitt Ungenutzte Verbindungen - wobei da viele Geräte angezeigt werden, die funktionieren).
-
@Holzlenkrad Nur zum Verständnis als Neueinsteiger: Ist die ganze Technik rund um Docker so unzuverlässig, dass man mehrere gleiche Versuche braucht bis es zufällig mal klappt? Oder was ist der Hintergrund dieses Ratschlags (fast alles wegwerfen und dann nochmals gleich machen)?
Mein Vorgehen und Verständnis des Ganzen ist also aber prinzipiell richtig wenn du schreibst, dass "es im Endeffekt sogar richtig" war? Es braucht eine IP (250 bei mir) im gleichen Subnetz (192.168.1.x bei mir) auf der die Heimnetzgeräte dann ioBroker ansprechen können und von ioBroker angesprochen werden, ja? Und als Gateway gibt man die Fritzbox an? -
@stevie77
Nein, Docker funktioniert so wie es soll.Aber der Linux Kernel hat seit Januar einen Bug und mit sudo rpi-update installierst du einfach einen neuen Kernel, ohne Fehler.
Der Vorschlag den Container zu löschen war nur, damit es danach auch sicher klappt. Aber wenn ich noch mal so darüber nachdenke, sollte es auch ohne den Docker Container zu löschen direkt funktionieren.
Wie gesagt, hast du den Kernel von Raspberry Pi schon aktualisiert? Es bringt dir nichts, wenn du jetzt deine Konfiguration hinterfragst, wenn das Problem an einer völlig anderen Stelle liegt...
-
Ich verstehe den ganzen Hype um das MACVLAN noch nicht so ganz recht.
Mag zwar schön und gut sein, dass der Container eine eigene IP bekommt. Jedoch bringt es den Nachteil mit sich, dass z.B. der InfluxDB- oder Mosquitto-Container auf dem gleichen Gerät (Rasppi) nicht mehr erreichbar ist für iobroker, weil beide über die gleiche Netzwerkkarte mit zwei IPs funken.
Grundlegend funktioniert das MACVLAN jetzt, dank dem Kernel-Update...
Ich persönlich sehe aber mehr Sinn in einem Bridge-Netzwerk mit entsprechenden Port-Freigaben.
Oder verdenke ich mich hier irgendwo? -
@FoodFighter Mich hat halt dazu in der Anleitung der Satz "Eine entsprechende (noch unvollständige) Liste der Ports habe ich in der Knowledgebase abgelegt." abgeschreckt. Das könnte für mich als Anfänger zu dem Szenario führen, dass ioBroker nicht ordentlich funktioniert, weil irgendwelche Ports vergessen wurden zu öffnen und ich werde u.U. nie rausbekommen, welche das sein könnten...
-
@FoodFighter said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Jedoch bringt es den Nachteil mit sich, dass z.B. der InfluxDB- oder Mosquitto-Container auf dem gleichen Gerät (Rasppi) nicht mehr erreichbar ist für iobroker, weil beide über die gleiche Netzwerkkarte mit zwei IPs funken.
Hat bei der der InfluxDB Container auch eine eigene IP-Adresse über macvlan? Oder nutzt du da einfach nur den Bridge Mode?
Dass die Docker Container mit macvlan nicht mit dem Host (und entsprechend den Container im Bridge Mode) kommunizieren können, ist ein bekanntes Problem. Das löst man, indem man eine zusätzliche virtuelle Netzwerkkarte auf dem Raspberry Pi erstellt und die mit der physischen verknüpft.
War mir aber zu kompliziert. Ich habe das jetzt so gelöst, dass bei mir iobroker sowohl das macvlan Interface hat, als auch das Bridge Interface zur Kommunikation mit den anderen Containern
-
@Holzlenkrad said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Hat bei der der InfluxDB Container auch eine eigene IP-Adresse über macvlan? Oder nutzt du da einfach nur den Bridge Mode?
InfluxDB, Mosquitto und Portainer laufen im Bridge-Mode. (iobroker im Moment auch noch/wieder)
Pihole läuft im Host-Mode.Das löst man, indem man eine zusätzliche virtuelle Netzwerkkarte auf dem Raspberry Pi erstellt und die mit der physischen verknüpft.
Das klingt mir persönlich auch nach viel zu viel Frickelei und nach unnötigen Fehlerquellen
Ich habe das jetzt so gelöst, dass bei mir iobroker sowohl das macvlan Interface hat, als auch das Bridge Interface zur Kommunikation mit den anderen Containern
DAS klingt nach der Lösung, die ich auch bevorzugen würde! Wie hast du dem Container denn zusätzlich zum macvlan noch das Bridge-Interface eingehängt?
Über Portainer hat man pro Container nur die Möglichkeit ein Netzwerk auszuwählen...oder ich übersehe den Punkt immer und immer wieder.Auf die Weise wär das ganz cool. IOBroker hätte seine eigene IP, Sachen wie COAP (Shellies) würden funktionieren, weil iobroker nicht im virtuellen Docker-Netzwerk versteckt ist, die Kommunikation zwischen den Containern würde funktionieren....Das klingt für mich nach dem ultimativen Masterplan
[edit]
oh...ich lese oben gerade - du hast das über ein docker-compose-yml gemacht.
Dann frage ich mal andersrum -> kann man das auch über Portainer machen? (rein aus Interesse)[edit-edit]
Ja, geht.
Container mit einem Netzwerk erstellen, danach den gestarteten Container anklicken (Übersicht) und dann unten auf "Join Network"Sau Geil...det freut mir - danke!
-
@FoodFighter said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
[edit]
oh...ich lese oben gerade - du hast das über ein docker-compose-yml gemacht.
Dann frage ich mal andersrum -> kann man das auch über Portainer machen? (rein aus Interesse)Hab gerade mal in Portainer rein geguckt, aber da auch keine Möglichkeit gefunden.
Ja genau, per docker-compose. Hat noch weitere Vorteile. Z.B. müssen Ports für den Zugriff auf die Datenbank gar nicht mehr gepublisht werden, wenn ohnehin nur Dienste, die unter Docker laufen in die Influx DB schreiben dürften, weil dann alles Docker-intern abläuft.
Das macht die ganze Sache natürlich noch mal komplexer. Aber wie gesagt, für mich funktioniert es so ganz gut und ich habe mit dem Setup bis jetzt zum Kernel Bug auch noch keine Probleme gehabt.
Edit: Ach super, dass du da im Portainer eine Möglichkeit gefunden hast. Noch besser. Ich nutze den eigentlich nur zum Monitoren meiner Container, also logfiles oder mal Consolenzugriff
-
Man darf dann nur nicht vergessen, dass man dem InfluxDB und Mosquitto-Containern eine feste virtuelle IP zuweist (zB 172.17.0.4) und die Container über die iobroker-Adapter dann auch entsprechend über diese internen IPs ansprechen muss, nicht mehr über die IP vom RaspPi (bei mir zB 192.168.178.11)
-
@Holzlenkrad So, hab nun den Kernel von 4.19.97-v7l+ auf 4.19.114-v7l+ upgedatet (mit Reboot). Das hatte ich sogar schonmal ausgeführt, mich aber von den Warnungen abschrecken lassen und abgebrochen. Danach im ersten Versuch den Container neu erstellt, da kackte die Ausführung des Containers aber nach ner Weile im 2. Schritt des ioBroker-Starts ab. Also habe ich alles nochmals gelöscht und alles von vorne...
Ergebnis nun: Im Logfile sind nun die letzten Einträge Starting ioBroker (was vermutlich richtig ist?)...host.iobroker check instance "system.adapter.admin.0" for host "iobroker" host.iobroker check instance "system.adapter.discovery.0" for host "iobroker" host.iobroker check instance "system.adapter.info.0" for host "iobroker"Ich kann aber die IP 192.168.1.250 immer noch nicht anpingen von meinem Windows-PC 192.168.1.26. So gesehen brachte das keine Veränderung, außer dass im Logfile der vorherige Fehler
2020-04-13T00:59:02.436388708Z Cannot send diag info: ETIMEDOUT 2020-04-13T00:59:10.427076733Z failed to download new sources, use cached sources 2020-04-13T00:59:10.427240080Z Cannot download json from http://download.iobroker.net/sources-dist-hash.json. Error: Error: ETIMEDOUTnicht mehr auftritt.
Doch was falsch mit meiner Netzwerkkonfiguration?
Mod-Edit: Code/Log in Code Tags gepackt. Bitte benutzt die Code Tags Funktion -> </>
Hier gehts zur Hilfe. -
@Holzlenkrad Trotz Kernel-Update scheine ich immer noch genau an dem Problem zu hängen. Bin jetzt einen Schritt weiter: Wenn ich aus dem ioBroker-Container heraus meinen Windows-Rechner 192.168.1.26 anpinge, dann kann ich auch plötzlich vom Windows-Rechner .26 auf die ioBroker-Installation 192.168.1.250 zugreifen und die GUI von ioBroker im Browser aufrufen. Und mit meinem Notebook mit ip .24 verhält es sich exakt gleich. Das ist ja genau der Kernel-Bug, ne?
Was kann man als Linux-Anfänger beim Kernel-Update falsch machen? Deinen genannten Befehl duo rpi-update habe ich ohne Fehlermeldungen bis zum Ende ausgeführt. uname -r zeigt den neuen Kernel 4.19.114-v7l+ an. Muss man den Kernel irgendwie noch committen/aktivieren o.ä.? Reboot habe ich gemacht, Raspi war auch mal stromlos...
-
@stevie77
Ja, genau das sind die Symptome des Kernel-Bugs.
Du hast aber auch recht, dass bei dir der Kernel aktuell ist, wie er soll.Ich kann mir nur vorstellen, dass irgendein Teil deines Setups bzw. Netzwerk eben doch noch eine fehlerhafte ARP Tabelle hat.
Die Container hattest du in Portainer mal komplett gelöscht? Vielleicht auch mal das macvlan löschen?
Ansonsten könntest du auch mal die IP-Adresse ändern (also 192.168.1.250) und gucken ob es dann direkt funktioniert. Danach kannst du ja wieder zurück auf 250 gehen.Was mir noch gerade auffällt, wieso nutzt du eigentlich bei der IP-Range vom macvlan Netzwerk als Größe 32Bit? Bei der Subnetmask ist die Anzahl der verfügbaren IP-Adressen dann eigentlich 0. Lieber mal 30 oder eine kleiner Zahl nutzen.
Stand das in irgendeiner Anleitung so drin? -
@stevie77
Ich bin genau so vorgegangen, wie du es auch beschreibst -> rpi-update, anschließend sudo reboot, seitdem funktioniert das bei mir einwandfrei mit dem macvlan.
Mein Kernel ist ebenfalls auf 4.19.114-v7l ... dementsprechend solltest du wohl nichts falsch gemacht haben.
Das hilft dir jetzt zwar nicht wirklich weiter, ich hätte aber auch keine spontane Idee, was da bei dir anders sein soll.
Vllt. einfach mal ein
sudo apt-get update
gefolgt von
sudo apt-get upgrade
ausführen? (kann wohl nicht schaden mal alles auf den aktuellsten Stand zu bringen)
Ebenfalls wäre es noch eine Grashalm-Idee die IP vom MACVLAN mal von 250 auf z.b. 252 zu ändern.
(Achtung: Dein DHCP-Bereich hast du m.M.n. sehr groß gewählt (.2 - .249) -> Aufpassen, dass Geräte mit Statischen IPs außerhalb dieses Bereiches liegen und/oder nicht zufällig eine bereits per DHCP vergebene IP bekommen. Dir bleiben als statische IPs prinzipiell nur .250-.254 (.255 = Broadcast) Man kann zwar auch IPs aus dem DHCP-Bereich statisch vergeben, das kann aber auch zu Kollisionen führen)Alternativ - wenn auch nur ein Workaround, weil du scheinbar das macvlan gerne nutzen möchtest - könntest du den Container auf Bridge-Mode umstellen und erstmal die Ports 8081 & 8082 freigeben / publishen.
Sobald dir irgendwo benötigte Port-Freigaben über den Weg laufen, merkst du das eigentlich recht schnell daran, dass die gewünschte Seite eben einfach nicht erreichbar ist.
André hat hier schon eine sehr nutzige Aufzählung gestartet, die erstmal alles abdecken sollte.
node-red (1880), mqtt (1883) dürften schnell interessant werden
Falls du mit weiteren mqtt-Servern wie dem sonoff- oder dem shelly-adapter arbeitest, wirst du spätestens in der Einstellung des Adapters über den benötigten bzw. einstellbaren Port stolpern.
(Bei shelly ist das default 1882, bei sonoff 1883 - muss aber geändert werden, sofern ein anderer MQTT-Broker auf dem Port läuft)
Erreichbar ist die Admin-Seite dann unter der IP des RaspPis 192.168.1.16:8081
