Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[geohem]

@werniemann
Ich bin zwar der Meinung, dass deine Verzeichnis Übergabe funktionieren sollte.
Ich lege allerdings ein Volume im dicker Verzeichnis an.

-v fhem_data:/opt/fhem

Dann liegt die fhem Konfiguration im Unterverzeichnis volumes von docker.
docker/volumes/fhem_data/_data
Dahin kannst du dann deine Konfiguration kopieren.

[geohem]

ähm, sorry.
Das war für nightstorm99 gedacht.

[Wernieman]

Kein Problem ;o)

[nightstorm99]

@werniemann
Ich bin zwar der Meinung, dass deine Verzeichnis Übergabe funktionieren sollte.
Ich lege allerdings ein Volume im dicker Verzeichnis an.

-v fhem_data:/opt/fhem

Dann liegt die fhem Konfiguration im Unterverzeichnis volumes von docker.
docker/volumes/fhem_data/_data
Dahin kannst du dann deine Konfiguration kopieren.

Danke, probiere ich aus.

Gruß
Denny

[geohem]

Ich habe weitere Pakete zum Docker Image hinzugefügt, allerdings vorerst nur im Dev Image. Wenn du kannst, probiere dieses einmal aus, bis es im produktiven Image verfügbar ist.

Ich denke das geht auch in der dev Version nicht, auch da braucht tts den mplayer.
Ich habe auch hier ein wenig angepasst und die Sprachausgabe über meinen bestehenden mpd Server realisiert. Der spielt nun zur gegebenen Zeit mp3 file mit dem gewünschten Text ab.

Insgesamt eine gelungene Idee mit dem docker-fhem, danke.

[Loredo]

Es baut gerade gibt eine neue Produktiv-Version 1.5.0 des FHEM Docker Image.

Dabei werden soweit erkenntliche Abhängigkeiten für alle FHEM Module mit eingebaut. Einige Perl Module gibt es jedoch nicht als fertige Debian Pakete und auf der ARM Plattform dauert das bauen des Images dann zu lange. Daher sind diese Pakete auf ARM dann leider nicht enthalten.
Für die i386 Plattform ergeben sich ebenfalls einige Einschränkungen.

Hier die Neuerungen im Überblick:

Alle Plattformen (amd64, i386, arm64v8, arm32v7, arm32v5):
- alle von FHEM Modulen benötigten Debian Pakete (soweit automatisch erkennbar)
- alle von FHEM Modulen benötigten Perl Module, die als Debian Paket verfügbar sind (soweit automatisch erkennbar)
- Unterstützung für Python3 (für das GOOGLECAST Modul)

Nur auf amd64, i386, arm64v8, arm32v7:
- FHEM Alexa Connector Support (für das alexa Modul)
- Node.js 10.x LTS (8.x LTS bei i386)

Nur auf amd64 und i386:
- Manuell gebaute Perl Module: Crypt::OpenSSL::AES, CryptX, Device::SMBus, Net::MQTT::Constants, Net::MQTT::Simple

Nur auf amd64:
- Manuell gebaute Perl Module: Crypt::Random, Math::Pari

[The-Holgi]

Hallo,
Danke für das update.
Habe von Version 1.4.2 auf die 1.5.0 upgedatet, ist es richtig, das das image nun 1Gb groß ist, oder habe ich da irgendwie Mist gebaut?
Meine "alte" Version (1.4.2)  war 461 Mb groß.

Gruß Holger

[Loredo]

Hm, also 1 GB klingt zu groß. Woran hast du die Größe abgelesen? Einige Layer des alten Images bleiben auf deiner Festplatte erhalten, solange du sie nicht aufräumst.


Die Größe der Images je nach Plattform kann man auf Docker Hub nachsehen.
Für AMD64 zum Beispiel hier:
https://hub.docker.com/r/fhem/fhem-amd64_linux/tags


Dort sieht man, dass das "latest" Image genau 400 MB groß ist derzeit.

[FunkOdyssey]

Ich habe das dev und liege bei einer Imagegröße von 1,1 GB.
Aber liegt das nicht nahe, wenn nodejs, SSH, Homebridge und Alexa in ein Image gepackt werden? Ich bin einerseits begeistert, aber andererseits widerspricht das meine Vorgehensweise in Docker (1 Dienst - 1 Container).
Aber soweit ich das abschätzen kann läuft Alexa aktuell doch sowieso nur auf dem gleichen Host, oder? Die Angabe von Hostnamen existiert derzeit, soweit ich das überflogen habe, nicht.

Danke für die Anpassung!

[The-Holgi]

