Timberwolf Server - Docker - Was habt ihr damit vor

[terseek]

Bei mir gibt es auch Interesse für EDOMI im Docker-Container.

Was ich bis jetzt verstanden habe ist, daß es von Seiten der CPU-Architektur in den Desktopmodellen gehen sollte. Eine weitere Bedingung für EDOMI ist jedoch CentOs 6.x, das wäre doch bei den Desktopmodellen anders; also würde EDOMI dort nicht laufen,oder mißverstehe ich da etwas?

[Robert_Mini]

Ich denke der Wunsch ist ohnehin bekannt, aber dennoch der Vollständigkeit halber:
Docker für wiregate plugins in perl für alles, was mit Logik nicht mehr darstellbar ist und in einer Hochsprache wir Perl einfacher ist .
Ich hab perl extra für das Wiregate gelernt und liebe es inzwischen (auch wenn laufend google zur Unterstützung bei der Befehlssuche braucht).

Ich hoffe aber, dass ihr die WG-plugins irgendwie in einen Docker bekommt, ohne dass man 1 Docker je plugin braucht! Das wäre bei 50 Plugins ein Problem...

lg
Robert

[Jockel]

Ja, da schließe ich mich an, Samba und sftp wären sehr wünschenswert.

NFS eine nette Zugabe, aber nicht unbedingt erforderlich. Mit NFS hatte ich in der Vergangenheit immer wieder Probleme mit den Nutzerrechten, vielleicht ist das mit aktuellen Versionen besser geworden. Wenn nicht, würde ich darauf eher verzichten.

[Cepheus73]

Ich möchte gerne eine Asterisk-Installation im Docker laufen lassen.
Weil wir derzeit nur einen gefritzten Speedport haben, der die eingehenden Nummern nicht in einem rückrufbaren Format an das Telefon weitergibt. Daher brauche ich einen kleinen SIP-Server, der das Nummern umschreiben erledigt.
Eine neue Fritzbox ist dafür Overkill, da ich das WLAN/DECT u.a. zwecks Aufstellort im Serverschrank im Keller nicht nutzen kann/will.

Und EDOMI oder/und CometVisu.

[irgendwer]

Samba und am besten auch SFTP (ich nutze vscode mi ftp-sync)

[StefanW]

Hallo,

Erst einmal: Eine gute Idee, die Themen etwas aufzuteilen!

Gerne. Vorschläge zu weiterer Aufteilung gerne an mich, ausnahmsweise auch per PN.

Was mich interessieren würde: Wird es möglich sein, Verzeichnisse im Filesystem der SSD des Timberwolfs ("host mounted") in den Docker Containern zu nutzen oder werden für persistente Daten nur Docker-Volumes unterstützt?

Ja, es ist vorgesehen, dass es Verzeichnisbereiche auf dem Timberwolf Host gibt, in den die Container ihre persistente Daten speichern. Das wird dann auch durchaus in das Backup miteinbezogen. Alles andere wäre verkrüppelt. Kann man ja mit Quotas im Griff behalten.

Damit zusammenhängend, falls ich die Daten im Filesystem des Timberwolf ablegen kann: Können die als Netzwerkshare freigegeben werden um so z.B. die openHAB Konfigurationsdateien ändern und die Logfiles einsehen zu können?

Ansich eine gute Idee, sollte nichts dagegen sprechen aus meiner Sicht. Bespreche ich aber erst mit der Technik. Der Aufwand für uns liegt da immer daran, dafür auch eine Oberfläche zu bauen, wo man das einfach einstellen kann. Was ist da gewünscht? Samba? NFS?

==> Wird geklärt

lg

STefan

[Jockel]

Erst einmal: Eine gute Idee, die Themen etwas aufzuteilen!

