Edomi im Docker-Container - revised

[starwarsfan]

Hi

1) Gibt es bestimmte Gründe, warum ihr nicht docker-compose verwendet? Ich finde das fast übersichtlicher und es kümmert
sich auch automatisch um den Autostart.

Naja, das kann man so oder so sehen. Der Container wird aktuell mit einem Einzeiler gestartet. Machst Du das mit Compose, musst Du ggf. erst das yaml-File anpassen und dann wiederum mit einem Einzeiler den Container starten. Zudem musst Du auch erst noch Compose installieren...

2) Wäre es nicht sinnvoll/hilfreich, zumindest für "Heimautomatisierer und nicht ITler" das komplette EDOMI-Verzeichnis (wie aus dem Backup) auf den
Host zu mounten?

Nein, nicht wirklich. Edomi ist so eng mit dem System verwoben, wenn man das komplett herauslösen will, dann braucht man auch keinen Container mehr. Ausserdem müsste ja erstmal aus dem Container heraus das gemountete Verzeichnis mit einem Ur-Edomi bestückt werden etc. pp. Nein, dafür ist das aktuelle Handling viel zu einfach, um an dieser Stelle derart tiefgreifende Umbauten zu machen.

Somit wären bei jedem
Rebuild noch alle Daten vorhanden und man muss kein backup einspielen.

Rebuild? Warum das? Modifzierst Du das Image händisch und baust selber? Spricht natürlich nichts dagegen, nur würde mich der Usecase interessieren...

[starwarsfan]

Hi Thomas

Guten Abend noch mal,

offenbar werden auch die services nicht sauber beendet, daher gleich noch eine weitere Ergänzung, jetzt gleich als patch File:

Super, ist schon eingebaut und der Build auf DockerHub läuft gerade. Vielen Dank!

[Samoht]

Guten Abend,

ich habe mir dieses Docker-compose mal angeschaut (kannte ich bis dahin gar nicht, ich bin erst seit ein paar Tagen mit docker unterwegs). Meiner Meinung nach ist das sehr hostabhängig und damit nicht allgemein verwendbar. Welche Ports oder welche Verzeichnisse in den container gemappt werden, hängt ja von Deinem System ab.
Das komplette edomi Verzeichnis allein wird dir im Zweifelsfall nicht viel nützen, da hier auch eine Datenbank im Spiel ist, deren Daten sicherlich nicht im edomi Verzeichnis liegen... also entweder aus dem Backup neu installieren oder mit "docker save... " den aktuellen Zustand des Containers in ein Image gießen und daraus im Restore-Fall wieder den gesicherten Zustand wiederherstellen.

Gruß,
Thomas

[givemeone]

Hallo Thomas,

danke, funktioniert!!!

Ich habe noch 2 Fragen zum Verständnis:
1) Gibt es bestimmte Gründe, warum ihr nicht docker-compose verwendet? Ich finde das fast übersichtlicher und es kümmert
sich auch automatisch um den Autostart.
2) Wäre es nicht sinnvoll/hilfreich, zumindest für "Heimautomatisierer und nicht ITler" das komplette EDOMI-Verzeichnis (wie aus dem Backup) auf den
Host zu mounten? Somit wären bei jedem
Rebuild noch alle Daten vorhanden und man muss kein backup einspielen. Mit dem Patch oben von Thomas sind danach sogar noch die
MySQL-Datenbanken in ordentlichem Zustand
Ich denke das würde die ersten Gehversuche mit Edomi massiv vereinfachen!

[Samoht]

Guten Abend noch mal,

offenbar werden auch die services nicht sauber beendet, daher gleich noch eine weitere Ergänzung, jetzt gleich als patch File:

--- start.sh    2018-10-30 21:51:13.000000000 +0100
+++ start.sh.modified    2018-10-30 21:35:57.000000000 +0100
@@ -50,14 +50,44 @@
 service httpd start
 service ntpd start
 service sshd start
+
 /usr/local/edomi/main/start.sh &
 
+edomiPID=$!
+
 # Edomi start script is ended either by call of 'reboot' or 'shutdown'.
 # These two files are replaced by helper scripts and their output is
 # evaluated during the next steps.
-#
+
+stop_services()
+{
+    service sshd stop
+    service ntpd stop
+    service httpd stop
+    service vsftpd stop
+    service mysqld stop
+}
+
+
+docker_exit()
+{
+    echo "SIGINT or SIGTERM"
+    php /usr/local/edomi/main/control.php quit
+    echo "wait for edomi shutdown..."
+    wait $edomiPID
+    stop_services
+    
+    echo "shutdown now..."
+    
+    trap - SIGINT SIGTERM
+    exit 0
+}
+
+
+trap docker_exit SIGINT SIGTERM
+
 # But at first wait until Edomi background script is exited.
-wait
+wait $edomiPID
 
 # Handle if Edomi restore process is running, which will be sent to background
 # by Edomi main script. So at this point the Edomi start script is finished but
@@ -80,8 +110,12 @@
     rm -f /tmp/do*
     # Trigger container restart by simulating an internal error
     # Container must be startet with opeion "--restart=on-failure"
+
+    stop_services
+
     echo "Exiting container with return value 1 to trigger Docker restart"
     exit 1
+
 elif [ -e /tmp/doShutdown ] ; then
     # Edomi called 'shutdown'
     rm -f /tmp/do*
@@ -89,5 +123,8 @@
 
 # Exit container with 0, so Docker will not restart it
 # Container must be startet with opeion "--restart=on-failure"
+
+stop_services
+
 echo "Exiting container with return value 0 to prevent Docker restarting it"
 exit 0

Gruß, Thomas

[Samoht]

Guten Abend,

