Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[eisler]

Hallo Loredo,

hatten wir schon mal, sollte das nicht täglich geupdatet werden?
Auf hub.docker.com steht "Updated 2 days ago".

Grüße
Stephan

[vbs]

Habt ihr evtl. einen Tipp für mich, wie ich ein USB-Device in Docker sauber einbinden kann, dessen Bezeichnung sich potenziell ändern kann?

Ich würde gernen einen VOC-USB-Stick einbinden in einen Container den ich per compose starte. Der Stick ist momentan als "/dev/bus/usb/002/009" erreichbar. Wird aber beim nächsten Anstecken ein anderer Pfad sein.

Ich hab schon versucht, per udev eine Regel zu definieren, die das Gerät immer als Symlink auch nach "/dev/iaqstick" legt. Jedoch funktioniert der Stick nicht, wenn ich nur dieses Device dem Container bereit stelle. Aus der compose.yml:

Code Auswählen Erweitern

    devices:
    - "/dev/iaqstick:/dev/iaqstick"


Das ist vermtl. eine bessere Beschreibung als ich sie zustande bringe:
https://github.com/moby/moby/issues/13840

Hat das jemand da eine schöne Lösung für? Danke!

[kadettilac89]

Habt ihr evtl. einen Tipp für mich, wie ich ein USB-Device in Docker sauber einbinden kann, dessen Bezeichnung sich potenziell ändern kann?


Hat das jemand da eine schöne Lösung für? Danke!

devices:
            #- " /dev/ttyUSB0:/dev/ttyUSB0" 
            #- " /dev/ttyUSB1:/dev/ttyUSB1"
            - "/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0:/dev/ttyUSB0" 
            - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A7031TM7-if00-port0:/dev/ttyUSB1"

Über Serial Boy ID?

Sieht bei mir so aus wie oben gepostet.

[kadettilac89]

Coole autocorrection    Serial by  ID natürlich

[vbs]

Dieser VOC-Stick ist leider kein serielles Device und taucht deshalb nicht unter /dev/serial auf

Code Auswählen Erweitern

T:  Bus=02 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
P:  Vendor=03eb ProdID=2013 Rev=10.00
S:  Manufacturer=AppliedSensor
S:  Product=iAQ Stick
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbfs


Driver ist "usbfs".

[kadettilac89]

Ok. Sauber ist vielleicht das falsche Wort dafür aber so wird es gehen

Docker-compose mit einer .env datei nutzen

Beim Start des Servers den sym-link auswerten und eine Zeile (variable) in der .env mit der aktuellen Adresse  /dev/bus/USB... setzen. Name z.b. usbport

Im docker-compose eine Zeile
-{usbport}:/dev/usb1

Beim Start des Server ein docker-compose up ausführen. Wenn der port geändert wurde wird der Container neu erzeugt mit richtigem Link. Wenn der port gleich bleibt wird nichts neu generiert

Nachteilig ist halt die 2 Minuten Zeit die ggf. Benötigt werden.

[vbs]

Hm, hatte auch über sowas nachgedacht, aber bin mir wegen mindestens eins Punktes unsicher:
Wenn ich "restart: always" setze, dann wird der Container ja nach dem nächsten Reboot automatisch wieder gestartet (von irgendeinem Docker-Dienst offenbar). Ich vermute mal, dass dieser Docker-Dienst es ja nicht hinbekommen wird, auch erst automatisch diese Env-Variable auszuwerten und stattdessen den Container einfach gemäß des zuletzten gesetzten Wertes starten wird? Der wird dann wahrscheinlich nach dem nächsten Reboot ja nicht mehr stimmen.

[kadettilac89]

Das ist richtig. Du kannst aber entweder den Dienst in systemd anpassen und ein docker-compose up einfügen oder einen eigenen Dienst schreiben.

Aber selbst wenn du docker starten lässt, würde das docker-compose up den Container neu starten. Du hättest ggf. Ein paar fehler im log.

[vbs]

Ok danke dir! Ist ja schonmal ein Weg. Noch schicker wäre es natürlich mit Docker-Bordmitteln.

[kadettilac89]

kennst du dich mit systemd aus? im ordner /etc/systemd/system/docker.service.d eine config eingefügt ändert den dienst ohne dass du viel machen musst. meine container downloads liegen bei mir extern ... beispiel meiner local.conf

Code Auswählen Erweitern


