Edomi im Docker-Container - RockyLinux (x86_64 & aarch64)

[starwarsfan]

Hallo miteinander,

die Version 2.03.5 des Edomi-Dockerimages basierend auf RockyLinux ist verfügbar (vorherige CentOS 6/7 Versionen bleiben bestehen, siehe entsprechender Thread). Dockerfiles incl. Dokumentation befinden sich auf GitHub und hier kann das Image bezogen werden. Folgende Anmerkungen dazu:

• Das Image
  • basiert auf RockyLinux
  • ist ein Multi-Arch-Image für x86_64 sowie ARMv8 (aarch64)
  • Image-Pull auf beiden Architekturen gleich:
    

    docker pull starwarsfan/edomi-docker:2.03.5

• Es gibt aktuell die Version 2.03.5
• Das Basis-System wurde in das Image starwarsfan/edomi-baseimage ausgelagert, welches wiederum auf starwarsfan/edomi-baseimage-builder basiert. Damit müssen nicht bei jedem Build die RockyLinux-Pakete heruntergeladen und installiert werden
• Edomi selbst befindet sich im Image starwarsfan/edomi-docker
• Es sind Mountpoints für die Verzeichnisse /var/edomi-backups, /var/lib/mysql sowie /usr/local/edomi vorhanden, so dass insbesondere die Backups auf einem Verzeichnis auf dem Host vorgehalten werden können
• Integrierter Reverse-Proxy. Damit braucht es kein Mapping für den Websocket-Port mehr!
• Es wird bei jedem Start des Containers das Löschen der mysql.sock verhindert
• Die Fehlermeldung bzgl. /dev/vcsa sollte nicht mehr auftreten.
• Es sind zwingend die folgenden Optionen bei docker run ... zu verwenden:
  • -p <host-port>:88
    Es ist zwingend notwendig, die verwendeten Ports mit jeweils einem solchen Statement in den Container zu mappen. Das betrifft insbesondere den http-Port sowie die drei Ports für die KNX-Kommunikation. Werden weitere Ports verwendet, bspw. für UDP-Traffic aus eigenen Logiken heraus, müssen diese ebenfalls nach obigem Schema gemappt werden.
  • -e HTTPPORT=<host-port>
    Mit dieser Option muss der verwendete Zugriffsport angegeben werden, sofern es nicht Port 80 (http) ist. Das ist notwendig, damit der integrierte ReverseProxy korrekt arbeitet.
  • --restart=on-failure
    Diese Option wird benötigt, damit der Container via Edomi-Admin-UI gestoppt oder neu gestartet werden kann.
• Der Container kann via Edomi-Update-Mechanismus auch direkt aktualisiert werden, wenn eine neue Edomi-Version vorliegt.
• PHP 7.4 mit den folgenden Paketen:
  • php
  • php-curl
  • php-gd
  • php-json
  • php-mbstring
  • php-mysqlnd
  • php-process
  • php-snmp
  • php-soap
  • php-xml
  • php-zip
• Es ist eine ganze Reihe zusätzlicher Pakete für Userland-LBS'e bereits vorab installiert. Namentlich für die folgenden Bausteine:
  • Telegram-LBS (19000303 / 19000304)
  • Mailer-LBS (19000587)
  • Philips HUE Bridge (19000195)
  • MQTT Publish Server (19001051)
  • AlexaControl LBS (19000809)
  • MikroTik-LBS (19001059)
• Für den Image-Build steht in beiden Git-Repos das Helper-Script buildImage.sh zur Verfügung. Details siehe "buildImage.sh -h".
• URL zur Edomi-Update-Site von der nicht mehr gültigen IP auf

  edomi.de

  geändert.

Achtung 1: Insbesondere bei der Verwendung des Edomi-eigenen Update-Mechanismus ist eine gewisse Vorsicht geboten! Wird ein neuer Container angelegt (docker run ...), so wird dieser die Edomi-Version enthalten, welche das ursprüngliche Docker-Image enthält. Mitunter passen da aber die vorhandenen Backup-Daten nicht dazu, wenn es bereits eine neuere Edomi-Version gab und der Container via Edomi selbst auf die neueste Version aktualisiert wurde. Es sollte als dafür gesorgt werden, dass es ein Backup der alten Edomi-Version gibt, welches nach einem erneuten docker run ... importiert und danach auf die neueste Edomi-Version aktualisiert wird.

