ioBroker in eigenem docker-container auf RPi3

Sylvan

Ich versuche iobroker auf einem Raspberry Pi 3 (mit Arch Linux) unter Docker zum Laufen zu bekommen.
Die fertigen Images (buanet, angelnu) versagen bei mir jedoch den Dienst.

Also dachte ich mir: Dann mach halt ein eigenes Image.
Sollte ja nicht so schwer sein - ein debian baseimage und dann einfach der sehr kurzen Installationsanleitung folgen.
Viele verschiedene Testkonstellationen später (alpine-base, node-base, debian-9/10-base, raspbian-stretch-base, node 8 vs. node 10) lande ich immer beim selben Problem:

Ich bekomme iobroker installiert und ein iobroker status im Container bringt mir die Meldung das iobroker läuft.
Eine Aufruf von Port 8081 im Browser versagt jedoch.

Was ich zum debuggen schon alles versucht / herausbekommen habe:

egal ob der Container im bridged oder host-mode läuft - geht nicht.
im host-mode bringt ss -tanp die Info, dass die Ports 8081-8084 nicht geöffnet sind.
Die Ports 9000 und 9001 werden von iobroker.js-con geöffnet
im bridge-mode sind die Ports 8081-8084 natürlich offen - hierbei allerdings natürlich nur seitens des docker-proxy.
ein ss -tanp im Container selbst zeigt nämlich, dass dort die Ports 8081-8084 nicht geöffnet wurden (egal ob host oder bridged mode).
iobroker list adapters meldet, u. A.:
system.adapter.admin.0 : admin - enabled, port: 8081, bind: 0.0.0.0, run as: admin
Stoppen und neustarten der Admin-Instanz bringt keinen Erfolg

Das letzte Dockerfile sieht bei mir so aus:

FROM raspbian/stretch as iobrokerbase

ENV LANG="de_DE.UTF-8" \
	LANGUAGE="de_DE:de" \
	LC_ALL="de_DE.UTF-8" \
	TZ="Europe/Berlin"

RUN apt-get update -y \
	&& apt-get install -y curl locales \
	&& sed -i 's/^# *\(de_DE.UTF-8\)/\1/' /etc/locale.gen \
	&& locale-gen \
	&& curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - \
	&& sudo apt-get install -y nodejs \
	&& sudo mkdir -p /opt/iobroker/ \
	&& curl -sL https://iobroker.net/install.sh | bash - \
	&& apt-get clean -y \
	&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

WORKDIR /opt/iobroker/
ADD scripts/run.sh run.sh
RUN chmod +x run.sh
VOLUME /opt/iobroker/

EXPOSE 8081 8082 8083 8084
CMD /opt/iobroker/run.sh

mit folgender kurzen run.sh:

#!/bin/sh
node node_modules/iobroker.js-controller/controller.js

Und aufgerufen wird es aktuell per docker-compose (auch per docker build und docker run habe ich es versucht) mit folgender docker-compose.yml:

version: '3.4'

services:
    iobroker:
        build:
            context: .
            dockerfile: Dockerfile
        restart: unless-stopped
        ports: 
            - "8081-8084:8081-8084"
        cap_add:
            - NET_ADMIN

docker inspect und docker ps schaut gut aus (Ports korrekt gemappt) und ein Sprung in den Container zeigt ja wie oben beschrieben dass alles korrekt installiert wurde und eigentlich auch läuft.
Nach all den Versuchen hoffe ich nun durch Belästigung der User hier mein Problem zu lösen.

BBTown

es fällt mir schwer zu glauben, dass RAM und Power eines RPi3 ausreichen um sowohl Docker als auch ioBroker im Verbund sauber und stabil zum Laufen zu bekommen ...

Sylvan

@BBTown said in ioBroker in eigenem docker-container auf RPi3:

es fällt mir schwer zu glauben, dass RAM und Power eines RPi3 ausreichen um sowohl Docker als auch ioBroker im Verbund sauber und stabil zum Laufen zu bekommen ...