wenn der Docker container mit "docker stop edomi" beendet wird, reagiert das image leider nicht wirklich darauf mit der Folge, dass die MySQL Datenbank nicht richtig geschlossen wird.
Ich habe daher die /root/start.sh etwas modifiziert um einen sauberen shutdown zu ermöglichen. Der Code wird zwischen dem Aufruf der start.sh und dem wait eingefügt, wobei beide Zeilen etwas modifiziert werden:

/usr/local/edomi/main/start.sh &

edomiPID=$!

# Edomi start script is ended either by call of 'reboot' or 'shutdown'.
# These two files are replaced by helper scripts and their output is
# evaluated during the next steps.

docker_exit()
{
    echo "SIGINT or SIGTERM"
    php /usr/local/edomi/main/control.php shutdown

    echo "wait for edomi shutdown..."
    wait $edomiPID

    echo "shutdown now..."
    trap - SIGINT SIGTERM
    exit 0
}

trap docker_exit SIGINT SIGTERM

# But at first wait until Edomi background script is exited.
wait $edomiPID
# wait
# ab hier dann wieder original

Vielleicht kann das mit in das Image aufgenommen werden?

Gruß,
Thomas

[trant]

Danke, es läuft bei mir, hab mir trotzdem ein eigenes Image gebaut, das die ini Datei manipuliert.
Ja, das mitn aktivieren ist mir eigentlich egal, wenn ich mal neu starte, dann aktivier ich halt.
Ich bin ja im Moment nur mal am testen, ob Edomi was für mich ist. Es ist sehr mächtig und die Ruleengune und die LBS gefallen. Leider bin ich nix der GUI-Designer, und die GUI Bastelei schreckt mich noch.
Aktuell bin ich auf openHAB mit hunderten Items und ebensovielen Rules, da wird eine Migration auch spannend.

[MKHR]

Ich hab das ganze (plus noch irgend etwas anderes das ich vergessen habe) bereits bei mir lokal liegen. Mangels besserer Idee habe ich eine weitere Umgebungsvariable für den Websocket-Port eingeführt. Man muss dann leider den Port zwei mal im Docker Kommando deklarieren (ein mal fürs expose, ein mal in der Umgebungsvariable).
Ich schicke dir hoffentlich noch am WE nen Merge / Pull Request.

Wie Yves beschrieben hat muss der Websocket Port in der ini mit dem, der exposed wird übereinstimmen.
Also trant, Lösung auf die Schnelle: Vorher überlegen welchen Port du als Websocket Port nimmst. Im Docker Kommando diesen Port 1:1 exposen, also bspw 7080:7080. Nach dem Start von Edomi in der "Basiskonfiguration" das Setting für den Websocket entsprechend anpassen. Danach sollte die Visu laufen.
Das mit dem "nach jedem Neustart das Projekt erneut aktivieren" ist aber auch nicht ganz normal, da fällt mir aber spontan auch nix zu ein.

[starwarsfan]

Hallo miteinander,

die Idee ist eigentlich, dass die beim Docker-Run übergebenen Parameter in die Edomi-Konfig eingetragen werden und des im Nachgang keine Anpassungen mehr an der Basis-Konfig braucht. In der aktuellen Implementierung ist jedoch noch gar nicht vorgesehen, dass die Ports im Container anders sein können. Sprich, bisher hat es ausgereicht, die Ports von aussen auf 80 bzw. 8080 zu mappen.

Wie auch immer, ich werde das gern implementieren. Da ich im Moment allerdings ziemlich unter Wasser bin, warte ich noch auf den Feature-Request, dass die User-LBS in einem Subfolder untergebracht werden können, um dann mehrere Sachen auf einen Rutsch zu erledigen.

[trant]

Das schon aber wenn ich in der Basiskonfig von 8080 auf 48080 ändere, und im run ein 48080:48080 mache, funktiert es trotzdem nicht. Dachte Das es liegt daran, dass das Port 48080 im Image ja nicht exposed wird. Das hab ich nun erweiter und nun läufts.

Edit: hab die Doku nochmal bemüht, sollte ohne mein EXPOSE auch laufen, muss ich nochmal checken. Nichtsdestotrotz müsste ich so zuerst immer manuell die Edomi Basiskonfig anpassen. Jetzt baue ich halt aufs starwarsfan Image auf.

[s01iD]

Die Funktion ist genau dafür gedacht von Außen auf einen anders gemapten Port zuzugreifen.

[trant]

Es ist ja dadurch trotzdem kein "Exposed Port", gehts trotzdem?
Hab mir das Image nun schon neu gebaut

[s01iD]

Du kannst den Port in Deiner Edomi-Basis-Konfiguration anpassen. "Websocket: TCP-Port".

[trant]

Nächstes Problem, habe nun versucht eine Visu zu erstellen. Beim Aufruf dieser, komme ich zwar über den Login drüber, aber es wird mit nichts angezeigt.
Grund dafür ist, dass Edomi ja standardmässig den WS Port 8080 konfiguriert hat und ich diesen, wie oben ersichtlich auf 48080 auf meinem Host mappe. 8080 kann ich nicht verwenden, da ich da schon was anderes drauf habe.
Ist der WS Port über eine Variable im Docker setzbar?

Edit: muss wir dann das Image wohl selbst bauen

[trant]

Aktiviert hab ich es.
Glaub auch dass das rm nicht korrekt ist, aber mit nur stop start gehts auch nicht.

Obwohl ich alle meine anderen verwendeten Container auch beim stoppen entferne, jedefalls die die ich noch nicht auf docker-compose umgestellt habe.

Edit: Kommando zurück, läuft (auch mit meinem remove). Ich muss nur nach jedem Neustart das Projekt erneut aktivieren.