Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Loredo]

Hallo,

auf Docker Hub stehen ab sofort 2 fertige Basis Docker Images für FHEM bereit:

• latest --> die aktuelle Stable Version des Docker Images, zusammen mit einem up-to-date FHEM.
• dev --> die aktuelle Entwickler Version des Docker Images, zusammen mit einem up-to-date FHEM.

Alle Images werden für unterschiedliche Plattformen angeboten. Derzeit sind dies für Linux:

• x86-64/AMD64
• i386
• ARM32v5, armel
• ARM32v7, armhf
• ARM64v8, arm64

Die richtige Plattform wird automatisch gewählt, wenn man das Image über das Meta-Repository läd:

Code: [Auswählen]

docker pull fhem/fhem

Ohne die Angabe eines Tags am Ende wird das "latest" Image geladen. Wenn man hinten ":dev" anhängt, bekommt man entsprechend das andere Image.
Statt über das Meta-Repository zu gehen, kann man auch direkt aus einem der Plattform-spezifischen Repositories das Image laden. Dort stehen dann auch weitere Tags bereit, beispielsweise wenn man eine ganz bestimmte Version fest verwenden möchte statt über die "Rolling Tags" zu gehen.


Der Source Code wird auf Github unter github.com/fhem/fhem-docker verwaltet.


Was bedeutet Basis Image?
Die Idee ist, dass FHEM in dem Image möglichst unverändert ausgeliefert wird und nur solche Voreinstellungen gemacht werden, die für ein Docker Image generell sinnvoll sind. Auf dieser Grundlage kann jeder dann bei Bedarf seine eigenes Dockerfile schreiben und dort "FROM fhem/fhem" als Ausgangslage verwenden. Vermutlich ist das aber selten notwendig, denn Zusatzmodule sind soweit bereits im Image integriert. Sollte etwas fehlen, wird es zentral für alle ergänzt.


Wie benutze ich das Image?
Das FHEM Installationsverzeichnis /opt/fhem wird (sicherlich nicht überraschend für die, die Docker kennen) als eigenes Volume definiert. Man kann also seine bestehende FHEM Installation beim starten des Containers über "-v /pfad:/opt/fhem" mit angeben. Wenn man das nicht tut, dann wird die FHEM Installation nach Zerstörung des Containers gelöscht. Ist das beim Start angegebene FHEM Verzeichnis leer, so wird FHEM dort aus dem Docker Image heraus installiert. Mit dieser Vorgehensweise kann man also seine Grundinstallation starten.


Was bietet das Image?
Neben vorinstallierten Paketabhängigkeiten sind folgende Dinge verfügbar:

• Healthcheck über Port 7072, der auch die FHEMWEB Instanzen überwacht
• Automatischer Neustart im Falle eines plötzlichen Absturzes (unabhängig von Docker "restart always")
• Anzeige der verwendeten Docker Image Version direkt in FHEM über integriertes FHEM Modul "DockerImageInfo"
• Möglichkeit ARM Images auf einem x86-64 System zu starten (über QEMU)
• Änderung der UID/GID, unter der FHEM läuft

Folgende FHEM Einstellungen werden automatisch vorgenommen:

• attr global commandref modular
• attr global dnsServer <DNS_aus_resolv.conf>
• attr global mseclog 1
• attr global nofork 0
• attr global pidfilename ./log/fhem.pid
• attr global updateInBackground 1
• define DockerImageInfo DockerImageInfo

Dabei wird die dnsServer Einstellung bei jedem Neustart automatisch aktualisiert.


Wie kann ich das Image für mein eigenes FHEM Image verwenden?
Wenn du selbst ein FHEM Image baust, dann kannst du dich in die Start und Konfigurationslogik des Basis Images einklinken.
Die folgenden Scripte werden an den entsprechenden Stellen im Ablauf ausgeführt, wenn sie vorhanden sind:

• /pre-init.sh - Wird beim allerersten Start des Containers noch vor der FHEM Installation ausgeführt.
• /post-init.sh - Wird beim allerersten Start des Containers direkt nach der FHEM Installation ausgeführt.
• /pre-start.sh - Wird bei jedem Start von FHEM vor dem eigentlichen Start ausgeführt, auch mehrfach während ein Container läuft.
• /post-start.sh - Wird bei jedem Start von FHEM direkt nach dem Start ausgeführt, auch mehrfach während ein Container läuft.

[chris1284]