Schonmal mit Docker beschäftigt?
Docker erzeugt einen völlig vernachlässigbaren Overhead. Die jeweilige Anwendung im Container läuft dann absolut vergleichbar als wäre sie nativ auf dem System.

Ich habe hier z. B. einen Pi 3+ da läuft n nginx + php, dazu ein jdownloader, smokeping und obendrein das relative Schwergewicht guacamole. Alles läuft problemlos und RAM liegt bei ~ 300 MB (also noch ca. 600 frei). CPU bei nahe 0% im Leerlauf. Wenn mal guacamole loslegen soll dann sind es schonmal über 50-80 % aber das ist unabhängig davon ob ich es in einem Container laufe oder direkt auf dem Hostsystem.

Eine Anwendung in Docker unterscheidet sich nicht wirklich im RAM/CPU-Verbrauch von einer direkt installierten. Und Docker selbst frisst auch so gut wie keine Ressourcen. Wenn man ioBroker nativ auf einem Raspberry Pi 3 laufen lassen kann, dann geht das genauso wenn dieses in einem Docker-Container läuft. Der Ressourcenanbedarf unterscheide sich hierbei nicht.

BBTown

@Sylvan sagte in ioBroker in eigenem docker-container auf RPi3:

Schonmal mit Docker beschäftigt?

ja, ich hatte ioBroker eine ganze Weile unter Docker auf meinem QNAP! NAS am laufen;
derzeit betreibe ich dort nach wie vor 3 andere Docker Container.
Mein ioBroker läuft seit einer Weile nunmehr allerdings in einer VM unter Proxmox auf einem Intel NUC

Sylvan

@BBTown said in ioBroker in eigenem docker-container auf RPi3:

ja, ich hatte ioBroker eine ganze Weile unter Docker auf meinem QNAP! NAS am laufen;
derzeit betreibe ich dort nach wie vor 3 andere Docker Container.

Dann verstehe ich die Frage nicht ganz. Dann müsste dir ja bekannt sein, dass Docker keinen signifikanten Einfluss auf Leistung/Ressourcenanforderung hat.

@BBTown said in ioBroker in eigenem docker-container auf RPi3:

Mein ioBroker läuft seit einer Weile nunmehr allerdings in einer VM unter Proxmox auf einem Intel NUC

Der problemlose Umzug auf ein anderes Device wäre eben ein solcher Grund für den Einsatz von Docker. Wenn mein Pi mal abraucht oder ich zum Entschluss komme ich brauch doch mehr Power dann muss ich nicht alles neu aufsetzen, sondern schiebe nur mein Dockerfile und das Config-Volume auf ein anderes Device und kann dort nahtlos weitermachen (wenn das Image das andere System auch unterstützt) und ioBroker läuft dort mit exakt den selben Abhängigkeiten und Einstellungen. Eine VM kann ich hingegen nicht von einem Pi auf einen NUC schieben (Architekturwechsel). Mal davon abgesehen, dass ne VM wirklich signifikanten Overhead mitbringt.

BBTown

@Sylvan
Um ggf. Mißverständnisse auszuräumen.
Ich habe rein gar nichts gegen einen Betrieb unter Docker.
Für mich ist die Verwaltung und Pflege von VMs und/oder LXCs jedoch einfacher.

Meine ioBroker Umgebung benötigt bummelig 2 GB RAM
Mein QNAP! NAS - auf der ich ioBroker unter Docker laufen hatte - hat 8GB RAM.

Daher meine Eingangsantwort, dass ich annehme, dass Du mit ioBroker unter Docker auf einem RPi3 von der Performance und Stabilität her langfristig nicht glücklich sein wirst.

Sylvan

@BBTown said in ioBroker in eigenem docker-container auf RPi3:

Daher meine Eingangsantwort, dass ich annehme, dass Du mit ioBroker unter Docker auf einem RPi3 von der Performance und Stabilität her langfristig nicht glücklich sein wirst.

