UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Frage] TeslaLogger im Portainer?

Informationen über Docker, Verwaltung mit portainer und VMs
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#21

Beitrag von StefanW »

Hallo zusammen,

wir hatten das Update schon geprüft. Leider haben wir in der neuen Portainer Version eine wichtige Funktion nicht gefunden (Sperrliste für lokale Dateien, damit man darüber nicht auf den geschützten Systembereich zugreifen kann). Wir hatten den Eindruck, diese wichtige Funktion ist in die womöglich kostenpflichtige Profi-Version gewandert. Wir müssen da wohl noch tiefer forschen.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

thtrp
Reactions:
Beiträge: 26
Registriert: Fr Nov 26, 2021 8:53 pm
Hat sich bedankt: 9 Mal
Danksagung erhalten: 21 Mal

#22

Beitrag von thtrp »

Chris M. hat geschrieben: So Jan 09, 2022 11:04 am Auch der CometVisu-Container verletzt (leicht) die Docker-Philosophie, da dort der knxd-Prozess und der Webserver-Prozess gleichzeitig laufen (müssen). Getrennt wäre da schon deutlich sauberer.
Auch wenn ich mir bzgl. der Docker-Philosophie nicht zu 100% sicher bin, sehe ich den knxd als Kandidaten für einen eigenen unabhängigen Container. Diverse Systeme setzen ihn voraus, wobei es bei dieser Abhängigkeit mWn keine weitere Spezialisierungen gibt (sei da, nimm Telegramme per IP an und schicke sie auf den Bus). Ob es hier also sinnvoll wäre für die CV, die Homebridge und alle anderen jeweils eigene Instanzen zu spawnen - auch wenn es wahrscheinlich mehr Docker-like ist - bin ich mir nicht sicher.

Bei komplexeren Abhängigkeiten - gerade was z. B. unterschiedliche Versionen der eingesetzten Komponenten oder spezielleren Konfigurationen, die sich anders überschneiden würden, angeht - steigt die Relevanz.
Viele Grüße
Thorsten
________________________________________
Wiregate / TWS 2600 ID:596 + 2 PBM, VPN: bei Bedarf, Reboot nach Rücksprache
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#23

Beitrag von starwarsfan »

Hallo miteinander
thtrp hat geschrieben: So Jan 09, 2022 11:27 am Auch wenn ich mir bzgl. der Docker-Philosophie nicht zu 100% sicher bin, sehe ich den knxd als Kandidaten für einen eigenen unabhängigen Container.
Das würde mich jetzt etwas genauer interessieren. Wieso sollte man auf dem TW einen Container mit dem knxd laufen lassen? Genau das macht der TW doch perfekt selber!? An der Anzahl der Tunnel kann's wohl auch nicht liegen. Oder was übersehe ich gerade?
thtrp hat geschrieben: So Jan 09, 2022 11:27 am Diverse Systeme setzen ihn voraus
Welche denn? Beispiele?
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -
Benutzeravatar

Chris M.
Reactions:
Beiträge: 1190
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 234 Mal
Danksagung erhalten: 853 Mal
Kontaktdaten:

#24

Beitrag von Chris M. »

Solange niemand den knxd-Socket bereit stellt muss es die CV für sich selber machen. Daher ist der CV-Container so gebaut, dass da ein eigener knxd mit drinnen ist und somit der Container nach außen eine KNX Tunnel-Verbindung aufbaut.
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache

thtrp
Reactions:
Beiträge: 26
Registriert: Fr Nov 26, 2021 8:53 pm
Hat sich bedankt: 9 Mal
Danksagung erhalten: 21 Mal

#25

Beitrag von thtrp »

starwarsfan hat geschrieben: So Jan 09, 2022 11:47 am Welche denn? Beispiele?
Auch wenn wir damit langsam etwas ins OT abdriften:
Ich mag nicht ausschließen, dass ich noch Lücken habe oder mir einiges zum TW nicht komplett klar ist, aber spontan:
- Wie @Chris M. schon geschrieben hat, enthält der CV-Container einen knxd. Zur Funktion oder dem Aufbau der TW-App für die CV kann ich keine Aussage treffen.
- Das homebridge-knx shim erwartet einen knxd.
- Ohne es zu verwenden sieht die Anleitung von FHEM z. B. auch einen knxd für die Verbindung vor (zumindest auf den ersten Blick in einer der Dokus, die ich gefunden habe).

Am Beispiel des Homebridge-knx shim:
Derzeit läuft meine Konfiguration noch gegen den WG-knxd. Ich hatte kurz den Versuch gemacht, die IP und den Port des TW anzugeben, was scheiterte. Gibt es einen Weg den TW ohne eine zusätzliche knxd-Installation als Ersatz zu verwenden, die ich oder Chris übersehen haben?