Sehr gut,  endlich was offizielles. Kann ich GID und UID definieren, im GitHub ist dies nicht dokumentiert.

[chris1284]

Das FHEM Installationsverzeichnis /opt/fhem wird (sicherlich nicht überraschend für die, die Docker kennen) als eigenes Volume definiert.

Wie verhält es wenn ich bisher in eine DB logge, ist SQLite/MySQL im Image integriert? Wie Verhält es sich bei Usern mit config-db?

[Loredo]

Kann ich GID und UID definieren, im GitHub ist dies nicht dokumentiert.

Wenn du einen Vorschlag hast das einzubauen, nur zu.
Habe ich im Developer Image eingebaut.

Wie verhält es wenn ich bisher in eine DB logge, ist SQLite/MySQL im Image integriert?

Es ist ein Basis Image. SQlite als Dateibasierte Lösung funktioniert natürlich direkt. Ansonsten hat ein Docker Image nur einen einzelnen Zweck. Eine MySQL/MariaDB Datenbank gehört in einen eigenen, separaten Container und ist nicht Teil des Images. Eine automatisierte Migration von A nach B ist nicht vorgesehen.

Wie Verhält es sich bei Usern mit config-db?

configDB kann über die Umgebungsvariable CONFIGTYPE beeinflusst werden:

Code: [Auswählen]

-e CONFIGTYPE=configDB


[rudolfkoenig]

die aktuelle Stable Version von FHEM, zusammen mit der aktuellen Stable Version des Docker Images

Ich weiss nicht genau, was diese Version enthaelt, aber wenn es 5.8 ist, dann bitte es nicht als stable bezeichnen: 5.8 ist nicht mehr oder weniger stabil, als ein durchschnittlicher "nightly". 5.8 ist als Ausgangspunkt gedacht, damit man irgendwo anfangen kann. Siehe auch https://fhem.de/#Download


P.S. Die Voreinstellung fuer updateInBackground ist 1 und fuer nofork ist 0, und es bleibt vermutlich auch dabei.

[Loredo]

Hi Rudi,


danke für dein Feedback!

Ich weiss nicht genau, was diese Version enthaelt, aber wenn es 5.8 ist, dann bitte es nicht als stable bezeichnen: 5.8 ist nicht mehr oder weniger stabil, als ein durchschnittlicher "nightly". 5.8 ist als Ausgangspunkt gedacht, damit man irgendwo anfangen kann. Siehe auch https://fhem.de/#Download

5.8 entspricht halt dem letzten Release Tag, genau wie es auch unter fhem.de/#Download der Fall ist. Den Release Zyklus von FHEM generell können wir aber gerne mal in einem anderen Fred besprechen 
Allgemein ist nunmal die Erwartung, dass ich bei einem "latest" Image die letzte offiziell veröffentlichte Version erhalte. Da tue ich mich schwer den SVN Build als "latest" zu bezeichnen (auch wenn die Bezeichnung ggf. aus Entwicklersicht etwas verwirrend scheint, so ist halt der Standard Tag...). Ich wollte auch nicht davon abweichen was man als ZIP/TGZ Download auf der Website bekommt.


Ich kann noch ergänzen, dass der automatische Build sich auf den Tag im FHEM SVN stützt. Wenn du also ein neues Release machst, spiegelt sich das auch entsprechend im Docker Image sofort wieder.

P.S. Die Voreinstellung fuer updateInBackground ist 1 und fuer nofork ist 0, und es bleibt vermutlich auch dabei.

Ja das stimmt. Diese Einstellungen so zu belassen sind jedoch für den stabilen Betrieb als Container in dieser Konstellation unabdingbar, weshalb die Einstellungen, die ein Benutzer evtl. hinterher geändert hat, wieder rückgängig gemacht werden, da der Container ansonsten nicht mehr richtig funktioniert.

[rudolfkoenig]

Ich wollte auch nicht davon abweichen was man als ZIP/TGZ Download auf der Website bekommt.

Auf der Webseite wird das .tgz mit "starting point for the update process" beschrieben.
latest ist inzwischen 1.5 Jahre alt, und ist keineswegs stabiler, als beta, auch wenn in der Beschreibung auf Docker Hub das suggeriert wird (stable vs. bleeding edge). Nach dieser Beschreibung wird kein Anfaenger beta herunterladen, und die Maintainer duerfen sich mit laengst vergessenen Bugreports herumschlagen.