Im Grunde möchte ich im Moment nur erste Gehversuche mit ioBroker unternehmen (Hab bald eine KNX-Anlage). Eben darum wollte ich "mal schnell" einen Container für basteln, so dass ich iobroker ohne viel Aufwand und Nebeneffekte testen kann. Würde sich dabei später herausstellen, dass ich mehr Performance/Speicher benötige, dann könnte ich auch mit der Lösung schnell woanders hin umziehen. Daher ist im Prinzip docker gesetzt aber der Pi als Hostsystem nicht unbedingt.

So wie ich es gelesen hatte scheint ioBroker im Grundausbau erstmal nicht so extrem zu sein von den Anforderungen. Erst je nach Menge und Art der verwendeten Adapter ändert sich dieses Bild. Ist dem so?
Da ioBroker ja auch direkt vorgefertigte Images für RPi 2 aufwärts anbietet, muss ich ja davon ausgehen, dass die Pis prinzipiell für ioBroker geeignet sind. Ob nun nativ oder in einem Docker-Container macht da ja wie besprochen keinen Unterschied.

Daher hoffe ich nun, dass mir jemand einen entscheidenden Tipp gibt, woran mein Vorhaben im Moment eigentlich scheitert.

BBTown

@Sylvan sagte in ioBroker in eigenem docker-container auf RPi3:

Erst je nach Menge und Art der verwendeten Adapter ändert sich dieses Bild. Ist dem so?

ja, dem ist so

Da ioBroker ja auch direkt vorgefertigte Images für RPi 2 aufwärts anbietet, muss ich ja davon ausgehen, dass die Pis prinzipiell für ioBroker geeignet sind.

absolut

Sylvan

Habe es jetzt zum Laufen bekommen.
War anscheinend ein Problem mit den Rechten innerhalb des Containers.
Hierzu habe ich mich für die relevanten Teile schamlos am buanet-Image bedient.
Genau konnte ich es noch nicht herausschälen aber es funktioniert erst einmal.

Falls jemand mal an der selben Stelle steht wie: ich hier meine Lösung:

Dockerfile:

FROM debian:stretch as iobrokerbase

ENV DEBIAN_FRONTEND noninteractive

# locale erstellen, node installieren, iobroker installieren, wieder aufräumen
RUN apt-get update -y \
    && apt-get install -y curl locales gosu \
    && sed -i 's/^# *\(de_DE.UTF-8\)/\1/' /etc/locale.gen \
    && locale-gen \
    && curl -sL https://deb.nodesource.com/setup_10.x | bash - \
    && apt-get install -y nodejs \
    && mkdir -p /opt/iobroker/ \
    && curl -sL https://iobroker.net/install.sh | bash - \
    && echo $(hostname) > /opt/iobroker/.install_host \
    && echo $(hostname) > /opt/.firstrun \
    && apt-get autoremove -y \
    && apt-get clean -y \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* \
    && chsh -s /bin/bash iobroker

ENV LANG="de_DE.UTF-8" \
    LANGUAGE="de_DE:de" \
    LC_ALL="de_DE.UTF-8" \
    TZ="Europe/Berlin" \
    DEBIAN_FRONTEND="teletype" \
    SETUID=1000   \
    SETGID=1000

