Bereitstellung Jessie + FHEM Docker Image

[StefanP.]

Hi,

der Start des Docker Containers muss tatsächlich über ssh erfolgen. Danach taucht der Container im GUI auf und kann dann ganz normal verwaltet werden, z.B. können die Ports 8083, 84, 85 und 7072 übers GUI geöffnet werden, die Logs werden angezeigt, laufende Prozesse etc.

Warum der --device Parameter dem GUI nicht bekannt ist - keine Ahnung. Vermutlich ein Bug.

Noch 3 Dinge, die mir im Laufe der Testerei aufgefallen sind:
1. die Zeitzone muss beim Start des Containers auf Europe/Berlin eingestellt werden
2. damit das PRESENCE Modul via LAN Ping funktioniert, brauchts den Befehl "chmod u+s `which ping`"
3. mit "docker exec -it <containerId> /bin/bash" kann man sich mit dem laufenden Daemon Container verbinden (wird vom GUI auch noch nicht unterstützt)

Generell würde ich immer mit der Kommandozeile über ssh arbeiten - das GUI ist (wie so oft) zwar anwenderfreundlich, aber doch sehr eingeschränkt, was die Features von Docker betrifft.

Viel Spaß,
Stefan

[graszegger]

Hallo,

ich kann den Container und FHEM Starten:

Code Auswählen Erweitern


2015.05.28 07:48:59 1: Including fhem.cfg
2015.05.28 07:48:59 3: telnetPort: port 7072 opened
2015.05.28 07:48:59 3: WEB: port 8083 opened
2015.05.28 07:48:59 3: WEBphone: port 8084 opened
2015.05.28 07:48:59 3: WEBtablet: port 8085 opened
2015.05.28 07:48:59 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2015.05.28 07:48:59 1: Including ./log/fhem.save
2015.05.28 07:48:59 1: usb create starting
2015.05.28 07:48:59 1: PERL WARNING: Can't exec "lsusb": No such file or directory at ./FHEM/98_autocreate.pm line 366.
2015.05.28 07:48:59 3: Probing CUL device /dev/ttyACM0
2015.05.28 07:48:59 1: define CUL_0 CUL /dev/ttyACM0@9600 1034
2015.05.28 07:48:59 3: Opening CUL_0 device /dev/ttyACM0
2015.05.28 07:48:59 3: Setting CUL_0 baudrate to 9600
2015.05.28 07:48:59 3: CUL_0 device opened
2015.05.28 07:48:59 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2015.05.28 07:48:59 1: usb create end
2015.05.28 07:48:59 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2015.05.28 07:48:59 0: Server started with 10 defined entities (version $Id: fhem.pl 6913 2014-11-08 10:32:44Z rudolfkoenig $, os linux, user fhem, pid 7)



--device=/dev/ttyACM0 wird aber von der GUI nicht unterstützt und ist dort beim Container auch nicht zu sehen.
Starte ich den Container über die GUI wird das device nicht verbunden/gefunden.

In der Hilfe auf der Synology finde ich dazu folgendes:

Die Ausführung von Docker unterstützt nicht die nachstehenden Parameter:
"a", "attach"
"add-host"
"c", "cpu-shares"
"cap-add"
"cap-drop"
"cidfile"
"cpuset"
"device"
"dns"
"dns-search"
"entrypoint"
"env-file"
"expose"
"h", "hostname"
"i", "interactive"
"lxc-conf"
"net"
"restart"
"rm"
"security-opt"
"sig-proxy"
"t", "tty"
"u", "user"
"w", "workdir"

Führe ich den befehl über telnet erneut aus wird ein zweiter Container erstellt und gestartet.
docker run -d -p 8083:8083 --device=/dev/ttyACM0 xiberger/jessie_fhem /bin/bash -c /opt/fhem/fhem.sh

Somit sind natürlich auch alle einstellungen verloren ... der name des Containers wird scheinbar irgendwie zufällig generiert.
Ich vermute nach einem Neustart sind also alle Einstellungen verloren?

