Offizielles FHEM Docker Basis Image für verschiedene Plattformen

Begonnen von Loredo, 28 Juli 2018, 21:24:57

Vorheriges Thema - Nächstes Thema

Dirk070

Hallo Loredo,

Danke für die Info. Ich habe die Modul 99_DockerImageInfo.pm manuell über "Edit Files" in Fhem angelegt, mit dem Code aus dem GitHub.
Container neu gestartet und die Meldung ist weg. Sieht also erstmal gut aus.

Dabei ist mir aber aufgefallen, dass mein angelegt Verzeichnis für Fhem nun leer ist.
Die Installation ist unter /volume1/@docker/volumes in einem kryptisch (dynamisch) benannten Verzeichnis gelandet.

Ich vermute mal, dass dieses Verzeichnis gelöscht wird, wenn ich den Container lösche.
Wie lässt sich denn das verhindern?

Danke und Gruß
Dirk

Dirk070

Hallo,

ich denke, ich habe die Lösung.

  • fhem in Docker laden
  • Abbild starten
  • Erweiterte Einstellungen: automatischer Neustart
  • unter Netzwerk: selbes Netzwerk wie der Docker Host nutzen
  • Volume fhem (unterhalb von Docker) angelegt und auf Mount-Pfad /opt/fhem gelegt
  • Also in Docker unter ,,Volume", ,,Datei/Ordner" = ,,docker/fhem" und ,,Mount-Pfad" = ,,/opt/fhem"
  • Inhalte des Verzeichnis /volume1/@appstore/fhem/opt nach /volume1/docker/fhem kopiert

Der letzte Punkt zeigt die Verzeichnisse, wenn vorher über das Paketzentrum der Syno das Fhem-Paket genutzt wurde.

Container starten.

Loredo

Nein, ich weiß jetzt, was du falsch machst.
Du musst deine FHEM Installation nicht nach /volume1/docker/fhem kopieren, sondern nach /volume1/docker/opt/fhem (analog zum Grundsatz, dass FHEM normalerweise in /opt/fhem installiert ist).


In dem ersten Verzeichnis liegt die leere FHEM Installation, die jedes Image dann kopiert, wenn du noch keine fertige FHEM Installation mitbringst. Darin ist auch 99_DockerImageInfo.pm enthalten und wird auch von dort nach der Aktualisierung des Images rüber kopiert, um ein Update des Moduls zu gewährleisten. Du kannst nicht einfach die mitgelieferte FHEM Installation überschreiben, die löscht das Image selbstständig nach dem ersten Start eines neuen Containers.

Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Dirk070

Danke für Deine Hilfe.
Mit dem letzten von mir beschriebenen Ablauf funktioniert es aktuell, der Inhalt des Verzeichnis wird nicht mehr gelöscht.

Das Verzeichnis beinhaltet nun die Dateien und die Logs werden dort auch aktualisiert.
Mit meinem Laien-Verständnis müsste doch das docker/fhem auf das opt/fhem aus dem Container gemapped werden.
Dann wäre es egal, ob ich physisch noch ein "opt" anlege.

Oder bin ich auf dem Holzweg.....und warum funktioniert es jetzt?

Loredo

Du bist auf dem Holzweg, weil das Image nunmal anders arbeitet und nicht vorherzusagen ist, was bei einem Update (sprich der Neuerstellung des Containers) passiert. Aktuell hast du wahrscheinlich einfach Glück, weil der Container ab dem zweiten Start ein anderes Verhalten hat.
In jedem Fall bekommst du keine Updates des 99_DockerImageInfo Moduls, wenn du das Verzeichnis vorher überschreibst.

Btw, ich weiß nicht wie Synology das macht, aber du willst nichts direkt in das Image hinein kopieren, sondern ein permanentes Volume in das Image nach /opt/fhem mappen. Ansonsten sind deine FHEM Änderungen weg, wenn du den Container aktualisierst.

Beschäftige dich etwas mehr mit den Docker Grundlagen, das ist nichts FHEM spezifisches :)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Dirk070

#395
Mache ich, Danke jedenfalls für die Erklärungen!!!!

Ich probiere die Tage mal, den Container neu zu starten und auch mal neu aufzusetzen. Dann sehe ich ja, was mit den Einstellungen etc. passiert.

Eine Info/Frage aber doch noch: mein Ordner "/volume1/docker/fhem" ist ein permanentes Verzeichnis (den Unterordner "docker" habe ich so benannt, das hat nichts mit der Dockerverwaltung der Syno zu tun).

Dirk070

So, hier nun das zugesagte Ergebnis des Tests auf der Syno.
Vorweg, das "/volume1/docker/fhem" ist ein permanentes Verzeichnis, das ich angelegt habe und befindet sich nicht im Docker-Container.
Ich habe in diesem Verzeichnis die persistenten Daten aller Docker-Images abgelegt, mit jeweils einem Unterverzeichnis pro Container.

Zum Test: ich habe den Container gestoppt und anschließend gelöscht. Danach einen neuen Container aus dem selben Abbild mit identischen Einstellungen erzeugt.
Nach dem Start hat Fhem im Log alle Infos gezeigt, die auch vor dem Stop/Löschen vorhanden waren. So sollte es sein.

Zur Info für alle Syno-Anwender:
Man kann die Einstellungen eines Containers in eine Datei exportieren (ca. 1KB).
Löscht man den Container, kann man diesen über den Import mit 2 Klicks wieder erzeugen.
Dürfte bei Updates auf das Abbild interessant sein.