# /opt/iobroker wird ein host-volume. Es wird also initial mit dem Inhalt vom Host überschrieben
# Daher muss hier im Image dessen Inhalt in einen temporären Ordner verschoben werden und später beim Erzeugen
# des Containers (dann wurde das Verzeichnis vom Host gemountet) wieder nach /opt/iobroker zurück (passiert in der run.sh).
WORKDIR /opt/iobroker/
ADD scripts/run.sh /opt/run.sh
RUN chmod +x /opt/run.sh \
    && mkdir /tempo \
    && mv /opt/iobroker/* /tempo/

EXPOSE 8081 8082 8083 8084

ENTRYPOINT ["/opt/run.sh"]

mit dazugehöriger run.sh:

#!/bin/sh
# basiert zu großen Teilen auf https://github.com/buanet/docker-iobroker/blob/master/scripts/iobroker_startup.sh

uid=$SETUID 
gid=$SETGID

if [ -f /opt/.firstrun ]
then
	# falls /opt/iobroker = externes volume, dann hier die Daten dorthin verschieben (sonst wird es mit host-Daten beim Container-Erstellen überschrieben)
	mv /tempo/* /opt/iobroker/
	rm -r /tempo
	
	usermod -u $uid iobroker
	groupmod -g $gid iobroker
	chown -R $uid:$gid /opt/iobroker
	chown -R $uid:$gid /opt/scripts
	rm -f /opt/.firstrun
fi

if [ -f /opt/iobroker/.install_host ]
then
	sh /opt/iobroker/iobroker host $(cat /opt/iobroker/.install_host)
	rm -f /opt/iobroker/.install_host
fi

# gosu = sudo-Ersatz vor allem innerhalb von containern
chmod 755 /opt/iobroker/iobroker
sed -i 's/sudo -H -u/gosu/g' /opt/iobroker/iobroker
gosu iobroker node node_modules/iobroker.js-controller/controller.js

# falls iobroker abschmiert dennoch den Container weiterbeatmen:
tail -f /dev/null

und gestartet wird das ganze bei mir mit docker-compose:

version: '3.4'

services:
    iobroker:
        build:
            context: .
            dockerfile: Dockerfile
            network: host
        image: iobroker
        container_name: iobroker
        restart: unless-stopped
        volumes:
# iobroker-Ordner auf dem Host (für einfaches Backup und Umzug)
            - "./config:/opt/iobroker"
# bei host-mode:
        network_mode: "host"
        expose:
            - "8081-8084"
        network_mode: "host"
# bei Bridge-Mode:
#        ports: 
#            - "8081-8084:8081-8084"
# könnte für einige Adapter nötig sein:
        cap_add:
        - NET_ADMIN

@Sylvan
Hallo, erst mal vielen dank für die doku hier.
Ich habe das versucht nach zubauen,
scheitere jedoch an der iobroker Installation im Container. (ps: der läuft sogar siehe unten)
Im Dockerfile habe ich stretch gegen buster geändert.
Kannst du mir weiter helfen?
Meine Umgebung:

pi3 mit aktuellen Rasbian.
Docker mit curl -fsSL https://get.docker.com | sh installiert
docker-compose mit folgenden befehlen installiert
apt install libffi-dev libssl-dev python3-pip
pip3 install docker-compose
#(pip meldet Fehler bei der Ausführung , daher pip3)
docker-compose -v
docker-compose version 1.25.0, build b42d419

der Container läuft. Ich kann mich mit dem Container verbinden und im Container Befehle ausführen.
npm -v 6.13.4
node -v v10.18.0
nodejs -v v10.18.0
wird vom Dockerfile korrekt installiert
curl -sL https://iobroker.net/install.sh | bash - \ <-wirft tausende Fehler

der Installer erkennt das er im Container läuft und gibt am Anfang hinweise (leider nicht dokumentiert) am Ende wird folgendes ausgeworfen

=========================================================
Finalizing installation (4/4)
=========================================================
Unsupported init system, cannot enable autostart!
Fixing directory permissions...
main: Zeile 272: return: 172.17.0.2: Ein numerischer Parameter ist erforderlich.
=========================================================
ioBroker was installed successfully
Open http://:8081 in a browser and start configuring!
=========================================================
You need to re-login before doing anything else on the console!

Der iobroker läuft trotz der vielen Fehlermeldungen

root@fb948b332646:~# iobroker info
Platform       : linux
Architecture   : arm
CPUs           : 4
Speed          : 1200 MHz
Model          : ARMv7 Processor rev 4 (v7l)
RAM            : 926 MB
System uptime  : 03:42:57
Node.js        : v10.18.0
Disk size      : 58.5 GiB
Disk free      : 53.0 GiB
NPM            : v6.13.4

aber

root@fb948b332646:/opt# iobroker logs
2019-12-30 00:11:24.009  - info: host.fb948b332646 iobroker.js-controller version 2.1.1 js-controller starting
2019-12-30 00:11:24.022  - info: host.fb948b332646 Copyright (c) 2014-2019 bluefox, 2014 hobbyquaker
2019-12-30 00:11:24.023  - info: host.fb948b332646 hostname: fb948b332646, node: v10.18.0
2019-12-30 00:11:24.027  - info: host.fb948b332646 ip addresses: 172.17.0.2
2019-12-30 00:11:24.094  - info: host.fb948b332646  Error inMem-objects listening on port 9001
2019-12-30 00:11:24.122  - info: host.fb948b332646  Error inMem-states listening on port 9000
2019-12-30 00:11:24.221  - info: host.fb948b332646 connected to Objects and States
2019-12-30 00:11:24.306  - info: host.fb948b332646 3 instances found
2019-12-30 00:11:24.320  - info: host.fb948b332646 starting 3 instances
2019-12-30 00:11:24.364  - info: host.fb948b332646 instance system.adapter.admin.0 started with pid 1334
2019-12-30 00:11:27.324  - error: admin.0 (1334) admin.0 invalid process id scenario 785 vs. 1334. Stopping
2019-12-30 00:11:27.329  - info: admin.0 (1334) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2019-12-30 00:11:27.867  - error: host.fb948b332646 instance system.adapter.admin.0 terminated by request of the instance itself and will not be restarted, before user restarts it.
2019-12-30 00:11:27.869  - info: host.fb948b332646 Do not restart adapter system.adapter.admin.0 because desired by instance
2019-12-30 00:11:28.345  - info: host.fb948b332646 instance system.adapter.discovery.0 started with pid 1345
2019-12-30 00:11:31.047  - error: discovery.0 (1345) discovery.0 invalid process id scenario 792 vs. 1345. Stopping
2019-12-30 00:11:31.059  - info: discovery.0 (1345) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2019-12-30 00:11:31.603  - error: host.fb948b332646 instance system.adapter.discovery.0 terminated by request of the instance itself and will not be restarted, before user restarts it.
2019-12-30 00:11:31.605  - info: host.fb948b332646 Do not restart adapter system.adapter.discovery.0 because desired by instance
2019-12-30 00:11:32.342  - info: host.fb948b332646 instance system.adapter.info.0 started with pid 1356
2019-12-30 00:11:35.498  - error: info.0 (1356) info.0 invalid process id scenario 799 vs. 1356. Stopping
2019-12-30 00:11:35.517  - info: info.0 (1356) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2019-12-30 00:11:36.065  - error: host.fb948b332646 instance system.adapter.info.0 terminated by request of the instance itself and will not be restarted, before user restarts it.
2019-12-30 00:11:36.066  - info: host.fb948b332646 Do not restart adapter system.adapter.info.0 because desired by instance
2019-12-30 00:14:31.672  - info: info.0 (799) Popup news was read...

und weiter

docker -D run fb948b332646 -d
mv: das Verschieben zwischen Geräten ist fehlgeschlagen: '/tempo/node_modules/ip' zu '/opt/iobroker/node_modules/ip';
das Ziel kann nicht entfernt werden: Das Verzeichnis ist nicht leer

... mit vielen weitern Verzeichnissen.
also das script run.sh schlägt fehl.
Ich sehe auch den Ordner tempo nicht
der Ordner /opt/iobroker auf dem Host bleibt leer
der Port 8081 ist nicht erreichbar

Ich hoffe mir kann jemand weiter helfen.
Gruß Timo

duffbeer2000

@Tibo Quizfrage, warum nimmst nicht das Image von Buanet? Das sollte inzwischen ohne Probleme auf einem Pi laufen

NEWS

ioBroker in eigenem docker-container auf RPi3

Support us

839
Online

31.7k
Users

79.8k
Topics

1.3m
Posts

NEWS

ioBroker in eigenem docker-container auf RPi3

Support us

839Online

31.7kUsers

79.8kTopics

1.3mPosts

839
Online

31.7k
Users

79.8k
Topics

1.3m
Posts