Die empfohlene Vorgehensweise für ein Update des Basis-Images ist diese hier:

1. Backup machen
2. Edomi auf aktuelle Version updaten
3. Erneutes Backup machen
4. Neues Image pullen
5. Edomi stoppen
6. Neuen Container basierend auf neuem Image incl. der vorhandenen Volumes einrichten
7. Neuen Container starten
8. Backup einspielen

Achtung 2: Der Websocket-Port darf über das Admin-UI nicht geändert werden!
Achtung 3: Zugriff momentan nur via http:// möglich. Für die Erweiterung auf https:// können sich nginx-Spezialisten gern bei mir melden!
Achtung 4: Wird ein Backup wiederhergestellt, ist ggf. wieder die nicht mehr funktionieren IP der Update-Site vorhanden. Diese dann bitte via Edomi-Basiskonfiguration auf "edomi.de" ändern. Im nächsten Backup wird das dann korrekt sein.

Feedback ist wie immer gern gesehen, also immer her damit!

[philipp900]

Hallo Yves,

Danke für deine Arbeit.
Ich verwende dein centos Image bereits seit 2 Jahren ohne Probleme.

Wäre es möglich, dass du auch eine Version des neuen Images ohne nginx anbietest oder den abschaltbar machst?
Ich habe sowieso bereits einen nginx im Netz mit letsencrypt am laufen und möchte eine weiteren Proxy dazwischen eigentlich vermeiden.

Schönes Wochenende,
Philipp

[givemeone]

Auf das hab ich mich sehr gefreut, bin gespannt auf einen Test.
Habe erst kürzlich an einem völlig gekapselten Docker ohne jegliche Portfreigabe nach extern gearbeitet, was bis auf den websocket erfolgreich geklappt hat.

Mit deinem neuen Image sollte dann der websocket auch problemlos funktionieren!

Herzlichen Dank!

[starwarsfan]

Hallo Philipp

Wäre es möglich, dass du auch eine Version des neuen Images ohne nginx anbietest oder den abschaltbar machst?

Das ist vermutlich gar nicht nötig. Ich habe am Edomi-Setup nichts verändert. Das heisst, dass der Edomi-Indianer unverändert an Port 80 lauscht. Aus diesem Grund muss beim neuen Container der eingehende Port auch auf Port 88 gemappt werden, weil nginx auf diesem Port lauscht und dann alles weitere im Container an die Edomi-Ports weiterreicht. Von daher kannst Du einfach mal probieren, das Portmapping wie bisher zu machen, dann geht's am integrierten Nginx vorbei.

[rovivo]

Beitrag in Edomi im Docker-Container - revised

[Vielfrass]

Hallo Yves,

Vielen Dank schon mal für deine Geduld!
Jetzt also in diesem Thread weiter.
Ich habe jetzt das Image gepullt und es taucht auch in der Liste in Portainer auf.
Ganz naiv würde ich den Container jetzt so starten wie die "alte" Version, aber entsprechend das Image in der Commandline anpassen, also so:

sudo docker run \
    --name edomi-rocky \
    --restart=on-failure \
    -p 80:88 \
    -p 50000:50000/udp \
    -p 50001:50001/udp \
    -p 22222:22 \
    -d \
    starwarsfan/edomi-docker:edomi-docker:2.03.3

Die Einträge zu KNX hatte ich beim letzten Mal bewusst weggelassen, da dort ja eigentlich die IP des Containers stehen soll
Mein Problem war ja aber, dass ich genau diese IP vor dem Starten des Containers nicht kenne, weil er eine beliebige IP-Adresse aus dem Pool bekommt.
Deswegen hatte ich die Felder leer gelassen, dann abgewartet, welche IP der Container bekommt und habe dann über das Webinterface in Edomi über die Basiskonfiguration die Adressen nachgetragen.
Das hat dann auch so weit funktioniert, dass die KNX-Schnittstelle lief und ich wieder ein quasi-produktives System habe.
Das einzige, was mich an der Sache jetzt noch stört, ist die -zumindest für mich - beliebig vergebene IP-Adresse. Hier würde ich gerne eine selbst definierte Adresse vergeben.

