Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Wernieman]

Docker <> VM. Ja bei einer VM würdest Du so vorgehen. bei Docker gibt es aber fertige upgedatete (und normalerweise getestete) Container, warum sollte man dann einen Sonderweg gehen?

[Sidey]

Code Auswählen Erweitern

docker Container "zerstören"
quelle für image ändern
neues Image ziehen ghcr.io/fhem/fhem/fhem-docker:bullseye
container starten
fertig

Es muss doch eine andere Möglichkeit geben als diese.

Gibt es, aber diese ist nicht im Sinne eines Containers. Der ist so gemacht, dass er einfach ausgetauscht wird. Einzelne Bestandteilen eines Containers zu erneuern ist nicht das, wofür Container gemacht sind.


Was ist denn der Grund, dass Du eine abweichende Vorgehensweise suchst?

Grüße Sidey

[Otto123]

Mein Problem ist doch eigentlich nur, dass ich die beiden Devices "Fhem Installer Status" und "Node.js Package Update Status" nicht aktualisiert bekomme. Wofür gibt es diese Dinger wenn sie nicht funktionieren. Oder funktionieren Sie nur wegen dem NAS nicht?

Das Image, welches Du verwendest ist alt - Asbach Uralt. Was Du beschreibst ist bei allen so, nicht nur bei Dir.
Das typische Prozedere wie man einen docker Container aktuell macht habe ich Dir erklärt.
Wenn Dir docker pur|cli (oder wie immer man die Kommandozeile bezeichnen mag) und docker-compose nichts sagen, muss es ja dann einen völlig anderen Weg geben wie Du docker auf deinem NAS betreibst!?

Du missverstehst ev. "das Prozedere" - es geht nicht um "neu einrichten", oder um "Verlust Deiner Daten". Es geht lediglich um ein neues Image. Deswegen die Empfehlung, wirf das alte weg und nimm ein neues.
Das Prozedere ist eine Sache von wenigen Minuten down time für Dein FHEM und bei schlechter Internetverbindung noch ein paar Minuten für das Image ziehen, was aber vor dem Wechsel passieren kann.

Wenn Du aber nicht sagen kannst, wie Du Dein (docker) System betreibst, kann Dir auch keiner gezielt helfen.

[Superposchi]

Was ist denn der Grund, dass Du eine abweichende Vorgehensweise suchst?

Der Grund ist einfach der, dass ich aus allgemeinen Computerabläufen keinen Sinn darin sehe etwas funktionierendes plattzumachen um etwas upzudaten. Der Begriff "Never change a running System" sagt dir doch bestimmt auch etwas, oder?

Wenn Du aber nicht sagen kannst, wie Du Dein (docker) System betreibst, kann Dir auch keiner gezielt helfen.

Das NAS hat eine App "Container-Station". Darin wird der Fhem-Docker geladen und gestartet. Da alles unter dieser Oberfläche läuft bzw. innerhalb der Station kann ich kaum Angaben über die Art des Betriebs machen.

Das Image, welches Du verwendest ist alt - Asbach Uralt. Was Du beschreibst ist bei allen so, nicht nur bei Dir.

Das letzte Mal habe ich den Container vor ca. 4, max. 5 Monaten erneuert. Wenn er jetzt schon "uralt" ist, wie kann ich dann sicherstellen, dass der nächste Container den ich ziehe nicht wieder alte Komponenten enthält. Es kann ja kaum in 4-5 Monaten so viele Änderungen gegeben haben, dass der Container damals aktuell gewesen sein soll und jetzt uralt.

Du missverstehst ev. "das Prozedere" - es geht nicht um "neu einrichten", oder um "Verlust Deiner Daten". Es geht lediglich um ein neues Image. Deswegen die Empfehlung, wirf das alte weg und nimm ein neues.

