Offizielles FHEM Docker Basis Image für verschiedene Plattformen

volschin · 09 Juli 2019, 20:28:19

Zitat von: kadettilac89 am 09 Juli 2019, 19:15:45
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 ...

Gibt es die Modifikation irgendwo abgelegt?

kadettilac89 · 09 Juli 2019, 20:34:00

Zitat von: volschin am 09 Juli 2019, 20:28:19
Gibt es die Modifikation irgendwo abgelegt?

ist quick'n'dirty ...

Request der Änderung bzw. Erweiterung damit SSH genutzt wird
https://forum.fhem.de/index.php/topic,97064.msg943070.html#msg943070

Codeänderung
https://forum.fhem.de/index.php/topic,87714.msg943068.html#msg943068

Musst halt dann WOL-Modul vom Update ausnehmen.

kadettilac89 · 09 Juli 2019, 20:52:35

Zitat von: kadettilac89 am 08 Juli 2019, 22:02:19
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

Mir ist schon mal aufgefallen, dass speedtest-cli für das Modul nun woanders liegt. Ist ein Attribut im Modul (Path). Wer aber nicht weiß, wie man das im Docker prüft wird nachfragen.

Früher /usr/local/bin/speedtest-cli
Buster /usr/bin/speedtest-cli

Last auf dem System:
Mem: würde sagen, ist identisch. Die stündlichen Spikes sind nicht da weil speedtest-cli nicht gefunden wurde
CPU: wenn man die 1% Linie ansieht scheint es, als wäre CPU etwas höher. Die Spikes haben etwas höhere Ausschläge.

Mein Server ist für FHEM oversized, darum ist die Systemlast unter 1%. Da kann eventuell jemand mit schwächer Hardware testen. Bei mir kann FHEM aus dem Vollen schöpfen, habe einige Docker laufen auf einem virtuellen Host mit 8 GB Ram, und vollen Zugriff auf CPU (i3 5010U).

Die rote Linie zeigt den Reboot nachdem das neue Image geladen wurde.

volschin · 09 Juli 2019, 20:56:35

Eine Frage hätte ich noch zum Image. Gibt es einen Grund, warum stretch getagged wird und nicht stretch-slim?

Loredo · 10 Juli 2019, 12:31:08

Zitat von: volschin am 09 Juli 2019, 19:39:26
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?

Ja:
https://github.com/fhem/fhem-docker/blob/3b4b4d040053c206d1dd58dd29d0ba5cb673a736/Dockerfile#L252

Loredo · 10 Juli 2019, 12:32:37

Zitat von: volschin am 09 Juli 2019, 20:56:35
Eine Frage hätte ich noch zum Image. Gibt es einen Grund, warum stretch getagged wird und nicht stretch-slim?

Es gab/gibt einen Grund, aber ich kriege das gerade nicht mehr unbedingt zusammen. Aber ist das nicht wirklich egal und eher eine homöopatische Frage...

EDIT: Ich glaube es lag vor allem daran, dass die Locale/Sprachdateien so stark aufgeräumt werden und somit keine umfassende Sprachunterstützung mehr möglich ist.

Loredo · 10 Juli 2019, 18:58:17

Zitat von: kadettilac89 am 09 Juli 2019, 12:10:59
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.

Inzwischen tendiere ich dazu die Empfehlung durchaus zu geben, dass der Container im Netzwerk Modus "host" betrieben wird.
Der Grund ist, dass es inzwischen mit mit (einer noch nicht im SVN veröffentlichten Version) dem Siri Modul in Kombination mit dem npmjs Modul sehr leicht möglich ist Homebridge zu installieren. Bekanntlich basiert Homekit stark auf mDNS und ohne die Komplexität eines weiteren Proxy ist es doch einfacher, wenn man den Container einfach im Hostmode laufen lässt. Diejenigen, denen es neben der Funktion auch auf das i-Tüpfelchen an Sicherheit ankommt, die haben in der Regel ohnehin die Möglichkeit einen virtuellen Server nur für Docker abzustellen. Sprich, wenn man Docker in einem virtuellen Server laufen lässt statt bare metal, dann kann man dort IMHO auch getrost den FHEM Container direkt im selben LAN betreiben. Wer es übertreiben will, muss ja nicht auf dem selben virtuellen Server auch andere Container betreiben... somit bekommt man das, was man von einem Docker Container erwartet: Eine fix und fertige Laufzeitumgebung für FHEM, die einfach zu replizieren ist.

volschin · 10 Juli 2019, 19:01:09

Zitat von: Loredo am 10 Juli 2019, 12:32:37
EDIT: Ich glaube es lag vor allem daran, dass die Locale/Sprachdateien so stark aufgeräumt werden und somit keine umfassende Sprachunterstützung mehr möglich ist.

Das ist definitiv so, Locales und manpages werden abgeräumt. Ist aber eigentlich nichts, was man in einem Container braucht.

Loredo · 10 Juli 2019, 19:21:55

Doch, wenn man mit unterschiedlichen Zeitzonen oder Sprachen gleichzeitig arbeiten möchte.
Das fängt schon an, dass viele (und ich auch) gerne das System und die Backend Konfiguration in Englisch haben, das User Interface aber für andere auch in Deutsch sein soll (nebst korrekter Formatierung von Zahlen und Zeiten). Das Astro Modul erlaubt dies beispielsweise, kann das aber nur, wenn das Betriebssystem unten drunter nicht alle Sprachen außer Englisch abgeräumt hat.