Ich gebe zu "diverse" basierte auf der eigenen Erfahrung mit 2 mir bekannten Systemen, aber ich bin mir aufgrund der langen Historie des knxd/eibd ziemlich sicher, dass es noch mehr Anwendungen gibt, die darauf Aufsetzen, auch wenn es wahrscheinlich auch alternative Ansätze geben mag.
Viele Grüße
Thorsten
________________________________________
Wiregate / TWS 2600 ID:596 + 2 PBM, VPN: bei Bedarf, Reboot nach Rücksprache

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#26

Beitrag von StefanW »

Guten Morgen,

der knxd ist ein Fork des eibd, an dem wir von 2009 bis 2014 (in etwa) miteinwickelt haben, insbesondere haben wir den eibd Einsatztauglich gemacht.

Nach meinem Kenntnisstand wird der eibd / knxd überwiegend von Open Source Software (und auch kommerziellen Produkten) eingesetzt als KNXnet/IP Tunneling Client. Es mag sein, das in der ein oder anderen Software etwas eigenes programmiert wurde, aber warum sollte man sich das antun, wenn es etwas fertiges gibt.

Eine Aufteilung in Multi-Container sehe ich kritisch, weil das die meisten Nutzer überfordert und den Support erschwert. Zudem ist die meiste Open-Source-Software damit gebundelt, es zu entbundeln halte ich nicht für zielführend.

Es mag ja sein, dass ein Multi-Container-Konzept informationstheoretisch das bessere Konzept sein mag, aber nur um 0,5% der IT Puristen zufrieden zu stellen, sollten wir nicht 99,5% der normalen Nutzer abhängen, die sich ohnehin schon mit dem Verständnis für einen Container und die Zusammenhänge mit Netzwerk / Mappings / Docker Volumes usw. sehr gefordert sind.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#27

Beitrag von starwarsfan »

Hallo Stefan
StefanW hat geschrieben: So Jan 09, 2022 1:07 pm Eine Aufteilung in Multi-Container sehe ich kritisch, weil das die meisten Nutzer überfordert und den Support erschwert. Zudem ist die meiste Open-Source-Software damit gebundelt, es zu entbundeln halte ich nicht für zielführend.
Das ist jetzt aber ein Widerspruch!?

StefanW hat geschrieben: So Jan 09, 2022 1:07 pm Es mag ja sein, dass ein Multi-Container-Konzept informationstheoretisch das bessere Konzept sein mag, aber nur um 0,5% der IT Puristen zufrieden zu stellen, sollten wir nicht 99,5% der normalen Nutzer abhängen, die sich ohnehin schon mit dem Verständnis für einen Container und die Zusammenhänge mit Netzwerk / Mappings / Docker Volumes usw. sehr gefordert sind.
Jetzt werden verschiedene Dinge durcheinander geworfen. Das Splitting in Multi-Container-Setups macht es eben gerade einfach, die einzelnen Komponenten zu pflegen. Wer will es sich denn bitte freiwillig antun, für Software X neue Images zu bauen, nur weil eine benötigte von-der-Stange-Komponente Y eine neue Version hat? Da wird lediglich das neue Image gepullt und im Idealfall nur dieser Container oder eben das gesamte Bundle neu gestartet. Das ist die Idee, separate Container zu bundlen, um ein Gespann der benötigten Komponenten zu erhalten. Ansonsten kann man auch gleich eine VM aufsetzen oder echtes Blech betreiben und regelmässig "apt update && apt upgrade -y" machen. Aber wehe, dann hat man eine zu neue Version von Y installiert, welche sich nicht mit X verträgt. ;)

Das hat nichts mit IT-Puristen zu tun, das ist einfach die Folge dessen, den Maintenance-Aufwand zu reduzieren. Schlussendlich ist so ein Multi-Container-Setup bspw. mit Docker-Compose wesentlich einfacher zu betreiben, als selbiges händisch mit einzelnen Containern zu machen. Anstelle von mehreren "docker run ..." mit zig verschiedenen Parametern gibt's einfach ein "docker-compose up" (ggf. noch ein Konfigurationsfile) und das Container-Bundle läuft. Ich gehe schwer davon aus, dass das mit Portainer-Stacks ähnlich aussieht (habe ich mir bisher noch nicht angeschaut).
Zuletzt geändert von starwarsfan am So Jan 09, 2022 2:25 pm, insgesamt 2-mal geändert.
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -

thtrp
Reactions:
Beiträge: 26
Registriert: Fr Nov 26, 2021 8:53 pm
Hat sich bedankt: 9 Mal
Danksagung erhalten: 21 Mal

#28

Beitrag von thtrp »

Wenn wir über docker compose bzw portainer stacks reden, non ich bei dir, jedoch liegt da die Verantwortung beim Maintainer.

