ElabNET Technik Forum

gbglace hat geschrieben: ↑Di Sep 04, 2018 6:54 pm Naja wenn das für mich nicht unbedingt alles Fremdbegriffe wären, würde ich wohl sagen, Gute Auswahl.

Irgendwo sind dann offensichtlich einem nicht IT-studiertem Grenzen im Verständnis gegeben.

Ich bin hier auch raus, Göran.

Hinzugefügt nach 1 Minute 10 Sekunden:

FabKNX hat geschrieben: ↑Di Sep 04, 2018 7:51 pm Funktionieren muss es.

Signed

Hallo Bodo,

bodo hat geschrieben: ↑Di Sep 04, 2018 8:21 pmApache2 webserver, PHP5 oder höher und MySQL oder MariaDB, auch gerne extra (wie uch immer das geht), wären schön. Es gibt auch fertige LAMP Images, wie mattrayner/lamp:latest, nur da hatte Nano gefehlt.

danke. Machen könnte man natürlich viel.

Hier ging es mir eigentlich zunächst nur um einen "BASIS" Container und die Frage, was mindestens enthalten sein muss, damit man dann alles andere sich installieren kann.

Also was ist MUST TO HAVE

lg

Stefan

ich glaube das das obige erstmal reicht als MUST HAVE. Man kann ja über apt dann selbst beliebig Pakete nachinstallieren.

Was ich nur noch nicht ganz kapiert habe: Wenn ich da was manuell nachinstalliere und dann ein neues Basis Image irgendwann von euch kommt wie kann ich das dann wieder zusammenführen? Oder muss ich mir jetzt alles was ich nachinstalliere aufschreiben damit ich das dann irgendwann wieder alles manuell nachziehen darf/kann? Oder kann man irgendwie ein eigenes "Delta image erstellen das dann einfach auf der neuen Basis von euch wieder alles nachinstalliert?

Dumme Fragen, aber ich habe da leider noch keinen wirklichen Durchblick was da wie mit Docker alles geht (ja vmtl. geht alles, nur WIE am sinnvollsten?)

Ich möchte hier aufgrund von rsslog.php, dass das rsslog plugin in der CometVisu bedient, erwähnen.
Braucht ebenfalls php, das man sonst per apt-get nachinstallieren müsste.

Auch update_rrd zum befüllen von rrd's aus plugins sollte funktionieren. Ich weiß aber ehrlicherweise nicht, welche Bibliothek o.ä. da dahintersteckt.
Diese Dinge kommen sonst spätestens beim meinem umfangreichen Test der plugin-Umgebung noch raus. Habe aber an meinem WG nichts installiert, das nicht per apt-get gegangen wäre.

lg
Robert

StefanW hat geschrieben: ↑Di Sep 04, 2018 8:32 pm Also was ist MUST TO HAVE

Hoi

Also ohne einen Webserver (z.B. Apache2 und PHP) geht mit der Cometvisu eh nix.

Ich bespreche nochmal intern, warum meine "Systemer" mit der Stirn runzeln, wenn ich mit SAMBA komme.

Kann ich mir schon vorstellen, warum er das nicht möchte, mein Mitgefühl hat er jedenfalls! Ist mal was anderes für mich, auf der Seite "das könnte man doch noch gerade machen" zu sitzen und mich nicht selbst mit abstrusen Wünschen des Kunden plagen zu müssen Jedenfalls von hier aus einmal ein dickes "Danke, gut gemacht!" an die Entwickler und "last euch nicht zu sehr von unseren vielen Wünschen nerven"...

Ich würde überlegen, Samba auch per Docker zur Verfügung zu stellen, Das hätte vor allem auch den Vorteil, dass es einfach zu deaktivieren ist, wenn z.B. von einem Integrator beim Kunden nicht gewünscht.

Ich wünsche mir bei dem Debian zumindest den Editor nano dazu, sollte eigentlich dabei sein.
Apache2 webserver, PHP5 oder höher und MySQL oder MariaDB, auch gerne extra (wie uch immer das geht), wären schön.
Es gibt auch fertige LAMP Images, wie mattrayner/lamp:latest, nur da hatte Nano gefehlt.

Ich hatte auch erst überlegt einen Editor zu erwähnen, aber da hat doch jeder so seine eigenen Vorlieben, bei mir wäre es im Textmodus z.B. der joe. Daher weiss ich nicht, ob man so etwas wirklich in eine Basisimage als "must have" packen sollte. Ähnliches gilt für den Webserver, um nur ein paar statische Sachen auszuliefern würde ich wohl auch keinen Apache nehmen.

