Debian Docker ioBroker
-
Hallo,
super ich freu mich.
Ich nutze x86 Hardware bzw. VMs (zuerzeit oft debian)
Da ich schon eine iobroker installation auf einem Raspi habe würde ich die Konfiguration gerne übernehmen (alte log daten übernehmen wäre nicht wichtig, jedoch wäre es gut zu wissen diese übernehmen zu können
)Ich möchte weiterhin auch meine History Daten in eine Datenbank schreiben, eventuell auch mehr???
Deine Auflistung der Tools kenne ich so gar nicht, sind aber auf den ersten Blick interessant.
Deswegen wäre eine Varinate mit docker-compose eine denke ich gute Wahl.
Eine NAS setze ich ein, jedoch nur um darauf Backups abzulegen.
Weißt du zufällig auch, ob duch einen Reverse Proxy Zertifikate in den einzelnen Containern überflüssig werden (ich denke hier an Let's Encrypt).
Vielen Dank
Viele Grüße
Michael
-
` > Generiert dann im Container im /opt/iobroker Volume die Dateien vom Backup …
Muss man sich halt überlegen, wie mans haben will :), nur als Möglichkeit ... `
Willst du die Daten immer im Container haben? Dann sind sie natürlich hin, wenn du den Container mal löscht. Du kannst alternativ ja direkt auf dein altes /opt/iobroker mappen. Dann bleibt dein Image sauber. So mußt du es immer erneut erstellen, weil du ja sicher nicht immer dein altes Backup drin haben willst wenn du den container neu erstellst.
-
` > Ich nutze x86 Hardware bzw. VMs (zuerzeit oft debian)
Da ich schon eine iobroker installation auf einem Raspi habe würde ich die Konfiguration gerne übernehmen `
Willst du docker-iobroker zukünftig auf der x86 Hardware einsetzen? Dann kannst du z.B. das buanet image direkt nutzen.
Willst du den Raspi nutzen, must du das Image auf dem Raspi neu erstellen, weil das buanet auf docker-hub für amd86 erstellt ist.
Beides ist möglich, eine Schritt für Schritt Anleitung unterscheidet sich aber drastisch.
> Weißt du zufällig auch, ob duch einen Reverse Proxy Zertifikate in den einzelnen Containern überflüssig werden (ich denke hier an Let's Encrypt).Tut mir leid, da kann ich im Moment nichts zu sagen, hab mich noch nicht damit beschäftigt.
-
Hi,
also die Daten sollten außerhalb des Containers liegen, das gleiche dann enstprechend für eventuelle Datenbanken.So das beim starten die aktuellen Daten und Vis entsprechend immer verfügbar sind.
In Zukunft soll der iobroker definitiv nur noch auf x86 Hardware laufen.
Der Raspi soll nur noch die Schnittstellen (zigbee,RPI-RF-MOD,etc) bereitstellen.
-
> also die Daten sollten außerhalb des Containers liegen, das gleiche dann enstprechend für eventuelle Datenbanken.
ok.Meine Bemerkung/Frage diesbezüglich sollte @dwm gehen.
> In Zukunft soll der iobroker definitiv nur noch auf x86 Hardware laufen.Alles klar.
-
vllt noch als Hinweis.
Ich nutze auf meinem Raspi folgendes allinone image:
Homematic All-In-One mit piVCCU
-nodejs 8.11.1
-ioBroker
-redis
-piVCCU 2.31.25 mit IP-Support
Aus diesem Image soll dann nur die iobroker(eventuell redis) Komponente umgezogen werden. Die anderen müssen ja auf dem raspi weiterlaufen.
Bei einem testweisen restore auf einer neuen Hardware musste ich dann auch redis nachinstallieren, damit iobroker wieder startet.
Was redis nun genau macht, ist mir noch nicht so klar.
-
…-ioBroker
...
Aus diesem Image soll dann nur die iobroker(eventuell redis) Komponente umgezogen werden. ... `
Das sollte kein Problem sein. sicher musst du nach dem Umzug innerhalb des Containers:
cd /opt/iobroker sudo reinstall.shmachen, da evtl. die node.js Version abweicht. Außerdem musste bei mir nach Plattformwechsel immer z.B. der serialport node-modul neu kompiliert werden. Aber das ist alles beherrschbar.
-
ok,
ich lass mich überraschen, was dann noch alles auf mich zukommt
-
Ich hab da mal was zusammengeschrieben. Habe aber Hemmungen, das hier einfach einzustellen. Gibt schon genug halb-gare Sachen, die Anfänger häufig eher verwirren. Da muss ich nicht noch Öl ins Feuer..
Falls gewünscht kann ich es dir aber gern als PM zur Verfügung stellen. Habe den Text im Markdown Format, falls du das lesen kannst.
Gruß
-
hi,
ja gerne per PM.
markdown ist kein Problem. Ich schau es mir an und falls ich irgendwo wirklich nicht weiter weiß würde ich mich melden.
Grüße
-
PM ist raus.
-
Hallo Leute,
ich bin neu an der Docker,IOBroker,Homematic,Grafana u.ä front!
Ich habe den Forumeintrag aufmerksam gelesen jedoch fehlt mir scheinbar was.
Die installation mit docker-compose find ich sehr intressant weil hier einige Komponenten angeführt sind welche ich auch gerne nutzen würde.
ZU meiner Umgebung:
Zotac ZBox Nano Quadcore 8GB Ram 120GB SSD mit
Ubuntu 16.04 LTS Server x64
Docker Host
Portainer IO.
Der Dockerhost funktioniert so weit.
nun hab ich aber ein problem mit dem Starten des IO Broker Containers. gezogen hab ich mir das Original iobroker/iobroker:latest
leider geht aus den Posts vor mir nicht hervor wie ich diesen mit ganz normalen Standardvariablen in Betrieb nehmen kann.
Mein Ziel: (wie das von so machen..)
Ich möchte gerne meine RaspberryMatic es was Visualisieren und eine History in der InfluxDB Speichern und mit Grafana Darstellen. (Wetterstation in unserem entfernten Schrebergarten, Heizungsdaten der Wohnung, Stromverbrauch im Garten und in der Wohnung).
In diesem Sinne danke ich für euer Hilfe!
LG
Manuel
-
Ein kurzer Hinweis, da ich mich auch gerade damit beschäftige.
Wenn man /opt/iobroker/iobroker-data in Docker als Volume anlegt, können die States/Objekte auch bei Umzug oder Austausch des Containers erhalten werden.
Die eigentliche Adapter-Software fehlt dann, wird aber von ioBroker automatisch in der richtigen Version installiert.
-
` > nun hab ich aber ein problem mit dem Starten des IO Broker Containers. gezogen hab ich mir das Original iobroker/iobroker:latest
leider geht aus den Posts vor mir nicht hervor wie ich diesen mit ganz normalen Standardvariablen in Betrieb nehmen kann. `
Für ioBroker/influxdb/grafana sollte die yaml etwa so aussehen:
! ````
version: '2'
! services:
! # Define a Telegraf service
telegraf:
image: telegraf:latest
depends_on:
- influxdb
volumes:
- ./tick/telegraf:/etc/telegraf #place for telegraf.conf
- /var/run/docker.sock:/var/run/docker.sock #only if you use docker plugin
links:
- influxdb
container_name: telegraf
restart: alwaysDefine an InfluxDB service
influxdb:
image: influxdb:latest
volumes:
- ./tick/influxdb/data:/var/lib/influxdb #databases
- ./tick/influxdb/backups:/backups
ports:
- "8086:8086" #http
hostname: influxdb
container_name: influxdb
restart: alwaysDefine a Chronograf service
chronograf:
image: chronograf:latest
depends_on:
- influxdb
environment:
INFLUXDB_URL: http://influxdb:8086
KAPACITOR_URL: http://kapacitor:9092
ports:
- "8888:8888"
links:
- influxdb
#- kapacitor
container_name: chronograf
restart: always! # grafana
see http://docs.grafana.org/installation/docker/
arm image see https://github.com/fg2it/grafana-on-raspberry/wiki
grafana:
user: root
image: grafana/grafana
#image: fg2it/grafana-armhf:v5.1.4
depends_on:
- influxdb
env_file:
- ./grafana/grafana_config.env
ports:
- "3000:3000"
volumes:
- ./grafana/data:/var/lib/grafana
links:
- influxdb
hostname: grafana
container_name: grafana
restart: always#iobroker
iobroker:
privileged: true
stdin_open: true
tty: true
depends_on:
- influxdb
ports:
- "1880:1880" #node-red
- "1883:1883" #mqtt
- "2001:2001" #homematic
- "8081:8081" #iobroker admin
- "8282:8282" #flot
- "8088:8088" #terminal
- "8284:8284" #socketIO
- "6666:6666/udp" #tuya Adapter
- "8887:8887/udp" #tuya proxy
- "8887:8887/tcp"
- "8889:8889/udp" #tuya proxy-web
- "8889:8889/tcp"
volumes:
- /dev:/dev
- ./iobroker:/opt/iobroker
- ./iob_scripte:/scripte
##ggf. host backupordner mounten (sB. ssd)
#- ~/myiobbackups:/opt/iobroker/backups
hostname: iobroker
container_name: iobroker
restart: always
image: buanet/iobroker! ````
telegraf/chlonograf kannst du natürlich weglassen, wenn du sie nicht brauchst.
Die Ports (besonders iobroker) musst du ggf. anpassen.
telegraf: die telegraf.conf muss auf dem host vorhanden sein und das Verzeichnis entsprechend den Container gemappt werden.
Bei mit: ./tick/telegraf
InfluxDB: Das Database Verzeichnis sollte im Host (vorhanden) sein und natürlich ebenfalls gemountet werden.
Bei mir: ./tick/influxdb/data und ./tick/influxdb/backups
Grafana: die Datei grafana_config.env muss auf dem host vorhanden sein und das Verzeichnis entsprechend den Container gemappt werden.
Bei mir: ./grafana/grafana_config.env
Das daten Verzeichnis sollte im Host (vorhanden) sein und natürlich ebenfalls gemountet werden.
Bei mir: ./grafana/data
iobroker:
Mapping: /dev:/dev - nur wenn du USB Sticks (Zigbee) im Container brauchst
Ein host iobroker-Verzeichnis bei mir: ./iobroker (sollte hier schon beschrieben sein)
./iob_scripte empfiehlt sich für dem js2fs-Adapter (wenn du den benutzt)
-
- ./iobroker:/opt/iobroker ```` `Kurze Rückfrage: Welchen Zweck erfüllt das Mapping des gesamten Installationsverzeichnisses? So wie ich das verstanden habe, ist es in Docker sogar ausdrücklich so gedacht, dass bei einem Update des Containers die Anwendungssoftware (/opt/iobroker/node_modules) nicht erhalten bleibt, sondern nur die Daten (/opt/iobroker/iobroker-data).
-
******** Auszug, hoffentlichg nicht zu lang ********************
Was heißt iobroker im Docker-Container ?
Ohne hier allzu weit auszuholen, muss doch einiges gesagt werden.
Container ähneln in gewisser Weise VMs - aber sehr weit her ist es nicht mit der Ähnlichkeit.
Container sind eher so eine Verpackung von Programmen, die alles beinhaltet, was das Programm so zum Arbeiten braucht.
Außer dem eigentlichen Kernel, der wird vom host-System- mitgenutzt.
Der Container läuft in einer geschützten Umgebung und hat normalerweise keine Berührung/Kommunikation mit dem Host,
auf dem er läuft. Mal stark vereinfacht gesagt.
Sie sind dafür gemacht, Programme/Dienste mal eben zu starten, zu nutzen und dann in den Müll zu werfen.
Es lassen sich damit mal eben mehrere ioBroker Instanzen erschaffen die auf dem gleichen Host laufen aber
unterschiedlich konfiguriert sein können.
Da Programme i.d.R. Daten produzieren, die man beim Beenden nicht unbedingt im Müll wissen will,
werden Container so designt, dass Programm und Daten(Konfigurationsdaten/Datenbanken etc.) vom eigentlichen Programm getrennt werden.
Konfigurationsdaten werden häufig in Umgebungsvariablen gesteckt und Bewegungsdaten (Datenbanken etc.) werden möglichst an zentraler Stelle verwaltet.
Docker bietet die Möglichkeit Verzeichnisse des host in den Container zu mounten.
Bringt man die Bewegungsdaten nun in diesem Bereich unter, bleiben diese nach Löschen des Containers erhalten
da sie sich ja in einem host-Verzeichnis befinden.
Man kann also munter fleißig Container wegwerfen.
Da sind wir beim ioBroker. Der ist ja nicht unbedingt für den Einsatz unter docker designt.
Hier finden sich nahezu alle Daten im Verzeichnis /opt/iobroker, was ja auch Sinn macht,
denn im Grunde gehört ja jeder Adapter zu den Bewegungsdaten, die man nicht unbedingt verlieren will.
Was also tun? Alle Daten im Container?
Ist nicht gut allein wegen der Datensicherung. Und Container sind auch keine 'richtigen' Container mehr, wenn man sie nicht löschen darf.
Alle Daten außerhalb des Container? Das bedeutet, das komplette /opt/ioBroker an irgend einer Stelle im host-Dateisystem unterzubringen
in den Container als /opt/iobrker zu mounten.
Der Container ist dann zwar nur noch eine leere Hülle, mit seinem Linux-Unterbau (base-image) mit ggf. installierten Tools
wie der node.js Version u.s.w, dafür haben wir aber alle relevaten 'Arbeitsdaten' an zentraler Stelle auf dem host.
Wenn ein iobroker-container mit einem solchen Mount erstellt wird, muss das Verzeichnis im host vorhanden sein,
da ja iobroker überhaupt erstmal da sein muss um gestartet werden zu können.
Wie kommt man nun an so ein iobroker-Verzeichnis im host? Das ist einfach.
Wollt ihr ohnehin die Daten einer bestehenden Installation weiterverwenden, also nur in einen docker-container umziehen,
könnt ihr einfach das originale /opt/iobroker irgendwo hinkopieren oder es auch direkt verwenden.
Das alte oder neue Verzeichnis wird dann als /opt/iobroker in den Container gemappt.
Wollt ihr lieber mit einer ganz frischen Installation starten ist das auch ganz einfach.
Das iobroker-Image (die Basis für den Container) bringt ja eine nagelneue iobroker Installation mit,
auch wenn diese nach dem Mount nicht mehr erreichbar ist.
Wir können uns also kleinen Hilfscontainer basteln, dessen Aufgabe nur darin besteht, das frische /opt/iobroker
in den host zu kopieren und sich nach getaner Arbeit selber löscht.
docker run --rm -it -v ~/myiobhome:/mytemp \ --name tempiob \ buanet/iobroker \ cp -r /opt/iobroker /mytempErstellt einen Container (tempiob) aus dem image buanet/iobroker und mappt das host-verzeichnis ~/myiobhome als /mytemp in den Container. Mit cp -r /opt/iobroker /mytemp wird beim Container-start das Container-interne Verzeichnis /opt/iobroker in das gemappte /mytemp kopiert, landet also direkt im host-verzeichnis ~/myiobhome.
Sollte sich das Image buanet/iobroker noch nicht auf eurem Rechner befinden, wird es automatisch von https://hub.docker.com/r/buanet/iobroker/ geladen.
Das war's.
Gruß
-
Hier finden sich nahezu alle Daten im Verzeichnis /opt/iobroker, was ja auch Sinn macht,
denn im Grunde gehört ja jeder Adapter zu den Bewegungsdaten, die man nicht unbedingt verlieren will. `
Und genau das möchte ich anzweifeln. Wenn man /opt/iobroker als Volume anlegt, wird alles (auch node_modules, in dem sich die Pakete befinden) extern gespeichert. Wenn man nun ein Update einspielt (was möglicherweise im Container andere Versionen der Pakete enthält), werden diese Änderungen aber beim Laden des (noch alten) Volumes überschrieben - sprich man hat wieder die alten Versionen drauf.
ioBroker hat die Funktion, dass fehlende Adapter-Module beim Start automatisch nachinstalliert werden. Wenn man nur /opt/iobroker/iobroker-data als Volumen hat, wird extern gespeichert, welche Adapter installiert sein sollten, sowie alle deren States/Objekte. Tauscht man nun den Container aus, erkennt die enthaltene iobroker-Instanz, dass die Adapter fehlen und installiert sie nach - in der aktuellen Version mit aktuellen Paketen. Alle States und Objekte der Instanzen bleiben erhalten.
Oder übersehe ich hier was grundlegendes?
-
Im Prinzip hast du recht. Allerdings befindet sich in /opt/iobroker z.B. auch logs. Und was die node-module anbetrifft, ist es mir auch lieber, ich hab die aktuellen Versionen im host und packe mein Verzeichnis lieber zyklisch.
Aber da man die Verzeichnisse auch separat mounten kann, spricht überhaupt nichts dagegen, das so zu machen, wie man möchte.
> Tauscht man nun den Container aus, erkennt die enthaltene iobroker-Instanz, dass die Adapter fehlen und installiert sie nach - in der aktuellen Version mit aktuellen Paketen. Alle States und Objekte der Instanzen bleiben erhalten.Na ja, bisher hab ich die Datensicherung meist eingespielt, DAMIT ich den alten Zustand wiederherstellen konnte, weil nach irgend einer Adapteraktualisierung nichts mehr ging;-)
Ich halte es eigentlich immer so, dass ich mir (zumindest vor größeren Änderungen) immer eine Kopie des kompletten host-iobroker-verzeichnis kopiere. Dann kann ich auf Knopfdruck einen 2.ten Container erstellen oder den alten ersetzen um temporär die Verzeichniskopie zu mounten. Meist mach ich einen neuen Container in dem ich in aller Ruhe basteln kann. Ist ja mit docker so einfach.
Gruß
-
vorest mal vielen lieben dank für die erklärung.
ist das "auslagern" des verzeichnisses auch notwenig wenn die Gesammelten daten in eine Andere InfluxDB Docker instanz geschrieben werden?
oder geht es hier um die IOBroker konfiguration welche in diesem Pfad gespeichert wird?
Und leider hab ich das mit dem yml script noch nicht ganz verstanden. kann ich das auf meine umgebung umbauen/reinkopieren und starten und der legt mir alle Dockercontainer mit den Richtigen Ports und verbindungen an wie ich es braucht?
LG & Danke!
Manuel
-
Ich halte es eigentlich immer so, dass ich mir (zumindest vor größeren Änderungen) immer eine Kopie des kompletten host-iobroker-verzeichnis kopiere. Dann kann ich auf Knopfdruck einen 2.ten Container erstellen oder den alten ersetzen um temporär die Verzeichniskopie zu mounten. `
Ok das macht Sinn. Sauberer im Sinne von Docker wäre hier vermutlich wie du auch schreibst ein frischer Container.
