1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Dumb-Init: Yelp baut Init-System…

Wozu überhaupt Docker?

  1. Thema

Neues Thema Ansicht wechseln


  1. Wozu überhaupt Docker?

    Autor: Geistesgegenwart 07.01.16 - 18:01

    Ich habe bisher nicht wirklich mit Docker gearbeitet, aber von allem was ich bisher gelesen habe verstehe ich nicht, wieso man das überhaupt braucht.

    Die meisten Blogs etc. argumentieren immer, warum Docker besser als andere Virtuelle Maschinen sind (Xen, VMware, etc.) - und da sehe ich natürlich die Vorteile. Wenn aber eine Docker Instanz aus einem einzigen Prozess besteht - wieso lasse ich diesen Prozess dann nicht direkt - ohne Docker/LXC abstraktion - auf dem Hostsystem laufen?

    Oft wird angeführt, das man mehrere Linuxe auf einem Host nutzen kann, aber das stimmt ja so nicht direkt: Der Linuxkernel und dessen API-level ist für alle Dockerinstanzen gleich, lediglich der Userspace wird vollständig eingeblendet (also jeweils andere libc und bibliotheken). Aber gerade bei Linux ist es doch so, dass sowieso alle (frei verfügbaren) Pakete in jeder Major Distro vorhanden sind. Braucht man wirklich so oft einen JBoss auf CentOs und ein Postgre auf Ubuntu auf dem gleichen Rechner? Ich könnte doch direkt beides auf dem selben Host (CentOS oder Ubuntu) laufen lassen...

  2. Re: Wozu überhaupt Docker?

    Autor: RipClaw 07.01.16 - 19:16

    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------
    > Ich habe bisher nicht wirklich mit Docker gearbeitet, aber von allem was
    > ich bisher gelesen habe verstehe ich nicht, wieso man das überhaupt
    > braucht.
    >
    > Die meisten Blogs etc. argumentieren immer, warum Docker besser als andere
    > Virtuelle Maschinen sind (Xen, VMware, etc.) - und da sehe ich natürlich
    > die Vorteile. Wenn aber eine Docker Instanz aus einem einzigen Prozess
    > besteht - wieso lasse ich diesen Prozess dann nicht direkt - ohne
    > Docker/LXC abstraktion - auf dem Hostsystem laufen?

    Der Vorteil von Docker Containern ist das man eine definierte Umgebung hat. Das heißt der Entwickler kann in der gleichen Umgebung testen in der die Applikation dann letztendlich auf dem Server läuft.
    Man weiß genau welche Versionen von welchen Programmen installiert sind und das alle Abhängigkeiten erfüllt sind.

    Der Nachteil ist die zusätzliche Komplexität für den Admin in der Einrichtung und der Wartung. Sowas wie apt-get update && apt-get upgrade kann er leider vergessen.
    Bei Sicherheitsupdates müssen die Container neu gebaut werden.

  3. Re: Wozu überhaupt Docker?

    Autor: Fleshgrinder 07.01.16 - 22:01

    http://www.boycottdocker.org/

  4. Re: Wozu überhaupt Docker?

    Autor: Geistesgegenwart 07.01.16 - 22:38

    Fleshgrinder schrieb:
    --------------------------------------------------------------------------------
    > www.boycottdocker.org

    Ja, so wie dort auch steht kann debootstrap + chroot im Prinzip auch verwendet werden um ein definierten Userspace aufzusetzen. Debootstrap ist auf debian repositories limitiert, aber wenn ich für meine Software anstatt ein Dockerfile eben ein .dpkg aufsetze und das in ein apt Repo packe, sollte ich doch auch jeden beliebigen Softwarestand deployen können (inkl aller Versionen wie es mir beliebt). Klar nicht so ausgereift wie Docker, aber ich verstehe nicht wieso Kernelerweiterungen bzw. LXC auf Kernel-Level da notwendig ist.

  5. Re: Wozu überhaupt Docker?

    Autor: xUser 07.01.16 - 22:41

    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------

    > Wenn aber eine Docker Instanz aus einem einzigen Prozess
    > besteht - wieso lasse ich diesen Prozess dann nicht direkt - ohne
    > Docker/LXC abstraktion - auf dem Hostsystem laufen?
    >
    > Oft wird angeführt, das man mehrere Linuxe auf einem Host nutzen kann, aber
    > das stimmt ja so nicht direkt: Der Linuxkernel und dessen API-level ist für
    > alle Dockerinstanzen gleich, lediglich der Userspace wird vollständig
    > eingeblendet (also jeweils andere libc und bibliotheken). Aber gerade bei
    > Linux ist es doch so, dass sowieso alle (frei verfügbaren) Pakete in jeder
    > Major Distro vorhanden sind. Braucht man wirklich so oft einen JBoss auf
    > CentOs und ein Postgre auf Ubuntu auf dem gleichen Rechner? Ich könnte doch
    > direkt beides auf dem selben Host (CentOS oder Ubuntu) laufen lassen...

    Dann musst du aber bei jedem Update die Abhängigkeiten prüfen... natürlich kann man unter Linux alle Libs für jeden Prozess ein- oder ausblenden, aber mehrere unabhängige Prozesse auf dem gleichen Server garantieren Chaos.

    Im Prinzip hat man ja schon länger Server nach Applikationen gruppiert und den Webserver, die Datenbank und den Mailserver getrennt. Dazu hat man hat man dann Virtualisierung genutzt, weil sich jeder normaler physischer Server bei nur einer Aufgabe langweilt. Jetzt treibt man das ganze noch ein bisschen weiter und steckt jeden einzelnen Prozess in ein Image, welches man nicht updatet, sondern jedes mal neu baut (definierter Build-Prozess und read-only zur Vereinfachung und Zusammenführung von Administration und Entwicklung).

    Warum der Aufwand? Cloud-Computing. Jetzt kann man in der Cloud minimale Hosts mit einer definierten Kernel Version starten (nach Virtualisierung) und die eigentlichen Anwendungen kommen dann als einzelne Prozesse oben drauf, unabhängig von den Libraries das Hostsystems. Bei Bedarf kann man jetzt einzelne Prozesse von Hosts zu Host schieben (weil ja definierter Container), und somit eine höhere Auslastung über alle physischen Maschinen erreichen.

    Aufgrund der gleichen/definierten Umgebung wird das Debugging der Prozesse erheblich vereinfacht.



    1 mal bearbeitet, zuletzt am 07.01.16 22:42 durch xUser.

  6. Re: Wozu überhaupt Docker?

    Autor: Geistesgegenwart 07.01.16 - 23:08

    xUser schrieb:
    --------------------------------------------------------------------------------
    > Dann musst du aber bei jedem Update die Abhängigkeiten prüfen... natürlich
    > kann man unter Linux alle Libs für jeden Prozess ein- oder ausblenden, aber
    > mehrere unabhängige Prozesse auf dem gleichen Server garantieren Chaos.

    Ich sehe nicht wie Docker das Problem löst. Du musst selbst dafür sorgen, dass deine einzelnen Dockercontainer untereinander kompatibel sind (also z.B. Datenbankserver zum Applikationsserver passt). Zugegeben Debian ist ein schlechtes Beispiel, aber eine chroot Umgebung in einem Gentoo würde auch ausreichen um jegliche Kombinationen von Versionen untereinander zu installieren.

    Ich gebe zu, der Docker Hub und damit der Softwarefundus ist riesig, wogegen du bei Debian nur auf die Versionen aus stable/unstable/testing zugreifen kannst. Aber z.B. Homebrew auf dem Mac (wie auch die gentoo portage und die FreeBSD ports) sind nichts anderes als eine Reihe von "build recipies" mit der du Software (in beliebiger Version) aus den Quellen heraus installieren kannst. Gerade Homebrew installiert alles in eigene Verzeichnisse ("Cellars"), d.h. du kannst durchaus auch 3 mal PostgreSQL installiert haben in z.B 9.2, 9.4 und jetzt 9.5 - alles auf dem selben Host. Die können auch gleichzeitig laufen, entweder du weisst einem Host mehrere IPs zu oder auf der gleichen IP mehreren Ports.

    Ich sehe daher nach wie vor keine Notwendigkeit da Kernelsupport (LXC) vorrauszusetzen, sowas kann UNIX von Hause aus.

    >
    > Im Prinzip hat man ja schon länger Server nach Applikationen gruppiert und
    > den Webserver, die Datenbank und den Mailserver getrennt. Dazu hat man hat
    > man dann Virtualisierung genutzt, weil sich jeder normaler physischer
    > Server bei nur einer Aufgabe langweilt.

    Hm ich habe bisher eher im Webserver, Mailserver und auch Datenbank zusammen in einer VM installiert - eben als drei Prozesse die unter einem Kernel laufen. Wenn der Kernel vom Host widerverwendet werden soll um Overhead zu sparen geht das mit FreeBSD jails und OpenVZ unter Linux (zugegeben ist OpenVZ aber nicht mainline und eine schlechtere Umsetzung als Jails).

    > Jetzt treibt man das ganze noch ein
    > bisschen weiter und steckt jeden einzelnen Prozess in ein Image, welches
    > man nicht updatet, sondern jedes mal neu baut (definierter Build-Prozess
    > und read-only zur Vereinfachung und Zusammenführung von Administration und
    > Entwicklung).

    Binarys bei Homebrew oder BSD ports sind auch immer definiert und identisch, auch in verschiedenen Versionen. Das selbe würde ich jetzt mal von einem *kompletten* chroot system via Debootstrap auch behaupten (sofern identische Konfiguration).

    > Warum der Aufwand? Cloud-Computing. Jetzt kann man in der Cloud minimale
    > Hosts mit einer definierten Kernel Version starten (nach Virtualisierung)
    > und die eigentlichen Anwendungen kommen dann als einzelne Prozesse oben
    > drauf, unabhängig von den Libraries das Hostsystems. Bei Bedarf kann man
    > jetzt einzelne Prozesse von Hosts zu Host schieben (weil ja definierter
    > Container), und somit eine höhere Auslastung über alle physischen Maschinen
    > erreichen.

    Docker instanzen dürftest du nur von Host-zu-Host schieben können sofern diese runtergefahren sind, bzw. gerade keine Systemrelevanten resourcen halten (z.B. nen socket), da dieser nicht replizierbar ist. Und einen Prozess auf Maschine A zu stoppen und auf Maschine B zu starten sollte doch auch möglich sein?

    > Aufgrund der gleichen/definierten Umgebung wird das Debugging der Prozesse
    > erheblich vereinfacht.

    Das glaube ich niemals. Mit dem ehrwürdigen gdb kann ich als root-user an JEDEN Prozess im System mich dranhängen. Bei Docker muss ich über das Kernel API, also muss da Docker eine Abstraktionsschicht zum Debugging zur Verfügung stellen. Inwiefern das besser sein soll als direkt mit gdb zu attachen kann ich nicht erkennen.

    Ich gebe zu, Docker hat eine sehr gute Userexperience - die Tools sind einfach und werden schnell verstanden. Man kann sicher schnell mal eben Version XY von Anwendung Z installieren, schneller als man unter Linux das zeug zusammenkompiliert hat. Hier haben aber die UNIX/Linux maintainer mit ihren zigtausend Schaltern die Schuld. Homebrew/portage/ports verfolgen ähnliche Ansätze, sind aber komplexer zu bedienen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Acsys Lasertechnik GmbH, Mittweida
  2. Stadtwerke München GmbH, München (Home-Office möglich)
  3. AOK Rheinland/Hamburg - Die Gesundheitskasse, Düsseldorf
  4. Oberfinanzdirektion Karlsruhe, Karlsruhe

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. externe Festplatten und SSDs günstiger, Apple generalüberholt reduziert)
  2. 166,99€ (Bestpreis!)
  3. (u. a. Asus ROG Strix B450-F Gaming-Mainboard für 98,95€)
  4. 69,99€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de