Des weiteren ist mir auch aufgefallen, wenn das Paket über die GUI heruntergeladen wird wird es über SSH nicht erkannt und erneut heruntergeladen.

Gibt es einen Befehl um den vorhanden Container mit dem Device zu starten?

Vielen Dank!

fg
Roland

[StefanP.]

Hi,

die oben beschriebenen Sachverhalte sind (fast) alle korrekt.

Docker hat gewisse Eigenheiten, an die muss man sich erst gewöhnen.
Ich würde das Einlesen in die Docker Basis Doku empfehlen, da sind die meisten Fragen beantwortet: https://docs.docker.com/userguide/

Im Detail:
- mit der Kommandozeile über ssh arbeiten, da mächtiger als das GUI
- das Image ziehen, dann den Container starten und Modifikationen vornehmen
- wenn im Container Änderungen am Image vorgenommen werden (Konfig, Aktualisierungen, Anpassungen der fhem.cfg etc.), dann können diese Änderungen mit dem "docker commit" Befehl im Image persistiert / zurück geschrieben werden. Am besten ein sprechendes Label / "Tag" mitgeben, sonst verliert man bei der wachsenden Anzahl von Images den Überblick
- jeder Container bekommt dafür eine eigene Id
- wenn die Änderungen im Image persistiert sind (mit einem Tag, z.B. ":v2"), würde der Start eines neuen Containers entsprechend mit dem modifizierten Image "xiberger/jessie_fhem:v2" erfolgen
- "docker list images" zeigt alle Images, "docker ps" zeigt alle Container
- "docker rm" und "docker rmi" löschen Container bzw. Images

Docker braucht eine gewisse Einarbeitungszeit. Es ist nicht immer selbsterklärend. Man muss viel mit den selbstgenerierten Ids arbeiten, was nicht 100% intuitiv ist.
Man wird dafür mit einer schlanken lauffähigen fhem Installation belohnt, die grad einmal 40MB Speicher braucht...

Viel Spaß & Grüße,
Stefan

[graszegger]

Vielen Dank für den Link mit der Doku!

By default, Docker containers are "unprivileged" and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a "privileged" container is given access to all devices (see lxc-template.go and documentation on cgroups devices).

When the operator executes docker run --privileged, Docker will enable to access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host. Additional information about running with --privileged is available on the Docker Blog.

If you want to limit access to a specific device or devices you can use the --device flag. It allows you to specify one or more devices that will be accessible within the container.

In der GUI findet man unter den "Erweiterten Einstellungen" / "Umwelt" (dort wo auch der Ausführungsbefehl angegeben werden kann) die Option "Container mit hoher Priorität ausführen".
Ich vermute dies entspricht der option "--privileged".

Auf jeden fall funktioniet es mit dieser Option nun auch in der GUI ohne die CLI anfassen zu müssen
Ein CHMOD sollte dadurch auch nicht mehr notwendig sein....

Ob es gut ist den Container mit root rechten laufen zu lassen ist eine andere Frage .... !?

[StefanP.]

Ich hab in einem der vielen Docker Artikel gelesen (ich find ihn grad nicht mehr.. waren zuviele...), dass die --privileged Option vermieden werden sollte - der Container hat damit wohl root Zugriff auf die Host Ressourcen bzw Firmware (wie eben das tty device). Wenn der Container Amok läuft (aus welchen Gründen auch immer - z.B. rein hypothetisch angenommen, jemand würde es gelingen, einen Exploit als fhem pm Modul einzuschleusen), kann das die Syno killen... das wäre mir persönlich zu heiss.

Es gibt wohl die Möglilchkeit, mit einem "capabilities Flag" diese uneingeschränkten Rechte wieder zu beschränken:
http://opensource.com/business/15/3/docker-security-tuning

Ich würde da eher den chmod Weg beim Startup der Syno gehen, das kann ja auch über ein Startup Script erledigt werden. Der Container selbst braucht ja m.E. keine weiteren Rechte außer den Zugriff auf den CUL.


