fhem-docker: Wie alt ist dein Image wirklich?

[Sidey]

Hallo zusammen,

ich pflege das Container Image für FHEM (https://github.com/fhem/fhem-docker). Zwei Dinge möchte ich euch mitgeben.

1. Bitte prüft einmal, wie alt euer Image ist

Wer vor längerer Zeit einmal fhem/fhem:latest (oder ghcr.io/fhem/fhem-docker:latest) gezogen hat, bekommt beim Neustart des Containers kein neues Image. Docker zieht nur bei einem expliziten docker pull bzw. docker compose pull nach. Ein "latest" ist also nur ein Name, der irgendwann einmal auf irgendetwas gezeigt hat. Das hat mehrere Folgen:

• Ihr wisst nicht, welche Version ihr tatsächlich betreibt, und könnt sie in einem Forenbeitrag auch nicht nennen.
• "latest" ist nicht gleich "aktuell": Es zeigt je nach Zeitpunkt auf ganz unterschiedliche Generationen des Images (v3/buster, v4/bullseye, v5/bookworm).
• Ein späteres Pull kann ungeplant einen Generationswechsel bringen, ohne dass man es merkt und ohne einfaches Zurück.

So prüft ihr das Erstellungsdatum:

Code Auswählen Erweitern

# Erstellungsdatum des Images, mit dem ein Container tatsächlich läuft
# (<container> = Name aus "docker ps", beim Compose-Beispiel z. B. home-fhem-1)
docker image inspect --format '{{.RepoTags}} {{.Created}}' $(docker inspect --format '{{.Image}}' <container>)

# Übersicht aller lokalen Images mit Alter
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.CreatedSince}}' | grep -i fhem

Ist das Datum mehr als ein paar Monate alt, lauft ihr mit einem veralteten Debian und Perl, einer nicht mehr unterstützten Node.js-Version und ohne Sicherheitsupdates. Im Zweifel steht dort sogar noch 2023 oder früher.

Empfehlung: einen konkreten Release-Tag verwenden, z. B.

Code Auswählen Erweitern

image: ghcr.io/fhem/fhem-minimal-docker:5.5.0-bookworm

(bzw. 5.5.0-threaded-bookworm). Auch der Tag 5-bookworm ist beweglich: Er zeigt auf den jeweils neuesten 5.x-Stand, aber nur wer aktiv docker compose pull ausführt, bekommt diesen auch. Das Problem ist also dasselbe wie bei "latest", nur ohne den Sprung in eine neue Generation. Mit einem festen Release-Tag ist jederzeit klar, was läuft, und ein Update ist eine bewusste Änderung im Compose-File. Wer das nicht von Hand verfolgen will, lässt Renovate/Dependabot im eigenen Compose-Repository Update-Vorschläge als Pull Request erzeugen.

2. Was seit Herbst 2024 passiert ist – und warum sich ein Update lohnt

Seit dem Start von Version 5 (November 2024 Beta, Januar 2025 final) gab es mehr als 400 Commits und Releases bis v5.5.0 (Oktober 2026). Die wichtigsten Punkte:

Basis und Laufzeit

• Umstieg auf Debian 12 "bookworm"; die bullseye-Images sind aus dem Build entfernt (v4/bullseye ist End-of-Life seit Januar 2025).
• Perl 5.40.5 (zu Beginn von v5 war es 5.36, danach 5.38; auch v4/bullseye hatte 5.38.5); normale und threaded-Variante weiterhin verfügbar.
• Laufzeitumgebungen wieder im Support: Die alten Images bringen Laufzeiten mit, die der Hersteller nicht mehr pflegt: v3 enthielt Node.js 16, v4 Node.js 18 (beide ohne Sicherheitsupdates, Node.js 18 seit April 2025), dazu in v4 noch Python 2.7 sowie Debian 11 bullseye und Perl 5.38. Mit einem Image-Update wechselt ihr automatisch auf eine unterstützte Umgebung: Debian 12, Perl 5.40 und Node.js 22 (nur im Standard-Image). Das ist der eigentliche Grund, warum sich das Update lohnt: Die Laufzeit unter FHEM bekommt wieder Sicherheitsupdates, ohne dass ihr einzelne Pakete selbst nachziehen müsst.
• Node.js wird im Standard-Image aus dem offiziellen Node-Image übernommen statt über apt – deutlich aktueller und nachvollziehbarer.
• Plattformen: amd64, arm64, arm/v7 (und i386 für das Minimal-Image).

Sicherheit und Wartung

• Jeder Build wird mit Trivy gescannt, zusätzlich wird das tatsächlich veröffentlichte Image geprüft.
• Bekannte CVEs durch unbenutzte C-Header (linux-libc-dev) wurden entfernt.
• Renovate hält Basis-Images, Perl, Node und CPAN-Tooling aktuell, Digest-Updates werden automatisch eingespielt und fließen in das jeweils nächste Release ein. Wer einen festen Tag nutzt, sollte ihn deshalb regelmäßig anheben, um die Sicherheitspatches zu bekommen.

Perl-Module

• Die benötigten CPAN-Module werden mit cpm gebaut, automatisch gegen die Abhängigkeiten der FHEM-Module inventarisiert und je Plattform verifiziert (Build-Report als PR-Kommentar). Fehlende Module fallen dadurch im Build und nicht erst bei euch zur Laufzeit auf.
• Nachgezogen u. a.: libfann2 für AI::FANN, HiPi-Build-Header, svn im Image.

Betrieb im Alltag