Zurück zum eigentlichen Thema: Die Commandline zum Starten des Containers gibt mir folgendes Statement zurück:

docker: invalid reference format.

Irgendwo habe ich also wohl noch ein Brett vorm Kopf.

[starwarsfan]

Hi

Ganz naiv würde ich den Container jetzt so starten wie die "alte" Version, aber entsprechend das Image in der Commandline anpassen, also so:

sudo docker run \
--name edomi-rocky \
--restart=on-failure \
-p 80:88 \
-p 50000:50000/udp \
-p 50001:50001/udp \
-p 22222:22 \
-d \
starwarsfan/edomi-docker:edomi-docker:2.03.3

Das passt solange, wie Du auch tatsächlich via Port 80 auf den Container zugreifen willst. Sobald Du dort etwas anderes als 80 mappst, muss die Option HTTPPORT angegeben werden!

Die Einträge zu KNX hatte ich beim letzten Mal bewusst weggelassen, da dort ja eigentlich die IP des Containers stehen soll
Mein Problem war ja aber, dass ich genau diese IP vor dem Starten des Containers nicht kenne, weil er eine beliebige IP-Adresse aus dem Pool bekommt.

Ich gehe davon aus, dass Du MacVLAN nicht mehr verwendest, korrekt? Denn die IP des Containers spielt keine Rolle, da auf die IP des Hosts zugegriffen wird. Da brauchst Du nach dem Containerstart überhaupt nichts anpassen. Einfach den Container starten und im Browser die IP des Hosts eingeben. Da Du ja den Standard-HTTP-Port mappst, braucht es auch keine spezielle Port-Angabe.

Das einzige, was mich an der Sache jetzt noch stört, ist die -zumindest für mich - beliebig vergebene IP-Adresse. Hier würde ich gerne eine selbst definierte Adresse vergeben.

Wie gesagt, das ist ein Denkfehler. Es braucht keine separate IP für den Container.

Die Commandline zum Starten des Containers gibt mir folgendes Statement zurück:

docker: invalid reference format.

Hm, das sieht nach falschen Aufrufparametern aus. Wie gesagt, es ist immer eine schlechte Idee, nur einen Teil eines tatsächlich verwendeten Befehls zu zeigen, weil man der Annahme ist, dass "der andere Teil" nicht relevant ist. Meine Glaskugel ist nach wie vor bei der Wartung, von daher...

[Vielfrass]

Hallo Yves,

Zu allererst Mal eine kurze Bitte um Entschuldigung. Ich bin das Thema, wie gesagt, sehr sehr blauäugig angegangen und hatte praktisch absolut keinen Plan von der ganzen Geschichte. Habe mir deswegen gestern noch diverse FAQs und Videos zum Thema Docker angeschaut und bin jetzt, so denke ich zumindest, deutlich schlauer.

MacVLAN habe ich jetzt ausgeschaltet, Edomi rufe ich über die Host-Adresse des Docker-Rechners und den Port 80 auf.
KNX-Verbindung läuft und die Volumes habe ich auch entsprechend eingebunden.
Backup habe ich eingespielt und ist scheinbar problemlos durchgelaufen.
Kurzum - momentan habe ich das Gefühl, als hätte alles einwandfrei funktioniert.

Container habe ich jetzt, wie folgt aufgerufen:

sudo docker run \
    --name edomi \
    --restart=on-failure \
    -p 80:88 \
    -p 50000:50000/udp \
    -p 50001:50001/udp \
    -p 22222:22 \
    -e KNXACTIVE=true \
    -e KNXGATEWAYIP=192.168.2.5 \
    -e KNXGATEWAYPORT=3671 \
    -e HOSTIP=192.168.2.125 \
    -v edomi-backups:/var/edomi-backups \
    -v edomi-db:/var/lib/mysql \
    -v edomi-installation:/usr/local/edomi \
    -d \
    starwarsfan/edomi-docker:2.03.3

Ein paar Fragen hätte ich aber noch - Falls die hier nicht reingehören, dann bitte kurz Bescheid sagen:

