alternatives Docker Image

[SaschaG]

Hi,

Ja, würde vermutlich reichen, aber es stellt sich dann die Frage, warum dann überhaupt ein extra Netzwerk? Da ich mit meinem Beispiel ja gar nicht in die Untiefen der Docker - Möglichkeiten eintauchen wollte, und diese hierfür auch gar nicht brauche, erschien mir das löschen konsequenter.

Gruß
Sascha

[tullsta]

Hallo Sascha,

yep - funktionert jetzt, aber

Der Fehler liegt in meiner Beispiel "docker-compose.yaml". Ist aber zum Glück leicht zu beheben. Lösche bitte folgende Zeilenaus deiner Portainer-Stack-Config:

• Zeile 33-34
• Zeile 15-16
• Zeile 3-6

kann es sein, dass es eigentlich nur die "internal: true"-Zeile (Zeile 5) ist?
=> from docker docu:

--internal

Restrict external access to the network

Danke und liebe Gruesse - tullsta

[SaschaG]

Ok,

Hab das mal nachgestellt. Der Fehler liegt in meiner Beispiel "docker-compose.yaml". Ist aber zum Glück leicht zu beheben. Lösche bitte folgende Zeilenaus deiner Portainer-Stack-Config:

• Zeile 33-34
• Zeile 15-16
• Zeile 3-6

Die Doku werde ich entsprechend anpassen.

Danke fürs testen und viel Erfolg.

Sascha

[tullsta]

Hi,
Kannst du deine Portainer-Stack-Config mal posten? Was sagen die container Logs?

gerne:

Screenshot2.png


Screenshot3.png


Screenshot.png

Danke und liebe gruesse - tullsta

[SaschaG]

Hi,

Kannst du deine Portainer-Stack-Config mal posten? Was sagen die container Logs?

Gruß
Sascha

[tullsta]

Hallo Sascha,

ich hab' heute versucht, shng im docker via portainer stack ans Laufen zu bekommen (shng:full).
Soweit ohne Fehlermeldung, aber ich bekomme keine "published ports"...
Sehe im Moment auch nicht, was ich hier anders mache als in anderen stacks / docker-compose files.

Auch manuell via "docker-compose up" bringt hier keine Verbesserung/Aenderung.

Irgendeine Ahnung, woran das liegen koennte?

Danke und LG - tullsta

[SaschaG]

Update:

• Offizielle Konfig Style wird jetzt unterstützt um solchen Problemen aus dem Weg zu gehen.
• zusätzliche Flavor
  • med: Alle Plugins sollten laufen. Evtl. ist ein Selbstupdate notwendig um notwendige Python libs nach zu installieren. Läuft aber automatisch...
  • visu: wie med aber zusätzlich ist noch smartViSU eingepackt. Wenn potentielle User es schaffen die "docker-compose.yaml" zu kopieren und "docker-compose up -d" abzusetzen läuft alles "out of the box"
• neue Env - Parameter
  • PUID - explizites setzen der smarthome User-ID
  • PGID - explizites setzen der smarthome Group-ID
  • WWW_GID - Setzt die Group-ID für die smartVISU und fügt smarthome dieser Goup ID hinzu
  • ADD_GID - Fügt smarthome dieser Group ID hinzu. Z.B. für Gruop "dialout" um USB Geräte ansprechen zu können.

Ich packe die Info's wieder in Post #1.

Gruß
Sascha

[henfri]

Hallo,

sorry Sascha, ich hatte den Thread nicht aboniert.
Ich habe nix zum Dockerfile hinzugefügt, ohne dass es damals nötig war - vielleicht war es auch ein Plugin.
Aber ich denke, das Risiko können wir eingehen. Lass es doch erstmal weg. Ich kann das Image ja auch einmal testen - da fällt dann etwas auf, oder nicht :-)

Gruß,
Hendrik

[SaschaG]

Hallo nochmal,

Eine Frage aus Beitrag #13 konnte ich für mich beantworten. Werde ich für das "legacy behavior" mit einbauen um Kompatibilitätsprobleme wie in #14 zu vermeiden. Was ist mit den anderen beiden Fragen? Kann mir da einer weiterhelfen?

1. Anpassung der Zeitzone. Notwendig? Hab hier keinen Effekt auf den Container feststellen können. Die Zeit im Container stimmt mit der des Docker-Hosts überein.
2. Anpassung der Sprache auf de-DE UTF8. Notwendig? Hab hier keinen Effekt auf den Container feststellen können.

Danke und Gruß
Sascha

[SaschaG]

Hallo 64er,