Doch ich verstehe das Prozedere schon, habe es ja mehrmals gemacht. Ich verstehe nur die Logik dahinter nicht. In der gesamten Computerwelt bedeuten Updateprozesse einzelne Programme durch neuen Code zu ersetzen ohne das Betriebssystem zu erneuern.
Es kommt für mich von der Logik mit dem Schritt gleich statt ein Windowsupdate zu machen, Eine Komplettsicherung zu machen, Windows dann komplett zu löschen und inkl. der aktuellsten Änderungen neu aufzuspielen und anschließend sie Sicherung wieder einzuspielen.

Docker <> VM. Ja bei einer VM würdest Du so vorgehen. bei Docker gibt es aber fertige upgedatete (und normalerweise getestete) Container, warum sollte man dann einen Sonderweg gehen?

Für mich ist dieser Weg eher der Sonderweg, weil er eben nicht den üblichen Prozessen in der Computerwelt entspricht.

[balli1187]

@Superposchi

ich empfinde deine Art und Weise ehrlich gesagt als ziemlich schnippisch und leicht arrogant in Anbetracht der Tatsache, dass du hier eigentlich Hilfe erbittest und schon mit gewissen docker-Grundbegriffen (compose, cli) und dem Konzept Probleme hast.
Dann mit der großen Keule der "gesamten Computerwelt" zu argumentieren, finde ich etwas abenteuerlich....

Ich versuche es trotzdem noch einmal, da ich auch FHEM auf einem QNAP betreibe.

Im Hintergrund der Container Station läuft ein ganz normales Dockersystem. Die Container Station ist nur eine Oberfläche. Du kannst dort den Container stoppen, das Image neuladen (=aktualisieren) und den Container über die Weboberfläche neu aufsetzen. Vielleicht braucht es das letzte nicht mal und es reicht ein einfaches downloaden des aktualisierten Images (weiß ich nciht, da ich alles über die Kommandozeile mache).

Container funktionieren grob gesagt so, dass alles gekapselt wird und einen Snapshot vom Zeitpunkt der Erstellung gebildet wird. Du baust das Image ja nicht neu, sondern lädst es herunter. Wenn es also vom Maintainer seit Jahren nicht gepflegt wird, dann bringt es auch nichts regelmäßig das selbe veraltete Image zu laden.
Daher der Hinweis von Otto auf ein neueres Image zu wechseln, welches gepflegt wird.

DA ich wie gesagt nicht mit der Container-Station direkt arbeite, kann ich nur den Tipp geben auf die QNAP Shell zu wechseln und dort dein Konfiguration in ein Compose-File zu schreiben. Das lässt sich aus meiner Sicht leichter pflegen, da man die Konfig später ändern / ergänzen, wenn es notwendig ist oder eben auch mal Teile zur Fehlersuche auskommentieren kann.
Falls die Shell nichts für dich ist, installiere Portainer über die Container Station und pflege deine Container darüber. Es bietet auch die Möglichkeit mit compose-Konfigs (heißt dort Stack) zu arbeiten, nur halt in einer schönen Weboberfläche. Ist ähnlich der Container Station aber bietet mehr Möglichkeiten.

[Superposchi]

@balli1187
Ich bin weder schnippisch noch arrogant. Ich habe lediglich auf die Frage geantwortet, weshalb ich das nicht als den normalen Weg betrachte. Und wenn du ehrlich zu gibst, gibt es in der gesamten IT-Welt keinen Updateprozess der so funktioniert. Allerhöchstens VM-Maschinen könnte man ansatzweise vergleichen. Daher ist daran auch nichts abenteuerlich oder sonst was.

Wenn es also vom Maintainer seit Jahren nicht gepflegt wird, dann bringt es auch nichts regelmäßig das selbe veraltete Image zu laden.

Genau da ist aber der Hund begraben. Denn woran erkennt der Anwender ob ein Image regelmäßig gepflegt wird oder nicht. Soweit ich es bisher gesehen habe, werden weder Versionsnummern noch irgendwelche Aktualisierungsinformationen im Docker-Hub angezeigt. Der benutzte Container ist nach Angaben hier im Forum der Standard-Container für Fhem. Wenn es andere gepflegtere gibt, wäre eine Information interessant welche das sind. Es gibt immerhin eine beträchtliche Anzahl inzwischen.

