[HowTo] ioBroker unter Docker auf Synology DiskStation
-
@steff-h naja Hättest du ein Log?
Das Backup muss nicht gross sein, es enthält nur die Konfiguration
-
also ich habe jetzt eine komplett neue Instanz aufgesetzt.....
die Situation mit dem Backup, dass man 2 Stunden warten muss, hätte ich bei einem 3 MB großen Update nicht gedacht
Gedult hätte ich mitbringen müssen, das hatte ich irgendwie aufgrund des Schocks nicht.....er hat jetzt sehr viel wiederhergestellt, muss jetzt alles Punkt für Punkt kontrollieren, ob wirklich alles wieder da ist
js-controller ist jetzt auf Version 2.2.9, er bietet mir aber wieder das Update zu 3.0.17 an, genau dieses Update ging bei der alten Instanz schief.....Ebenso ist mir vor dem Absturz noch aufgefallen, dass Javaskript in der Version 4.5.1 nicht mehr ausführbar war (Punkt und "Play-Pfeil" immer rot) weshalb ich den js-controller überhaupt updaten wollte.....weiß man da eventuell einen bekannten Fehler?
-
@steff-h Das update ist deswegen so klein weil der controller nach dem einspielen eines Backups einfach alles neu frisch installiert.
Ohne Log zum Thema "Update auf js.controller 3.0" kann man wenig sagen. Da es aber schon ein paar tausend User erfolgreich gemacht haben ... ...
AUch zu js 4.5.1 ist bisher kein Problem bekannt
Zu allem gilt an sich: Was sind denn die Ausgaben? Was steht denn im Log?
-
Hab unter Version 4 des ioBroker-Abbilds auf meiner DS718+ ein Update des js-controllers auf Version 3.0.18 durchgeführt. Dabei wurden auch zahlreiche meiner Adapter aktualisiert. Lief alles problemlos durch. Auch bei der Bedienung des ioBrokers gibt es bisher keine Auffälligkeiten.
-
@apollon77 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
@steff-h Das update ist deswegen so klein weil der controller nach dem einspielen eines Backups einfach alles neu frisch installiert.
Ohne Log zum Thema "Update auf js.controller 3.0" kann man wenig sagen. Da es aber schon ein paar tausend User erfolgreich gemacht haben ... ...
AUch zu js 4.5.1 ist bisher kein Problem bekannt
Zu allem gilt an sich: Was sind denn die Ausgaben? Was steht denn im Log?
Mit dem Log kann ich leider nicht dienen, Instanz leider komplett weg, werde mich aber die Tage nochmal am update versuchen
-
Moin,
nachdem ioBroker nun ja als macvlan auf IP 192.168.1.249 in meinem Netzwerk auf nem Pi-Host läuft, wollte ich nun die andere Anleitung zur Anbindung des E3/DC-Hauskraftwerks ausführen und hab mir mit Docker Compose eine MySQL-DB samt phpMyAdmin (2 voneinander abhängige Container) installiert. Jetzt laufe ich dann wohl auf das Problem, dass ich mit dem Adapter sql.0 Probleme beim Zugriff auf die MySQL-DB bekomme.
Die beiden Container MySQL und phpMyAdmin bekommen automatisch ein eigenes Netzwerk mit IPs drin und verstehen sich dadurch. Der Container iobroker hat neben dem Netzwerk iob_public auch noch die Standard-Bridge, wie angeraten. Vom ioBroker aus komme ich natürlich trotzdem nicht an die DB, zumindest nicht über die IP des Raspi-Hosts (192.168.1.25).
Nun habe ich dem Container mysql-iobroker per Portainer zusätzlich auch noch die Standard-Bridge hinzugefügt:
Nun kann ioBroker tatsächlich die MySQL-DB erreichen:
So weit, so gut. Nun stellen sich die Fragen:
- Um zu verhindern, dass das manuell zum MySQL-Container hinzugefügte Bridge-Netzwerk nach jedem Neustart des MySQL-Containers wieder weg ist, kann ich das Hinzufügen der Bridge vermutlich im docker-compose.yml angeben (gehe ich mal von aus). Kann ich da angeben, dass der Container jedesmal die 172.17.0.3 bekommt? Weil ich die im ioBroker ja fest hinterlegen muss...
- Was passiert (z.B. bei einem Pi-Neustart), wenn ein anderer Container vor dem MySQL-Container startet und die 172.17.0.3 dann evtl. schon belegt ist? Wenn ich Bridge zu nem Container per Portainer hinzufüge, dann scheint die IP-Adresse ja frei vergeben zu werden. Dann könnte ja die Datenbank ne andere IP bekommen und für ioBroker wieder nicht erreichbar sein...
- Oder anders gefragt, wie kann ich irgendwie sicherstellen, dass die 172.17.0.3 immer für den MySQL-Container frei bleibt? Müsste ich dann alle Container, die ich in Zukunft benutze so per Docker oder Docker Compose erstellen/starten, dass ich immer das Netzwerk mit IP-Adresse mitgebe (vorausgesetzt das geht)?
-
Die Probleme mit der Anbindung der direkt als Paket auf der DS eingerichteten MariaDB 10 Datenbank über MACVLAN führten letztlich dazu, dass ich etwas entnerft auf einen Host-Betrieb des ioBroker umgeschwenkt bin. Leider haben sich da irgendwie im MACVLAN- oder Bridge-Betrieb immer die SQL-Datenbank und der Zugriff auf den yahka-Adapter ausgestochen. Seit Umstellung auf den Host-Betrieb läuft wieder alles rund.
-
@dtp: Du hättest eigentlich die beiden Container MYSQL und phpMyADmin in dasselbe Netzwerk hängen müssen, wie dein iobroker container. Also einfach über docker-compose beim start den beiden containern das existierende macvlan (iob_public) zuweisen. Dann sehen und sprechen alle 3 miteinander.
Das bridge Netzwerk ist dazu eigentlich nicht notwendig.
(wenn ich mich richtig an die Anleitung von buanet erinnere, hat er dort dem macvlan bei Erstellung allerdings nur eine einzige IP-Adresse zugewiesen, das müsstest Du erweitern)IP-Adressen (und sogar MAC-Adressen für z.B. Filterregeln in Deinem Router) lassen sich einfach in der docker-compose zuweisen. Hier mal ein Auszug aus meinem eigenen docker-Container, aber Zuweisung zu einem existirenden NEtzwerk funktioniert mit jedem anderen Container auch.
services: iobroker: image: buanet/iobroker:latest container_name: ioBroker hostname: ioBroker-Host *** environment / volumes / etc. Abschnitt *** (den Abschnitt habe ich hier rausgelöscht, um es übersichtlicher zu halten) mac_address: 02:42:13:5B:C5:64 (Beispiel) networks: iob_public: ipv4_address: 192.168.1.130 (Beispiel) #network "iob_public" zeigt auf bereits existierendes externes docker netzwerk networks: iob_public: external: name: iob_publicWenn Du das willst, kannst Du Deinen Containern auch noch das bridge Netzwerk zusätzlich mitgeben. Ich hätte vermutlich nur Angst, dass es da zu Konflikten kommt. Der Abschnitt in docker-compose sähe ungefähr so aus:
services: iobroker: *** diverses *** networks: iob_public: ipv4_address: 192.168.1.130 (Beispiel) bridge: ipv4_address: 172.17.0.3 (Beispiel)GRüße
-
@ts020339 sagte in [[HowTo][Anleitung]
Okay, danke für die Bestätigung dass es so gehen müsste.
(wenn ich mich richtig an die Anleitung von buanet erinnere, hat er dort dem macvlan bei Erstellung allerdings nur eine einzige IP-Adresse zugewiesen, das müsstest Du erweitern)
Variante 1: Exakt das hat eine schnelle Lösung erstmal verhindert, das hatte ich tatsächlich auch schon probiert. Kann ich einfach in Portainer die Netzwerkkonfiguration iob_public_conf und das Netzwerk iob_public löschen, neu erstellen und dann dem ioBroker-Container sagen, er soll das neue Netzwerk nehmen? Oder müsste ich bei jedem Neustart das Netzwerk neu hinzufügen (merkt er sich ja scheinbar nicht wenn nachträglich hinzugefügt)? Momentan merkt er sich iob_public, weil der Container damit erstellt/neu aufgebaut wurde? Oder würde da ein Recreate oder Edit mit neu deployen helfen? Daten dürfte ich damit nicht verlieren, da ich ja das Verzeichnis wie in der Anleitung beschrieben außerhalb des Containers gemappt habe?!
Variante 2: Als Alternative hatte ich es bereits geschafft per Docker Compose tatsächlich für MySQL und phpMyAdmin ein separates (virtuelles) Netzwerk mit festen IPs drin zu bauen. Damit könnte ich dann immer dieselbe IP in ioBroker für die DB-Verbindung angeben. Inzwischen habe ich auch herausgefunden, dass man die DB-Verbindung über den Servicenamen hinbekommt. Dann ist es ja sowieso kein Problem mehr. Immer unter der Voraussetzung, man fügt dem ioBroker-Container das neue Netzwerk hinzu. Was man dann bei jedem Neustart aber wiederholen muss und das Runterfahren des DB-Stacks geht dann auch nicht, da dessen Netzwerk noch von ioBroker verwendet wird.
Variante 3: Du erstellst also auch ioBroker per Docker Compose, wenn ich das richtig gesehen habe, ne? Aber das Netzwerk iob_public erstellst du also nicht per Compose sondern greifst auf es als bestehendes Netzwerk zurück?! Warum nicht auch komplett erstellen? Müsste doch mit den gezeigten Bordmitteln auch gehen, oder?
Wollte Compose erst vermeiden, aber das gleichzeitige reproduzierbare Hoch- und Runterfahren hat schon was, merke ich inzwischen. War mir auch nicht sicher, ob ich die DB für ioBroker brauche (hielt die Anbindung meines E3/DC-Hauskraftwerks erst für ne Spielerei, deswegen DB optional für Spielbetrieb), aber inzwischen werde ich die drei Container wohl immer zusammen brauchen. Würdest du mir vielleicht dein komplettes docker-compose.yml zukommen lassen (geht das per Chat)? Dann würde ich den Schritt wagen und hätte eine vergleichbare Lösung in der Hinterhand als Backup sozusagen... -
@andre said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Zur installation von zusätzlichen Linux Paketen könnt ihr auch eine Umgebungsvariable benutzen. in diesem Fall die Variable "PACKAGES" (Siehe hier). Die manuelle Installatation innerhalb eines Containers ist kein guter Weg, da du diesen Schritt immer wiederholen musst, wenn du einen neuen Container erstellst...
@Holzlenkrad sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Ach so, hier hieß es schon ein paar Mal, dass der Kernel der Diskstation einen Bug in Verbindung mit dem Netmode host hat.
Das ist korrekt, allerdings habe ich im aktuellen Beta (v3.0.2) dazu was getan. Dort sollte der "Host-mode" wieder funktionieren.
sudo setcap 'cap_net_raw,cap_net_admin+eip' $(readlink -f $(which node))Sollte im aktuellen Beta nicht funktionieren, da das Image statt "sudo" den Befehl "gosu" verwendet.
Capabilities wie "NET_ADMIN" oder "NET_RAW" sollten/ müssen bei Bedarf auch in den erweiterten Container-Einstellungen gesetzt werden. Geht allerdings nur im Portainer:
MfG,
AndréGuten Abend,
ich versuche seit einigen Tagen mein RPI Iobroker Installation auf meine Synology, im Docker unter zu bringen.
Bis jetzt habe ich soweit alles zum laufen bekommen, bis auf zwei Dinge hmip, und den radar2 Adapter.Auch mit den Env Variable Packages "vi libcap2-bin arp-scan bluetooth bluez libbluetooth-dev libudev-dev net-tools", dem einschalten der Capabilities, versucht den Befehl in der konsole mit
gosu root setcap 'cap_net_raw,cap_net_admin+eip' $(readlink -f $(which node))oder auch
sudo setcap 'cap_net_raw,cap_net_admin+eip' $(readlink -f $(which node))Kommt dieser Fehler...
Failed to set capabilities on file `/usr/bin/node' (Operation not supported) The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileKomme ich nicht weiter und der Adapter bringt mir ständig diesen Fehler...
radar2.0 2020-04-24 22:07:37.928 error (12366) Error: bind EACCES 0.0.0.0:67 at state.handle.lookup (dgram.js:242:18) at process._tickCallback (internal/process/next_tick.js:63:19) radar2.0 2020-04-24 22:07:37.927 error (12366) uncaught exception: bind EACCES 0.0.0.0:67Habe eine macvlan Konfiguration...
Hat jemand eine Idee oder weiss was dem kleinen Radar2 hier fehlt?
Bin ich mit den setcap auf dem richtigen Weg? Warum will er den die Befehle hier nicht nehmen?Würde mich über Hilfe oder ein Link zur Problemlösung freuen, danke!
-
@ts020339 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Danke für den Ansatz. Ohne die zusätzliche Bridge und mit vordefiniertem macvlan-Netzwerk habe ich die Erstellung des ioBroker-Containers per Compose nun auch hinbekommen. Lediglich die Bridge funktioniert noch nicht.
Wenn Du das willst, kannst Du Deinen Containern auch noch das bridge Netzwerk zusätzlich mitgeben. Ich hätte vermutlich nur Angst, dass es da zu Konflikten kommt. Der Abschnitt in docker-compose sähe ungefähr so aus:
services: iobroker: *** diverses *** networks: iob_public: ipv4_address: 192.168.1.130 (Beispiel) bridge: ipv4_address: 172.17.0.3 (Beispiel)version: "3.8" services: iobroker-test: container_name: iobroker-test image: buanet/iobroker:latest hostname: iobroker restart: always mac_address: 02-42-C0-A8-01-F9 dns: - 127.0.0.1 - 192.168.1.1 networks: iobroker-network: ipv4_address: 192.168.1.225 bridge-network: ipv4_address: 172.17.0.100 volumes: - "/home/pi/docker-data/iobroker-compose-data:/opt/iobroker" environment: - PACKAGES=nano networks: iobroker-network: external: name: iobroker-network #bridge-network: # external: # name: bridgeWie oben aufgeführt, gibt's den Fehler: ERROR: Service "iobroker-test" uses an undefined network "bridge".
Wenn ich versuche bridge-network vergleichbar auf die vorhandene Standard-Bridge zu mappen (auskommentierte Zeilen wieder rein), dann gibt's den Fehler ERROR: for iobroker-test user specified IP address is supported on user defined networks only. Mir scheint das mit dem Vergeben der IP der falsche Ansatz zu sein. Wie kann ich definieren, die Standard-Bridge zusätzlich zu verwenden aber ohne eine IP zu definieren?Danke und Grüße,
Steffen -
@stevie77 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
dann gibt's den Fehler ERROR: for iobroker-test user specified IP address is supported on user defined networks only
Ist mir tatsächlich auch aufgefallen.
Passiert übrigens genauso, wenn man versucht der Bridge direkt über Poirtainer eine IP zuzuweisen.
Ohne feste interne IP kann es beim RPi-Reboot passieren, dass man hinterher die interne influxdb- und mosquitto-IP im IOBroker wieder anpassen muss. (Je nachdem in welcher Reihenfolge die Container durchstarten)
Ein Reboot kommt bei mir nicht oft vor, habe ich daher nicht weiter verfolgt. -
Nutzt nach Möglichkeit ein selbst erstelltes Bridge Netzwerk. Im default Bridge gibt it es einige Besonderheiten.
Außerdem empfehle ich bei der Konfiguration z. B. des SQL adapters nicht auf d die IP, sondern auf den Namen des Containers mit der DB zu setzen (setzt ein selbst erstelltes bridge Netzwerk voraus).MfG,
André -
@stevie77 @FoodFighter
nutzt, wie @andre schreibt, eigene erstellte bridge Netzwerke, nicht das Standard bridge Netzwerk, wenn ihr so Multi-Netzwerk-Container betreiben wollt. (Und wenn das wirklich notwendig ist. Oft ist es sinnvoller den Dienst der auf dem Host-Netzwerk läuft auch in das eigene "docker"/"iobroker" Netzwerk zu schieben, bzw ihm ein eigenes macvlan NEtzwerk zu verpassen. Dann kann man den Dienst ganz normal über das Netzwerk unter eigener IP-Adresse erreichen. )Zur Vollständigkeit: in das Standard-"bridge"-Netzwerk kommt ihr mit folgendem docker-compose Eintrag
services: app: image: ubuntu:latest network_mode: bridgeAber ich weiß aktuell gar nicht, ob das zusammen mit anderen Netzwerken nutzbar ist. Wie oben geschrieben, dann lieber selber vorher ein eigens bridge Netzwerk erstellen. Geht über docker auf der Kommandozeile oder sehr einfach auch in Portainer. Danach kann man seinen Containern die erstellten Netzwerke zuweisen.
Damit die Container-Netzwerk-Einstellungen auch einen Image-Wechsel/Update überstehen (also der Original-Container gelöscht wird und aus einem Image neu erzeugt wird), müsst ihr die Netzwerke bereits bei Container-Erzeugung zuweisen. Entweder über docker-compose (siehe oben) oder ihr beschäftigt euch mit den "Stack"-Funktionalitäten in Portainer. Dort geht das auch:
-
-
So, ich hab mir jetzt wie angeraten ne eigene Default-Bridge gebastelt, wo alle erzeugten Container zusätzlich reinkommen. Mir war zu Beginn der Vorteil von Docker Compose ja nicht so ganz klar und der Aufwand ist initial auch nicht ganz gering (einige Nacht-Sessions jetzt), aber wenn man es mal hat, ist der Aufwand für z.B. eine weitere Testinstanz ja quasi super gering. Externes ioBroker-Verzeichnis kopieren, docker-compose.yml leicht anpassen und man hat eine neue ioBroker-Installation samt DB und DB-Client zum Testen. Sehr geil! Vielen Dank an alle für eure Unterstützung!
Der Vollständigkeit halber:
version: "3.8" services: iobroker: container_name: iobroker image: buanet/iobroker:latest hostname: iobroker restart: always mac_address: 02-42-C0-A8-01-F9 dns: - 127.0.0.1 - 192.168.1.1 networks: iobroker-network: ipv4_address: 192.168.1.224 default-network: volumes: - "/home/pi/docker-data/iobroker-data:/opt/iobroker" environment: - PACKAGES=nano depends_on: - mysql-iobroker mysql-iobroker: container_name: mysql-iobroker image: hypriot/rpi-mysql:latest restart: always networks: default-network: ports: - "3306:3306" volumes: - db-data:/var/lib/mysql environment: - MYSQL_DATABASE=iobroker - MYSQL_USER=x - MYSQL_PASSWORD=y - MYSQL_ROOT_PASSWORD=z phpmyadmin: container_name: phpmyadmin-iobroker image: jackgruber/phpmyadmin restart: always networks: default-network: ports: - "8080:80" volumes: - temp-data:/sessions environment: - PMA_ARBITRARY=1 - PMA_HOST=mysql-iobroker - PMA_PORT=3306 depends_on: - mysql-iobroker volumes: db-data: temp-data: networks: iobroker-network: external: name: iobroker-network default-network: name: default-network driver: bridgeDann kann ich mich jetzt ja endlich wieder konkreten Projekten in ioBroker widmen und das mal besser kennenlernen.
Viele Grüße,
SteffenPS: Wie sichert man eigentlich die SD-Karte eines Raspberry Pi 4 komplett? Einfach kopieren wird zum Wiederherstellen ja wahrscheinlich nichts bringen...
-
@qosi said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
@andre said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Zur installation von zusätzlichen Linux Paketen könnt ihr auch eine Umgebungsvariable benutzen. in diesem Fall die Variable "PACKAGES" (Siehe hier). Die manuelle Installatation innerhalb eines Containers ist kein guter Weg, da du diesen Schritt immer wiederholen musst, wenn du einen neuen Container erstellst...
@Holzlenkrad sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Ach so, hier hieß es schon ein paar Mal, dass der Kernel der Diskstation einen Bug in Verbindung mit dem Netmode host hat.
Das ist korrekt, allerdings habe ich im aktuellen Beta (v3.0.2) dazu was getan. Dort sollte der "Host-mode" wieder funktionieren.
sudo setcap 'cap_net_raw,cap_net_admin+eip' $(readlink -f $(which node))Sollte im aktuellen Beta nicht funktionieren, da das Image statt "sudo" den Befehl "gosu" verwendet.
Capabilities wie "NET_ADMIN" oder "NET_RAW" sollten/ müssen bei Bedarf auch in den erweiterten Container-Einstellungen gesetzt werden. Geht allerdings nur im Portainer:
MfG,
AndréGuten Abend,
ich versuche seit einigen Tagen mein RPI Iobroker Installation auf meine Synology, im Docker unter zu bringen.
Bis jetzt habe ich soweit alles zum laufen bekommen, bis auf zwei Dinge hmip, und den radar2 Adapter.Auch mit den Env Variable Packages "vi libcap2-bin arp-scan bluetooth bluez libbluetooth-dev libudev-dev net-tools", dem einschalten der Capabilities, versucht den Befehl in der konsole mit
gosu root setcap 'cap_net_raw,cap_net_admin+eip' $(readlink -f $(which node))oder auch
sudo setcap 'cap_net_raw,cap_net_admin+eip' $(readlink -f $(which node))Kommt dieser Fehler...
Failed to set capabilities on file `/usr/bin/node' (Operation not supported) The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) fileKomme ich nicht weiter und der Adapter bringt mir ständig diesen Fehler...
radar2.0 2020-04-24 22:07:37.928 error (12366) Error: bind EACCES 0.0.0.0:67 at state.handle.lookup (dgram.js:242:18) at process._tickCallback (internal/process/next_tick.js:63:19) radar2.0 2020-04-24 22:07:37.927 error (12366) uncaught exception: bind EACCES 0.0.0.0:67Habe eine macvlan Konfiguration...
Hat jemand eine Idee oder weiss was dem kleinen Radar2 hier fehlt?
Bin ich mit den setcap auf dem richtigen Weg? Warum will er den die Befehle hier nicht nehmen?Würde mich über Hilfe oder ein Link zur Problemlösung freuen, danke!
Hallo zusammen,
ich habe weitere Pakete der ENV hinzugefügt, die in auf der Suche nach einer Lösung zu dem Thema Radar2 gefunden habe.
build-essential libcairo2-dev libcap2-bin libpango1.0-dev libjpeg-dev librsvg2-dev arp-scan bluetooth bluez libbluetooth-dev libudev-dev net-tools openssh-serverLeider hilft das auch nicht weiter...
Muss ich den iobroker im host bridge laufen lassen und nicht in einer macvlan konfiguration?
Für jegliche Hilfe bin ich dankbar! -
Ich habe jetzt auch einfach mal für jeden Container ein vollumfassendes Compose-File gemacht.
Schaden kann es nicht, ich sehe es als Einstellungs-Backup.
Ich habe bewusst für jeden Container ein eigenes Compose-File erstellt zwecks Modularität.Zur Vollständigkeit auch meine kompletten Docker-(Compose) Files:
Vielleicht hilft es irgendwann mal jemanden weiter, der hier drüber stolpert.
Bevor das aber völlig ins OffTopic läuft soll es das diesbezüglich gewesen sein. -
@stevie77 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Wie sichert man eigentlich die SD-Karte eines Raspberry Pi 4 komplett? Einfach kopieren wird zum Wiederherstellen ja wahrscheinlich nichts bringen...
Da gibt es viele Möglichkeiten.
Im Einfachsten Fall fährst du den Pi herunter und clonst die komplette SD-Karte mit z.B. Win32DiskManagerHier werden weitere Möglichkeiten beschrieben.
Ich persönlich halte es so:
Auf dem RPi selbst läuft nur Docker - sonst nichts.
Die Container bekommen alle ein Volume ins Pi-Home-Verzeichnis gemountet, in dem dann die jeweiligen Einstellungen drin liegen.
Das Home-Verzeichnis sichere ich ab und zu mal auf den NAS.Sollte der Pi die Segel streichen -> Neues Raspbian auf eine SD-Karte spielen, Docker installieren, die Backups der Container zurück ins Home-Verzeichnis ziehen -> die o.g. Docker-Compose-Files nacheinander ausführen -> fertig.
Das umständlichste dabei wäre es dann das Raspbian wieder auf die SSD zu verschieben und den PI nur noch von SD booten zu lassen....Vielleicht kann Raspbian das ja endlich bald mal komplett von SSD - dann wird auch das lachhaft.
-
@FoodFighter sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:
Ich habe jetzt auch einfach mal für jeden Container ein vollumfassendes Compose-File gemacht.
Schaden kann es nicht, ich sehe es als Einstellungs-Backup.
Ich habe bewusst für jeden Container ein eigenes Compose-File erstellt zwecks Modularität.Zur Vollständigkeit auch meine kompletten Docker-(Compose) Files:
Hatte mich davon inspiriert vorhin auch daran versucht das Netzwerk per Docker zu erzeugen (geht ja schneller als mit Portainer). Leider hat dein Beispiel erst bei mir funktioniert, als ich noch die Parent network card mit angegeben habe (vorher war der ioBroker nicht sichtbar, IP 224 nicht anpingbar).
docker network create --driver=macvlan --subnet=192.168.1.0/24 --ip-range=192.168.1.224/28 --gateway=192.168.1.1 -o parent=eth0 iobroker-networkMacht auch Sinn, da dies in Portainer ein Pflichtfeld für MACVLAN ist. Kannst du mir erklären, warum das bei dir ja offensichtlich ohne funktioniert?