Hm,
die größe habe ich in Portainer abgelesen bzw ist mir zufällig aufgefallen wie groß das image ist.
https://www.bilder-upload.eu/bild-096309-1547574975.jpg.html
Warum ist es bei mir so groß? Habe es mit docker pull fhem/fhem geladen.

Gruß Holger

[The-Holgi]

Hier noch ein screenshot:
https://www.bilder-upload.eu/bild-6e5a68-1547575996.jpg.html

[Loredo]

Ich denke die Größe wird dann einfach auf Docker Hub falsch angezeigt (warum auch immer).

Aber liegt das nicht nahe, wenn nodejs, SSH, Homebridge und Alexa in ein Image gepackt werden?

Absolut, ja.


Nachdem das neue Image in Layer je nach Bereich aufgeteilt ist, kann man auch etwas genauer sagen was wieviel wegnimmt:
http://take.ms/Ert1C


Die Entwicklergemeinde nutzt halt alles, was es so gibt und nimmt nicht immer die selben Tools/Libraries für ähnliche Dinge. Dazu ist der Entwicklerpool zu divers

Ich bin einerseits begeistert, aber andererseits widerspricht das meine Vorgehensweise in Docker (1 Dienst - 1 Container).

Wer möchte, kann das ja weiterhin tun, da spricht ja grundsätzlich überhaupt nichts dagegen. Plattenplatz sollte da jetzt nicht unbedingt das Thema sein heutzutage...
Der Punkt ist halt, dass Leute (zurecht) erwarten, dass sie das fertige Image nicht erst noch selbst erweitern müssen, damit Module lauffähig sind. Wer ein schlankes Image möchte und genau weiß was er tut, der muss das selbst bauen (geht ja auch, die Quellen gibt es ja zum abgucken). Ich denke auch für eine ganze Reihe anderer macht es das austesten leichter - auslagern geht immer, sofern das Modul das unterstützt.

Aber soweit ich das abschätzen kann läuft Alexa aktuell doch sowieso nur auf dem gleichen Host, oder? Die Angabe von Hostnamen existiert derzeit, soweit ich das überflogen habe, nicht.

Laut André soll man die Node.js basiertem Daemons explizit wie bisher auch extern betreiben können. Nach meinen ersten Tests geht das allerdings derzeit nicht mehr innerhalb von einem Docker Container, da der Prozess sich kurz nach dem Start wieder beendet. Wahrscheinlich hat es was mit dem veränderten stdin/stdout Verhalten zu tun (Docker lässt den Prozess ja eigentlich im Vordergrund laufen, aber wenn man ihn im normal üblichen detached Modus in den Hintergrund schickt, fallen natürlich stdin/stdout weg). Ich denke aber mal, dass das irgendwann wieder gehen wird.


Wenn man also die neue alexa-fhem Version benutzen will statt der alten, dann muss man derzeit wohl den Prozess von FHEM direkt managen lassen. Das geht auch im Docker Image zuverlässig, wenn FHEM der Vaterprozess ist.


Was auch gehen soll ist über SSH remote einen Prozess zu starten. Da funktioniert für eine normale VM oder ein richtiges Device, aber im Falle von Docker müsste man dann einen SSH Daemon laufen lassen, was etwas unschön ist.

[The-Holgi]

Danke für die Erklärung. Mich stört die Größe nicht, kam mir nur komisch vor.

Gruß Holger

[Wernieman]

Du musst im Docker einen Prozess im "Vordergrund" laufen lassen, da er sonst von docker gekillt wird. Deshalb wird z.B. der apache im offiziellen apache-Docker-Image so gestartet.

Hintergrund:
Wenn der Start Prozess sich verabschiedet geht docker davon aus, das der Container nicht mehr gebraucht wird. Also wenn Dein Programm sich im Hintergrund startet und damit die PID vechselt, geht dockr davon aus, das es sich beendet hat.

Was ich nicht verstehe, wieso ssh im docker-Container? Es ist docker und keine VM!

[Loredo]

Wie Docker mit Prozessen umgeht, ist mir geläufig.

justme1968 (der alexa-fhem Entwickler) denkt mehr in VMs und dass man etwas in einer separaten VM laufen hat. Containerisierung ist ihm nicht so bekannt, daher liegt es nun an der Community die richtigen Requirements zu finden und für ihn zu formulieren, so dass er versuchen kann sie zu berücksichtigen.

alexa-fhem bleibt auch im Vordergrund, kommt aber eben mit dem Detaching offenbar nicht richtig klar bisher. Um das zu debuggen, brauchts erstmal eine dafür geeignete Umgebung. Hilfe ist dabei gerne willkommen, denn wie man auf Github vielleicht gesehen hat, hatte ich vor ein alexa-fhem-docker Image dort bereitzustellen.