Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[beddo]

Das geht zum Beispiel, indem du Befehle in das /pre-init.sh Script packst, welches dann beim allerersten Start des Containers ausgeführt wird. Wiederkehrende Befehle können in das /pre-start.sh Script gepackt werden. Beide Scripte musst du selbst erstellen und als Volume nach / mounten. In der docker-compose.yml Datei ist das dann ein weiterer Eintrag analog zu dem Eintrag für die Daten, die du nach /opt/fhem mountest.

Ok hiermit oute ich mich nun als zu doof.
Aber wie bekomme ich das gemountet.

Bsp:
            - ./fhem/data/:/opt/fhem/   # hier mounte ich die normale installation
            - ./fhem/config:/                # hier lege ich mein post-init.sh rein, dort führe ich ein apt-get aus und kopiere Beispielsweise meine eigene fhem.cfg, die controls.txt und für FTUI gleich meine html Files.

Beim Ausführen sagt mir docker-compose jedoch ich darf nach / nicht mounten
Lege ich mein post-init.sh - in meinem Beispiel unter ./fhem/data/ wird die Datei nicht ausgeführt.

[Loredo]

Scheint nicht ganz offensichtlich, aber die Lösung ist ganz einfach: Du kannst auch einzelne Dateien und nicht nur Verzeichnisse in den Container mounten:

Code Auswählen Erweitern


            - ./fhem/data/:/opt/fhem/
            - ./fhem/config/pre-init.sh:/pre-init.sh


[ChrisW]

nochmal um drauf zurück zu kommen wie kann ich das DockerInfo rausschmeißen ? Und wozu ist das gut ?

[Loredo]

Das kann man nicht rausschmeißen, es ist integraler Bestandteil und informiert beispielsweise über die aktuelle Version des verwendeten Images.
Wenn du das nicht möchtest: Es zwingt dich niemand das Image zu verwenden.


Edit: Image 1.8.1 kann jetzt mit rereadcfg umgehen. Außerdem kann man das DockerImage Device löschen, das Modul bleibt jedoch im Speicher.

[Julisch]

Wieso werden die Docker Images auf hub.docker.com je nach Architektur unterschiedlich getaggt?

Es sollte naheliegend sein, dass die jeweilige Version von FHEM konsistent für alle Architekturen gleich getaggt ist.

Stattdessen:

amd64 (https://hub.docker.com/r/fhem/fhem-amd64_linux/tags):
5.9-s18494_v1.8.1
5.9-s18494_v1.8.0-beta-14-gd6549d9-dev
5.9-s18494_v1.8.0-beta-13-g3e8bb8b-dev
5.9-s18491_v1.8.0

armhf (https://hub.docker.com/r/fhem/fhem-arm32v7_linux/tags):
5.9-s_v1.8.1
5.9-s_v1.8.0-beta-14-gd6549d9-dev
5.9-s_v1.8.0-beta-13-g3e8bb8b-dev
5.9-s_v1.8.0

Warum tut man so etwas?
Kann man das bitte korrigieren?

[Loredo]

Trotz deiner Ausdrucksart, danke für das Finding. Schaue ich mir gelegentlich genauer an.

Es dürfte jedoch nicht schwer sein zu erraten, dass das keineswegs Absicht ist und einfach nur die SVN Revision Nummer hinter dem s(=Subversion) fehlt.

[Julisch]

Danke. Das wäre ziemlich nice, wenn ihr das korrigieren könntet.

[FunkOdyssey]

Was ist so schlimm daran, dass du dich vermutlich nur dafür registriert hast? 😄

Der Ton deiner Zeilen ist schon recht vorwurfsvoll.

[Loredo]

Derzeit finde ich keinen Grund dafür. Auf dem Build System sind alle Images richtig getaggt, beim "docker push" Befehl geht dann seltsamerweise eben dieser Teil des Tags verloren.
Ich tippe auf einen Fehler bei Docker Hub o.ä., immerhin gab es dort auch einige Umstellungen in der letzten Zeit.


Aus der Tag Historie der ARM Images geht auch hervor, dass alle Builds bis Version 1.4.4 korrekt getaggt waren.


Trotzdem ist die fehlende FHEM Revision kein Beinbruch, denn der mitgelieferte Versionsstand von FHEM spielt keine große Rolle. Bestandsinstallationen werden nicht über das Image aktualisiert und neue Setups auf der grünen Wiese sollten sowieso zu beginn immer noch ein "update" Kommando ausführen (siehe Diskussion hier früher bzw. Statement dazu von Rudi). Der entscheidende Teil über die Version des Systems um FHEM drum herum ist also nach wie vor gegeben.

[Julisch]

Vorsicht! Bei genauem Blick auf den Screenshot ist mir aufgefallen, dass Du arm32v5 gepusht hast. Im Docker Hub sind aber amd64 und arm32v5 korrekt. Da steht die Revisionsnummer korrekt im Tag mit drin.

Wo es nicht funktioniert sind arm32v7 und arm32v8. Wollt ihr euch vielleicht die beiden nochmal genauer angucken?

[Loredo]

Danke.


Ich denke ich konnte etwas finden und habe den Build Cache einmal geleert, anschließend sollte alles wieder einheitlich sein.

[Julisch]

Jawohl! Hat funktioniert. Die Tags sind wieder konsistent. Vielen Dank!

[ulli]

Hallo zusammen,

ich steige gerade auf Docker um und wollte fhem nun auch umziehen.
Ich musste feststellen das das Image riesig ist und viele Funktionen vorhält welche ich garnicht nutze.
Ist es  möglich Funktionen wie z.B. Alexa über z.B. ENV Variablen raus zu nehmen, so das ich ein Image über docker-compose auf meine Anwendung zusammenbauen kann?

[Loredo]

Du kannst natürlich das Dockerfile nehmen und so anpassen, wie es dir beliebt. Es liegt alles auf Github.
Allerdings wirst du dann auch nicht am Update Prozess teilnehmen können und musst selbst für Kompatibilität sorgen.


Über das docker-compose YAML lässt sich das nicht steuern, denn das Image wird vorher gebaut. Das Image ist aktuell darauf ausgelegt heruntergeladen und direkt gestartet zu werden zu können, ohne dass die Startzeit erstmal langwierig Pakete herunterladen und nach installieren muss. Derzeit gibt es auch noch keine Möglichkeit überhaupt zu erkennen, welche fehlenden Pakete denn ein bestimmtes FHEM Modul hat, das wird noch eine ganze Weile dauern.

[ulli]

Ja ich möchte hald gerne an Updates dann bleiben.
Wenn ich das dockerfile und das yaml vom git ziehe müsste es doch über eine env File konfigurierbar sein oder?
Bauen muss ich es dann damit natürlich selbst