ElabNET Technik Forum

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

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.

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?

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.

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.

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

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).

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.

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/

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.