Docker ist bei mir auf dem Timberwolf auch ganz klar im Focus, vielleicht kann ich damit meinen bestehenden Server für die Hausautomatisierung komplett ablösen, mal schauen, wie die Performance aussieht. Geplant habe ich unter anderem: openHAB, MQTT, caldav, PostgreSQL, imap (Dovecot), smtp (Postfix) und vielleicht noch ftp (nur für Daten die in die Visu eingebunden werden sollen). Grafana, Influx und nginx (als reverse Proxy) kann der Timberwolf ja eh.

Was mich interessieren würde: Wird es möglich sein, Verzeichnisse im Filesystem der SSD des Timberwolfs ("host mounted") in den Docker Containern zu nutzen oder werden für persistente Daten nur Docker-Volumes unterstützt?

Damit zusammenhängend, falls ich die Daten im Filesystem des Timberwolf ablegen kann: Können die als Netzwerkshare freigegeben werden um so z.B. die openHAB Konfigurationsdateien ändern und die Logfiles einsehen zu können?

[starwarsfan]

Hallo Stefan

Ok, kurz zur Erklärung:

Wir haben zwei Prozessorplattformen:

• ARMv7L: Das ist die Plattform unserer größeren Hutschienenserver (ab 2 CPU Kerne).
• x86_64: Das ist die klassische Intel PC Plattform in 64 Bit

...

Vielen Dank für die umfangreichen Infos!

Damit möchte ich aber anregen, beim 950er/960er TW einen entsprechenden Hinweis hinzuzufügen, dass man dort nur ARM Docker-Images laufen lassen kann! Das ist vielen sicher nicht klar und man sollte somit vorab prüfen, ob das gewünschte Image in einer ARM-Version verfügbar ist.

Für Edomi nach heutigem Kenntnissstand bedeutet das: Da offenbar 64 Bi CentOS gefordert sind, wird ein Host-Linux benötigt, dessen Kernel und GNU/Linux ebenfalls für 64 Bit kompiliert wurden - und damit eine Prozessorarchitektur in 64 Bit.

Für Edomi auf den Hutschienenservern wäre zu klären, ob eine 32 Bit ARM Entwicklung möglich wäre. Weil Edomi für 64 Bit ARM Docker soll es angeblich geben

Nein, nicht das ich wüsste. Edomi bedingt zwingend CentOS 6.x in 64Bit als Basis-System und davon gibt es laut CentOS-Downloadpage keine ARM-Portierung. Aktuell ist CentOS 7 und somit wird es nahezu unmöglich bzw. mit extremen Aufwand verbunden sein, jetzt noch CentOS 6.x nach ARM zu portieren. Das lohnt sich sehr wahrscheinlich nicht.

Nach meinem Kenntnisstand gibt es nur ein Edomi Docker-Image. Das wird von mir gepflegt und ist für x86_64 Docker-Hosts.

Es sollte jetzt aber kein EDOMI-Thread werden, sondern Docker im allgemeinen.

Wenn Bedarf besteht, dann machen wir auch gerne eine separaten EDOMI-auf Timberwolf Thread. Hierzu bräuchten wir dann aber auch Experten, die fundiert etwas beitragen können zu den angesprochenden Themenkreisen 64-Bit / Cent-OS / Performance

Gerne, da bin ich auf jeden Fall dabei.

Unterm Strich heisst das nun aber mit ziemlicher Sicherheit, dass ich meine 950Q-Bestellung stornieren und wohl gleich auf den 2500er ordern werde...

[StefanW]

Es sollte jetzt aber kein EDOMI-Thread werden, sondern Docker im allgemeinen.

Wenn Bedarf besteht, dann machen wir auch gerne eine separaten EDOMI-auf Timberwolf Thread. Hierzu bräuchten wir dann aber auch Experten, die fundiert etwas beitragen können zu den angesprochenden Themenkreisen 64-Bit / Cent-OS / Performance

lg

Stefan

[StefanW]

Ok, kurz zur Erklärung:

Wir haben zwei Prozessorplattformen:

• ARMv7L: Das ist die Plattform unserer größeren Hutschienenserver (ab 2 CPU Kerne).
• x86_64: Das ist die klassische Intel PC Plattform in 64 Bit