1. Dein Image beruht ja auf Version 2.03 - mein letztes Backup stammt aber noch aus 2.02 (warum auch immer). Siehst du hier irgendwelche Probleme? Backup ist, wie schon gesagt, ganz normal durchgelaufen. Die Version im Webinterface wurde auch entsprechend auf 2.02 "zurück gesetzt".
2. Was ich noch nicht zu 100% verstanden habe ist das Thema rund um die zusätzlichen Volumes. Unter welchem Pfad liegt denn vom Hostrechner aus gesehen nun meine Edomi-Installation? Beim Kopieren der Backups habe ich das Verzeichnis noch irgendwie in meinem FTP-Client gefunden, aber jetzt habe ich keinen blassen Dunst mehr, wo es sich befindet.
3. In der Readme in Kapitel 3.2 steht noch etwas zu zusätzlich benötigten Daten. Dort habe ich für diverse Kalender auch ein paar Dateien, die ich noch einbinden muss. Wenn meine zweite Frage geklärt ist, würde ich das gerne noch tun.
   Frage hierzu - muss ich den Container wieder komplett wie oben angegeben aufrufen, oder kann ich nur die "zusätzlichen" Aufrufe starten, während der Container noch läuft (oder gestoppt ist)?
   quasi so:
   

   sudo docker run --name edomi -v /"Vergessene_Dateien":/PFAD...

Vielen Dank nochmal für den ganzen Input bis hierher.
Werde mir jetzt noch ein paar Beginner-Videos für Docker anschauen

Grüße,
Johannes

[starwarsfan]

Hallo Johannes

Zu allererst Mal eine kurze Bitte um Entschuldigung. Ich bin das Thema, wie gesagt, sehr sehr blauäugig angegangen und hatte praktisch absolut keinen Plan von der ganzen Geschichte. Habe mir deswegen gestern noch diverse FAQs und Videos zum Thema Docker angeschaut und bin jetzt, so denke ich zumindest, deutlich schlauer.

Kein Ding, jeder hat mal angefangen.

MacVLAN habe ich jetzt ausgeschaltet, Edomi rufe ich über die Host-Adresse des Docker-Rechners und den Port 80 auf.
KNX-Verbindung läuft und die Volumes habe ich auch entsprechend eingebunden.
Backup habe ich eingespielt und ist scheinbar problemlos durchgelaufen.
Kurzum - momentan habe ich das Gefühl, als hätte alles einwandfrei funktioniert.

Na das ist doch schonmal sehr gut!

sudo docker run \
--name edomi \
--restart=on-failure \
-p 80:88 \
-p 50000:50000/udp \
-p 50001:50001/udp \
-p 22222:22 \
-e KNXACTIVE=true \
-e KNXGATEWAYIP=192.168.2.5 \
-e KNXGATEWAYPORT=3671 \
-e HOSTIP=192.168.2.125 \
-v edomi-backups:/var/edomi-backups \
-v edomi-db:/var/lib/mysql \
-v edomi-installation:/usr/local/edomi \
-d \
starwarsfan/edomi-docker:2.03.3

Tip top, das passt so.

1. Dein Image beruht ja auf Version 2.03 - mein letztes Backup stammt aber noch aus 2.02 (warum auch immer). Siehst du hier irgendwelche Probleme? Backup ist, wie schon gesagt, ganz normal durchgelaufen. Die Version im Webinterface wurde auch entsprechend auf 2.02 "zurück gesetzt".

Die beiden Versionen, also Backup und Container sollten überein stimmen. Du hast in dem Fall Glück gehabt, dass es funktioniert. Der empfohlene Weg ist der, dass das Quellsystem auf die gleiche Version des Zielsystems aktualisiert werden muss, bevor ein Backup davon verwendet wird.

2. Was ich noch nicht zu 100% verstanden habe ist das Thema rund um die zusätzlichen Volumes. Unter welchem Pfad liegt denn vom Hostrechner aus gesehen nun meine Edomi-Installation?

