Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[kjmEjfu]

Alpine ist sehr viel besser für Container geeignet, weil es so reduziert ist.

@Otto: wenn du in deinem Dockerfile ein "RUN" nutzt, dann kannst du auch dort files per wget runterladen. Man muss nur daran denken, dass jedes RUN das aktuelle Verzeichnis verliert. Heißt man muss das immer erst wieder setzen.

also z.B.

Code Auswählen Erweitern


RUN cd /opt/fhem && wget http://.... && chmod ....

Ein, für mich, sehr lehrreiches Beispiel ist auch https://github.com/instantlinux/docker-tools/blob/main/images/duplicati/Dockerfile

[Wernieman]

Ich würde RUN auch versuchen zusammenzuschmeißen. Bei jedem RUN wird eine eigene "Dockerschicht" erzeugt.

[klugec]

Hallo,

im Moment nutze das offizielle FHEM aus dem Dockerhub. Wie ich mitbekommen habe ist die Version auf Github aktueller (ghcr.io/fhem/fhem/fhem-docker:buster).
In der Beschreibung steht drin das alexa-fhem und tradfri-fhem nicht vorinstalliert ist.
Wie müsste ich das nachträglich installieren? Ich nutze für all meine Anwendungen Docker-Compose (yaml).

Ich danke euch für eure Antworten.


LG

[Otto123]

Ich denke, für alexa-fhem einen separaten container nehmen: https://github.com/fhem/alexa-fhem-docker
Zumindest meine Hoffnung, stehe nämlich auch kurz vor der Umstellung eines solchen Systems.

[kadettilac89]

Hallo,

im Moment nutze das offizielle FHEM aus dem Dockerhub. Wie ich mitbekommen habe ist die Version auf Github aktueller (ghcr.io/fhem/fhem/fhem-docker:buster).
In der Beschreibung steht drin das alexa-fhem und tradfri-fhem nicht vorinstalliert ist.
Wie müsste ich das nachträglich installieren? Ich nutze für all meine Anwendungen Docker-Compose (yaml).

Wenn du die Dienste in Fhem-Container willst hast du den Parameter s. u. da kannst du  beim Erstellen des Containers die Pakete installieren lassen. Beispiel für google-home von mir. npm müsste bei dir schon installiert sein, kannst dann auch weglassen.

Code Auswählen Erweitern


            NPM_PKGS: "npm gassistant-fhem"


Alternativ, wenn npm bei dir enthalten ist, kannst du unter Menüpunkt System->node.js alexa-fhem / tradi-fhem nachinstallieren. Das musst jedesmal machen wenn das Image aktuallisiert wird.

[klugec]

Wenn du die Dienste in Fhem-Container willst hast du den Parameter s. u. da kannst du  beim Erstellen des Containers die Pakete installieren lassen. Beispiel für google-home von mir. npm müsste bei dir schon installiert sein, kannst dann auch weglassen.

Code Auswählen Erweitern


            NPM_PKGS: "npm gassistant-fhem"


Alternativ, wenn npm bei dir enthalten ist, kannst du unter Menüpunkt System->node.js alexa-fhem / tradi-fhem nachinstallieren. Das musst jedesmal machen wenn das Image aktuallisiert wird.

Vielen Dank für die schnelle Antowrt. Ich werde mich damit mal befassen und bei Fragen oder Problemen melde ich mich wieder. 

EDIT:

Ich bekomme über docker-compose eine Fehlermeldung wenn ich die yaml ausführe:

Code Auswählen Erweitern

Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Pulling fhem (ghcr.io/fhem/fhem/fhem-docker:buster)...
ERROR: manifest unknown

Der Teil in meiner yaml sieht so aus:

Code Auswählen Erweitern

  #Hausautomation FHEM
  fhem:
    restart: always
    ports:
      - "$FHEM_PORT:8083"
      - "7072:7072"
      - "1883:1883"
      - "8090:8090"
      - "8383:8383"
      - "3002:3002"
    image: ghcr.io/fhem/fhem/fhem-docker:buster
    depends_on:
      - mariadb
    container_name: fhem
    volumes:
      - $DOCKERDIR/fhem:/opt/fhem/
    networks:
      t2_proxy:
        ipv4_address: 192.168.91.249
    environment:
      FHEM_UID: 1000
      FHEM_GID: 1000
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      GPIO_GID: 6002
      TZ: $TZ
      NPM_PKGS: "alexa-fhem tradfri-fhem alexa-cookie2"
    labels:
      ## Watchtower
      - "com.centurylinklabs.watchtower.enable=true"

Hab ich da jetzt einen Denkfehler? Hab bisher immer nur mit dem dockerhub gearbeitet

[kadettilac89]

Ich bekomme über docker-compose eine Fehlermeldung wenn ich die yaml ausführe:

Code Auswählen Erweitern

Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Pulling fhem (ghcr.io/fhem/fhem/fhem-docker:buster)...
ERROR: manifest unknown

Ich vermute für die CPU-Architekur gibt es (noch) keinen Container. Hast du den Docker auf einen Raspberry versucht? ARM-CPU ... Teste mal mit dem originalen Image, das gibt es für Raspberry CPU

[klugec]