Ich sehe es eher so, dass Elabnet ein Basisimage mit den absoluten Basics zur Verfügung stellt, eibd würde ich da auch noch zu zählen, Apache & Co aber nicht mehr. Auf Basis dieses Images können dann weitere Images für spezielle Anwendungen erstellt werden. Meist werden die Anpassungen auch nur kleine sein. Es spricht ja nichts dagegen, wenn die Dockerfiles dann hier geteilt werden. Dann wird es wohl schnell eine Kollektion mit den am meisten genutzten Anwendungen geben.

Es ist ja gerade einer der Vorteile von Docker, das Images auf anderen Images aufbauen und nicht jedes mal das Rad neu erfinden müssen. Es entspricht eigentlich auch nicht der Philosophie von Docker, möglichst viel in ein Image zu packen, eigentlich ist die Empfehlung da immer einen Container pro Aufgabe. Das muss man sicher nicht übertrieben verbissen sehen, aber ein kompletter Server in einem Image ist sicher auch nicht sinnvoll.

Bei Docker gilt: ein Container pro Server/Aufgabe.
Für unseren Anwendungszweck sehe ich das etwas liberaler - z.B. braucht die CometVisu einen Web-Server + PHP, das sollte da wohl alles in einen Container.

Daher hätte ich - ohne Docker-Experte und Philosoph zu sein - das nach Aufgaben sortiert. Also einen Contianer für CometVisu (mit PHP und z.B. Apache) aber sonst nichts, einen mit den WG-Plugins, einen als Basis für eigene Experimente, einen mit SMB/CIFS, ...

Den eibd/knxd hätte ich in einen eigenen, minimalen Container gepackt, der sonst nackig ist, aber dafür den Socken und/oder Port friegibt, auf den alle eibd/knxd-Anwender zugreifen können. So braucht das auch nur einen einzigen Tunnel für alle Nutzer.

Das sehe ich so ähnlich, man muss es mit der Aufteilung nicht übertreiben. Allerdings sollte man beachten, das Docker nur einen Prozess pro Container überwachen und ggf. neu starten kann. Datenbank und Webserver in einem Container sähe ich da dann schon nicht als so ideal an.

Ich denke, man sollte das, wie ja auch von Docker vorgegeben, in Schichten aufbauen
1. Basiscontainer mit eibd und dem allernötigtsen
2. Darauf aufbauend je einen Container mit Webserver & PHP und einen mit den Wiregate Plugins
3. Auf dem Webserver aufbauend dann die Cometvisu usw.

oder so ähnlich...

Mit aufbauend meine ich nicht, dass die parallel laufen sollen um ihre Aufgabe zu erfüllen, sondern dass die jeweils untere Schicht im Dockerfile als Basis für die nächste genommen wird.

Samba würde ich in eine separaten Container bereitstellen, der dann das Root-Verzeichnis der Volumes bereitstellt. Bei ssh kann man diskutieren. Ich sehe vor allem aus Gründen der Bequemlichkeit Argumente dafür, ssh in den Containern zu integrieren. Dann vielleicht eine Zwischenstufe zwischen 1 und 2 für den SSH-Server.

Wie geschrieben bin ich Docker-Anfänger, wenn aber diese Schichten seitens Docker möglich sind, würde ich basierend [mention]StefanW[/mention]'s Vorschlag sowie den weiteren Kommentaren folgendes vorschlagen:

1. Schicht

Basis-Container:
- Aktuelles Debian Linux
- Unterstützung Bash
- apt Unterstützung um weiteres nachzuinstallieren
- Zugriff per SSH auf den Container (damit ist gleich auch SFTP/WinSCP möglich)
- eibd und Schnittstelle


2. Schicht

Perl/Plugin-Container:
- Basis-Container
- PERL
- Laufzeitumgebung Plugins


Webserver-Container:
- Basis-Container
- Webserver inkl. PHP-Unterstützung


Samba-Container:
- Basis-Container
- Samba-Server / CIFS/SMB-Unterstützung


3. Schicht

CometVisu-Container:
- Webserver-Container
- Laufzeitumgebung CometVisu

LAMP-Container:
- Webserver-Container
- MySQL-Server


Rot markiert die Container, die von Timerwolf-Seite kommen müssten um die Grundfunktionalitäten wie im Wiregate abzudecken.

Ergänzend zum Basis-Container fände ich dort einen einfachen Editor wie nano auch noch super. Ich selbst bin eigentlich vim-Nutzer, aber IMHO ist nano für die Anfänger einfacher.

Ich schließe mich hier an. Nicht zu viele Funktionen in den Basis Container. Es gibt sicher viele Anwendungsfälle für PHP, Apache, usw.. Aber bestimmt auch mindestens drei Mal so viele ohne .