[Otto123]

Wenn das nicht arrogant ist, die Antworten auf Deine Fragen mit " ... wäre eine Information interessant  ..." abzutun

Lesen Lesen lesen ... wollen wollen wollen ...

Zu meiner Aussage: Dein Image ist alt - ich kann nichts dafür das auf dem Dockerhub nicht alles steht - aber so ist es im Leben - und immerhin steht dort

Dockerhub

More information
You may visit the project site on Github to learn more about handling and optional configuration for this image.

Der Link dort in dieser Zeile  https://github.com/fhem/fhem-docker/

[kjmEjfu]

Und wenn du ehrlich zu gibst, gibt es in der gesamten IT-Welt keinen Updateprozess der so funktioniert. Allerhöchstens VM-Maschinen könnte man ansatzweise vergleichen. Daher ist daran auch nichts abenteuerlich oder sonst was.

Nein, VMs würde man so updaten wie einen normalen Rechner auch.
Container sind vom Konzept her so gedacht, dass man sie hochfährt und statt einem Update löscht und neu hochfährt. Es gibt also bei Docker Container quasi kein Update, man ersetzt sie einfach.
Wieso und weshalb das so ist und wieso und weshalb das eine sehr gute Sache ist, würde hier so weit führen. Da hilft es eventuell die eine oder andere Einführung zu Docker zu lesen.
Eventuell nutzt du Docker so wie es nicht gedacht ist.

Genau da ist aber der Hund begraben. Denn woran erkennt der Anwender ob ein Image regelmäßig gepflegt wird oder nicht. Soweit ich es bisher gesehen habe, werden weder Versionsnummern noch irgendwelche Aktualisierungsinformationen im Docker-Hub angezeigt. Der benutzte Container ist nach Angaben hier im Forum der Standard-Container für Fhem. Wenn es andere gepflegtere gibt, wäre eine Information interessant welche das sind. Es gibt immerhin eine beträchtliche Anzahl inzwischen.

Die letzte Aktualisierung sieht man z.B. dort: https://hub.docker.com/r/fhem/fhem/tags
Aktueller, und vor allem gepflegt, ist halt der, den Otto schon erwähnt hat: https://github.com/fhem/fhem-docker/pkgs/container/fhem%2Ffhem-docker

[balli1187]

Container sind aber nun mal genauso gedacht. Ein gewisser Entwicklungsstand wird gekapselt und aus ausführbare Umgebung mit allem was für die Asuführung benötigt wird übergeben. Das Update wird dann durch Bauen eines neuen Image durchgeführt, welches du als Anwender dir wieder herunterladen kannst und die alte Umgebung entsorgst.
Das mag anders sein als das was du bisher so kennst aber vielleicht solltest du dann eher mal schauen welche Vorteile das bietet. Es bietet eben einige Vorteile, sonst wären Docker und Co nicht seit Jahren so beliebt.
Ich für meinen Teil kann nicht behaupten sämtliche Vorgänge/Möglichkeiten in der gesamten IT-Welt zu kennen aber wenn du das kannst...

Bei mir kommt das etwas arrogant rüber, wenn du gleichzeitig sagst, dass du nicht weist was "compose" bedeutet oder wie du an irgendwelche Informationen zu deinem System/Container kommst.
Als schnippisch empfinde ich solche Aussagen wie "Der Begriff "Never change a running System" sagt dir doch bestimmt auch etwas, oder?" ebenfalls gepaart mit den genannten Wissenslücken.
Aber gut, vielleicht ist das ja nur mein Empfinden. Mich würde es jedenfalls nicht wundern, wenn der weitere Support für dich sehr dünn ausfällt. Ist ja nur ein gut gemeinter Hinweis.

