Edomi im Docker-Container - revised

[uzi10]

was bringt eig php 7.0?

[starwarsfan]

Hi

Wird das eigentlich von dir auch weiter verfolgt werden, wenn Christian seine Ankündigung wahr macht und das ganze als "offenes" normales PHP-Paket veröffentlicht? Könntest du dir ein Paket für Docker vorstellen mit PHP7?

Ist schon in Arbeit.

[crewo]

starwarsfan danke für deine Arbeit hier! Das wird langsam immer interessanter für mich, bisher läufts auf nem APU, aber warum hier ein weiteres Gerät vorhalten wenn das auch per Docker auf der Synology laufen kann.

Wird das eigentlich von dir auch weiter verfolgt werden, wenn Christian seine Ankündigung wahr macht und das ganze als "offenes" normales PHP-Paket veröffentlicht? Könntest du dir ein Paket für Docker vorstellen mit PHP7?

[jeff25]

Sehr cool Yves, werde ich gleich testen. Frei mich schon total auf die nächste Edomi Version, hoffe sie kommt sehr bald :-)

[starwarsfan]

Hallo miteinander,

die aktuelle Latest-Version des Docker-Images hat einige Verbesserungen erfahren:

Es gibt jetzt direkt drei Mountpoints für die wichtigsten Daten:

• /var/edomi-backups
• /var/lib/mysql
• /usr/local/edomi

Werden diese mit Docker-Volumes verwendet, bleiben sämtliche relevanten Daten in den Volumes und können bei einem neuen Container wiederverwendet werden. Das coolste Feature dabei ist, dass Volumes von Docker automatisch bei der initialen Verwendung befüllt werden, also wenn sie noch leer sind. Dann werden die am jeweiligen Ort im Image befindlichen Daten von Docker in das Volume kopiert. Das wären hier also sämtliche Datenbanken, die Edomi-Installation sowie allfällige Backups.

Dass Backup einspielen entfällt damit vollständig. Solange nicht irgendetwas von ausserhalb der drei Mountpoints gebraucht wird, ist mit einem neuen Container alles wieder so wie vorher. Es ist damit eigentlich auch überflüssig, bei einer neuen Edomi-Version einen neuen Container zu instanziieren, da der Edomi-Content in den Volumens "alt" bleibt. Also einfach ganz normal in Edomi auf Update klicken und gut ist es.

Details dazu in Abschnitt 3 im Readme auf GitHub.

Update 1.62 > 1.63
Der Patch von Christian bzgl. dem Edomi-Update-Problem von 1.62 auf 1.63 ist direkt im Image enthalten und wird durch ein kleines Helper-Script aktiviert.

Siehe dazu Appendix C im Readme auf GitHub.

Zusatzpakete
Ich habe fast alle Packages aus dieser Liste direkt installiert. Das sollte das Setup von Community-LBS stark vereinfachen. Lediglich die gcc-Komponenten sind nicht dabei, das ist für das Image dann doch etwas zu speziell. Hier die Liste der zusätzlich installierten Pakete:

• git
• httpd
• mod_ssl
• mysql
• mysql-server
• nano
• ntp
• openssh-server
• php-devel
• php-gd
• php-mbstring
• php-mysql
• php-pear
• php-process
• php-snmp
• php-soap
• php-xml
• php-xmlrpc
• tar
• unzip
• vsftpd
• wget

Bitte Bescheid sagen, wenn noch etwas Essentielles fehlt und direkt mit in das Image könnte.

Also wer mag, kann gern schon mit starwarsfan/edomi-docker:latest testen. Immer her mit dem Feedback!

[starwarsfan]

Hallo

Noch etwas, falls es jemand interessiert.
Mit dieser NGINX-Config kann man problemlos EDOMI inkl. Visu komplett über port 443 nach aussen frei geben, also auch inkl. Websocket.

Cool, danke für's Teilen!

Idee: Vielleicht könnten wir das künftig im Dockerimage "direkt" unterstützen.... dann wäre manches einfacher .

Sicher eine Idee. Ich tendiere im Moment dahin, via Docker-Compose das ähnlich wie das hier aufzubauen.

[givemeone]

Noch etwas, falls es jemand interessiert.
Mit dieser NGINX-Config kann man problemlos EDOMI inkl. Visu komplett über port 443 nach aussen frei geben, also auch inkl. Websocket.

