wie js controller updaten (Synology Docker)
-
@haselchen
3.1.6 -
@haselchen
nicht ganz, einige Adapter wurden aktualisiert aber der js controller steht immer noch bei 1.2.3 und
backitup läuft auch noch nicht..nochmal den container neu starten?
Ja, mach mal Container Neustart
Synology DS218+ & 2 x Fujitsu Esprimo (VM/Container) + FritzBox7590 + 2 AVM 3000 Repeater & Homematic & HUE & Osram & Xiaomi, NPM 10.9.7, Nodejs 22.22.2 ,JS Controller 7.0.7 ,Admin 7.8.24
-
@haselchen
hm... also Instanzen wurden alle aktualisiert und auch der js ist jetzt bei der finalen Version angekommen. Leider muss ich noch aber sagen, da die hälfte meine Instanzen nicht mehr anläuft...
Es kommen aber jetzt ständig Adapter Update dazu, die will ich erstmal alles durchführen... -
@haselchen
hm... also Instanzen wurden alle aktualisiert und auch der js ist jetzt bei der finalen Version angekommen. Leider muss ich noch aber sagen, da die hälfte meine Instanzen nicht mehr anläuft...
Es kommen aber jetzt ständig Adapter Update dazu, die will ich erstmal alles durchführen... -
Das liegt daran, weil der JS Controller jetzt über der Version 2 ist und alle Deine installierten Adapter müssen dahingehend erstmal auf die geforderte Version aktualisiert werden.
@haselchen
das war ja eine Geburt...:-) jetzt ist aber alles schick und grün und auf dem neusten Stand.
Jetzt muss ich nur aufpassen das mir die Updates nicht wieder weglaufen.
Wenn alles läuft mache ich halt immer ungerne Änderungen aus deisem Grund hatte ich auch so lange gewartet.Also nochmal vielen vielen Danke an alle die mitgeholfen haben und starke Nerven bewiesen haben!:-)
Gruß Jan
-
@haselchen
das war ja eine Geburt...:-) jetzt ist aber alles schick und grün und auf dem neusten Stand.
Jetzt muss ich nur aufpassen das mir die Updates nicht wieder weglaufen.
Wenn alles läuft mache ich halt immer ungerne Änderungen aus deisem Grund hatte ich auch so lange gewartet.Also nochmal vielen vielen Danke an alle die mitgeholfen haben und starke Nerven bewiesen haben!:-)
Gruß Jan
Freut mich ungemein.
Im Prinzip musst du nicht viel machen in nächster Zeit , ausser deine Backups machen.
Dein Nodejs ist soweit aktuell und der JS Controller sowieso.Du musst deinen 1.Beitrag (Threadtitel) noch auf gelöst setzen.
-> 3 Punkte -> unter bearbeiten -
Freut mich ungemein.
Im Prinzip musst du nicht viel machen in nächster Zeit , ausser deine Backups machen.
Dein Nodejs ist soweit aktuell und der JS Controller sowieso.Du musst deinen 1.Beitrag (Threadtitel) noch auf gelöst setzen.
-> 3 Punkte -> unter bearbeiten@haselchen
kennst du dich auch mit backitup aus? -
@haselchen
kennst du dich auch mit backitup aus? -
@haselchen
kennst du dich auch mit backitup aus?@jan_xx ,
ich würde dir jetzt empfehlen, ein backup von iobroker zu machen und anschließend den container und den gemounteten iobroker Ordner zu löschen und einen neuen leeren Ordner anzulegen.
Anschließend die neueste Version des buanet Conainers V5...erstellen.
Danach kannst du in dem Container dein backup wieder einspielen.Damit hast du ein wirklich sauberes System und der neue Container basiert auf einem sehr schlanken Linux.
Ich mache generell immer nur updates vom Container selbst und nicht im Container die Pakete ausführen. Ein Fehlerfrei laufender Container mit Iobroker ist damit garantiert..Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...
-
@jan_xx ,
ich würde dir jetzt empfehlen, ein backup von iobroker zu machen und anschließend den container und den gemounteten iobroker Ordner zu löschen und einen neuen leeren Ordner anzulegen.
Anschließend die neueste Version des buanet Conainers V5...erstellen.
Danach kannst du in dem Container dein backup wieder einspielen.Damit hast du ein wirklich sauberes System und der neue Container basiert auf einem sehr schlanken Linux.
Ich mache generell immer nur updates vom Container selbst und nicht im Container die Pakete ausführen. Ein Fehlerfrei laufender Container mit Iobroker ist damit garantiert..Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...
@K_o_bold sagte in wie js controller updaten (Synology Docker):
@jan_xx ,
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...
Diese Aussage müsstest du bitte belegen.
Bin ja offen für alles und lernfähig.
Ich arbeite seit 2 Jahren mit der V3 , habe den Container 100 mal gestoppt ,gestartet, intern upgedatet und 0,0 Probleme.
Und ich bin absolut kein Profi. -
@jan_xx ,
ich würde dir jetzt empfehlen, ein backup von iobroker zu machen und anschließend den container und den gemounteten iobroker Ordner zu löschen und einen neuen leeren Ordner anzulegen.
Anschließend die neueste Version des buanet Conainers V5...erstellen.
Danach kannst du in dem Container dein backup wieder einspielen.Damit hast du ein wirklich sauberes System und der neue Container basiert auf einem sehr schlanken Linux.
Ich mache generell immer nur updates vom Container selbst und nicht im Container die Pakete ausführen. Ein Fehlerfrei laufender Container mit Iobroker ist damit garantiert..Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...
@K_o_bold sagte in wie js controller updaten (Synology Docker):
@jan_xx ,
ich würde dir jetzt empfehlen, ein backup von iobroker zu machen und anschließend den container und den gemounteten iobroker Ordner zu löschen und einen neuen leeren Ordner anzulegen.
Anschließend die neueste Version des buanet Conainers V5...erstellen.
Danach kannst du in dem Container dein backup wieder einspielen.Damit hast du ein wirklich sauberes System und der neue Container basiert auf einem sehr schlanken Linux.
Bis hierhin absolute Zustimmung, wobei das Löschen des alten iobroker Ordners natürlich Zeit hat, so etwas mache ich wenn das neu aufgesetzte System gut läuft.
Ich mache generell immer nur updates vom Container selbst und nicht im Container die Pakete ausführen. Ein Fehlerfrei laufender Container mit Iobroker ist damit garantiert..
Ich bin kein Container Fachmann, aber nachdem iobroker selbst bereits ständig Updates innerhalb des Containers macht, sehe ich nicht weshalb man das nicht auch selbst tun könnte/sollte/dürfte, und meine damit Updates für Node, zusätzliche Software etc. Natürlich nur wenn man weiss was man da treibt. Und ein Backup hat :-)
Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...
Das stimmt so nur, wenn man mit Docker Compose arbeitet, hier wird ein Container(und damit alle seine Änderungen) bei einem Stop/Restart komplett gelöscht und dann wieder beim Start neu aufgebaut. Dieses Verhalten kann man auch für den 'normalen' Docker einstellen, das ist jedoch nicht der Standard.
Updates zu fahren im Container entspricht absolut nicht der Container-Philosophie(nur ein einziger Prozess), ich nutze jedoch Docker als Ersatz für eine VM und habe in meinen bescheidenenen use cases bisher absolut keine Nachteile feststellen können. Für den Anwenderkreis, welcher ein stabiles iobroker System will und auch darauf angewiesen ist, gilt aber Deine Empfehlung von oben, am Container nichts zu ändern, es sei denn durch ein Update desselben
iobroker läuft unter Docker auf QNAP TS-451+
SkriptRecovery: https://forum.iobroker.net/post/930558 -
@K_o_bold sagte in wie js controller updaten (Synology Docker):
@jan_xx ,
ich würde dir jetzt empfehlen, ein backup von iobroker zu machen und anschließend den container und den gemounteten iobroker Ordner zu löschen und einen neuen leeren Ordner anzulegen.
Anschließend die neueste Version des buanet Conainers V5...erstellen.
Danach kannst du in dem Container dein backup wieder einspielen.Damit hast du ein wirklich sauberes System und der neue Container basiert auf einem sehr schlanken Linux.
Bis hierhin absolute Zustimmung, wobei das Löschen des alten iobroker Ordners natürlich Zeit hat, so etwas mache ich wenn das neu aufgesetzte System gut läuft.
Ich mache generell immer nur updates vom Container selbst und nicht im Container die Pakete ausführen. Ein Fehlerfrei laufender Container mit Iobroker ist damit garantiert..
Ich bin kein Container Fachmann, aber nachdem iobroker selbst bereits ständig Updates innerhalb des Containers macht, sehe ich nicht weshalb man das nicht auch selbst tun könnte/sollte/dürfte, und meine damit Updates für Node, zusätzliche Software etc. Natürlich nur wenn man weiss was man da treibt. Und ein Backup hat :-)
Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...
Das stimmt so nur, wenn man mit Docker Compose arbeitet, hier wird ein Container(und damit alle seine Änderungen) bei einem Stop/Restart komplett gelöscht und dann wieder beim Start neu aufgebaut. Dieses Verhalten kann man auch für den 'normalen' Docker einstellen, das ist jedoch nicht der Standard.
Updates zu fahren im Container entspricht absolut nicht der Container-Philosophie(nur ein einziger Prozess), ich nutze jedoch Docker als Ersatz für eine VM und habe in meinen bescheidenenen use cases bisher absolut keine Nachteile feststellen können. Für den Anwenderkreis, welcher ein stabiles iobroker System will und auch darauf angewiesen ist, gilt aber Deine Empfehlung von oben, am Container nichts zu ändern, es sei denn durch ein Update desselben
@fastfoot sagte in wie js controller updaten (Synology Docker):
Ich bin kein Container Fachmann, aber nachdem iobroker selbst bereits ständig Updates innerhalb des Containers macht, sehe ich nicht weshalb man das nicht auch selbst tun könnte/sollte/dürfte, und meine damit Updates für Node, zusätzliche Software etc. Natürlich nur wenn man weiss was man da treibt. Und ein Backup hat
Man muss ganz klar unterscheiden: der /opt/iobroker Ordner ist ein gemountetes Volumen, das heisst, er ist persistent.
Im Gegensatz dazu wird der Rest des Containers nur mit einem Overlay abgebildet: das System merkt sich die Unterschiede zwischen Image und dem, was du geändert hast. Und das nur bis zum nächsten Rebuild.
Damit ist auch klar, was der Unterschied bezüglich Updates ist: ioBroker Updates (im Volumen) sind so gedacht und erwünscht; Updates des Systems sich gegen die Grundsätze von Containern.
Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...Das stimmt so nur, wenn man mit Docker Compose arbeitet, hier wird ein Container(und damit alle seine Änderungen) bei einem Stop/Restart komplett gelöscht und dann wieder beim Start neu aufgebaut. Dieses Verhalten kann man auch für den 'normalen' Docker einstellen, das ist jedoch nicht der Standard.
Um Gottes Willen, nein! Docker Compose hast genau dieselbe Funktionalität wie Docker, was Container betrifft; das einzige, was Compose hinzufügt, ist die Container Orchestrierung (auf einem Host). Je nachdem welche Befehle du verwendest, können sowohl Docker als auch Compose den Container neu bilden.
Wenn man bei QNAP (und wahrscheinlich auch Synology) unter die Haube schaut, generieren die mit all den Einstellungen, die du machst, ein docker-compose.yml. Sprich: da ist Docker Compose darunter.
Updates zu fahren im Container entspricht absolut nicht der Container-Philosophie(nur ein einziger Prozess), ich nutze jedoch Docker als Ersatz für eine VM und habe in meinen bescheidenenen use cases bisher absolut keine Nachteile feststellen können. Für den Anwenderkreis, welcher ein stabiles iobroker System will und auch darauf angewiesen ist, gilt aber Deine Empfehlung von oben, am Container nichts zu ändern, es sei denn durch ein Update desselben
Container als 1:1 Ersatz für eine VM zu verwenden, ist möglich, aber überhaupt nicht die Idee. Das schöne an Containern ist ja, dass man sie jederzeit neu builden kann und damit die neuste darunter liegende Software hat. Genau das verlierst du mit Änderungen ausserhalb von /opt/iobroker. Aber du sagst es ja selber: basteln kann man immer.
-
@fastfoot sagte in wie js controller updaten (Synology Docker):
Ich bin kein Container Fachmann, aber nachdem iobroker selbst bereits ständig Updates innerhalb des Containers macht, sehe ich nicht weshalb man das nicht auch selbst tun könnte/sollte/dürfte, und meine damit Updates für Node, zusätzliche Software etc. Natürlich nur wenn man weiss was man da treibt. Und ein Backup hat
Man muss ganz klar unterscheiden: der /opt/iobroker Ordner ist ein gemountetes Volumen, das heisst, er ist persistent.
Im Gegensatz dazu wird der Rest des Containers nur mit einem Overlay abgebildet: das System merkt sich die Unterschiede zwischen Image und dem, was du geändert hast. Und das nur bis zum nächsten Rebuild.
Damit ist auch klar, was der Unterschied bezüglich Updates ist: ioBroker Updates (im Volumen) sind so gedacht und erwünscht; Updates des Systems sich gegen die Grundsätze von Containern.
Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...Das stimmt so nur, wenn man mit Docker Compose arbeitet, hier wird ein Container(und damit alle seine Änderungen) bei einem Stop/Restart komplett gelöscht und dann wieder beim Start neu aufgebaut. Dieses Verhalten kann man auch für den 'normalen' Docker einstellen, das ist jedoch nicht der Standard.
Um Gottes Willen, nein! Docker Compose hast genau dieselbe Funktionalität wie Docker, was Container betrifft; das einzige, was Compose hinzufügt, ist die Container Orchestrierung (auf einem Host). Je nachdem welche Befehle du verwendest, können sowohl Docker als auch Compose den Container neu bilden.
Wenn man bei QNAP (und wahrscheinlich auch Synology) unter die Haube schaut, generieren die mit all den Einstellungen, die du machst, ein docker-compose.yml. Sprich: da ist Docker Compose darunter.
Updates zu fahren im Container entspricht absolut nicht der Container-Philosophie(nur ein einziger Prozess), ich nutze jedoch Docker als Ersatz für eine VM und habe in meinen bescheidenenen use cases bisher absolut keine Nachteile feststellen können. Für den Anwenderkreis, welcher ein stabiles iobroker System will und auch darauf angewiesen ist, gilt aber Deine Empfehlung von oben, am Container nichts zu ändern, es sei denn durch ein Update desselben
Container als 1:1 Ersatz für eine VM zu verwenden, ist möglich, aber überhaupt nicht die Idee. Das schöne an Containern ist ja, dass man sie jederzeit neu builden kann und damit die neuste darunter liegende Software hat. Genau das verlierst du mit Änderungen ausserhalb von /opt/iobroker. Aber du sagst es ja selber: basteln kann man immer.
@alle
Ich wollte jetzt keine Unruhe hier rein bringen, ich habe halt zusätzlcih mal den Adapter installiert und wollte ihn mal testen. Das Backup funktioniert auch einwandfrei auf NAS oder andere Medien. Aber als ich versucht habe das Image welches durch backitup über web browser herzustellen geht es irgendwie nicht weiter. Hier wollte ich nur wissen ob das ein generelles bekanntes Problem ist?Gruß Jan
p.s. Muss an anderer Stelle gleich nochmal ein Thema zu Blockly aufmachen... -
@alle
Ich wollte jetzt keine Unruhe hier rein bringen, ich habe halt zusätzlcih mal den Adapter installiert und wollte ihn mal testen. Das Backup funktioniert auch einwandfrei auf NAS oder andere Medien. Aber als ich versucht habe das Image welches durch backitup über web browser herzustellen geht es irgendwie nicht weiter. Hier wollte ich nur wissen ob das ein generelles bekanntes Problem ist?Gruß Jan
p.s. Muss an anderer Stelle gleich nochmal ein Thema zu Blockly aufmachen...@jan_xx Ich würde empfehlen, den "offiziellen" Weg von André zu verwenden:
Aus: https://smarthome.buanet.de/2020/10/iobroker-docker-image-backup-restore/
Der Clou an der Sache: Seit Version 4.1.0 des ioBroker Container Images ist es möglich vor dem ersten Start ein Backupfile in das noch leere Verzeichnis, welches in den Container als /opt/iobroker eingebunden wird, zu kopieren. Das Backup wird dann vom Startup-Script des Container erkannt und für die Wiederherstellung verwendet. Vollautomatisch.
Weiteren Informationen dazu findet ihr auch in der Readme auf Github. Bitte behaltet bei der Prozedur nach dem Start des Containers die Logausgabe im Auge. Hier könnt ihr sehen ob der Restore erfolgreich durchgeführt werden konnte oder es ggf. Probleme gab.
Nachdem der ioBroker Container dann gestartet ist und ihr Zugriff auf den ioBroker Admin bekommen habt, könnt ihr im dortigen Log beobachten wie der ioBroker nun die Adapter nach und nach neu installiert. Jetzt braucht ihr eigentlich nur noch etwas Geduld, und der Restore ist abgeschlossen. -
@jan_xx Ich würde empfehlen, den "offiziellen" Weg von André zu verwenden:
Aus: https://smarthome.buanet.de/2020/10/iobroker-docker-image-backup-restore/
Der Clou an der Sache: Seit Version 4.1.0 des ioBroker Container Images ist es möglich vor dem ersten Start ein Backupfile in das noch leere Verzeichnis, welches in den Container als /opt/iobroker eingebunden wird, zu kopieren. Das Backup wird dann vom Startup-Script des Container erkannt und für die Wiederherstellung verwendet. Vollautomatisch.
Weiteren Informationen dazu findet ihr auch in der Readme auf Github. Bitte behaltet bei der Prozedur nach dem Start des Containers die Logausgabe im Auge. Hier könnt ihr sehen ob der Restore erfolgreich durchgeführt werden konnte oder es ggf. Probleme gab.
Nachdem der ioBroker Container dann gestartet ist und ihr Zugriff auf den ioBroker Admin bekommen habt, könnt ihr im dortigen Log beobachten wie der ioBroker nun die Adapter nach und nach neu installiert. Jetzt braucht ihr eigentlich nur noch etwas Geduld, und der Restore ist abgeschlossen. -
@K_o_bold sagte in wie js controller updaten (Synology Docker):
@jan_xx ,
ich würde dir jetzt empfehlen, ein backup von iobroker zu machen und anschließend den container und den gemounteten iobroker Ordner zu löschen und einen neuen leeren Ordner anzulegen.
Anschließend die neueste Version des buanet Conainers V5...erstellen.
Danach kannst du in dem Container dein backup wieder einspielen.Damit hast du ein wirklich sauberes System und der neue Container basiert auf einem sehr schlanken Linux.
Bis hierhin absolute Zustimmung, wobei das Löschen des alten iobroker Ordners natürlich Zeit hat, so etwas mache ich wenn das neu aufgesetzte System gut läuft.
Ich mache generell immer nur updates vom Container selbst und nicht im Container die Pakete ausführen. Ein Fehlerfrei laufender Container mit Iobroker ist damit garantiert..
Ich bin kein Container Fachmann, aber nachdem iobroker selbst bereits ständig Updates innerhalb des Containers macht, sehe ich nicht weshalb man das nicht auch selbst tun könnte/sollte/dürfte, und meine damit Updates für Node, zusätzliche Software etc. Natürlich nur wenn man weiss was man da treibt. Und ein Backup hat :-)
Im Prinzip so wie buanet das in seiner sehr guten Doku beschrieben hat.
Das was du machst kann auch schief gehen. Wenn du mal den Container neu startest müsste eigentlich wieder alles alt sein...
Das stimmt so nur, wenn man mit Docker Compose arbeitet, hier wird ein Container(und damit alle seine Änderungen) bei einem Stop/Restart komplett gelöscht und dann wieder beim Start neu aufgebaut. Dieses Verhalten kann man auch für den 'normalen' Docker einstellen, das ist jedoch nicht der Standard.
Updates zu fahren im Container entspricht absolut nicht der Container-Philosophie(nur ein einziger Prozess), ich nutze jedoch Docker als Ersatz für eine VM und habe in meinen bescheidenenen use cases bisher absolut keine Nachteile feststellen können. Für den Anwenderkreis, welcher ein stabiles iobroker System will und auch darauf angewiesen ist, gilt aber Deine Empfehlung von oben, am Container nichts zu ändern, es sei denn durch ein Update desselben
@fastfoot sagte in wie js controller updaten (Synology Docker):
Updates zu fahren im Container entspricht absolut nicht der Container-Philosophie(nur ein einziger Prozess), ich nutze jedoch Docker als Ersatz für eine VM und habe in meinen bescheidenenen use cases bisher absolut keine Nachteile feststellen können. Für den Anwenderkreis, welcher ein stabiles iobroker System will und auch darauf angewiesen ist, gilt aber Deine Empfehlung von oben, am Container nichts zu ändern, es sei denn durch ein Update desselben
Danke für deine Ergänzungen.
Ich arbeite mit Docker-Compose und da kann man den container auch stoppen und wieder starten ohne dass deine Änderungen verloren gehen. Wenn du aber auf die Idee kommst den Container zu aktualisieren " pull-- befehl", dann verlierst du deine geänderten Pakete. Der gemountete Ordner und damit z.B. iobroker "js-controller" bleibt natürlich unverändert.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden287
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge