Offizielles FHEM Docker Basis Image für verschiedene Plattformen

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

Vorheriges Thema - Nächstes Thema

fallenguru

War mir nicht sicher, ob ich hier fragen soll, oder einen neuen Thread aufmachen. Hab's sicher versemmelt, sorry.

1. Die letzten Jahre hab ich Fhem nackt auf Debian (inzwischen) buster auf einem kleinen ARM-Board laufen, jetzt soll es gemeinsam mit ein paar anderen 24/7 "Infrastruktur"-Services auf einen Intel Mini-PC (auch buster) umziehen. Auf dem werd ich mich wohl oder übel sowieso mit Docker/VMs auseinandersetzen müssen -- isses dann gescheiter, Fhem auch gleich in der Docker-Variante zu betreiben? Sprich, ist das auf die Dauer tatsächlich pflegeleichter, auch wenn man noch keine Docker-Erfahrung hat, oder nur die neueste Sau, die durch's Dorf getrieben wird?

2. Ich hab nicht den ganzen Thread gelesen, aber gegen Ende tauchen ein paar Kommentare auf, die nahelegen, dass die Verwendung von Docker ein ziemliches Schreibaufkommen erzeugt ...?

Wernieman

ZitatIntel Mini-PC

Also betrifft Dich das nicht. Das Problem tritt beim Pi auf, da dort viel schreiben die SD-Card ruinieren kann. habe es hier bei meinem Test-Cluster aber nicht nachvollziehen können ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

P.A.Trick

Das mit der SD Karte und dem Schreibaufkommen ist sicherlich auch von der FHEM Config abhängig. Wenn du gnadenlos alles loggst und eine DB betreibst kann das schon sein.
Zu deiner Frage: nimm Docker - ich bin vor ein paar Tagen umgestiegen und finde es herrlich. Ich habe mal versucht ein paar Dinge im github festzuhalten. Vielleicht hilft es dir. Ist aber noch nicht fertig. Über Kommentare oder fragen würde ich mich freuen.

https://github.com/stormmurdoc/fhemdocker

Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

fallenguru

Zitat von: mumpitzstuff am 31 Januar 2020, 16:40:32
Ich [...]  kämpfe mit dem Problem, das bereits die Tatsache das dockerd und containerd laufen, [...] Nicht ein einziger Container läuft wie gesagt. Trotzdem schreiben die beiden Prozesse mehrere Gigabyte pro Tag auf die SD Karte.

Klingt nicht, als ob FHEM selbst der Übeltäter wär. Meine aktuelle Installation läuft seit vielen Jahren auf derselben SD. Loggt aus allen Rohren. Max ein paar MB/Tag.

Mehrere *GB*/Tag killen die günstige SSD in meinem neuen Mini aber auch.

mumpitzstuff

Probier es mal aus. Vielleicht bin ich ja ein Einzelfall und das Docker Zeug wird bei mir nicht richtig installiert. Du kannst es relativ schnell prüfen, indem du iostat aufrufst, den Wert notierst und ein paar Stunden später noch mal rein schaust. Sind's nur ein paar MB, ist alles ok.

Wernieman

Wir fahren (hier in der Firma) mittlerweile fast nur noch Docker-Server. Sogar "single Projekt Server" werden immer weiter auf docker migriert. Die ersten "nativ-Server Freunde" kamen letzten Woche und Fragten nach migration ...

also beruflich würde ich heute fast nur noch auf Docker gehen ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

M.Schulze

Zitat von: Wernieman am 12 Februar 2020, 08:05:45
Wir fahren (hier in der Firma) mittlerweile fast nur noch Docker-Server. Sogar "single Projekt Server" werden immer weiter auf docker migriert. Die ersten "nativ-Server Freunde" kamen letzten Woche und Fragten nach migration ...

also beruflich würde ich heute fast nur noch auf Docker gehen ...


Das hört sich ja total altmodisch an. Schon mal was von Kubernetes gehört ?
Muss ich das Licht aus machen?

Wernieman

Preis/Leistung von Kubernetes ist hier nicht gegeben ... da dann doch mehr als "nur" Kubernetes ....

Und Dienstleister kosten auch ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

guhu

Zitat von: balli1187 am 10 Februar 2020, 12:31:00
Was heißt "bietet das Image nicht an"? Von Haus aus ist Mail Versand doch garnicht implementiert.

Ich mache das über sendEmail in einer Funktion in den 99_myutils. Ein Beispiel ist im Mail-Wikieintrag unter "Raspberry Pi" zu finden.
Das hat den Umzug nach docker ohne weiteres überlebt.


Gesendet von iPhone mit Tapatalk

Ich hab's so gemacht: https://forum.fhem.de/index.php/topic,89745.msg1010980/topicseen.html#msg1010980
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

knueppler

Hallo,
ich verwende das image schon sehr lange und bin sehr zufrieden damit.
Allerdings habe ich nun mal wieder alles geupdated und noch einen MQTT2_Client definiert um meinen Roborock einzubinden nun wird mein log wie folgt geflutet:

2020.02.16 14:06:01 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.17.0.1)

Hat irgendjemand einen sachdienlichen Hinweis für mich, das wäre sehr lieb.

Danke, Christian

fallenguru

Danke für Eure Antworten. Auf den ersten Blick kann ich kein exzessives Schreibvolumen feststellen, insofern wunderbar.

Leider schaut's so aus, als ob FHEM wieder auf bare metal, oder zumindest in einen Eigenbau-Container müsste, zumindest kann ich die Philosophie des Entwicklers nicht nachvollziehen. Um genauer zu sein, die Reaktion auf meinen bug report haut mich ehrlich gesagt aus den Socken.
Ein bug report ist kein Ort für eine Diskussion, hier vielleicht schon. Mich würde schon interessieren, ob Ihr diesen Zugang (dem Admin dazwischenzupfuschen) in Ordnung findet. Keine Sorge, wenn kein Interesse besteht, geh ich einfach wieder und such mir eine andere Lösung, lieber wär mir, diese zu verbessern ;-)


Wernieman

Dann baue Dir Dein eigenes Docker Image ...

Mir ist z.B. für ein produktives System dieses Image auch zu groß. Liebe eher kleine Image ... und wenn man mehr braucht, kann man ein 2. Größeres machen, welches aber auf dem minimalem aufbaut. Auch dieses wurde abgelehnt ... trotzdem würde ich hier nicht auf den Entwickler "zeigen" ... jeder arbeitet anders ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

balli1187

Zitat von: fallenguru am 16 Februar 2020, 15:51:09
Danke für Eure Antworten. Auf den ersten Blick kann ich kein exzessives Schreibvolumen feststellen, insofern wunderbar.

Leider schaut's so aus, als ob FHEM wieder auf bare metal, oder zumindest in einen Eigenbau-Container müsste, zumindest kann ich die Philosophie des Entwicklers nicht nachvollziehen. Um genauer zu sein, die Reaktion auf meinen bug report haut mich ehrlich gesagt aus den Socken.
Ein bug report ist kein Ort für eine Diskussion, hier vielleicht schon. Mich würde schon interessieren, ob Ihr diesen Zugang (dem Admin dazwischenzupfuschen) in Ordnung findet. Keine Sorge, wenn kein Interesse besteht, geh ich einfach wieder und such mir eine andere Lösung, lieber wär mir, diese zu verbessern ;-)
Ich bin kein Entwickler aber stelle mir beim lesen deines big report folgende Fragen:
- wie sollten Änderungen in FHEM (Geräte anlegen) möglich sein, wenn die fhem.cfg readonly wäre? Ich meine das wird ja in die config GESCHRIEBEN und dann gespeichert... dauerhafte Änderungen wären da ja nicht mehr möglich oder übersehe ich was?
- allgemein sind volumes doch dazu gedacht gewisse Daten persistent zu machen. Auch hier wäre meine Frage wie das gehen sollte, wenn ein Container nicht in ein Volume schreiben dürfte?

Zitat von: Wernieman am 16 Februar 2020, 16:42:35
Dann baue Dir Dein eigenes Docker Image ...

Mir ist z.B. für ein produktives System dieses Image auch zu groß. Liebe eher kleine Image ... und wenn man mehr braucht, kann man ein 2. Größeres machen, welches aber auf dem minimalem aufbaut. Auch dieses wurde abgelehnt ... trotzdem würde ich hier nicht auf den Entwickler "zeigen" ... jeder arbeitet anders ...
Was bedeutet denn für dich "kleineres Image"? (Frage aus purem Interesse)
Generell schleppt FHEM ja auf Grund des fehlenden Managements für die Module ziemlich viel unnützes Zeug mit sich rum... ich kann mir jedenfalls nur schwer vorstellen, dass ein User auch nur die Hälfte aller Module wirklich im Einsatz hat.


Gesendet von iPhone mit Tapatalk
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero

Wernieman

Genau das meinte ich mit "Klein", wenig Balast. Hat aber den Nachteil, das eben nicht alles gleich "outofthebox" funktionieren kann.

Bei anderen Projekten geht man deshalb mittlerweile anders vor:
Basis Image mit Basis-Funktionalität
- Erweitertes Image für Alexa
- Erweitertes Image für ....

Natürlich bauen die Erweiterten auf das Basis-Image auf.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

balli1187

Aber an der Herangehensweise von FHEM einfach bei der Installation ALLE verfügbaren Module herunterladen und abzulegen, unabhängig davon ob diese jemals genutzt werden, änderst du doch mit einem Image nichts.
Das Image kleiner zu bekommen würde dann bedeuten in der FHEM installation herum zu fuhrwerken, oder?
Grundsätzlich fände ich ja gut nur die Module zu laden, die auch genutzt werden aber das müsste dann direkt in FHEM implementiert werden - unabhängig von Docker ja oder nein.


Gesendet von iPhone mit Tapatalk
FHEM auf QNAP im docker, nanoCUL per ser2net an VU+, 2x Echo Dot, 3x HM-ES-PMSw1-Pl, 3x HM-LC-Bl1PBU-FM, 6x Sonoff Basic, div. "Shelly Eigenbauten" von Papa Romeo, ESPRGBWW-Controller, ...
Projekte: Smart Mirror in Spiegelschrank auf RPi Zero