Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Sidey]

Allerdings ist die Firmata Unterstützung abhanden gekommen.
Ist das so geplant? Wie bekomme ich die wieder zurück?

Geplant war das nicht, dass latest aktualisiert wird. Ist jetzt halt passiert.

Bezüglich Firmata bin ich zwei Jahre zurück und habe auch damals keine Firmata CPAN Pakete im Image gefunden.

Du kannst das Paket unkompliziert über eine Umgebungsvariable beim Starten des Containers nachinstallieren :

-e CPAN_PKGS="Device::Firmata"

Grüße Sidey

[Muenzi]

Es sollte auch klappen, wenn Du den Update Befehl in die fhem.cfg schreibst mit der fhem gestartet wird.

Super, sorry es hat ein wenig gedauert bis ich wieder Zeit dafür hatte.

Hat aber alles geklappt.

Als kleine "Gedächtnisstütze" habe ich zu meinem Setup mal ein Github-Repo aufgemacht. Vielleicht interessiert es ja jemanden, der sich auch erst in Docker einarbeiten muss. Oder ein Pro wie Sidey oder die anderen hier gibt Good-Practice Tipps.

https://github.com/StephanMuenzberg/fhem_docker

[Wernieman]

    expose:
        - "3306"
        - "33060"
    ports:
        - "3306:3306"
        - "33060:33060"

Warum gibst Du Deine MariaDB nach außen frei?  Sie muß doch nur von FHEM und Grafana erreicht werden können und das ist durch das Docker-Netzwerk doch schon möglich.

Hinweis:
Alles was nicht von Außen (Aus Docker Sicht) erreicht werden kann, kann nicht mißbraucht werden.

Und warum hast DU eine docker-compose im Repro?

[Muenzi]

Hallo Wernieman,

das sind sehr gute Fragen.

Warum gibst Du Deine MariaDB nach außen frei?  Sie muß doch nur von FHEM und Grafana erreicht werden können und das ist durch das Docker-Netzwerk doch schon möglich.

Hinweis:
Alles was nicht von Außen (Aus Docker Sicht) erreicht werden kann, kann nicht mißbraucht werden.

Aktuell entwickle ich noch am lebenden Herzen, habe also keine separaten Entwicklungs- und Produktivinstanzen. Das heißt, ich muss mich für die Entwicklung (v.a. Normalisierung der History Tabelle, Views usw., siehe Ordner fhem/config/init/sql/) an der DB irgendwie auf die MariaDB draufschalten. Natürlich geht das direkt über eine interaktive Docker-Session, aber dann würde alles über die CLI laufen und das wäre dann doch etwas unhandlich.

Ich gebe dir aber vollkommen Recht. In einem produktiven System sollten die Port-Freigaben abgeschaltet sein.

Und warum hast DU eine docker-compose im Repro?

Das hat "historische" Gründe. Ich habe ewig gebraucht um eine brauchbare Docker-Compose für mein Raspi-Setup zu finden, die auch funktioniert hat. Damit ich die bei einem Datenverlust nicht wieder verliere habe ich sie drin gelassen. Aber es stimmt, eigentlich kann die raus, zumal ich mittlerweile auf docker-compose aus pypy umgestellt habe.

[Otto123]

Ich will mal vorsichtig vor einem unvorbereiteten Image Update warnen.
Auf Docker Hub gibt es offenbar seit 14 Tagen ein neues FHEM Image, das endet bei mir in einer Endlosschleife beim Start. Ich werde das noch näher untersuchen.

Der schnelle Weg zurück:

Code: [Auswählen]

docker image ls
...
docker tag ImageIdDesNeuen-latest-Image fhem/fhem:newest
docker tag ImageIdDesAlten-<none>-Image fhem/fhem:latest
docker compose up -d
BTW: auch das neue deconzcommunity/deconz Image läuft bei nicht...

Gruß Otto

[Sidey]

Auf Docker Hub gibt es offenbar seit 14 Tagen ein neues FHEM Image, das endet bei mir in einer Endlosschleife beim Start. Ich werde das noch näher untersuchen.

Ja, das ist so passiert weil latest quasi immer das neueste ist.
Welche Docker Version verwendest Du auf dem Host? Ggf. ein Debian Stretch?