Es gibt auch Benutzer, die haben ihr Ferienhaus auf Teneriffa in ihrer lokalen FHEM Instanz zuhause mit drin (also beispielsweise eben die Astrodaten). Das liegt aber in einer anderen Zeitzone und womöglich möchte man die Zeiten nicht in der deutschen Zeit angezeigt bekommen, sondern in Ortszeit. Das Astro Modul kann auch das, aber eben wieder nur, wenn das System unten drunter nicht die Zeitzonen Unterstützung gestutzt bekommen hat.

volschin · 10 Juli 2019, 19:24:21

Zitat von: Loredo am 10 Juli 2019, 18:58:17

Inzwischen tendiere ich dazu die Empfehlung durchaus zu geben, dass der Container im Netzwerk Modus "host" betrieben wird.
Der Grund ist, dass es inzwischen mit mit (einer noch nicht im SVN veröffentlichten Version) dem Siri Modul in Kombination mit dem npmjs Modul sehr leicht möglich ist Homebridge zu installieren. Bekanntlich basiert Homekit stark auf mDNS und ohne die Komplexität eines weiteren Proxy ist es doch einfacher, wenn man den Container einfach im Hostmode laufen lässt. Diejenigen, denen es neben der Funktion auch auf das i-Tüpfelchen an Sicherheit ankommt, die haben in der Regel ohnehin die Möglichkeit einen virtuellen Server nur für Docker abzustellen. Sprich, wenn man Docker in einem virtuellen Server laufen lässt statt bare metal, dann kann man dort IMHO auch getrost den FHEM Container direkt im selben LAN betreiben. Wer es übertreiben will, muss ja nicht auf dem selben virtuellen Server auch andere Container betreiben... somit bekommt man das, was man von einem Docker Container erwartet: Eine fix und fertige Laufzeitumgebung für FHEM, die einfach zu replizieren ist.

Ich sehe das ein bisschen anders. Der Vorteil von Docker ist, dass ich unterschiedliche Applikationen auch in ihren Abhängigkeiten von Bibliotheken etc. super entkoppeln kann. Ich habe zwei Homebridges in Docker laufen und wenn ich was Neues probieren will, ziehe ich mir kurz eine dritte und vierte hoch, ohne die Stabilität meiner laufenden einzuschränken.
Das von Dir doch wieder alles in einen Container pack-Konzept wird dem aber nicht gerecht. Die Entkoppelung einzelner Komponenten und Verpackung in schlanke Images ist eines der Basiskonzepte von Docker. Mit Docker-compose gibt es auch eine exzellente Möglichkeit diese komplexeren Konfigurationen zu erstellen, zu transportieren und auch zu versionieren.
Daher werde ich vermutlich auch eher kein Kunde für das Fertig-Image werden, aber gern auf die Ideen im Dockerfile zurückgreifen.

Loredo · 10 Juli 2019, 19:25:52

Das bleibt ja jedem selbst überlassen, wieviel Arbeit sich jeder damit machen will. Ob das tatsächlich nötig ist bzw. wie die Kosten/Nutzen Bilanz aussieht, muss jeder für sich selbst beurteilen. Du hast ja alle Möglichkeiten und musst keinesfalls alles aus dem Image heraus nutzen. Und selbstverständlich kannst du so viele andere Container nebendran laufen lassen, wie du magst. Die Überlappungen von Ports musst du da genauso managen, das ist also weder pro noch contra.

Man muss auch einfach erkennen, dass FHEM kein Microservice Dienst ist. Ich würde den Vergleich zwischen dem FHEM Docker Image und dem Home Assistant Image durchaus ziehen wollen... Ziel ist einfachste Inbetriebnahme und Recovery, nicht das bauen komplexester Zusammenhänge. Es soll Komplexität genommen werden, nicht die Basis für mehr Komplexität geschaffen. Aber ich denke das habe ich schon oft genug ausgeführt

volschin · 13 Juli 2019, 18:49:12

Schau Dir bitte mal den folgenden commit an:
https://github.com/fhem/fhem-docker/commit/449f647ca54576d856a33185cee8b480cd8d5ed0

Ich würde es für sinnvoll halten, wenn Du das für das Image übernimmst, da es die Zahl der intermediate Layer ein Stück reduziert.

Loredo · 13 Juli 2019, 20:11:32

Wofür genau muss man die reduzieren?

volschin · 13 Juli 2019, 20:27:59

Der Build dürfte inperformanter sein. Du kannst ja mal
docker history fhem/fhem
machen oder Dir den Log Output ansehen.

Loredo · 14 Juli 2019, 10:55:53

Zitat von: volschin am 13 Juli 2019, 18:49:12
Schau Dir bitte mal den folgenden commit an:
https://github.com/fhem/fhem-docker/commit/449f647ca54576d856a33185cee8b480cd8d5ed0

Ich würde es für sinnvoll halten, wenn Du das für das Image übernimmst, da es die Zahl der intermediate Layer ein Stück reduziert.

Ich frage mich noch immer, weshalb du in mein Repository direkt commited hast (und es wohl konntest?) und keinen Pull Request erstellst. Außerdem findet man die Commits komischerweise nur über den Direktlink, sehr verwirrend. Ich habe weder einen Überblick über deine Änderungen (ist wohl offenbar mehr als nur der eine Commit) noch kann ich diese überhaupt technisch übernehmen.
Bitte zukünftig an den Prozess halten.