Diskussion:Docker (Software)

message: * Dockerfiles sind Skripte (reine ASCII-Text-Dateien) die man verwenden kann, um automatisiert Images zu erzeugen und dabei zu konfigurieren.
* Docker-Images sind  binäre Dateien, die auf Festplatte gespeichert bzw. in die Cloud (Docker Hub) hochgeladen und damit weltweit zugänglich gemacht werden können. Nach meinem bisherigen Verständnis verhält sich Image und Container wie Objekttyp(Klasse) und Objekt(Instanz der Klasse)  ... stimmt das?  Geeignete Synonyme????: Container-Typ, Container-Package, Container-Abbild, Container-Backup, Container-Snapshot, Container-Vorlage? 
* Container sind Instanzen von Images, d.h. Container sind aktiv, 'lebendig' und benötigen RAM, Prozessorzeit und I/O (wird ihnen von der Docker-Infrastruktur zugewiesen). Sie können auf Anfragen reagieren. Wenn ich es richtig verstanden habe, enthalten Docker-Container hauptsächlich Serverprozesse (z.B. Webserver, Datenbanken), die auf Anfragen über die (evtl. virtuelle) Netzwerkkarte reagieren. 
* Pods sind Container-Stapel, die einen einzelnen Dienst über eine einzelne IP-Adresse anbieten. Sie werden als eine logische Einheit betrachtet. "Kubernetes introduces the concept of a pod, which represents a group of containers that should be deployed as a single logical service. The pod concept tends to fit well with the popular pattern of running a single service per container." , "Typischerweise handelt es sich um Container, die miteinander in Verbindung stehen und einen bestimmten Dienst anbieten, beispielsweise einen Web- oder Applicationserver... IP-Adressen sind dabei üblicherweise an einzelne Pods gebunden.... Hat man beispielsweise festgestellt, dass ein bestimmter Pod über 4 Replicas verfügen soll und stehen momentan nur 3 Instanzen zur Verfügung, (dann kann der Autrag erfolgen) eine weitere Instanz des Pods zu starten" (Zitat aus iX 4.2015, S.51)
* Infrastuktur: Eine Laufzeitumgebung der Container (z.B. CoreOS) enthält den Kernel. Ein darauf laufendes Framework (z.B. Kubernetes, "Steuermann") steuert die Ressourcenverteilung (Prozessoren, RAM. I/O) und die Überwachung der laufenden Container. Ein Provider kann damit "Container as a Service"(CaaS) anbieten.
* Image-Layer: Ein Image besteht üblicherweise aus mehreren Layern (Schichten), die übereinander gestapelt werden. Wie bei einem Stapel bzw. wie bei einer Zwiebel. Der Base-Layer enthält immer eine Linux-Distribution. Die darauf aufsetzenden Layer enthalten dazu passende Ergänzungen, Änderungen (das Delta). Sobald so ein Stack mit 'docker run oberster_layer/image' gestartet wird, werden alle darunterliegenden Layer auch aktiv und bilden zusammen die laufende Einheit aus Betriebssystem und Anwendungen. Diese sind im laufenden Betrieb unveränderlich (read-only). 
* AUFS-Layer: Auf die Image-Layer eines Containerstapels wird noch eine weitere Schicht gelegt. Wie eine äußerste ("Wachstums-")Schicht bei einer Zwiebel. Diese ist beschreibbar (read-write) und anfangs leer. Dort werden alle Änderungen (Schreibvorgänge) des laufenden Systems abgelegt. Sie können auf Wunsch mit 'docker commit' als Image-Layer 'eingefroren' werden und stehen dann als weitere Schicht zur Verfügung. Um im Bild zu bleiben: Der Containerstapel ist damit einen Container höher geworden bzw. die Zwiebel ist um eine Schicht gewachsen.
* Zum besseren Verständnis kann man sich die Layer auch als durchsichtige Klarsicht-Folien vorstellen. Auf jeder Folie ist ein Teil eines Bildes. Die Folien übereinandergelegt ergeben das ganze Bild. Nur die oberste Folie kann bemalt werden. Dabei können Bildteile von darunterliegenden Folien einfach überdeckt werden: sie sind noch da, aber im aktuellen Gesamtbild nicht mehr sichtbar. Das geniale: Die Folien können in anderern Bildern wiederverwendet werden. Die Folienstabel können dann in unterschiedlicher Infrastruktur aufgelegt werden (z.B. auf einen Overhead-Projektor, in einen Bilderrahmen)
* Das Docker-Logo stellt ein Container-Schiff dar. Was bedeutet das? Stellt das Schiff den Docker-Hub dar, der gerade die Image-Stapel weltweit verteilt? :) Oder sollte man sich bei dem Schiff eher eine Linux-Infrastruktur vorstellen, welches Ressourcen für die Container-Stapel (Pods) bereitstellt? Die Container müsste man sich dann durchsichtig vorstellen, denn jeder enthält jeweils nur einen Teilaspekt eines Linux-Dateisystems und der Anwender schaut von oben auf die einzelnen Containerstapel.
* Kann bitte jemand klären, ob Docker-Container auch Sinn machen für GUI-Client-Apps? (z.B. auf Qt-, KDE- oder Gnome-Basis)?  Kann man zukünftig z.B. seine Qt-Anwendung als Docker-Image ausliefern?
* PS: Welche Analogie gefällt euch am Besten? Das Container-System, die Zwiebel oder der Klarsichtfolien-Stapel :)
bitte korrigiert mich :) thx
--Matthias.Ebert (Diskussion) (01:07, 30. Mär. 2015 (CEST)
replies: text: Pflichte dem umfänglich bei. Leider sind Ihre Erläuterungen auch nicht viel besser. Instanzen, Images sind alles Fachberiffe - es fehlen Vergleiche und Abgrenzung zu herkömmlicher, bekannter Software. Ich weiß nach den ersten Zeilen bis zur Mitte bei Geschichte immer noch nicht, was das ist und wofür es gut ist. Es scheitert schon am Begriff Container. Links nach außen helfen gar nicht, weil statt der Erklärungen fortlaufend neue Begriffe Fragen aufwerfen. Das sollte jemand schreiben, der nicht aus der IT kommt. Schlechter Fachidioten-Artikel: Ich weiß auch nach der Diskussion immer noch nicht, was Docker macht und wofür das gut ist. Ich habe nur mitbekommen, dass man bei Mac alte Software wie iTunes auf neuen Betriebssystemen und Geräten damit laufen lassen kann. Solche Beispiel wären wünschenswert. --Rkendlbacher (Diskussion) 03:50, 28. Mär. 2023 (CEST)
thread_title:   Wäre schön, die Docker-Begriffe etwas anschaulicher zu beschreiben...  

message: Die Anmerkung unten betreffend selinux erscheint mir in der form ziemlich unsinnig. Sie linkt per url, nicht wie ueblich per wikilink, auf den wikipediaartikel zum thema SElinux. Allerdings ist das hier absolut unerwartet. Besser währe den SElinux begriff in den satz vor dieser anmerkung korrekt mit den SElinux wikipediaartikel zu verlinken und statdessen unten in die anmerkung die oeffentliche ankuendigung der institutuion/person zu linken welche diese erweiterung erstellt hat.
--91.3.15.224 09:01, 10. Apr. 2015 (CEST)
thread_title:  SeLinux 

message: Benutzer:Purist hat den Abschnitt „Sicherheitsrisiken“  vorgeschlagen. Dieser erweckt den Eindruck, Docker enthalte eine bekannte Sicherheitslücke, die beim Dockereinsatz zu einem erheblichen zusätzlichen Sicherheitsrisiko führen würde. Eine solche Sicherheitswarnung kann in Wikipedias Dockerartikel aufgenommen werden, aber nur, wenn es dazu einen Beleg einer zuverlässigen Publikationen gibt, siehe dazu Wikipedia:Belege. Eine zuverlässige Publikation wäre z.B. Heise online/iX/c't oder https://www.cert-bund.de/ . Keine zuverlässige Publikation ist das Blog https://reventlov.com/ . Wenn es sich bei dem dargestellten Sicherheitsrisiko um ein relevantes Sicherheitsrisiko handelt, muss sich dafür auch eine zuverlässiger Beleg finden, was aber bisher nicht der Fall ist.
Im Artikel stand schon bisher im Abschnitt „Grundlagen“: „Da die Ressourcentrennung alleine mit den Docker zugrunde liegenden Techniken wie Namespaces und Cgroups nicht völlig sicher ist“. Dies ist für mich ausreichend, und entspricht dem Grundsatz Wikipedia:Neutraler Standpunkt. Den vorgeschlagenen Abschnitt „Sicherheitsrisiken“ habe ich deshalb wieder herausgenommen. ---- (Diskussion) 23:40, 25. Apr. 2017 (CEST)
replies: text: Volles Streichbingo! In deinem Beitrag war von NPOV bis Relevanz ja das komplette Arsenal dabei. Mein Abschnitt erweckt nicht nur den Eindruck, sondern beschreibt die Wirklichkeit: der Einsatz von Docker als virtualisierte Container-Lösung birgt im Vergleich zu anderen virtualisierten Lösungen Gefahren für den Host und für andere auf diesem Host virtualisierte Container. Dein Beitrag hier erweckt den Eindruck, als hätte ich den Blog reventlov.com als einzige Quelle angegeben. Nur, damit es nicht übersehen wird, habe ich noch mehr zuverlässige Quellen hinzugefügt. Die Erwähnung dieses Sicherheitsrisikos in einem Halbsatz in einem Abschnitt über die Grundlagen - und dann auch noch mit dem relativierenden Zusatz „völlig“, denn was ist schon völlig sicher? - reicht für dieses Problem einfach nicht aus: von Virtualisierungslösungen wird ausgegangen, dass ein Container, in dem sich Anwendungen befinden und ausgeführt werden, keine Löcher oder Zugangsmöglichkeiten zu anderen Containern enthalten außer die, die man im Container absichtlich (per vollzogener, nicht per unterlassener Konfiguration) lässt. Bei Docker passiert das nicht und das kann man nicht mal eben in einem beiläufigen Halbsatz herunterspülen. Abschnitt wiederhergestellt. --Purist (Diskussion) 10:45, 1. Mai 2017 (CEST)
replies: text: In seiner jetzigen Form suggeriert der Artikel allerdings, es gäbe keinerlei Sicherheitsrisiken. Ein kurzer Blick in die angegebenen Quellen verrät aber, dass die Dinge wesentlich komplizierter liegen, und sich je nach Konfiguration durchaus Risiken ergeben können. Ich schlage daher eine Überarbeitung des Abschnitts vor und würde, wenn sich kein Protest regt, in der Zwischenzeit auch mit einem Textbaustein auf das Defizit aufmerksam machen wollen --Lapu (Diskussion) 21:06, 4. Feb. 2019 (CET)

text: Tolle Quelle, dieses reventlov - keine 5 Jahre später schon offline. --2003:CC:E727:1F00:4C09:2DE0:B4B4:7BF3 13:13, 13. Jul. 2023 (CEST)
thread_title:  Sicherheitsrisiko Docker-Resourcentrennung 

message: Das Unternehmen hinter Docker erhielt im Januar 2014 von mehreren Geldgebern zusammen 15 Millionen US-Dollar an Investitionen.[15] Im April 2015 folgten Investitionen in Höhe von 95 Millionen US-Dollar.[16] Insgesamt belaufen sich die Investitionen in die ursprünglich unter dem Namen dotCloud gegründete Firma damit auf gut 120 Millionen US-Dollar. 
Kann ich schlecht rechnen? 95 + 15 = 120 ? - Weapon X (Diskussion, Beiträge) 15:14, 11. Jul. 2019 (CEST)
replies: text: Wo steht denn, dass die fehlenden 10 Mio. nicht woanders hergekommen sind? --2003:CC:E727:1F00:4C09:2DE0:B4B4:7BF3 11:53, 13. Jul. 2023 (CEST)
thread_title:  Abschnitt "Geschichte"