Also wenn ich auf Dockehub gehe und dort nach FHEM suche steht dort direkt unter der Bezeichnung wann des Image zuletzt geupdatet wurde. In dem Fall hier "a year ago". Innerhalb dieses Threads wurde auch schon mehrfach über die Nachteile dieses Images diskutiert, was letztlich zu einem neuen Image geführt hat. FHEM selbst ist leider nicht optimal für Container-Anwendungen konzipiert, was man schon daran sieht, dass man nach einer frischen FHEM-Installation (rapsi, etc.) auch nicht auf dem neuesten Stand ist, sondern erstmal updaten muss.
Damit hätten wir uns jetzt einmal lang und breit im Kreis gedreht aber es bleibt wieder dabei, dass Umstieg auf ein anderes Image dich weiter bringt als zu versuchen dieses hier aktuell zu halten.

[Superposchi]

@balli1187
Ich habe ja nicht behauptet, dass das schlecht ist oder keine Vorteile hat. Nur, dass es anders ist als sonst üblich. Und für jemand der sich nicht so tief in der Materie auskennt eben unlogisch. Und ich kenne sicher auch nicht alle Möglichkeiten in der IT-Welt, doch wenn solche allgemeinen Pfloskeln nicht verstanden werden liegt das meiner Meinung nach eher an nicht wollen, als Arroganz etc..
Bitte nicht falsch verstehen, aber ich habe schon festgestellt, dass viele User hier im Forum sehr speziell sind und auf Worthülsen, Sprichwörter oder ähnliches komisch reagieren. Ich bin zum Beispiel ein Logik-basierter Mensch. Alles was nicht Logisch ist wird erst mal von mir kritisch angesehen und hinterfragt. Doch hier sind viele eben anders gestrickt und ich verstehe nicht wie.

Aber ich würde es gerne verstehen warum du so empfindest. Darum wäre ich dankbar für eine Erklärung warum du die Unkenntnis von "compose" oder fehlende Informationen zum System/Container als arrogant empfindest. Ich würde das eher als Hilflos interpretieren.

Ich habe jedenfalls mal den genannten Docker runtergeladen. Leider klappt es nicht.
Wenn ich die Fehlermeldung richtig interpretiere, liegt es an fehlenden Zugriffsrechten. Muss man dafür im Docker-Hub angemeldet sein? Bisher konnte ich die Container auch ohne angemeldet zu sein ziehen.