Das kann ich Dir auch nicht sagen, das hängt vom verwendeten Host-OS ab. Via "docker inspect ..." lässt sich das schon rausfinden aber daran sollte man nur wirklich dann händisch herumschrauben, wenn man genau weiss, was man tut. Die effektive Location spielt aber eben genau gar keine Rolle, das ist ja die Idee davon. Docker-Container werden mit jedem Start jungfräulich neu angelegt. Damit wird das gesamte bisherige Vorgehen beim Update einer Software über den Haufen geworfen, da nicht mehr das laufende System mit der neuen Version aktualisiert sondern einfach ein neuer Container mit der aktuellen Version gestartet wird. Damit nun aber die Daten nicht verloren gehen, welche persistent vorhanden sein müssen, gibt es Docker-Volumes. Diese bleiben bestehen und können in der neuen Instanz des Container weiterverwendet werden. Da sich Edomi an einigen Punkten recht eigenwillig verhält, gibt es diese drei Volumes, welche quasi die gesamte Edomi-Instanz enthalten. Du kannst den laufenden Container stoppen, löschen, mit dem gleichen Befehl wie vorher eine neue Instanz starten und wirst wieder das gleiche Edomi-Setup wie vorher haben.

Beim Kopieren der Backups habe ich das Verzeichnis noch irgendwie in meinem FTP-Client gefunden, aber jetzt habe ich keinen blassen Dunst mehr, wo es sich befindet.

Wie gesagt, das spielt keine Rolle. Die übliche Vorgehensweise ist, die Dateien via ssh resp. scp auf die Maschine zu kopieren. Das geht entweder direkt in die laufende Edomi-Instanz (Du hast ja den ssh-Port bereits gemappt) oder Du startest einen separaten ssh-Container, mountest dort die entsprechenden Edomi-Volumes und kopierst die gewünschten Daten via ssh auf die Volumes. Ich hab' das im Timberwolf-Forum vor einiger Zeit für Portainer dokumentiert, siehe hier.

3. In der Readme in Kapitel 3.2 steht noch etwas zu zusätzlich benötigten Daten. Dort habe ich für diverse Kalender auch ein paar Dateien, die ich noch einbinden muss. Wenn meine zweite Frage geklärt ist, würde ich das gerne noch tun.
Frage hierzu - muss ich den Container wieder komplett wie oben angegeben aufrufen, oder kann ich nur die "zusätzlichen" Aufrufe starten, während der Container noch läuft (oder gestoppt ist)?
quasi so:

sudo docker run --name edomi -v /"Vergessene_Dateien":/PFAD...

Wenn Du an den Mappings, Env-Vars etc. pp. etwas ändern möchtest, dann musst Du eine neue Container-Instanz starten. Details siehe oben. Aber wie bereits geschrieben, einfach via ssh/scp auf die laufende Instanz kopieren. Unter Windows wäre WinSCP eine gute Wahl dafür.

[Vielfrass]

Hallo Yves,

Vielen Dank nochmal für die Erklärungen!

Das ganze Docker-Konzept muss sich bei mir erst noch setzen. Die Idee, dass man mit dem Aufruf des Containers immer eine "clean slate" hat und ein zu 100% definiertes System hat, auf dem man aufbauen kann, ist schon ziemlich genial. Auf der anderen Seite ist es aber total ungewohnt, wenn man sein ganzes Leben vorher quasi nur Installer gewohnt war. Da braucht es eine Weile, bis man sich in die ganze Denke eingearbeitet hat.

Der Groschen mit den Port-Mappings und den Volumes ist jetzt auch so weit gefallen, dass sich die ganze Thematik rund um die Dateifreigaben und -pfade geklärt hat... Die einzelnen Clients sind jetzt in WinSCP eingerichtet und je nach dem, was gebraucht wird, der jeweilige Port vom Host oder von Container im Preset abgespeichert. So langsam finde ich Gefallen an der ganzen Sache - Denke, da werden demnächst noch ein paar Container dazu kommen. Dachte da an ein Open Source Zigbee Broker/Gateway und vielleicht ein PiHole. Da ist dann auf einmal jede Menge Potenzial für frei werdende Hardware in Form von RPis

Als, hoffentlich, abschließende Frage:

Wenn ich einen Container ein mal per run-Befehl gestartet habe und er dementsprechend in Portainer auftaucht, merkt er sich alle Variablen und Port-Mappings, die ich beim Start mitgegeben habe? Wenn mir die Maschine also mal wegen Stromausfall oder so ausfallen sollte und ich Portainer neu starte, dann reicht, sofern das nicht schon automatisch passiert, ein einfacher Klick auf den "Play-Button" und alles ist wieder in Butter?
Oder muss ich mir den ursprünglichen run-Befehl lieber irgendwo sichern, falls ich ihn zukünftig nochmal brauche. Man kennt die Thematik ja - momentan ist das noch alles präsent, aber wie das ganze in ein paar Monaten aussieht, ist dann doch wieder ein anderes Thema

