NEWS
[HowTo] ioBroker unter Docker auf Synology DiskStation
-
@andre said in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Build ist durch, Version gerade raus: https://github.com/buanet/docker-iobroker/releases/tag/v5.1.0
Image steht im Docker Hub zur Verfügung.
MfG,
AndréOK, habe jetzt von der Beta Version ein Backup erstellt (über BackitUp Adapter), ein neues Datenverzeichnis auf meiner DiskStation erstellt, dass Backup File dort hinein kopiert und mir die latest-v5 gezogen. Habe den Cointainer neu aufgesetzt (mit denselben Einstellungen wie mit der Beta, also Multihost master).
Die Logs sehen auch gut aus. Das Backup File wurde erkannt, ein Restore erfolgreich durchgeführt. Leider kann ich jetzt aber über den Browser nicht mehr auf die ioBroker Oberfläche zugreifen. Ein Ausflug in den Terminal zeigt aber, dass der ioBroker läuft.
Muss ich bei einem Restore auf irgendetwas Besonderes achten?
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
OK, habe jetzt von der Beta Version ein Backup erstellt (über BackitUp Adapter), ein neues Datenverzeichnis auf meiner DiskStation erstellt, dass Backup File dort hinein kopiert und mir die latest-v5 gezogen.
Warum? Das brauchst du nur machen wenn du z.B. Von v4 auf v5 migrierst. Innerhalb der v5 (auch von beta auf latest) muss das nicht sein. Sichere den eingehängten iobroker Ordner und häng ihn so wie er ist in den neuen Container...
Lies mal hier: https://smarthome.buanet.de/2020/10/iobroker-docker-image-updates-upgrades/
MfG,
André Germann -
@Glasfaser said in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Dein Hostname hat sich geändert ....
mache mal das:
iobroker host this
Wenn ich den Container stoppe, komme ich logischerweise nicht mehr ins Terminal. Wie kann ich also den Host anpassen?
-
@Glasfaser said in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Dein Hostname hat sich geändert ....
mache mal das:
iobroker host thisWenn ich den Container stoppe, komme ich logischerweise nicht mehr ins Terminal. Wie kann ich also den Host anpassen?
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
iobroker host this
in der Konsole
pkill -u iobroker iobroker host thisund dann den Container neu starten
-
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
OK, habe jetzt von der Beta Version ein Backup erstellt (über BackitUp Adapter), ein neues Datenverzeichnis auf meiner DiskStation erstellt, dass Backup File dort hinein kopiert und mir die latest-v5 gezogen.
Warum? Das brauchst du nur machen wenn du z.B. Von v4 auf v5 migrierst. Innerhalb der v5 (auch von beta auf latest) muss das nicht sein. Sichere den eingehängten iobroker Ordner und häng ihn so wie er ist in den neuen Container...
Lies mal hier: https://smarthome.buanet.de/2020/10/iobroker-docker-image-updates-upgrades/
MfG,
André Germann@andre said in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Warum? Das brauchst du nur machen wenn du z.B. Von v4 auf v5 migrierst. Innerhalb der v5 (auch von beta auf latest) muss das nicht sein. Sichere den eingehängten iobroker Ordner und häng ihn so wie er ist in den neuen Container...
Ja, das hatte ich auch zuerst so gemacht. Damit kam ich zwar wieder auf die Web-Oberfläche, allerdings lief dann ein Click auf "Adapter" oder "Logs" völlig ins Leere.
Ich vermute, dass liegt dann auch daran, dass ich den Hostnamen geändert habe.
-
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
iobroker host this
in der Konsole
pkill -u iobroker iobroker host thisund dann den Container neu starten
-
@andre said in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Warum? Das brauchst du nur machen wenn du z.B. Von v4 auf v5 migrierst. Innerhalb der v5 (auch von beta auf latest) muss das nicht sein. Sichere den eingehängten iobroker Ordner und häng ihn so wie er ist in den neuen Container...
Ja, das hatte ich auch zuerst so gemacht. Damit kam ich zwar wieder auf die Web-Oberfläche, allerdings lief dann ein Click auf "Adapter" oder "Logs" völlig ins Leere.
Ich vermute, dass liegt dann auch daran, dass ich den Hostnamen geändert habe.
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
allerdings lief dann ein Click auf "Adapter" oder "Logs" völlig ins Leere.
.... das kommt meistens , wenn der Verwahrungsort nicht genutzt werden kann .
dann kommt meistens soetwas im Log :
warn warning: Cannot read "http://download.iobroker.net/sources-dist-latest.json"siehe dazu hier :
https://forum.iobroker.net/topic/31973/latest-repo-funktioniert-oder-nicht -
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
allerdings lief dann ein Click auf "Adapter" oder "Logs" völlig ins Leere.
.... das kommt meistens , wenn der Verwahrungsort nicht genutzt werden kann .
dann kommt meistens soetwas im Log :
warn warning: Cannot read "http://download.iobroker.net/sources-dist-latest.json"siehe dazu hier :
https://forum.iobroker.net/topic/31973/latest-repo-funktioniert-oder-nicht@Glasfaser
Habe den Thread mal überflogen...Ich habe bei mir aber gar nichts an den Repos geändert. Ins Log kann ich auch nicht schauen, zumindest nicht über die Weboberfläche, weil es eben komplett leer ist.
Ich denke, es liegt eher - wie von dir richtigerweise bemerkt - an dem geänderten Hostnamen.
-
@Glasfaser
Habe den Thread mal überflogen...Ich habe bei mir aber gar nichts an den Repos geändert. Ins Log kann ich auch nicht schauen, zumindest nicht über die Weboberfläche, weil es eben komplett leer ist.
Ich denke, es liegt eher - wie von dir richtigerweise bemerkt - an dem geänderten Hostnamen.
Ist der Hostname evtl. in einer Konfigurationsdatei gespeichert, sodass ich ihn händisch anpassen könnte?
-
@Bongo sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Ich vermute was zuletzt gestartet war wird nach einem Reboot wieder gestartet.
So ist es bei reboot eigentlich. Die Restart Policy sagt eigentlich nur, was passiert wenn der container fehl schlägt...
Bisher hatte ich aber auch noch nie Probleme mit dem Restart der DS...@andre sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
So ist es bei reboot eigentlich. Die Restart Policy sagt eigentlich nur, was passiert wenn der container fehl schlägt...
Bisher hatte ich aber auch noch nie Probleme mit dem Restart der DS...So jetzt habe ich tatsächlich den Fall das sich meine DS918+ wieder aufgehängt hat und ich den Stecker ziehen musste. Und siehe da, der Container wo ich Restart policy auf Always gestellt hat wurde gestartet. Die anderen nicht.
Es macht also schon Sinn diese Einstellung zu machen.Ich habe es nun auch beim ioBroker-Container gemacht. Habe aber nicht gewußt, dass beim Deploy gleich das Update von 5.0 auf 5.1 gemacht wird. Jetzt steht der Status auf healthy. ioBroker funktioniert aber.
Wenn ich das Update richtig verstehe ist das neu rein gekommen. Aber wie gehts jetzt weiter? Muss ich da was machen?
-
@andre sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
So ist es bei reboot eigentlich. Die Restart Policy sagt eigentlich nur, was passiert wenn der container fehl schlägt...
Bisher hatte ich aber auch noch nie Probleme mit dem Restart der DS...So jetzt habe ich tatsächlich den Fall das sich meine DS918+ wieder aufgehängt hat und ich den Stecker ziehen musste. Und siehe da, der Container wo ich Restart policy auf Always gestellt hat wurde gestartet. Die anderen nicht.
Es macht also schon Sinn diese Einstellung zu machen.Ich habe es nun auch beim ioBroker-Container gemacht. Habe aber nicht gewußt, dass beim Deploy gleich das Update von 5.0 auf 5.1 gemacht wird. Jetzt steht der Status auf healthy. ioBroker funktioniert aber.
Wenn ich das Update richtig verstehe ist das neu rein gekommen. Aber wie gehts jetzt weiter? Muss ich da was machen?
Ich habe jetzt noch einmal einen frischen Multihost Master Container basierend auf latest-v5 aufgesetzt. Hier sehe ich direkt nach dem Start keinen einzigen Adapter, d.h. ich kann nichts installieren.
Hat das vielleicht doch etwas mit dem Container zu tun?Und auch mit einem frischen Beta Container habe ich keinen Zugriff mehr auf die Adapterliste. Er lädt praktisch bis in alle Ewigkeit.
Dasselbe gilt für den Tag v5.1.0.
-
@andre sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
So ist es bei reboot eigentlich. Die Restart Policy sagt eigentlich nur, was passiert wenn der container fehl schlägt...
Bisher hatte ich aber auch noch nie Probleme mit dem Restart der DS...So jetzt habe ich tatsächlich den Fall das sich meine DS918+ wieder aufgehängt hat und ich den Stecker ziehen musste. Und siehe da, der Container wo ich Restart policy auf Always gestellt hat wurde gestartet. Die anderen nicht.
Es macht also schon Sinn diese Einstellung zu machen.Ich habe es nun auch beim ioBroker-Container gemacht. Habe aber nicht gewußt, dass beim Deploy gleich das Update von 5.0 auf 5.1 gemacht wird. Jetzt steht der Status auf healthy. ioBroker funktioniert aber.
Wenn ich das Update richtig verstehe ist das neu rein gekommen. Aber wie gehts jetzt weiter? Muss ich da was machen?
@Bongo
Er hat das Update gemacht, weil du es ihm gesagt hast.
Du hast den Tag :latest benutzt und ich wette du hast deinen Container auf "always pull image" stehen. Also zieht er bei jedem Deploy immer automatisch das neuste :latest Image und das ist seit letzte Nacht glaube ich die 5.1.
Wenn du das nicht möchtest, dann solltest du nicht den latest Tag benutzen, sondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.S
-
@Bongo
Er hat das Update gemacht, weil du es ihm gesagt hast.
Du hast den Tag :latest benutzt und ich wette du hast deinen Container auf "always pull image" stehen. Also zieht er bei jedem Deploy immer automatisch das neuste :latest Image und das ist seit letzte Nacht glaube ich die 5.1.
Wenn du das nicht möchtest, dann solltest du nicht den latest Tag benutzen, sondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.S
@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
@Bongosondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.
Gibt es eine Möglichkeit, die Version des Image abzufragen?
-
@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
@Bongosondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.
Gibt es eine Möglichkeit, die Version des Image abzufragen?
-
@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
@Bongosondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.
Gibt es eine Möglichkeit, die Version des Image abzufragen?
@vepman said in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Gibt es eine Möglichkeit, die Version des Image abzufragen?
Jain.
Wie Glasfaser schon schrieb kannst du ins Log schauen - nachdem du das Image gestartet hast.
Aber am Image selber kannst du nicht erkennen welche Version es ist, weil du die Version "latest" heruntergeladen hast und dieser Tag ist volatil. Innerhalb von Docker (bzw. in jedem Github) wird die Version eines Image immer durch ihren Tag festgelegt. Es gibt theoretisch die Chance, dass du ein Image mit :latest Tag heruntergeladen hast, was exakt einem Release Tag entspricht - dann könntest du es am Hashwert des Images erkennen. Ist aber Glückssache und nicht wirklich intuitiv.S
-
@vepman said in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Gibt es eine Möglichkeit, die Version des Image abzufragen?
Jain.
Wie Glasfaser schon schrieb kannst du ins Log schauen - nachdem du das Image gestartet hast.
Aber am Image selber kannst du nicht erkennen welche Version es ist, weil du die Version "latest" heruntergeladen hast und dieser Tag ist volatil. Innerhalb von Docker (bzw. in jedem Github) wird die Version eines Image immer durch ihren Tag festgelegt. Es gibt theoretisch die Chance, dass du ein Image mit :latest Tag heruntergeladen hast, was exakt einem Release Tag entspricht - dann könntest du es am Hashwert des Images erkennen. Ist aber Glückssache und nicht wirklich intuitiv.S
-
@Bongo
Er hat das Update gemacht, weil du es ihm gesagt hast.
Du hast den Tag :latest benutzt und ich wette du hast deinen Container auf "always pull image" stehen. Also zieht er bei jedem Deploy immer automatisch das neuste :latest Image und das ist seit letzte Nacht glaube ich die 5.1.
Wenn du das nicht möchtest, dann solltest du nicht den latest Tag benutzen, sondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.S
@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
@Bongo
Er hat das Update gemacht, weil du es ihm gesagt hast.
Du hast den Tag :latest benutzt und ich wette du hast deinen Container auf "always pull image" stehen. Also zieht er bei jedem Deploy immer automatisch das neuste :latest Image und das ist seit letzte Nacht glaube ich die 5.1.
Wenn du das nicht möchtest, dann solltest du nicht den latest Tag benutzen, sondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.Danke, so wird es wohl ein. In diesem Fall ist das Update kein Problem.
Zum healthy-Status:
Wenn ich es richtig verstehe wird in der neuen Version überprüft ob der Prozess js-controller läuft. Wenn ja ist der Status healthy. Also ab jetzt ist der Normal-Status nicht mehr running sondern healthy.
Habe ich das richtig verstanden?
-
@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
@Bongo
Er hat das Update gemacht, weil du es ihm gesagt hast.
Du hast den Tag :latest benutzt und ich wette du hast deinen Container auf "always pull image" stehen. Also zieht er bei jedem Deploy immer automatisch das neuste :latest Image und das ist seit letzte Nacht glaube ich die 5.1.
Wenn du das nicht möchtest, dann solltest du nicht den latest Tag benutzen, sondern zB :5.0.0 - dann kannst du manuell updaten indem du den Tag irgendwann selber auf :5.1.0 anpasst zB.Danke, so wird es wohl ein. In diesem Fall ist das Update kein Problem.
Zum healthy-Status:
Wenn ich es richtig verstehe wird in der neuen Version überprüft ob der Prozess js-controller läuft. Wenn ja ist der Status healthy. Also ab jetzt ist der Normal-Status nicht mehr running sondern healthy.
Habe ich das richtig verstanden?Ich habe jetzt den ioBroker wieder in einer Multihost Lösung laufen. Mit den Environment variables IOB_MULTIHOST etc. hat das wunderbar funktioniert.
Ich habe jetzt allerdings noch einen toten Slave in der Liste. Der wird auch nicht mehr wieder kommen. Wie kann ich den denn löschen? Über das normale Papierkorbsymbol funktioniert es nicht. Es kommt halt die Meldung, dass ioBroker gestoppt werden muss, bevor ein Slave entfernt werden kann.
Wie ist denn das Prozedere in der Multihost Docker Variante?
-
Ich habe jetzt den ioBroker wieder in einer Multihost Lösung laufen. Mit den Environment variables IOB_MULTIHOST etc. hat das wunderbar funktioniert.
Ich habe jetzt allerdings noch einen toten Slave in der Liste. Der wird auch nicht mehr wieder kommen. Wie kann ich den denn löschen? Über das normale Papierkorbsymbol funktioniert es nicht. Es kommt halt die Meldung, dass ioBroker gestoppt werden muss, bevor ein Slave entfernt werden kann.
Wie ist denn das Prozedere in der Multihost Docker Variante?
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Über das normale Papierkorbsymbol funktioniert es nicht. Es kommt halt die Meldung, dass ioBroker gestoppt werden muss,
schau mal hier ,da haben wir erst gestern darüber in diesem Thread gesprochen wie es geht.
https://forum.iobroker.net/topic/38427/gelöst-keine-zugriff-mehr-auf-iob-webinterface-multihost
-
@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:
Über das normale Papierkorbsymbol funktioniert es nicht. Es kommt halt die Meldung, dass ioBroker gestoppt werden muss,
schau mal hier ,da haben wir erst gestern darüber in diesem Thread gesprochen wie es geht.
https://forum.iobroker.net/topic/38427/gelöst-keine-zugriff-mehr-auf-iob-webinterface-multihost
@Glasfaser Danke, konnte den toten Slave über den Objektbaum entfernen.
-
@andre Hallo, ich möchte meinen iobroker vom Raspi auf die Synology umziehen, bzw. hier einen Multihost einrichten. Alos die Synology ist dann der Master und der Raspi der Slave.
Ich hab dazu diene Anleitung befolgt. Hab aber Probleme mit dem Multihost, das bekomm ich einfach nicht zum laufen.
Ich habe als Netzwerk auch über die MCVLAN alles eingerichtet. Ich möchte iobroker unter einer eigenständigen IP verwalten.Das Image läuft, aber ich kann jetzt iobroker nicht öffnen.
Wenn ich im Terminal den Status abfrage, sagt er mir auch das iorboker nicht gestartet ist, kann es auch nicht starten.Ich denke dass ich einfach die Einstellungen für den Multihost oder vom Netzwerk falsch gesetzt hab. Weiß aber nicht was.
Hier der LOG vom ContainerActions ------------------------------------------------------------ --------------- 2020-11-09 16:20:24 --------------- ------------------------------------------------------------ ------------------------------------------------------------ ----- Welcome to your ioBroker-container! ----- ----- Startupscript is now running. ----- ----- Please be patient! ----- ------------------------------------------------------------ ------------------------------------------------------------ ----- Debugging information ----- ----- ----- ----- System ----- ----- arch: x86_64 ----- ----- ----- ----- Versions ----- ----- image: v5.1.0 ----- ----- node: v12.19.0 ----- ----- npm: 6.14.8 ----- ----- ----- ----- ENV ----- ----- IOB_MULTIHOST: master ----- ----- IOB_OBJECTSDB_HOST: 192.168.178.5 ----- ----- IOB_OBJECTSDB_PORT: 9001 ----- ----- IOB_OBJECTSDB_TYPE: file ----- ----- SETGID: 1000 ----- ----- SETUID: 1000 ----- ------------------------------------------------------------ ------------------------------------------------------------ ----- Step 1 of 5: Preparing container ----- ------------------------------------------------------------ Registering maintenance script as command. Done. ------------------------------------------------------------ ----- Step 2 of 5: Detecting ioBroker installation ----- ------------------------------------------------------------ Existing installation of ioBroker detected in /opt/iobroker. ------------------------------------------------------------ ----- Step 3 of 5: Checking ioBroker installation ----- ------------------------------------------------------------ (Re)Setting folder permissions (This might take a while! Please be patient!)... Done. Fixing "sudo-bug" by replacing sudo in iobroker with gosu... Done. ------------------------------------------------------------ ----- Step 4 of 5: Applying special settings ----- ------------------------------------------------------------ Some adapters have special requirements/ settings which can be activated by the use of environment variables. For more information take a look at readme.md on Github! Multihost is set as "master" by ENV and external objects db is set. Skipping this step... Done. Multihost is set as "master" by ENV and no external states db is set. Setting host of states db to "0.0.0.0" to allow external communication... Done. ENV IOB_OBJECTSDB_TYPE is set and value meets detected ioBroker installation. Nothing to do here. ENV IOB_OBJECTSDB_HOST is set and value is different from detected ioBroker installation. Setting host of objects db to "192.168.178.5"... Done. ENV IOB_OBJECTSDB_PORT is set and value meets detected ioBroker installation. Nothing to do here. ------------------------------------------------------------ ----- Step 5 of 5: ioBroker startup ----- ------------------------------------------------------------ Starting ioBroker...
747
Online32.4k
Users81.4k
Topics1.3m
Posts