ACHTUNG: Natürlich muss man dann ggf. noch etwas für die Absicherung tun, zB Zertifikatsautentifizierung, wenn man dem EDOMI-Login nicht
voll vertraut.

upstream edomi_websocket {
  server 172.19.0.2:443;
}
server {
    server_tokens off;
    listen  1.2.3.4:443 http2;
    server_name xx.domain.net;

   ssl on;
    ssl_certificate /etc/letsencrypt/live/xxxx/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cccc/privkey.pem;

    location = / {
            proxy_pass http://edomi_websocket;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
    }
   location /admin {
      proxy_pass http://127.0.0.1/admin/;
    }
    # Edomi Weiterleitung
    location /visu/ {
      proxy_pass http://127.0.0.1/visu/;
    }
    location /shared/ {
      proxy_pass http://127.0.0.1/shared/;
    }
    location /data/ {
      proxy_pass http://127.0.0.1/data/;
    }
    location /remote/ {
      proxy_pass http://127.0.0.1/remote/;
    }
}

In der edomi.ini muss als Port für Websocket 443 angegeben werden.
Damit das im Docker funktioniert, muss die ssl.conf datei vom Apache gelöscht werden, da diese sonst
den Port belegt.
In diesem Fall macht der NGINX davor das SSL, nicht der EDOMI/Docker-Apache.


Kurze Erklärung:
Eigentlich werden hier nur 2 kleine "tricks" angewandt.
1) Die Websocket-Portéinstellung 443 wird benötigt, damit a) der Edomi dort "hört" und b) damit die Visu die Verbindung auch auf Port 443 "anfragt".
Der Rest vom EDOMI-Docker hört an Port 80.
2) location = / in der NGINX.Config prüft genau auf diesen Wert, also ohne irgendeine Datei ... daher "muss" dies eine Websocketverbindung sein.
Somit kann hier direkt auf den Websocket weitergeleitet werden und alles funktioniert!
Nach "Aussen" benötigt nginx daher lediglich den Port 443 --> eine (wie ich finde) elegante Konfiguration, vorallem für Router.


Idee: Vielleicht könnten wir das künftig im Dockerimage "direkt" unterstützen.... dann wäre manches einfacher .

sG Joe

[Marino]

@ Yves Vielen Dank für die Bestätigung und die ausführliche Erläuterung. Das mit Edomi scheint wirklich nicht so einfach zu sein, denn alles freigeben möchte man ja auch nicht. Aber auch wenn es nicht die perfekte Lösung ist, so ist es eine Lösung mit der man Dank Deiner tollen Arbeit auf jeden Fall schon einmal gut arbeiten kann.

Ob eine bestimmte Software nun perfekt für Docker ist oder nicht, ist in meinen Augen teils egal. Wir haben einen kleinen NUC, der einige VM's drauf hat. Der läuft aber schon seit Jahren. Das Problem ist halt bei VM's, dass jeder sich Ressourcen reserviert, die niemand anders nutzen darf. Alleine da sehe ich einen großen Vorteil für Docker, weil einfach mehr Ressourcen zur Verfügung stehen, da nicht jeder reserviert und nicht freigibt, auch wenn nicht benötigt. Wenn Edomi beispielsweise nicht perfekt für Docker ist, so ist es in dem Fall aber doch besser, auch wenn man nicht dockertypisch handelt, sondern es ein wenig so sieht, wie eine Mini-VM

[starwarsfan]

Hallo Mario

Klar geht das, aber dann hat man halt einen undefinierten Zustand (Diff zum ursprünglichen Image on top).

Das ist schon klar, dass das "geht". Nur ging es hier nicht um den technischen Hintergrund sondern um die Probleme, welche sich zwischen den beiden Welten "Docker" und "nicht-Docker" bzw. der eigentlichen Idee hinter Docker ergeben.

Sowas wie "die reine Docker Lehre" halte ich für genauso krude wie Docker selbst. Docker ist eigentlich ne Alpha, die in production eingesetzt wird weils ach so hipp ist.

Sorry aber das ist lachhaft.