Edit:
An einem fehlenden login liegt es nicht.
Ich bekomme immer folgende Fehlermeldung:
Background task error for image_pull fhem/fhem-docker:latest: 404 Client Error: Not Found ("pull access denied for fhem/fhem-docker, repository does not exist or may require 'docker login': denied: requested access to the resource is denied"

[Sidey]

Aktuelle Images gibt es derzeit nur in der Github Container registry:

Klappt denn ein

Code Auswählen Erweitern

docker pull ghcr.io/fhem/fhem/fhem-docker:dev-bullseye

?

[balli1187]

Container sind eben anders gedacht. Für mich liest sich das alles so, als würdest du zu Porsche gehen und dich beschweren, dass das Zündschloss auf der falschen Seite ist. Das hat schließlich kein anderes Auto so.

Beim Lesen deiner ersten Posts habe ich den Eindruck, dass du dich zum einen beschwerst, weil Dinge nicht so sind wie du es kennst oder als richtig erachtest. Manche Sätze haben auch einen belehrenden Unterton, wobei ich bei der bereits zitierten Passage sogar fast davon reden würde, dass der Gegenüber "dumm gemacht" werden sollte.
Vor dem Hintergrund, dass du eben selbst eingeräumte Wissenslücken aufweist, empfinde ich diese Art als leicht arrogant.
Allgemeine Floskeln sehe ich da auch nicht. Container sind eben anders. Wenn ich in einem SQL-Forum schreibe, dass mein Code-Aufbau wie in Perl nicht funktioniert, werde ich auch nur die Antwort bekommen mich an SQL-Syntax zu halten. ES ist ja auch positiv zu sehen, dass dir die Leute hier schreiben, dass Container eben so nicht gedacht sind, denn du würdest viel Zeit mit dem Updaten innerhalb des Containers verbrennen und stündest nach jedem Neustart des Containers wieder bei 0.

Es wurde dir ja inzwischen auch von anderen ans Herz gelegt, vielleicht nochmal etwas zu den Docker Basics zu lesen, damit solche Fragen und Probleme garnicht erst aufkommen.

Zu dem anderen Contaienr kann ich nichts sagen, da ich den (noch) nicht in Nutzung habe aber da kannst du mal auf den letzten paar Seiten schauen. ich glaube dass es hier gerade erst Thema war.

Für mehr Hilfe solltest du dann aber auch etwa mehr von deinem Vorgehen (was und wie hast du es gemacht) und von deiner Fehlermeldung (Code-Tags) schreiben, sonst kann dir niemand helfen.

[Wernieman]

Für mich ist dieser Weg eher der Sonderweg, weil er eben nicht den üblichen Prozessen in der Computerwelt entspricht.

Komisch, in der Docker-Computer-Welt wird genau dieser Weg gegangen ... also nix mit "üblichen Prozessen in der Computerwelt" .. und ja, ich habe beruflich damit zu tun

Ich bin weder schnippisch noch arrogant. Ich habe lediglich auf die Frage geantwortet, weshalb ich das nicht als den normalen Weg betrachte. Und wenn du ehrlich zu gibst, gibt es in der gesamten IT-Welt keinen Updateprozess der so funktioniert. Allerhöchstens VM-Maschinen könnte man ansatzweise vergleichen. Daher ist daran auch nichts abenteuerlich oder sonst was.

Quod erat demonstrandum ... s.o.


@Otto:
Allerdings eine Kleinigkeit. Normalerweise läd man einen neuen Container, fährt dann den alten runter/den neuen hoch und Freit sich, das es funktioniert. Wenn nicht, dann fährt man eben den alten wieder hoch. Funktioniert nur eben nicht, wenn man den vorher löscht.

Natürlich sollte man nach einer Zeit X das System aufreumen, damit man nicht "mit dem ollen Schiedkrom" das System "verstopft"
Deine Meinung íst <> "gesamten IT-Welt" .... und ja, morgen mache ich genau so ein Update beruflich ....

[Otto123]

Background task error for image_pull fhem/fhem-docker:latest: 404 Client Error: Not Found ("pull access denied for fhem/fhem-docker, repository does not exist or may require 'docker login': denied: requested access to the resource is denied"

Das Image gibt es nicht, der empfohlene Link zum Image war

Code Auswählen Erweitern

ghcr.io/fhem/fhem/fhem-docker:bullseye

@Otto:
Allerdings eine Kleinigkeit. Normalerweise läd man einen neuen Container, fährt dann den alten runter/den neuen hoch und Freit sich, das es funktioniert. Wenn nicht, dann fährt man eben den alten wieder hoch. Funktioniert nur eben nicht, wenn man den vorher löscht.

Ja Werner ich weiß, aber ich ahnte auch schon den weiteren Verlauf und mein letzter Stand war auch, dass der kleine grüne Troll nicht willens ist zu beschreiben wie er sein docker bedient und er kein Terminal auf seiner NAS hat.
Solange man das Image nicht löscht (und das habe ich nicht empfohlen) kann man ja den alten container immer wieder starten. Also genau genommen wolltest Du sagen: man lädt erst das neue Image ... macht den neuen Aufruf ...
Ich muss es mir mal so irgendwo hinschreiben, spontan im Kopf ist halt immer das Vorgehen und nicht die exakte Abfolge.

[Wernieman]

dass der kleine grüne Troll nicht willens ist zu beschreiben wie er sein docker bedient und er kein Terminal auf seiner NAS hat.

Was für mich der Grund ist, nicht mehr zur Lösung beizutragen. Ist nicht das erste mal.
Bzw: Ich bewundere immer Deine Gelassenheit!

man lädt erst das neue Image ... macht den neuen Aufruf ...

Exacta. Hat z.B. bei selbstgebauten Containern (per Dockerfile) sogar den Vorteil, wenn sie getakt sind, das man exakt zu einer Version springen kann.