Wenn es um den Ansatz geht den ich angedeutet hatte, zb einen Knxd laufen zu lassen (und nicht mehrere Instanzen, also einen pro Stack), um damit verschiedene Anwendungen zu bedienen, bin bei Stefan, dass dieser für die Mehrheit zu komplex wäre, siehe auch die Herausforderungen bei dem SSH-Container für den Zugriff auf die Volumes. Keine Rocket-Science, aber auch kein Plug&Play.

Kurz: docker compose/stacks sind nMn relevant. Sofern man fertige Stacks nutzt ist es trotzdem eher eine Funktion für Fortgeschrittene Anwendwer.
Viele Grüße
Thorsten
________________________________________
Wiregate / TWS 2600 ID:596 + 2 PBM, VPN: bei Bedarf, Reboot nach Rücksprache
Benutzeravatar

Chris M.
Reactions:
Beiträge: 1190
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 234 Mal
Danksagung erhalten: 853 Mal
Kontaktdaten:

#29

Beitrag von Chris M. »

StefanW hat geschrieben: So Jan 09, 2022 1:07 pm Es mag ja sein, dass ein Multi-Container-Konzept informationstheoretisch das bessere Konzept sein mag,
Das ist es durchaus auch praktisch relevant.

Docker unterstützt eigentlich nur einen laufenden Prozess, denn für den ist dieser einzelne Prozess gleichbedeutend damit ob der Container läuft oder nicht. (Natürlich darf dieser Prozess selbst weitere starten, ist dann aber selber dafür verantwortlich)

Genau das kann z.B. bei der CometVisu Ärger machen: da ist dieser entscheidende Prozess der Web-Server. Wenn nun aber klamm heimlich hintenrum der knxd sich beendet (z.B. crasht), dann bekommt das Docker nicht mit und kann so gar nicht von sich selbst aus das Problem lösen.

Nun kann man mit zusätzlich Aufwand (Fake init-System, supervisord oder einem Watchdog) das Problem minimieren - ist aber halt immer ein Murks für ein Problem, das man bei korrektem Aufbau eben nicht hätte.
Relevante Issues dazu wären z.B. https://github.com/CometVisu/CometVisu/issues/1015 oder https://github.com/CometVisu/CometVisu/issues/822

Der Lichtblick dabei: da der knxd eben sehr stabil ist, hat dieses Problem in diesem konkreten Fall glücklicher Weise keine hohe Prio.
Es ist aber halt ein Verfügbarkeitsthema zwischen "funktioniert meistens", "funktioniert fast immer" (der aktuelle Zustand) und "funktioniert immer" (der erwünschte Zustand)

PS: Auch die Docker-Doku hat dazu eine Meinung: https://docs.docker.com/config/containe ... container/
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.

TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache
Benutzeravatar

starwarsfan
Reactions:
Beiträge: 1152
Registriert: Mi Okt 10, 2018 2:39 pm
Hat sich bedankt: 744 Mal
Danksagung erhalten: 923 Mal

#30

Beitrag von starwarsfan »

Hallo miteinander
thtrp hat geschrieben: So Jan 09, 2022 3:13 pm Wenn wir über docker compose bzw portainer stacks reden, non ich bei dir, jedoch liegt da die Verantwortung beim Maintainer.

Wenn es um den Ansatz geht den ich angedeutet hatte, zb einen Knxd laufen zu lassen (und nicht mehrere Instanzen, also einen pro Stack), um damit verschiedene Anwendungen zu bedienen, bin bei Stefan, dass dieser für die Mehrheit zu komplex wäre
Ich bin ganz bei Dir. Mir ging's mehr um das hier:
StefanW hat geschrieben: So Jan 09, 2022 1:07 pm Zudem ist die meiste Open-Source-Software damit gebundelt, es zu entbundeln halte ich nicht für zielführend.
Es geht ja nicht darum, irgendetwas zu "entbundeln", was es als Bundle bereits gibt. Wobei wir hier wohl erstmal klarstellen müssen, was ein "Bundle" in diesem Kontext ist. Hier im Docker-Umfeld ist das m.M.n. eine Kombination verschiedener Dienste resp. Container, welche in Summe für den User eine Applikation zur Verfügung stellen. Dabei läuft (im Idealfall) je Container ein Dienst, also bspw. ein MariaDB-, ein Nginx- und ein LetsEnrcrypt-Container. Da wären wir dann bei Docker-Compose bzw. Portainer-Stacks.
Kind regards,
Yves

- TWS 2500 ID:159 (VPN offen, Reboot nach Rücksprache) - PBM ID:401 - TWS 3500 ID:618 (VPN offen, Reboot nach Rücksprache) - ControlPro - ProxMox - Edomi (LXC / Docker) - ... -
Antworten

Zurück zu „Docker, portainer, VM“