• Healthcheck: Das Modul DockerImageInfo legt seine Definition jetzt selbst an, falls sie fehlt (auch bei configDB). Einmal save genügt. Abschaltbar mit DOCKER_IMAGEINFO_AUTODEFINE=0. Ohne diese Definition würde der Healthcheck dauerhaft fehlschlagen.
• Laufzeit-Erkennung: Docker, Podman, containerd, CRI-O und Kubernetes werden erkannt und im Reading model ausgewiesen.
• Logfile-Weiterleitung und Start-Wartelogik arbeiten jetzt auch nach dem Neuanlegen der Logdatei (Tageswechsel) zuverlässig.
• Dateirechte beim Start (Ownership-Fixes) sind korrigiert und per Tests abgesichert.
• Alle unterstützten Umgebungsvariablen sind dokumentiert (Tabelle in der README).

Image schlanker und klarer

• Das Minimal-Image (fhem-minimal-docker) ist die empfohlene Basis für neue Setups: FHEM-Perl-Umgebung, aber ohne Python/Node.
• Das Nachinstallieren von Paketen beim Containerstart (APT_PKGS, CPAN_PKGS, PIP_PKGS, NPM_PKGS) gilt als Anti-Pattern; APT_PKGS ist entfernt. Stattdessen das Image per eigenem Dockerfile oder build: im Compose erweitern – Beispiele stehen in der README und in der Migrationsanleitung.
• Ein überarbeitetes docker-compose.yml als Ausgangspunkt (Healthcheck, internes Backend-Netz, PostgreSQL optional).

Sidecar-Container (nur kurz)

Statt alles in ein Image zu packen, gibt es jetzt separate Images, die im Compose-Beispiel schon verdrahtet sind:

• ghcr.io/fhem/alexa-fhem und ghcr.io/fhem/alexa-cookie-service für die Alexa-Anbindung
• ein Postfix-Relay für den Mailversand aus FHEM

Sie hängen zusammen mit FHEM in einem internen Backend-Netz ohne direkten Zugang von außen (Ausnahme: der alexa-cookie-service veröffentlicht Port 58090) und lassen sich unabhängig updaten.

Das Compose-Beispiel für das eigene Setup nutzen

Das docker-compose.yml im Repository wird mit dem Image gepflegt (Healthcheck, internes Backend-Netz, Sidecars als Profile). Es ist dafür gedacht, direkt benutzt zu werden – das Repository muss man dafür nicht klonen, die eine Datei genügt:

Code Auswählen Erweitern

mkdir -p /docker/home && cd /docker/home
curl -fsSL -O https://github.com/fhem/fhem-docker/raw/dev/docker-compose.yml
docker compose up -d

Wichtig: Die Datei verwendet den beweglichen Tag 5-bookworm. Wer, wie oben empfohlen, einen festen Tag möchte, setzt ihn in der compose.override.yml:

Code Auswählen Erweitern

services:
  fhem:
    image: ghcr.io/fhem/fhem-minimal-docker:5.5.0-bookworm

Das Verzeichnis heißt später als Projektname in den Containernamen, bei mehreren Stacks also sinnvoll benennen. FHEM legt seine Daten unter ./fhem/ ab. Ein bestehendes FHEM-Verzeichnis kann dort einfach eingehängt werden.

• Eigene Einstellungen gehören in eine .env (z. B. TZ=Europe/Berlin; beim Alexa-Profil unbedingt ALEXA_COOKIE_SERVICE_TOKEN setzen, der Standardwert ist change-me) oder in eine compose.override.yml neben der Datei, die Compose automatisch mitliest. So bleibt die heruntergeladene Datei unverändert und lässt sich später einfach erneut holen.
• Die Zusatzdienste sind per Profil optional: docker compose --profile db up -d, --profile mail, --profile alexa.
• USB-Geräte, Host-Netzwerk oder privilegierter Modus sind hostspezifisch und gehören bewusst in die eigene Override-Datei.

Updaten

• Die Release-Hinweise bzw. die Migrationsanleitung (migration.md) ansehen, besonders wenn ihr noch *_PKGS-Variablen nutzt.
• Das Compose-File erneut laden und die Änderungen ansehen (z. B. curl -fsSL -o docker-compose.new.yml ... und diff) oder nur den Image-Tag in der eigenen Datei anheben.
• docker compose pull && docker compose up -d
• Nach dem Start (die DockerImageInfo-Definition entsteht kurz danach) einmal save ausführen und das Log prüfen.
• Nutzer von i386: Das Voll-Image (fhem-docker) wird seit 5.5.0 nicht mehr für linux/386 gebaut. Dort bitte auf das Minimal-Image wechseln.

Das FHEM-Verzeichnis im Volume wird dabei nicht angefasst; aktualisiert wird nur die Laufumgebung.

Links:

• Migrationsanleitung (Umstieg von v3/v4, Ersatz für die *_PKGS-Variablen): https://github.com/fhem/fhem-docker/blob/dev/migration.md
• Repository & README: https://github.com/fhem/fhem-docker
• Images: https://github.com/orgs/fhem/packages
• Probleme/Wünsche (z. B. fehlende Perl-Module): bitte als Issue im Repository

Rückmeldungen und Erfahrungen nach dem Update sind willkommen.

Grüße
Sidey

[CoolTux]

Sag mal mein Lieber, warst Du in meiner Kubernetes/Docker Schulung 
Das ist mit das erste was ich meinen Teilnehmern beibringe. Niemals never sollt Ihr latest als Tag nehmen sondern immer eindeutige Versionen.

Und das zweite ist, arbeitet immer mit Ressourcen Begrenzungen.


Grüße