[Otto123]

System: PRETTY_NAME="Debian GNU/Linux 10 (buster)"
Docker: Server: Docker Engine - Community Engine:   Version:          20.10.14

Ja, das ist so passiert weil latest quasi immer das neueste ist.

Die Begründung verstehe ich nicht ein neues Image sollte ja nicht zwangsweise zum Funktionsverlust führen
Du meinst das neue Image ist bullseye und läuft nicht auf einem Buster Host? 🤔
Ich denke, ich habe andere bullseye Images auf Buster Host getestet...

Aber wie gesagt: ich schaue es mir noch in Ruhe an.

[Sidey]

Die Begründung verstehe ich nicht ein neues Image sollte ja nicht zwangsweise zum Funktionsverlust führen

Das war nicht die Begründung für den Funktionsverlust, sondern eher, dass latest beim letzten deployment mit aktualisiert wurde.

Du meinst das neue Image ist bullseye und läuft nicht auf einem Buster Host? 🤔
Ich denke, ich habe andere bullseye Images auf Buster Host getestet...

Es gab da ein Problem mit einer alten Docker Engine und Images basierend auf Bullseye.
Leider habe ich es auf die schnelle nicht gefunden. Soweit ich mich erinnere war auf raspbian Strecke die docker engine zu alt für das bullseye Image . Da kam es auch immer zu reboots.
War halt eine Idee, dass es daran liegt.

[Sidey]

System: PRETTY_NAME="Debian GNU/Linux 10 (buster)"
Aber wie gesagt: ich schaue es mir noch in Ruhe an.

Ich habe auf einem amd64 System das fhem/fhem:latest problemlos gestartet.

[Otto123]

Ich habe ja nicht gesagt, dass es generell nicht läuft. Aber wenn man in einer bestehenden Installation das Image neu zieht (altes Image war das alte von Julian) gibt es offenbar Inkompatibilitäten. Ich kenne einen weiteren Fall wo es so passiert ist...

Ich wollte lediglich

... mal vorsichtig vor einem unvorbereiteten Image Update warnen.

Oder sagt man dazu anders wenn man ein aktuelleres Docker Image zieht und anwendet?

[Sidey]

Ich wollte lediglich 
Oder sagt man dazu anders wenn man ein aktuelleres Docker Image zieht und anwendet?

Passt, die Warnung ist ja durchaus auch in Ordnung. Ich konnte den Fehler nur leider nicht nachstellen. Wenn Du weitere Erkenntnisse hast, dann her damit.

Grüße Sidey

[GammaTwin]

Grüße,

es gibt auch ein "latest" buster-image:

Code: [Auswählen]

fhem/fhem:buster

[kennymc.c]

Ich hab festgestellt, dass wenn ich im WEB Device statt global eine bestimmte IP angebe, damit Fhem nur noch über diese IP erreichbar sein soll, der Health Status des Image nach kurzer Zeit auf unhealthy wechselt. Ich habe schon versucht DOCKER_HOST auf die entsprechende IP zu setzten. Gibt es einen anderen Weg, das selbe Ziel zu erreichen, wenn der Container im Host Modus laufen muss?

[Sidey]

Ich hab festgestellt, dass wenn ich im WEB Device statt global eine bestimmte IP angebe, damit Fhem nur noch über diese IP erreichbar sein soll, der Health Status des Image nach kurzer Zeit auf unhealthy wechselt.

Der Healthcheck läuft innerhalb des Containers gegen localhost.
Dieser Zugriff muss erlaubt sein.

Ich verstehe aber eventuell nicht exakt, was Du gemacht hast, also welche Attribut Du gesetzt hast.
Mich würde ebenso interessieren, was genau Du erreichen möchtest.


Grüße Sidey

[kennymc.c]

Ich möchte wie erwähnt, dass Fhem nur über ein Netzwerk Interface erreichbar ist, da mein Server mehrere NICs besitzt und Fhem momentan über alle erreichbar ist.
Momentan ist das WEB Device so definiert:

Code: [Auswählen]

WEB FHEMWEB 8083 globalWenn ich es auf

Code: [Auswählen]

WEB FHEMWEB 8083 192.168.1.203 ändere bekomme ich das genannte Problem mit dem Health Check.