Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[AlCalzone]

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.

[rewenode]

` > 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: always

Define 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: always

Define 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)

[AlCalzone]

@rewenode:

      - ./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).

[rewenode]

******** 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 /mytemp

Erstellt 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ß

[AlCalzone]

@rewenode:

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?

[rewenode]

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ß

[voltage_at]

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

[AlCalzone]

@rewenode:

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.

[rewenode]

@voltage_at:

..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?

.. `

Ich bin mir nicht sicher, welche 'ausgelagerten Verzeichnisse du meinst. Prinzipiell MUSS nichts ausgelagert werden, die Daten wären dann halt futsch wenn du den Container löscht.

Iobroker: siehe die beiden vorherigen Posts. Du kannst /opt/iobroker/iobroker-data auslagern oder /opt/iobroker. Ist Geschmacksache. Mit influxDB hat das erstmal nichts zu tun.

Influxdb: Willst du die nicht als Docker-Container betreiben, musst du da ja gar nichts machen.

Soll influx zukünftig im Container arbeiten, solltest du, vlt. sogar dein altes Influx-data-Verzeichnis, im host mappen. Du hast dann automatisch deine alten Daten im Container ohne über Export/Import zu gehen.

Soll die Influx im Container neu aufgesetzt werden, muss nur das data-Verzeichnis vorhanden sein. Die db wird automatisch generiert.

Ich hoffe, ich hatte deine Frage einigermaßen richtig verstanden.

Yaml

Klar kannst du Umbauen wie du willst.

Hier mal meine Verzeichnisstruktur, die du natürlich beliebig anpassen kannst.

****** Auszug *************************************************

Verzeichnisstruktur

Ich arbeite mit dem /opt/iobroker Verzeichnis im host. Ihr solltet Euch also vorab überlegen wo ihr das hin haben wollt.

Der Benutzer muss NICHT root sein.

Ich benutze ein eigenes Verzeichnis in meinem Homeverzeichnis wo ich die Mapp-Verzeichnisse aller (zusammengehörenden) Container erstelle.

Hat für mich den Vorteil, dass ich nur ein Verzeichnis sichern/packen muss für die Daten aller meiner entsprechenden Container (iobroker/datenbank usw.).

Sieht im Prinzip so aus:

myiobhome/  (hier kommt die docker-compose.yaml rein)
│
│
├── grafana   (hier liegt die grafana_config.env)
│          └── data
│
├── tick
│     ├── influxdb
│     │      │
│     │      ├── backups
│     │      └── data
│     │
│     ├── kapacitor (hier kommt die kapacitor.conf rein)
│     │
│     └── telegraf (hier kommt die telegraf.conf rein)
│
└── iobroker

iobroker ist klar. Komplettes /opt/iobroker

Die Verzeichnisse müssen vorhanden sein. Die angegebenen Konfigurationsdaten müssen in den Verzeichnissen sein.

ACHTUNG!!!

Auf Geräten mit ARM Hardware (Raspi -der sollte dafür auch schon zu wenig Speicher haben, rock64 etc.),

muss vorab das Image neu erstellt werden!

Erstellen der Container dann mit:

cd ~/myiobhome   # oder wo immer die Sachen bei Euch sind
sudo docker-compose up -d

Das wars schon.

[rewenode]

@AlCalzone:

.. Sauberer im Sinne von Docker wäre hier vermutlich wie du auch schreibst ein frischer Container. `

da hast du zu 100% recht

[voltage_at]

okay ich seh schon… mir fehlen grundlegende basics...

ich werd mich mit docker mal auseinandersetzen.. aber ich kann deine tipps mit meinem aktuellen wissestand leider nicht umsetzen.

Ich danke dir trotzdem und werde diesen Post im Hinterkopf behalten.

LG

[rewenode]

> okay ich seh schon… mir fehlen grundlegende basics...

Kein Problem. Melde dich einfach wenn du soweit bist und Fragen hast.

Vom Versuch, ohne hinreichende docker Kenntnisse kann ich auch nur abraten.