P.S.: das gehört jetzt nicht zum Security Thema: was mir selbst noch nicht klar ist: wenn die Syno (und damit der Container) neu gestartet wird, dann sind vermutlich die Inhalte des Containers (log Dateien, Erweiterungen etc.) verloren, wenn zwischendurch nicht ein docker commit abgesetzt worden ist... hmmm dazu muss ich mir mal Gedanken machen.

[gamauf]

Hallo Stefan!

Ich bin zwar kein Docker Experte, aber so wie ich das Konzept verstanden habe, sollte im Container nur die Binaries, also der Programmcode, aber nicht die individuelle Konfiguration (logs, fhem.cfg, etc) liegen. Das log Verzeichnis, fhem.cfg und was sonst noch zur Konfiguration gehört würde ich auf einer Freigabe der Disksation, die ich im Docker-Container mounte, ablegen.

[StefanP.]

Hi,

ja, stimmt, das ist eine gute Idee. Vermutlich müsste das ganze /opt/fhem Verzeichnis über ein share gemappt werden, dann geht nichts verloren. Die Updates laufen dann ja ohnehin in fhem und nicht über den Package Manager.

Die Frage, die ich mir grad stelle, ist, ob statt Docker nicht die VirtualBox mit einer "echten" virtuellen Linux Jessie Installation eine bessere Lösung ist (die zudem auch im Vgl. zum Docker Package auf allen Synology DSMs läuft)...

Naja, aber immerhin, die Docker Lösung funktioniert 

Schöne Grüße,
Stefan

[SpenZerX]

Hallo,

das Thema interessiert mich.
Wie viele Container mit FHEM könnte man denn auf aktueller Hardware x86 parallel laufen lassen? Wie wird dargestellt wie viel Rechenzeit die einzelnen Cointainer verbrauchen?
Würde gerne einen cloud FHEM-Entwicklungsserver aufbauen. Mit vielen Instanzen. wäre Docker da das richtige? Oder OpenShift?

MFG

[StefanP.]

Hallo,

Docker zeigt auf meiner Synology den Speicherbedarf für den laufenden Container mit 40MB an.
Ja, die Last wird ebenfalls angezeigt, benötigt minimal CPU - zu 98% läuft der Container (bei mir zumindest) im Leerlauf, hängt natürlich davon ab, was man mit der fhem Installation anstellt.

Zum Vergleich: meine VirtualBox VM (auch Jessie + fhem) läuft mit 128MB RAM.

Die Docker Installation hat einige Probleme verursacht (siehe oben) - das tty Device muss berechtigt werden, der ping lief am Anfang nicht, und interessanterweise machte der CUL Stick über Docker auch Probleme, auch wenn er problemlos erkannt und eingebunden worden ist.
Von da her gesehen bin ich jetzt auf die VirtualBox umgestiegen, out of the box alles problemlos, und für meinen Einsatzbereich (zur Ablösung meines Pi's) wohl die bessere Lösung.

Viel Erfolg,
Stefan

[kunze]

Hallo,

ich habe den Ansatz mit Docker noch mal weiterverfolgt und umgesetzt:
Mit diesem Docker Image (https://hub.docker.com/r/michaelatdocker/fhem/) läuft FHEM bei mir seit in paar Tagen auf der Synology.
Allerdings verwende ich keinen CUL stick sondern einen HM-CFG-USB-2 da ich weitgehend mit HomeMatic arbeite.
Der 'Treiber' (http://www.fhemwiki.de/wiki/HM-CFG-USB_USB_Konfigurations-Adapter#Einrichtung_auf_Synology_DiskStations)
für den HM-CFG-USB-2 läuft direkt auf der DiskStation und der Zugriff aus dem Docker Container erfolgt übers Netzwerk.

Schön Grüße

[paj]

Anyone stumbling across this due to fhem ttyusb access problems in a docker container you need to

1. use privileged mode
2. make sure the fhem container user is a member of the dialout group in the container i.e run usermod -a -G dialout fhem in your Dockerfile.