[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -g /media/SSD2/docker_lib -H unix://


an dieser Stelle könntest du " && sleep 5 && docker-compose up -d" einfügen.

läuft dein docker mit "privileged: true"? nicht empfohlen, aber manchmal nötig. Dann kannst du direkt auf den Host durchgreifen.

andere idee, /dev:/dev als volume mounten und beim systemstart mit docker exec -it <fhemcontainer> chown root:dailout ****   die Rechte ändern und über telnet in fhem ein defmod auf das DEVIO durchführen ... könnte gehen ...

[ulli]

Du bist natürlich herzlich eingeladen tatkräftig zu unterstützen, meckern kann schließlich jeder 

Ja dann nehme ich dich beim Wort

Anbei ein angepasstes Dockerfile mit folgenden Anpassungen:
* Zusätzliches Argument für eine Light Konfiguration (460MB container) in kombination mit den anderen Argumenten "IMAGE_LAYER_"
   IMAGE_LAYER_FHEM_BASE_ONLY
   IMAGE_LAYER_PERL_CPAN_BASE_ONLY
* Zusätzliche Argumente indem man je nach Bedarf Pakete ergänzen kann
    IMAGE_USER_PACKAGES_DEBIAN
    IMAGE_USER_PACKAGES_PERL
    IMAGE_USER_PACKAGES_PERL_CPAN

Was denkst du?


-------------------------
Update:
- Eins ist mir noch aufgefallen. Bei einer Abschaltung von NodeJS über das Argument erscheint in FHEM immer noch das "npmjs" Device.
  Natürlich mit einem Fehler.
- Die neuen Argumente lassen sich jetzt über das Docker-Compose File setzten.
   (Die wurden vorher immer wieder über das DockerFile überschrieben)

[Loredo]

Bitte einen Pull Request auf Github fürs korrekte Source Handling und Bugtracking aufmachen.


PS: Sinn ist nicht, dass das Dockefile mit jeder möglichen Variable zugebombt wird. Ziel ist, dass es ein vorkompiliertes Image gibt und nicht, dass man sich das Image jedes Mal selbst neu bauen muss. Um die Wartbarkeit zu erhalten soll das Dockerfile nicht noch mehr wenn/dann/sonst bekommen als ohnehin schon.

[Wernieman]

Dafür wurde bis jetzt das Dockerfile mit allen Möglichkeiten "zugebombt" ... also nicht gerade "leicht und einfach" aus Systemsicht ...

[Loredo]

Dem stimme ich so nicht zu.


Du kannst das ganze auch nur aus Anwendersicht betrachten: Ob da jetzt ein paar Hundert Megabyte mehr oder weniger auf der Festplatte/SSD/Speicherkarte/younameit liegen, kratzt niemanden. Es geht um die Funktion - und dass bei FHEM so viele kunterbunte Komponenten verwendet werden, dafür kann niemand was (und man kann das auch als Vorteil auslegen). Was man aber versuchen kann ist dies zu ordnen (siehe z.B. auch anderer Thread über Meta.pm). Wenn das mal geordnet ist, dann kann man auch besser entscheiden welche Pakete man für welches FHEM Modul auch tatsächlich braucht - vorher geht das nicht. Zumindest ist es nicht Ziel dieses Docker Images hier, dass sich hinterher wieder jeder seine Pakete selbst zusammensuchen muss. Deshalb sind alle Pakete, die man brauchen könnte, solange mit im Image enthalten, bis ein Installer in FHEM die ganze Sache übernehmen kann. Ziel ist ein "it just works", kein Wettbewerb 100 MB weniger Speicherplatz zu verbrauchen - sowas ist in 2019 wirklich überflüssig. Ziel ist, dass man sich auf die Programmierung innerhalb von FHEM konzentrieren kann und nicht erst noch Tage und Wochen mit Systemabhängigkeiten verbringen muss. Genau dafür ist Docker gemacht und genau das machen wir hier auch damit.


Also nochmal: Wer granulare Kontrolle darüber haben möchte, welche einzelne Datei in seinem Docker Container liegt und jede kleine Stellschraube selbst kennen will (oder muss), der baue sich doch bitte seine eigene Dockerfile Datei zusammen. Ich kann diese ganze Diskussion hier überhaupt nicht nachvollziehen, denn es geht in meinen Augen wirklich nur um Gefühlssachen, nix weiter. Ein Argument "ja aber die Dateien sind doch da und wer weiß was man damit anfangen könnte als Angreifer!" lasse ich nicht gelten - ein System hat auch dann sicher zu sein, wenn Dateien da sind, Punkt. Dafür lässt sich Docker selbst prima in einer VM betreiben, mache ich auch so auf einem Proxmox Server. Docker ist nur das Vehicle für die einfache Bereitstellung der Systemumgebung.

[Loredo]

Was denkst du?

Ich habe das mal uminterpretiert und ein erweitertes Dockerfile ins DEV Image eingecheckt:
https://github.com/fhem/fhem-docker/commit/7558a19e55c405c301c52754e222811fdd51a6fe