Ok, kurz zur Erklärung:
Wir haben zwei Prozessorplattformen:
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
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
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
.
Kommentar