Ich vermute für die CPU-Architekur gibt es (noch) keinen Container. Hast du den Docker auf einen Raspberry versucht? ARM-CPU ... Teste mal mit dem originalen Image, das gibt es für Raspberry CPU

Ich nutze einen raspberry pi 4 8gb mit dem offiziellen pi OS 64-bit (buster). Fhem aus dem docker hub funktioniert ohne Probleme. Weiß nicht ob man mit einem github Image irgendwas anders machen muss?

[Otto123]

im Dockerhub steht beim offiziellen Image ARM64v8 - im ghcr.io/fhem/fhem/fhem-docker:buster steht was von linux/arm64

Ich finde den Zustand vom "offziellen FHEM Docker Basis Image" ziemlich verwurschtelt. Ich seh da nicht mehr durch. Das ist weder Basis noch für den Laien verständlich - aber ich will nicht meckern, ich habe keinen Ansatz zu helfen. Vielleicht versuch ich deswegen, die Sache mit dem Dockerfile zu verstehen.

[kadettilac89]

Ich nutze einen raspberry pi 4 8gb mit dem offiziellen pi OS 64-bit (buster). Fhem aus dem docker hub funktioniert ohne Probleme. Weiß nicht ob man mit einem github Image irgendwas anders machen muss?

So wie es aussieht wurden die (dev)-Container nur für amd64 CPU erstellt aber nicht für die Raspberry ARM-CPU. Da musst du warten bis sich der Maintainer meldet.

Verwende erstmal das Original Image. Du kannst später immer noch ein anderes Image verwenden ohne dass du Daten verlierst.

Alternativ kannst du dir das Image selber erstellen. Dockerfile ist verfügbar ... lohnt vermutlich aber nicht. Weiß nicht wie viel Ahnung du davon hast.

Edit:
Teste mal dieses Image hier ... das ist auch als arm64 getaggt ... das lädt dann explizit arm64 für den rpi runter. Als Test ob die Manifest-Meldung noch kommt.

ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster@sha256:2d328e8c35060f8b2b4bcdbc819c0776b2bd8a5e35340c26c242ba2c18eb3ad0

[klugec]

So wie es aussieht wurden die (dev)-Container nur für amd64 CPU erstellt aber nicht für die Raspberry ARM-CPU. Da musst du warten bis sich der Maintainer meldet.

Verwende erstmal das Original Image. Du kannst später immer noch ein anderes Image verwenden ohne dass du Daten verlierst.

Alternativ kannst du dir das Image selber erstellen. Dockerfile ist verfügbar ... lohnt vermutlich aber nicht. Weiß nicht wie viel Ahnung du davon hast.

Edit:
Teste mal dieses Image hier ... das ist auch als arm64 getaggt ... das lädt dann explizit arm64 für den rpi runter. Als Test ob die Manifest-Meldung noch kommt.

ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster@sha256:2d328e8c35060f8b2b4bcdbc819c0776b2bd8a5e35340c26c242ba2c18eb3ad0

Ich habe es mal getestet. Das funktioniert komischerweise ohne Probleme.
Bei dem anderen Image steht ja auch Linux/ARM64 dabei, aber wieso das nicht funktioniert weiß ich nicht. Da bin ich nicht tief genug in der Materie drin

[Sidey]

Ich finde den Zustand vom "offziellen FHEM Docker Basis Image" ziemlich verwurschtelt.

Kannst Du das etwas präziser benennen was undurchsichtig ist?

[kadettilac89]

Ich habe es mal getestet. Das funktioniert komischerweise ohne Probleme.
Bei dem anderen Image steht ja auch Linux/ARM64 dabei, aber wieso das nicht funktioniert weiß ich nicht. Da bin ich nicht tief genug in der Materie drin

Funktioniert es auch mit dem Namen ohne dem @sha-Teil?
ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster

Das ist nicht das Image von dir, sondern ein anderes. Ich weiß jetzt nicht woher du den anderen Link hast. Entweder es ist generell nicht mehr vorhanden, oder es wurde (damals) nicht für arm erstellt. Ich glaube das war eines der ersten in Github mit der Container-Registry.

[Sidey]

Funktioniert es auch mit dem Namen ohne dem @sha-Teil?
ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster

Geht auch ohne. Alles was nach dem @ kommt, spezifiziert die Version.
Ich strebe an, sowas wie @3.0.0-buster oder @3.0.0-bullseye zu veröffentlichen.

Grüße Sidey

[kadettilac89]

Geht auch ohne. Alles was nach dem @ kommt, spezifiziert die Version.

Der Test mit dem @sha-Teil war dazu gedacht es generell zu testen. klugec hatte mit einer anderen github-Version einen Manifest-Error, ich konnte die Version mit amd64 aber ziehen. Der mit/ohne sha-Test sollte nur seine Installation von docker-compose bestätigen.

Wenn manifest cpu amd64 + arm64 enthält müsste es gehen. Da es neuere Github-Versionen gibt habe ich auch nicht mehr das ältere Image sondern ein aktuelles zum Testen vorgeschlagen. Wenn es mit dem neueren auch ohne @sha geht (Test von mir angefragrt) dann braucht es keiner weiteren Analyse.