Software muss, damit sie vom Prozessor ausführbar ist, auf den genauen Prozessortyp kompiliert sein, jede Architektur versteht nur die passenden Instruktionen. Das Betriebssystem und Dinge wie BIOS usw. spielen auch noch eine Rolle wegen Bibliotheken und API usw.


Desktop-Versionen der Timberwolf Server:
Die Desktop Versionen der Timberwolf Server basieren auf einem normalen PCs mit BIOS. Das es kein Intel-Prozessor ist sondern ein AMD-Prozessor spielt hier keine Rolle, da es sich um einen im Kern kompatiblen Prozessor handelt und die HW-Besonderheiten des AMD-Prozessors werden vom Linux-Kernel gehandelt (bzw. sind von uns auch so eingestellt worden). Damit läuft hier jede übliche Intel-kompatible 64 Bit Software drauf, also alles was man so bekommt.

Die Docker-Version ist dann auc die übliche Intel-64-Bit-Docker Version. Die Software im Container muss demnach für Linux und x86-64 kompiliert sein.


Hutschienen-Versionen der Timberwolf Server:
Die Timberwolf Server im REG Gehäuse sind mit ARM-Prozessoren ausgestattet. ARM-Prozessoren sind kleiner und benötigen deutlich weniger Energie, deshalb werden die auch in mobilen Devices verwendet. ARM ist eine Designschmiede für Prozessorarchitekturen, stellen jedoch keine Prozessoren her. Das tun dann Dutzende von Firmen, welche bei ARM die Lizenz für ein Design einkaufen und es dann noch für sich anpassen. Es gibt also nicht den ARM-Prozessor, sondern tausende. Eingeteilt werden diese nach Familien. In den D und Q-Versionen verwenden wir ARMv7. Das ist eine sehr leistungsstarke Familie und wurde auch (als -D) im iPhone 4s, iPad2 usw. verwendet.
Software die darauf laufen soll, muss dafür kompiliert werden. Es gibt kein BIOS, was die Sache aufwändig macht (mein Spruch während der Entwicklung "man merkt erstmal wie ARM man dran ist ohne BIOS"). Debian Linux gibt es für mehrere Prozessorarchitekturen, unter anderem auch für unseren ARM, die 'armv7l' mit Floating Point Prozessor.

Die Docker Version für diesen Server ist dann auch eine, die von Docker für ARMv7 bereitgestellt wird. Es ist eine offiziell unterstützte Architektur, also kein Community-Build, sondern Bestandteil des offiziellen Docker-Repositories.


Was ist Docker:
Docker ist ein Programm, mittlerweile ein Daemon, das auf der Basis von teils sehr alten Standard-Tools von GNU/Linux eine isolierte Umgebung bereitstellt, in der Programme laufen können, die nur begrenzte Zugriffsrechte auf Ressourcen des gesamten Betriebssystemes haben. Damit wird vermieden, dass sich Programme weder das System noch andere Programme (zu sehr) beeinträchtigen können.
Es wird mit diesen Tools ein eigener Namensraum geschaffen, eigene Netzwerkschnittstellen usw. . Das ursprüngliche Docker war dann auch nur ein python-Script, dass die richtigen Betriebssystembefehle aufgerufen hat, um diese Umgebung durch den Kernel und diese Tools erstellen zu lassen, in der dann letztlich die Programme gestartet wurden. Mittlerweile ist Docker ein eigener Daemon, tut aber im Kern noch das gleiche - und tausend Verwaltungsfunktionen dazu.

Container selbst sind Stapel von Images die zusammen gemerged sind, wobei nur in das das oberste Image geschrieben werden kann. Wie ein Stapel Papier, wobei nur auf dem obersten Papier des Stapels geschrieben werden darf. Aus Sicht der Anwendung erscheint dies als ein eigenes Dateisystem.

Das ist jetzt nur eine extrem verkürzte und vereinfachte Darstellung. Docker ist keine Systemvirtualisierung - imitiert also einen ganzen PC - sondern eine Software-Virtualisierung - und "vervielfacht" Kernel / API inkl. Prozessisolation.