Da wird so viel schindluder getrieben in der Dockerwelt, dass es einem nur so graust. Insbesondere, was den Umgang mit Updates und Permissions angeht. Da läuft halt zu gern einfach alles mit rootrechten weils so praktisch ist und jeder denkt das wäre sicher weil ist ja nur im Container - Mitnichten.

Und deswegen ist die Technologie schlecht? Das muss man erstmal verstehen...

Wollte hier eigentlich nicht derart reingrätschen, sorry. Beim Thema Docker kommt mir leider relativ schnell der Mock hoch.

Und? Es ist mit absolut jeder Technologie möglich, sie zu missbrauchen resp. falsch zu verwenden. Dass daraus dann die verschiedensten Probleme resp. Risiken entstehen ist ja nun wirklich nicht aussergewöhnlich und ich möchte fast behaupten, dass das zu Beginn jeder Neuerung resp. mit jeder neuen Technologie passiert ist. Man denke nur an die lustigen Diskussionen, als die Virtualisierung an und für sich spruchreif geworden ist. Und heute? Völlig normal und überhaupt nichts besonderes mehr.

Du hast offenbar noch nicht viel damit zu gehabt, wie Docker im Geschäftsumfeld eingesetzt wird und welche Anforderungen dabei zu erfüllen sind. Bei so Aussagen wie

Dabei wird beim Bauen wild alles aus dem Netz gesaugt.

kann man dann wirklich nur noch abwinken...

So, OT-Ende.

[trollvottel]

Der springende Punkt ist, dass es in der Docker-Welt keine In-App-Updates gibt, also die Applikation sich nicht selbst updated

Klar geht das, aber dann hat man halt einen undefinierten Zustand (Diff zum ursprünglichen Image on top). Probleme entstehen erst, wenn man dann das Image hinterher updaten will. Da verliert man dann eben seinen Diff. Ist an sich nicht schlimm, wenn die Updates dann über das Image reinkommen. Aber wenn halt sonst noch Zeugs mit im Container abgelegt wird, ists futsch.

Im Fall Edomi entspricht das 1:1 dem Vorgehen vom Author: Image installieren, nie wieder das System updaten. Hat irgendwie was von "Ich hab da ne businesskritische Anwendung, aber die läuft nur unter Windows 95 - Einfach Firewall davor und gut!" - Mitnichten. Mit der Hauptgrund, warum ich kein Edomi einsetze. Ich verstehe die Ansicht des Entwicklers "Was interessiert mich das Basissystem", aber dann muss ich halt entsprechend paketieren, was er aber nicht macht.

Sowas wie "die reine Docker Lehre" halte ich für genauso krude wie Docker selbst. Docker ist eigentlich ne Alpha, die in production eingesetzt wird weils ach so hipp ist. Da wird so viel schindluder getrieben in der Dockerwelt, dass es einem nur so graust. Insbesondere, was den Umgang mit Updates und Permissions angeht. Da läuft halt zu gern einfach alles mit rootrechten weils so praktisch ist und jeder denkt das wäre sicher weil ist ja nur im Container - Mitnichten. MEin Favorit: Docker in Docker (DIND). Oder die Behauptung Docker-Images wären jederzeit reproduzierbar - Dabei wird beim Bauen wild alles aus dem Netz gesaugt. 404er gibt's ja heute per Definition nicht mehr.

EDIT: Wollte hier eigentlich nicht derart reingrätschen, sorry. Beim Thema Docker kommt mir leider relativ schnell der Mock hoch.

[starwarsfan]

Hallo Nils

Zuerst einmal: Frohe Weihnachten!

Danke, gleichfalls!

1. Ich habe verstanden, dass das CentOS-Image quasi immer wieder genutzt werden kann. Das würde ich mir auch als Image hinlegen, möglicherweise mit 1-2 Extrapaketen installiert, die ich für einen LBS brauchte. Gibt es einen Grund für genau 6.8? Es sollte ja 6.5 sein. Ich hätte nun gedacht, 6.6 wäre am nächsten dort dran oder das neuste 6er (6.10) wäre auch besser. Wieso ist es genau 6.8? Oder war das bei der Erstellung das neuste und man bleibt dabei, da man 6.9 und 6.10 nicht getestet hat?