[starwarsfan]

Hi

Die Idee, dass man mit dem Aufruf des Containers immer eine "clean slate" hat und ein zu 100% definiertes System hat, auf dem man aufbauen kann, ist schon ziemlich genial.

So ist es. Allerdings ist genau das bei Edomi etwas "speziell", wenn man Volumes verwendet da genau dann sowohl die eigentliche Applikation als auch deren Daten auf diesen Volumes liegen und somit Edomi beim Start eines neuen Containers nicht wirklich "neu" ist. Normalerweise liegen nur die Daten auf Volumes, nicht aber die Applikation. Nichtsdestotrotz muss der Container neu instanziiert werden, wenn sich dessen Aufrufparameter ändern. Wenn Du also bspw. auf einem anderen/zusätzlichen Port auf den Container zugreifen möchtest, brauchts eine neue Instanz.

Auf der anderen Seite ist es aber total ungewohnt, wenn man sein ganzes Leben vorher quasi nur Installer gewohnt war. Da braucht es eine Weile, bis man sich in die ganze Denke eingearbeitet hat.

Wäre ja auch langweilig sonst...

Wenn ich einen Container ein mal per run-Befehl gestartet habe und er dementsprechend in Portainer auftaucht, merkt er sich alle Variablen und Port-Mappings, die ich beim Start mitgegeben habe?

So ist es. Du kannst einen Container beliebig stoppen/starten, die Parameter vom "docker run ..." bleiben erhalten. Ob natürlich die Applikation im Container das auch immer so ohne weiteres kann, steht auf einem anderen Blatt. Normalerweise ist es aber der Fall und auch Edomi sollte sich sowohl via Admin-UI als auch via "docker stop" herunterfahren lassen.

Wenn mir die Maschine also mal wegen Stromausfall oder so ausfallen sollte und ich Portainer neu starte, dann reicht, sofern das nicht schon automatisch passiert, ein einfacher Klick auf den "Play-Button" und alles ist wieder in Butter?

So sollte es sein, ja.

Oder muss ich mir den ursprünglichen run-Befehl lieber irgendwo sichern, falls ich ihn zukünftig nochmal brauche.

Selbstverständlich sollte man das tun! Frei nach Murphy wird es genau im ungünstigsten Zeitpunkt irgendwo knallen und Du bist froh, wenn Du dergleichen dokumentiert hast...

[beauty]

Hallo starwarsfan bräuchte mal deine Unterstüzung...
Ich habe mir nun auf meine Syno einen Container eingerichtet mit

sudo docker run \
    --name edomi \
    --restart=on-failure \
    -p 81:88 \
    -p 50000:50000/udp \
    -p 50001:50001/udp \
    -p 22222:22 \
    -e HOSTIP=192.168.0.3 \
    -e HTTPPORT=81 \
    -d \
    starwarsfan/edomi-docker:2.03.3

Wenn ich jetzt mit

http://192.168.0.3:81/admin/?login=admin&pass=admin

die Admin Seite aufrufen will kommt immer

 The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Auch mit anderen Ports kommt die selbe Meldung. In der Konsole sieht man das Edomi normal startet und eben zeigt das kein Live-Projekt aktiviert ist.
Bei deinem "alten" Docker-Image mit CentOS funktioniert alles auch mit Port 81.

[vento66]

Ich hab keine Ahnung von Docker und bin auch nicht Yves, aber Du mapst den Port 81 auf 88 und legst ganz unten den Port 81 als http port fest? Kann das so sein?

[beauty]

vento66 in Yves Anleitung steht

-e HTTPPORT=80
If a different http source port than 80 is mapped, this variable must be set with the used port!

Dann geh ich mal davon aus das es richtig so ist?

[vento66]

Nee ich würd sagen Du musst dann auch 81:81 mappen, aber wie gesagt ich schau mir das mal aus der Ferne an, vielleicht brauch ich das ja auch mal irgendwann.