Nochmals Danke an Loredo für den Austausch und Deine Infos. Und natürlich für das Image!!!! Super Sache.

Viele Grüße
Dirk

Loredo

Zum Feierabend noch ein Schmankerl:


Ein auf Debian Buster basierendes FHEM Docker Image will getestet werden, bevor ich es als neues Produktiv-Image markiere:



docker pull fhem/fhem-amd64_linux:buster
docker pull fhem/fhem-i386_linux:buster
docker pull fhem/fhem-arm32v5_linux:buster
docker pull fhem/fhem-arm32v7_linux:buster
docker pull fhem/fhem-arm64v8_linux:buster



Wie man sieht gibt es die bekannten Geschmacksrichtungen. Da Python3 RPi.GPIO nicht baut, ist es aktuell nicht mehr im Image enthalten. Ich bin auch nach wie vor nicht sicher, ob es dort überhaupt benötigt wird oder ob man diese Pakete nicht ohnehin eher auf dem "Host" System braucht. Da ich keinen RPi mit GPIO nutze, kann ich das nicht beurteilen.


Sofern im Laufe der Woche keine Probleme von freiwilligen Testern gemeldet werden, markiere ich Buster als Standard Image. Dann wird es auch unter "fhem/fhem" abrufbar sein, ohne dass man eine Plattform explizit angeben muss.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

kadettilac89

ich hab mal fhem/fhem-amd64_linux:buster gezogen, werde zwar nicht viel testen können, aber ich beobachte mal ob im Log oder auch so irgend was auffällt

sn0000py

Hallo ich muss gestehen ich habe mir jetzt nicht die 27 Seiten durchgelesen.

Ich hatte bis vor paar Woche (in der Wohnung) FHEM auf einem Raspberry PI 2 laufen.
Da ich nun einen Unraid Sever habe der 24/7 läuft und noch Reserven hat, würde ich FHEM gerne darauf laufen lassen (sind nun ins Haus gezogen)

Meine Frage läuft der FHEM im Docker nun schon stabil genug, und kann ich da auch alles drauf laufen lassen was ich benötige?
FHEM wird nur als NivetoHAve laufen - sprich alle Grundfunktionen laufen von haus aus schon mal.


Loredo

Aus meiner Sicht läuft das Docker Image sehr stabil.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

kadettilac89

Zitat von: sn0000py am 09 Juli 2019, 09:30:16
Meine Frage läuft der FHEM im Docker nun schon stabil genug, und kann ich da auch alles drauf laufen lassen was ich benötige?
FHEM wird nur als NivetoHAve laufen - sprich alle Grundfunktionen laufen von haus aus schon mal.

Ich habe schon eine Weile am Laufen, zuerst auf RPI und jetzt auf Linux Server .. läuft alles. Netzwerkdesign Docker ist halt anders als nativ. Netzwerk Magic Package z. B. geht niczht durch (Wake on Lan) ... Solche Dinge können auffallen. Ist aber dann Docker spezifisch und hat nichts mit Fhem zu tun.

Bis jetz tkonnte ich alles lösen.

volschin

Wie hast Du das mit dem Magic Packet gelöst? Ich habe jetzt schon einige Apps drumherum gedockert, jetzt will ich zeitnah auch an FHEM ran.


Gesendet von iPhone mit Tapatalk
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

kadettilac89

Zitat von: volschin am 09 Juli 2019, 19:08:54
Wie hast Du das mit dem Magic Packet gelöst? Ich habe jetzt schon einige Apps drumherum gedockert, jetzt will ich zeitnah auch an FHEM ran.


Gesendet von iPhone mit Tapatalk
Ich hab das wol Modul umgebaut um per ssh auf dem host das Paket zu senden. Du könntest auch host Networking machen. Das will ich aber nicht. Sicherheit ...

volschin

Zitat von: Loredo am 02 Juni 2019, 14:53:57
Die selben zeitlichen Schwierigkeiten, wie du bei deinem lokalen Rapi hast, gibt es beim Bau des Images auf dem Server ebenfalls. Laufzeiten sind dort jedoch zusätzlich beschränkt, so dass Perl Module, die sehr lange zum kompilieren brauchen, nicht mit enthalten sind. Das betrifft ganz besonders sehr viele Crypto Perl Module. Hinzu kommt, dass ganz besonders diese Perl Module dann häufig auch nicht stabil oder gar nicht kompilieren, besonders wenn es sich um die Geräteplattform ARM handelt und diese nur auf einer x86_64 CPU über QEMU emuliert wird.


Crypt::Rijndael_PP als pure Perl Implementierung (--> "_PP" am Ende) scheint mir recht neu zu sein und ist mir bisher nicht als Abhängigkeit aufgefallen. Hier ist zu hoffen, dass die Installation nicht lange dauert. Ich schaue mal, ob das Image so noch baut. Es kann aber jederzeit sein, dass das Modul nicht mehr baut und es sich nicht beheben lässt. In dem Fall wird es dann wieder aus dem Image verschwinden - entweder ganz oder zumindest für die ARM Plattformen. Daher ist der langfristige Rat, dass du dich von deiner ARM Abhängigkeit löst.




Edit: Neues PROD Image mit Crypt::Rijndael_PP (auch für ARM) baut gerade.
Weil das hier gerade aufgerufen wurde, hat mich im Dockerfile gewundert, dass kein Paket libcrypt-rijndael-perl installiert wird. Eigentlich war das immer die Basis, damit Homematic Devices mit AES funktionieren.
Übersehe ich da etwas?
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)