Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Otto123]

Ich hatte versucht die Amazon Echos mit dem Modul 37_echodevice zum Laufen zu bringen.

Guter Rat: entweder das ist im Image schon drin (da ist ne ganze Menge drin, ich kann es aber nicht sagen) oder Du hast eine 100% Anleitung wie das im Docker Image nachgerüstet werden kann. Am Besten ein Script was beim Start von docker eingebunden wird und alles automatisch macht. Oder noch besser dieses npm Zeugs kommt "extern" in einen extra "echodevice" container und im FHEM nur das define.
Wenn das alles nicht so ist (und nirgends was von Docker steht) lass es besser. Docker ist kein normaler host, im Image rumfummeln macht alle Vorteile von Docker für Dich kaputt und ist wahrscheinlich aufwendiger und komplizierter.

[passibe]

Da nichts anderes Verbunden hast, ist alles andere "weg".

Deshalb ergibt es eigentlich auch keinen Sinn innerhalb des Containers irgendwas mit apt zu machen. Bei der nächsten Änderung am compose file und einem d-compose down und up ist das alles weg...

Wenn man "Systemkomponenten" des Containers aktualisieren will, sollte man mittels Dockerfile ein neues Image bauen und dann daraus den Container erstellen.

[kadettilac89]

Deshalb ergibt es eigentlich auch keinen Sinn innerhalb des Containers irgendwas mit apt zu machen. Bei der nächsten Änderung am compose file und einem d-compose down und up ist das alles weg...

Man muss keine apt im Container installieren. Dafür bietet der Container die entsprechenden Parameter an. DAMit kann apt, NPM oder Perl mit installiert werden ohne eigene Dockerfile zu erstellen.

https://github.com/fhem/fhem-docker#add-custom-packages

Apt wäre z. B. -e APT_PKGS="package1 package2"

[passibe]

Ja, klar. Das ist ja auch gut und nützlich, dass man zusätzliche Packages per Environment Variable installieren kann.

Ich wollte nur darauf hinweisen, dass ein aktualisieren irgendwelcher Pakete per apt-get update im laufenden Container keinen Sinn ergibt.

[maddhin]

Deshalb ergibt es eigentlich auch keinen Sinn innerhalb des Containers irgendwas mit apt zu machen.

ich dachte eigentlich, dass die "Maintenance" ist, die gemacht werden sollte. Aber ich nutze Docker primär, weil ich mich eben nicht gut mit Linux auskenne. In diesem Sinne, freut es mich, so also nichts machen zu müssen / sollen. In der Hinsicht finde ich die Docker Container genial. Insbesondere auch, um innerhalb von 5 min das System komplett neu aufsetzen zu können.

Ich werde jetzt mal das AlexaCookie2 als package reinschreiben und gucken, ob das dann funktioniert...

[kadettilac89]

ich dachte eigentlich, dass die "Maintenance" ist, die gemacht werden sollte.

Der Fhem-Container hat unter dem Knoten "system" das Device "fhemServerApt". Das zeigt dir an wenn etwas aktuallisiert werden soll. Das geht dann direkt in diesem Device über update (set toUpgrade).

Ansonsten neuen Container ziehen wenn ein UPdate verfügbar ist. Ist beim Fhem-Image nichdt so oft der Fall.

[DoubleD]

Hallo Leute

mich hat es jetzt auch erwischt und ich habe docker installiert und das FHEM image läuft.

Jetzt die Frage aller Fragen.
Wie bringe ich meine bestehendes FHEM in Docker?
Muss ich wirklich nur /opt/fhem als volume angeben.

Dann würde ja die vordefinierten module aus den demo verloren gehen. bzw auch die Änderungen am logdevice.

Gruß DD

[kadettilac89]

Hallo Leute

mich hat es jetzt auch erwischt und ich habe docker installiert und das FHEM image läuft.

Jetzt die Frage aller Fragen.
Wie bringe ich meine bestehendes FHEM in Docker?
Muss ich wirklich nur /opt/fhem als volume angeben.

