An mir ist dieses ganze Thema irgendwie vorbei gegangen. Aber ich würde mich da dennoch, im privaten, gerne etwas einarbeiten. Jedoch denke ich, fehlt es mir da bereits am Verständnis: Docker: Wenn ich das richtig verstanden habe, dann ist Docker so etwas wie eine Virtuelle Maschine, welche die "Programme" in Images bereit stellt. Quasi wie ein "Plugin-System". Gehe ich davon richtig in der Annahme das man da ein "Image" (sagen wir mal von einem LAMP) erstellt, und dieses dann bereitstellen kann? Momentan sehe ich da aber so das eine oder andere Problem: Wenn ich da jetzt mal Apache hernehme. Wo liegen dann die HTDOCS? In dem Image oder wieder extern? Wenn im Image: Wie komme ich dann an diese Daten heran? Kann ich da MySQL / PHP direkt mit in dieses Image übernehmen oder müssen diese dann wieder separate Images sein? Kann ich dann dieses Image von einer Maschine auf eine andere nehmen und dort läuft dieses dann einfach "out of the box"? Kann ich dieses Images Crossplatform verteilen - sprich AMD64 und ARM? Kubernetes: Das habe ich soweit durchblickt: Es gibt einen Master und mehrere Nodes - Der Master macht die Lastverteilung auf die einzelnen Nodes. Aber - wieder am Beispiel eines LAMP - wenn ich dann meine HTTP Dateien ändere lösche hinzufüge, verteilt der Master die dann gleich auf allen Clients? So das auf jeden Client der gleiche Datenbestand besteht? Geschieht dies "on the fly" oder eher "sheduled" (zu einer bestimmten Zeit z.b.)? Hat der Master den selben Datenbestand wie die Nodes, oder ist dieser ausschließlich zur Verteilung zuständig? Wie funktioniert das dann in Verbindung mit Docker? Wird da das gesamte Image dann "ausgewechselt"? Ich hoffe mir kann da jemand etwas Licht in mein Dunkel bringen :-) Liebe Grüße
Ratlos schrieb: > An mir ist dieses ganze Thema irgendwie vorbei gegangen. Entschuldige die Vorab-Frage: bist Du zufällig mit einem gewissen "Rudi Ratlos" bekannt, verwandt, verschwägert oder gar identisch? ;-)
Nur_ein_Typ schrieb: > Ratlos schrieb: > >> An mir ist dieses ganze Thema irgendwie vorbei gegangen. > > Entschuldige die Vorab-Frage: bist Du zufällig mit einem gewissen "Rudi > Ratlos" bekannt, verwandt, verschwägert oder gar identisch? ;-) Nein, und es ist wahrlich eine ernstgemeintes Anliegen von mir.
Docker ist eher ein System, um Anwendungen zusammen mit ihren Dependencies zu verpacken, damit man unkompliziert verschiedene Bibliotheksversionen gleichzeitig nebeneinander verwenden kann. um bei deinem LAMP-Beispiel zu bleiben: Wenn du eine Webapplikation hast, die nur mit PHP5 funktioniert, dein aktuelles Ubuntu aber kein PHP5 mehr installieren mag, dann pack das Ganze in einen "FROM ubuntu:12.04" - Dockercontainer, und schon kannst du das Teil betreiben, ohne dass dein Server mit Uralt-Bibliotheksversionen geflutet wird. Docker ist dabei etwas mehr als eine chroot-Umgebung, aber etwas weniger als eine Virtuelle Maschine, und damit nicht Cross-Platform. Hat natürlich auch einen Nachteil: Sicherheitsupdates für z.B. verwundbare Bibliotheken sind aufwändiger, weil jedes Image eine eigene Version davon installiert haben kann. Kubernetes ist ein Tool, um solche Container auf vorhandene Hardware zu verteilen, zu überwachen, bei Hardwareausfall umzuverteilen usw. Mit der Verteilung deiner geänderten HTML-Dateien hat das wenig zu tun. Da wäre der übliche Weg: - Du editierst die Dateien - Du baust ein Docker-Image mit den neuen Dateien drinnen (Das passiert oft automatisch per CI - Tool nach dem Commit in die Versionsverwaltung) - Du startest das neue Image auf deiner Test-Umgebung - Du testest (Das kann beides auch automatisiert werden) - Du gibst das OK für das Update: Kubernetes fängt an auf deinem Server-Park das neue Image herunterzuladen und zu starten. - Wenn doch ein Fehler durch den Test gerutscht ist: Einfach auf die vorherige Version zurückspringen.
Ratlos schrieb: > Nein, und es ist wahrlich eine ernstgemeintes Anliegen von mir. Gut... okay, dann wollen wir mal. Also, Du verstehst das schon ganz richtig, Docker ist so etwas Ähnliches wie Virtualisierung. Aber dann... siehst Du es auch wieder falsch, fürchte ich. Docker emuliert keinen eigenen Computer wie eine virtuelle Maschine, sondern isoliert die Prozesse auf der Betriebssystemebene. Insofern ist ein Docker-Image etwas völlig anderes als ein VM-Image: während das VM-Image ein komplettes Betriebssystem mit Kernel und allem 'drum und 'dran beinhaltet, ist ein Docker-Image im Endeffekt nur ein lauffähiges Abbild eines Prozesses, ähnlich wie Deine Executables in, sagen wir, /usr/bin/ oder eine .exe-Datei unter Windows. Im Unterschied zu diesen Executables beinhaltet ein Docker-Image jedoch außerdem alle Abhängigkeiten, die das Programm im Image zur Laufzeit benötigt, also Shared Objects / Dynamic Link Libraries (*.so / *.dll). Um ein Docker-Image, mithin: einen solchen Prozeß zu starten, braucht man also nur das Image sowie eine Konfiguration. Diese Konfiguration wird Container genannt und beinhaltet einen Verweis auf das betreffende Image, sowie obendrein noch weitere Informationen, etwa zur Anbindung von Speicher und / oder Netzwerk. Ein Container wird nämlich komplett vom Betriebssystem isoliert betrieben und läuft in seinem eigenen Netzwerk, seinem eigenen Prozeß-ID-Namensraum, und so weiter. Sofern keine weiteren Maßnahmen ergriffen werden, können Prozesse des Hosts nicht auf die im Container zugreifen und umgekehrt können Prozesse im Container nicht auf solche des Hosts zugreifen. Kommen wir zu Deinem LAMP-Beispiel. Das würde man üblicherweise mit je einem Container für Apache und einem für das SQL-RDBMs machen, als Faustregel gilt: nur ein Programm je Container. Man kann das zwar anders machen, zum Beispiel mit einem supervisord, aber es gilt als schlechter Stil und gibt einige der Vorteile von Docker, insbesondere im Zusammenhang mit Kubernetes, auf. Damit nun Dein Apache (beziehungsweise das PHP darin) auf Deine Datenbank zugreifen kann, müssen sie über die Container-Konfiguration vernetzt werden; meistens wird man dazu ein eigenes softwaredefiniertes Netzwerk erstellen und beide Container damit verbinden. Zudem ist es vermutlich sinnvoll, wenn irgendetwas auf die Webseiten zugreifen kann, die Dein Apache ausliefern soll, also muß wiederum per Konfiguration angegeben werden, daß die Ports 80 (http) und / oder 443 (https) per DNAT auf den Apachen in Deinem Container gemappt werden. Es ist zwar möglich und wird zum Beispiel im Golang-Umfeld gerne gemacht, einfach nur ein statisch gelinktes Programm ins Image zu installieren. Aber in der Regel werden Docker-Images von einem bereits bestehenden Image mit einem vollständigen Betriebssystem (außer dem Kernel, dessen Funktionen stellt ja der Host bereit) erstellt, so daß ein (weitgehend) vollständiges System im Image installiert ist. Was den Storage angeht, so gibt es da verschiedene Varianten. Die einfachste ist, Deine htdocs und / oder die Datenverzeichnisse Deines RDBMS einfach mit in das Image zu packen, aber das funktioniert nur dann gut, wenn sie unveränderlich sind -- aber dann braucht ja es in der Regel keine dynamische Seite mit RDBMS... ;-) Also gibt es dazu bessere Möglichkeiten, nämlich sogenannte "Mounts" -- die im Prinzip entweder ein Verzeichnis des Hosts, oder ein Docker-Volume in den Container mounten. Dadurch können die Daten dynamisch verändert werden und bleiben auch dann erhalten, wenn der Container weggeworfen und neu erzeugt wird. Das ganze Docker-Universum wäre nur halb so sinnvoll, wenn es nicht noch einen weiteren Teil dabei gäbe, nämlich die Registry, über die Du Deine Images verteilen kannst. Anders gesagt: Du erstellst Dein Image, testest es, indem Du einen oder mehrere Container daraus erstellst und sie testest, und wenn alles wie gewünscht funktioniert, dann lädst Du Dein Image in die Registry. Dann kann jeder, der an Deine Registry kommt und das Image herunterladen darf, es einfach herunterladen, seinen eigenen Container daraus machen und ihn starten. Und wenn Du eine neuere Version Deines Image bereitstellst, kann er seine Version des Image ganz einfach aktualisieren und einen neuen Container daraus erzeugen... Kubernetes ist eine konsequent weitergedachte Implementierung dieses Konzepts, um Docker-Container auf einem Cluster zu betreiben. Dabei kümmert sich Kubernetes um die Verteilung der Last auf die Nodes, um die Bereitstellung von Storage, um die (Hoch)Verfügbarkeit der Prozesse auch dann, wenn ein Node ausfällt, und natürlich darum, die internen und externen Netzwerkverbindungen weiterzuleiten. Aber bevor Du Dich mit Kubernetes beschäftigst, lern' lieber erstmal Docker. ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.