Also m.M.n. ist es in dem Fall völlig egal, welche Minor-Version verwendet wird. Wichtig ist, dass es CentOS 6.x ist und als ich das Image erstellt habe, ist eben die aktuell gültige Variante davon eingeflossen. Und solange es keine triftigen Gründe gibt, auf eine höhere Minor-Version zu upgraden, würde ich es auch tunlichst vermeiden, mir damit unnötige weil unbekannte Probleme inzuhandeln.

2. Wenn ich einen Container mit run/build starte, startet er ja quasi eine Instanz des Images mit den getroffenen Einstellungen etc.. Hier wird doch eigentlich nur der Backup-Pfad dem Host-System übergeben. Sehe ich das richtig, dass bei jedem stoppen, bzw. Neustart des Host meine kompletten Daten weg wären, abgesehen vom Backup und ich beim erneuten run/build immer zuerst das letzte Backup zurück spielen muss und LBS installieren (die waren doch nicht im Backup oder?)?

Wie Du ja auch schon selber beantwortet hast, wird nur mit docker run ein neuer Container erstellt. Dieser kann beliebig oft gestoppt und wieder gestartet werden und wird dabei seine Einstellunge behalten.

3. Wenn ich ein Edomi-Update mache, wäre das nach meinem Verständnis auch nur temporär. Es sei denn, man erzeugt ein neuen Container eines Images mit dem Update.

Korrekt.

Wenn ich dann aber den neuen Container öffne und nur das Backup von letzter Nacht habe zum zurück spielen, dann ist es doch wieder die alte Version, da durch das Backup die Daten wieder verändert werden. Daher kann ich ja eigentlich nicht ein 1.56 Update auf 1.62 spielen, da ich anschließend ein 1.56 Edomi habe und wieder ein Update fahren muss.

Ja und nein. Es kommt darauf an, ob Du eventuell Modifikationen vorgenommen hast, welche nicht vom Backup abgedeckt werden.

In Hinblick auf Edomi ist das Ganze etwas zweischneidig. Nach der reinen Docker-Lehre ist es falsch, dass Daten im Container verändert werden. Die Idee von Docker ist ja, dass ein Container immutable ist, dessen Inhalt also unangetastet bleibt. Das ist aber durch die Art und Weise wie Edomi sich ins System einbindet, wie es arbeitet und wie es backup's nicht so ohne weiteres in einem Docker-Image abzubilden. Das wurde hier vor einiger Zeit schonmal angesprochen und ich bin da auch schon längere Zeit am überlegen, wie sich das ggf. besser im Docker-Image abbilden lassen würde.

Der springende Punkt ist, dass es in der Docker-Welt keine In-App-Updates gibt, also die Applikation sich nicht selbst updated. Gibt es eine neue Version der dockerisierten Applikation, wird ein neues Docker-Image gebaut. Genau das ist die aktuelle Vorgehensweise: Sobald es eine neue Edomi-Version gibt, baue ich ein neues Image, welches diese Version enthält.

Aber genau an diesem Punkt wird es schwierig, da das Edomi-Backup eben nicht nur die Applikationsdaten, sondern die gesamte Applikation incl. der Daten sichert und somit beim Restore auch wiederherstellt. Bei einem Docker-Image ist das aber nicht notwendig resp. wird genau dadurch der Container modifiziert. Eine mögliche Lösung ist, das gesamte Edomi-Verzeichnis, also das was auch im Backup steckt, in ein separates Volume zu packen und dieses in den Container zu mounten. Dazu braucht es aber noch etwas mehr "drumrum", da beim initialen Start des Containers dieses Volume natürlich leer ist. Das wiederum heisst, dass Edomi quasi zuerst "installiert" werden muss, was man eigentlich bei Docker-Images genau nicht will...

Alles nicht so einfach...

[Marino]

Danke für den Tipp. Das könnte evtl. wirklich das Problem sein. Und es passiert auch wirklich erst seit 1.62 und vorher noch nicht. Ich werde da mal weiter forschen. Einen zusätzlichen Container zu haben, mit dem man testet oder der ggf. mal schnell übernehmen kann, wenn doch mal etwas ist, strebe ich aber weiterhin an

[vento66]

Das dein APU neu startet hat vielleicht hiermit zu tun? https://knx-user-forum.de/forum/proj...19#post1272419
Ich hab davon mehrere im Einsatz, und keiner startet unkontrolliert neu....