Der Vorteil ist, dass Docker extrem leichtgewichtig ist und die Ressourcen geteilt werden. So lassen sich hunderte "Hello World" Container betreiben, bei dem jeder nur wenige KB Speicher benötigt. Da liegen VMs schon beim hundertfachen mindestens, weil in einer VM komplette Betriebssysteme zu installieren sind, bei Docker leihen sich alle Container die Ressourcen aus dem einen Kernel des Host-Systems.

In Bezug auf den Timberwolf Server ist das eine feine Sache, weil der Kunde hat in seinem Containern volle Root-Rechte, muss dabei nicht Sorge haben, etwas zu beschädigen am System, da sine Prozesse im Container isoliert sind.


Docker und die Prozessor-Architekturen

Docker kann keine anderen Architekturen emulieren, schließlich ruft es nur Betriebssystemfunktionen und Tools des Host-Systems auf. Daher laufen auf einem Docker, das unter 64 Bit Linux x86 läuft auch nur entsprechende Programme für Linux X86. Bei den ARM-Maschienen müssen es dann Programme sein, die für 'armv7l' kompiliert sind.

Mission impossible.

Für Edomi nach heutigem Kenntnissstand bedeutet das: Da offenbar 64 Bi CentOS gefordert sind, wird ein Host-Linux benötigt, dessen Kernel und GNU/Linux ebenfalls für 64 Bit kompiliert wurden - und damit eine Prozessorarchitektur in 64 Bit.

Für Edomi auf den Hutschienenservern wäre zu klären, ob eine 32 Bit ARM Entwicklung möglich wäre. Weil Edomi für 64 Bit ARM Docker soll es angeblich geben


lg

Stefan

[vento66]

Naja vielleicht erst mal schlau machen, und dann posten.....

[Smart Jeanie]

Und dann sagst Du uns gleich noch wie Centos 6.5 minimal auf den Raspi kommt.....

D.h. es gibt noch eine dritte technische Hürde, weil es kein CentOS 6-irgendwas für ARMe gibt?

[MuckiLegden]

Moin,

eigentlich bin ich ja auch auf der Suche nach einem kleinen Server, der einfach läuft und wo man sich nicht immer selbst um alles kümmern muss, aber mal z.B. mit Docker mal schnell was testen kann...
Ich habe hier allerdings Edomi direkt auf einem APU2C4 installiert und das ist mir erheblich zu langsam. Die Visu ist im Vergleich zu meinem NUC gefühlt deutlich verzögert in der Darstellung. Die Anzeige von Diagrammen dauert je nach Umfang des Zeitraumes bei meinen Archiven teilweise bis zu 30! Sekunden, auf dem uralten NUC sind es nur 1-2 Sekunden.
Ich habe mich ausdrücklich noch nicht um irgendwelche Tuning Geschichten gekümmert, die sicherlich möglich sind und ich habe mich auch noch nicht mit Docker beschäftigt...

Insgesamt habe ich aber arge Bedenken, ob Edomi auf so einem Timberwolf mit der gleichen Hardware mit 3-15 laufenden Docker-Containern wohl zufriedenstellend laufen würde...

Vg,
Mucki

[mmutz]

Ich könnte mir vorstellen, da einen IMAP-Server/fetchmail und/oder das Musikarchiv drauf laufen zu lassen, damit sich das NAS öfter und länger schlafen legen kann. Denn Backups ziehen oder Video streamen macht man dann doch eher selten, im Vergleich zu Musikhören und Mails checken, welche dauernd im Hintergrund laufen.

[stonie2oo4]

Wer weiß was kommt, vielleicht stellt Christian irgendwann doch mal die Sourcen öffentlich zu Verfügung.
Vielleicht wirds dann doch noch möglich.
Cool wäre es auf allen Fällen. Somit hätte der Timberwolf auch gleich noch "die beste" Visu .