Dann würde ja die vordefinierten module aus den demo verloren gehen. bzw auch die Änderungen am logdevice.

Wenn du das opt-Verzeichnis als Volume einbindest wird das verwendet. Welche "vordefinierten Module" meinst du? Wenn das Verzeichnis leer ist zieht Fhem die ganzen Dateien aus dem svn.

Wenn das Verzeichnis schon Dateien enthält wird nichts gelöscht.

Ich würde das Verzeichnis erstmal leer lassen bzw. durch Docker selbst erzeugen lassen. Wenn der Container läuft den Container stoppen und nur die selbst erstellten Dateien reinkopieren (fhem.cfg, fhem.save, dblog-Config, .... ggf. selbst erstelle Plots). Berechtigung korrigieren falls nötig und dann den Container wieder starten und testen und Log prüfen ob noch irgend was fehlt.

Wenn du das originale Verzeichins vorher sicherst kannst du immer wieder zurücksetzen und testen.

[Otto123]

Berechtigung korrigieren falls nötig

Macht das nicht der Container sowieso beim Start?

@DoubleD Du machst das auf ein und derselben Maschine? Dann einfach docker FHEM auf ein anderes Port mappen und die bestehende FHEM Installation offline (also beide FHEM aus) vom /opt/fhem Pfad nach deinem docker Pfad kopieren. So kannst Du mit beiden testen.

[kadettilac89]

Macht das nicht der Container sowieso beim Start?

Ich hab nicht jedes Detail des  entry-Script im Kopf. Ob die Berechtiugngen nur im init-Event oder immer gesetzt werden müsste man prüfen.

Berechtigungen von irgend welchen Files ist ein wiederkehrendes Thema im Thread. Vermutlich gibt es Konstellationen wo das nicht wie gewünsccht funktioniert. Darum der Hinweis. Wenn nur ein paar DAteien kopiert werden ist es kein großer Akt und vermeidet vielleicht Probleme. Man kann acuh mal ohne den Schritt testen.

[DoubleD]

@kadettilac89 und @Otto123

Danke für Eure Antworten!!!
Ich werds testen

Diese Erweiterungen meine ich... siehe Anhang

[kadettilac89]

Diese Erweiterungen meine ich... siehe Anhang

Die kommen mit dem Docker mit und werden wieder angelegt. Auch wenn du einen bestehednen Ordner einbindest.

[Sidey]

Ansonsten neuen Container ziehen wenn ein UPdate verfügbar ist. Ist beim Fhem-Image nichdt so oft der Fall.

Ich arbeite daran. Allerdings nur noch in Github Packages.

Die Zusätzlichen Laufzeitumgebungen (NodeJs, Python) bereiten mir allerdings Schwierigkeiten hinsichtlich Plattformunterstützung.
Am liebsten würde ich das alles in einer zukünftigen Version weg lassen und das ganze als reines FHEM Image ohne die Zusatzsoftware anbieten.
Die Zusatzdienste müsste man dann in eigenen containern unterbringen.


Der andere Punkt dem dem ich hadere ist das tag Schema. Aktuell lasse ich die Images auf Basis buster und bullseye bauen.
Ich fände etwas auf Basis vom semver geeigneter um hier Versionssprünge darstellen zu können.

[kadettilac89]

Ich arbeite daran. Allerdings nur noch in Github Packages.

Hast du damit Maintenance übernommen? CoolTux hatte ja den dev-Container vor einer Weile gebaut.

Aktuell funktioniert ja alles, apt-Updates können direkt aus Fhem gemacht werden, also keine Eile

fhem/fhem-minimal-docker finde ich gut, beschränkt auf Fhem mit weniger "Ballast". Werde ich mal testen.

[ch.eick]

Hey,
ich habe da auch mal eine Frage zum Phyton.
Nach wie vor scheint es einen Unterschied eine nativ installierten Buster oder Bulseye zum Docker Container zu geben.
Ich hatte mal versucht einen Vergleich zu machen, bekomme es aber leider nicht hin, dass alle Pakete gleich sind.

Gruß
   Christian