[Marino]

Zuerst einmal: Frohe Weihnachten!


Ich habe mal eine allgemeine Verständnisfrage.

Mein Edomi läuft momentan auf einem APU2C4, der aber immer mal wieder einfach neu startet und ich weiß nicht wieso. Also würde ich diesen gerne tauschen oder wenigstens ein Backup vorhalten, was übernehmen könnte. Daher lese ich mich gerade die letzten Tage in Docker ein und teste damit auch fleißig. Gestern habe ich mir die 20 Seiten hier durchgelesen und dazu aber noch eine Frage.

1. Ich habe verstanden, dass das CentOS-Image quasi immer wieder genutzt werden kann. Das würde ich mir auch als Image hinlegen, möglicherweise mit 1-2 Extrapaketen installiert, die ich für einen LBS brauchte. Gibt es einen Grund für genau 6.8? Es sollte ja 6.5 sein. Ich hätte nun gedacht, 6.6 wäre am nächsten dort dran oder das neuste 6er (6.10) wäre auch besser. Wieso ist es genau 6.8? Oder war das bei der Erstellung das neuste und man bleibt dabei, da man 6.9 und 6.10 nicht getestet hat?

2. Wenn ich einen Container mit run/build starte, startet er ja quasi eine Instanz des Images mit den getroffenen Einstellungen etc.. Hier wird doch eigentlich nur der Backup-Pfad dem Host-System übergeben. Sehe ich das richtig, dass bei jedem stoppen, bzw. Neustart des Host meine kompletten Daten weg wären, abgesehen vom Backup und ich beim erneuten run/build immer zuerst das letzte Backup zurück spielen muss und LBS installieren (die waren doch nicht im Backup oder?)?
Ich beantworte mal selber
Ich habe wohl aus Versehen immer mit dem run-Befehl immer einen neuen Container erstellt und darin gab es natürlich keine neuen Daten, da das Ursprungs-Image ja das gleiche war. Mit dem start-Befehl bleiben die gespeicherten Daten ja erhalten, den habe ich aber wohl nicht angewendet und nur neue Container erstellt. Wäre ja auch ungünstig, wenn nichts gespeichert wird

3. Wenn ich ein Edomi-Update mache, wäre das nach meinem Verständnis auch nur temporär. Es sei denn, man erzeugt ein neuen Container eines Images mit dem Update. Wenn ich dann aber den neuen Container öffne und nur das Backup von letzter Nacht habe zum zurück spielen, dann ist es doch wieder die alte Version, da durch das Backup die Daten wieder verändert werden. Daher kann ich ja eigentlich nicht ein 1.56 Update auf 1.62 spielen, da ich anschließend ein 1.56 Edomi habe und wieder ein Update fahren muss.
Da habe ich echt noch ein Verständnisproblem, denn würde ich eine neue Version nehmen und das alte Backup zurück spielen, müsste ich ja wieder ein Update machen, was nach einem stop wieder weg wäre.
Wenn das Update intern funktioniert (und ich habe noch nicht verstanden, warum es das eigentlich nicht sollte, aber soweit bin ich wohl noch nicht), dann ist da alles okay. Dann müsste ich aber eigentlich möglichst immer erst intern Updaten > Backup machen > neuen Container mit neuer Edomi-Version erstellen > Edomi-Backup zurück spielen, richtig?

Oder habe ich da irgend etwas komplett falsch verstanden?
Falsch verstanden hatte ich auf jeden Fall den run- und start-befehl. Run war für mich irgendwie das starten (auch vom namen her), war ja kein build. Daher habe ich immer neue Container erstellt und gedacht, dass nie Änderungen darin gespeichert werden...


Viele Grüße und ein schönes Fest wünsche ich.
Nils

[givemeone]

Das hätte ich gerne ein wenig genauer beschrieben. Wie genau sieht dein Netz aus und was hat jetzt welche Settings auf dem Docker-System?

"normales" 192er- Netz, Debian als HostOS.
KNXD direkt auf dem HostOS, das sich mit einem noch freien Kanal des KNX-Routers verbindet.
Im Docker auf dem HostOS habe ich für KNX die IP, analog zum Websocket, 172.19.0.1, statt der 192er eingetragen.
Seither keine Fehlermeldung mehr!