Die Container sind aktuell inkompatibel. Im Wesentlichen weil die Volumes ein anderes Format haben. Entsprechend müssten die Inhalte der Volumes und die Einstellungen in der "docker-compose.yaml" auf das von mir genutzte Format angepasst werden (siehe Post #1). Ich arbeite gerade daran, das auch dass Verhalten von Hendriks Container unterstützt wird um solchen Problemen vorzubeugen.

Gruß
Sascha

[64er]

Hallo Sascha,
bei mir läuft es leider garnicht.
Ganz seltsame Effekte:
Einstellungen über das Admin-Interface werden nicht übernommen.
Die Liste der Plugins ist unvollständig bzw. ändert sich beim 2. Aufruf.
Smartvisu erreiche ich nicht ... an der Stelle habe ich aufgegeben.

Ganz so viel falsch machen kann ich auf meinem Server nicht, da Hendrik's Image henfri/smarthome-ng:v1.9.0 ganz gut läuft.
Die Rechte passen alle, Volume's kopiert - gleiche Einstellungen, die ich vom henfri/smarthome-ng:v1.8.2 übernommen habe.

Gruß Mirko

[SaschaG]

Hallo Hendrik,

Danke für den Austausch per PN. Ich denke ich kann und werde hier einen Beitrag zum offiziellen Docker Image leisten. Ein paar Fragen zu deinem Image konnte ich für mich noch nicht klären. Evtl. kannst du oder jemand anderes hier weiterhelfen?

1. Du fügst den User "smarthome" zusätzlichen Gruppen hinzu. Das macht doch aber nur Sinn, wenn der Host zufällig die gleichen GID nutzt oder? Zugegeben, da das Image auf Debian basiert sollte es für alle Debian basierten Hosts passen. Eine bessere Lösung wäre es meines Erachtens UID, GID und extra-GID konfigurierbar zu machen, oder?
   1. "dialout" -> für Zugriff auf USB devices?
   2. "www-data" -> Für Zugriff auf smartvisu? Ich glaube hier ist es einfacher der smartvisu den User "smarthome" und Gruppe "www-data" zuzweisen.
2. Anpassung der Zeitzone. Notwendig? Hab hier keinen Effekt auf den Container feststellen können. Die Zeit im Container stimmt mit der des Docker-Hosts überein.
3. Anpassung der Sprache auf de-DE UTF8. Notwendig? Hab hier keinen Effekt auf den Container feststellen können.

Gruß
Sascha

[SaschaG]

Hallo Hendrik,

finde ich gut, dass es eine Alternative gibt.
Noch besser fänd ich allerdings wenn es nur eins gibt und wir die Vorteile von Deinem im offiziellen Image (smarthomeng-github) einbauen. Henning und ich freuen uns über Hilfe.
Hendrik

Es steht dir frei meine Entwürfe zu nutzen. Siehe Post 1. Würde mich freuen, wenn ich was zum Projekt beitragen kann/konnte.

Zu den Vorteilen:

• deutlich kleiner

Finde ich nicht so wichtig.

Das halte ich für einen Fehler, sorry. Ein gutes Docker Image ist nicht größer als notwendig. Um ehrlich zu sein war das meine Hauptmotivation. Ich fand 1,3Gb einfach zu viel und meine Ergebnisse geben mir da Recht.

• aktuell:
  Bullseye-slim
  Python 3.8.12
  SmarthomeNG v1.9.0

Auf 1.9 habe ich gerade aktualisiert.
Auf Bullseye-slim sollte sich das Image auch leicht umstellen lassen.

Ich springe hierfür vom offiziellen Python-Dockerimage ab. Macht es evtl. leichter "state of the art" zu bleiben?!

• einfacher zu Konfigurieren

Kannst du das konkretisieren?

Der Nutzer muss lediglich /mnt Mounten und alle´relevanten Daten sind dann persistent. Durch das passende setzen der Rechte vor dem Container Start sind auch nachträglich hinzugefügte Files (z.B. Config Files) gleich nutzbar. Das reduziert meines Erachtens deutlich die Einstiegshürde. Als Dockeranfänger hatte ich mit der passenden Rechtevergabe innerhalb und ausserhalb eines Containers am meisten zu kämpfen. Zumal hier auch noch 2 Container auf das gleiche volume "html" zugreifen müssen.

• Docker konformes Verhalten
  Container hängt nicht in endless loop auch wenn smarthomeNG sich verabschiedet hat.
  Docker Logging funktioniert.

Das finde ich gut.

• Vorlagen und Beispiele stehen ausserhalb des Containers zur Verfügung
• Rechte der Dateien werden passend gesetzt

Kannst du das beides konkretisieren?

Ist relativ simpel. Startet man das offizielle Image sind die gemounteten Verzeichnisse leer und smarthome.py bricht mit Fehlern ab. Startet man Meines, werden alle Beispiele und Default Dateien in den gemounteten Verzeichnissen zur Verfügung gestellt. Somit läuft das Image mit der Default-Config "out of the box" und könnte dann auch ausschließlich über das Admin Interface konfiguriert werden. Auch das verringert imho die Einstiegshürde.

Ich möchte mich noch mal ausdrücklich bedanken. Ich nutze Smarthome/SmarthomeNG seit ca. 8 Jahren um relevante Daten meiner Heizung via "eta_pu" zu visualisieren. Dein Image hatte ich ca. 3 Monate am laufen und alles läuft tadellos.

Gruß
Sascha

[henfri]

Hallo Sascha,

finde ich gut, dass es eine Alternative gibt.
Noch besser fänd ich allerdings wenn es nur eins gibt und wir die Vorteile von Deinem im offiziellen Image (smarthomeng-github) einbauen. Henning und ich freuen uns über Hilfe.

Zu den Vorteilen:

• deutlich kleiner

Finde ich nicht so wichtig.

• aktuell:
  Bullseye-slim
  Python 3.8.12
  SmarthomeNG v1.9.0

Auf 1.9 habe ich gerade aktualisiert.
Auf Bullseye-slim sollte sich das Image auch leicht umstellen lassen.

• einfacher zu Konfigurieren

Kannst du das konkretisieren?

• Docker konformes Verhalten
  Container hängt nicht in endless loop auch wenn smarthomeNG sich verabschiedet hat.
  Docker Logging funktioniert.

Das finde ich gut.

• Vorlagen und Beispiele stehen ausserhalb des Containers zur Verfügung
• Rechte der Dateien werden passend gesetzt

Kannst du das beides konkretisieren?

Gruß,
Hendrik

[SaschaG]

Hi,

Habe auf Python 3.8.12 umgestellt, damit openzwave funktioniert. Es sind auch noch ein paar Kleinigkeiten in den Docker Ressourcen eingeflossen. Aktuelle Ressourcen finden sich im Post 1 und auf dem DockerHUB.

Gruß
Sascha