Nicht falsch verstehen: Ich habe kein Problem mit einer stable Version, wenn jemand sich die Muehe macht, es zu pflegen, und den Leuten zu garantieren, dass es stabil laeuft. Nur ich mach das nicht.

[Loredo]

Ich verstehe das durchaus. Nur macht es dann überhaupt gar keinen Sinn auf der Website überhaupt irgendeine Datei, die mit einer Version gekennzeichnet ist, zum Download anzubieten.


Ich kann ja gerne die Beschreibung abändern und das Wort "stable" ersetzen, nur ändert es nichts daran, dass es eigentlich auch nach deiner Beschreibung überhaupt gar keinen Sinn mehr macht einem Beginner zu sagen, dass er die Datei fhem-5.8.zip laden soll, aber danach sofort wieder ein "update" machen muss. Ich kann ja verstehen, dass man aus Bequemlichkeit keine aktuelle ZIP Datei auf der Website anbietet, aber einleuchtend ist das nicht gerade.


Also wenn es hier quasi Konsens ist, dass man keine "Beta" Version (mehr) braucht und man stattdessen den tagesaktuellen Entwicklungsstand als "latest" haben möchte: Habe ich nichts dagegen, aber dann muss eben auch klar sein, dass hier genauso Leute um die Ecke kommen mit "da geht was nicht".


Ist damit quasi offiziell gesagt, dass es keine weiteren offiziellen Releases von FHEM mehr geben wird?

[rudolfkoenig]

Ist damit quasi offiziell gesagt, dass es keine weiteren offiziellen Releases von FHEM mehr geben wird?

Ich glaube wir haben eine unterschiedliche Auffassung, was 5.7, 5.8, etc ist.

Fuer mich sind das Startpunkte fuer den update, nichts mehr. In diesem Sinne wird auch ein 5.9 geben, hoffentlich demnaechst. Und ich werde die Entwickler bitten, moeglichst keine neuen Features in der Woche zuvor zu implementieren, damit man 5.9 nach dem Herunterladen starten kann. Ich finde sie weiterhin sinnvoll, fuer den seltenen Fall, dass jemand "gestern" im Halbschlaf das halbe Repository geloescht hat, oder ein Modul mit Syntax-Error eingecheckt hat.

[betateilchen]

wird kein Anfaenger beta herunterladen, und die Maintainer duerfen sich mit laengst vergessenen Bugreports herumschlagen.

Das ist genau der Grund, warum ich vor langer Zeit die Trennung von "stable" und "nightly" auf debian.fhem.de aufgegeben habe und nur noch das nightly ( eigentlich ein "daily", weil 07:55 Uhr morgens nicht mehr nachts ist  ) bereitstelle.

Auch ein neues Release 5.9 wird am ersten Tag seiner Veröffentlichung nichts anderes als ein "nightly" sein

[Loredo]

Habe den Tag "beta" jetzt in "latest" umbenannt und die Doku im Wording entsprechend angepasst.

[rudolfkoenig]

Danke!

[FunkOdyssey]

Auch wenn es hier und im GitHub-Repo mehrfach beschrieben steht, verstehe ich die beiden Tags nicht.

Ich arbeite immer mit dem aktuellen Trunk. Ist das dann der DEV-Tag beim Docker-Projekt?

Ich verstehe die Tags und Branches bei FHEM nicht. Ist natürlich irgendwie offtopic hier. Aber ist nicht jede getaggte Version nach dem Update wieder auf Trunk-Niveau?

[Loredo]

Ich arbeite immer mit dem aktuellen Trunk. Ist das dann der DEV-Tag beim Docker-Projekt?

Nein. Der Tag bezeichnet nur den Entwicklungsstand für das Docker Image. Unabhängig davon hat jedes Image FHEM auf dem Stand des "Trunk" enthalten.

Aber ist nicht jede getaggte Version nach dem Update wieder auf Trunk-Niveau?

Richtig.

[rudolfkoenig]

Eigentlich sollte:
- trunk die aktuelle Entwicklung enthalten
- in tags jede "veroeffentlichte" Version vermerkt sein, es ist sowas wie ein Stempel, da erfolgt keine Weiterentwicklung
- branches steht fuer jeden frei, der eine abweichende/experimentelle Version bestimmter Module pflegen will

Soweit ich sehe sind in tags einige alte Experimente, die eigentlich ins branches gehoeren, ich habe sie verschoben.