Login
Newsletter
Werbung

Thema: Linux Containers: LXC in Version 2.1 freigegeben

4 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Warum am Fr, 8. September 2017 um 15:26 #

Warum sollte man LXC statt Docker verwenden?

Docker scheint einige Vorteile zu haben. Z.B:
- Verbreitet sich rasant.
- Docker Hub: 100,000+ free apps, public and private registries (https://hub.docker.com/)

  • 0
    Von Lyq am Fr, 8. September 2017 um 15:41 #

    Weil Docker und LXC unterschiedliche Probleme lösen?
    Docker hat sicher seine Berechtigung, aber ein Ersatz für LXC ist es nicht.

    • 0
      Von Potz Blitz am Mo, 11. September 2017 um 12:26 #

      Die Frage, was wofür gut ist, würde mich auch interessieren.

      Wenn ich es richtig verstehe, hat LXC Vorteile, wenn man einen Container in dem bestimmte Anwendungen laufen selber bauen will. Docker wird dagegen gewählt, wenn man einen fertigen Container mit meist nur einer Anwendung beziehen will.

      Habe ich das so richtig beschrieben?

      • 0
        Von gj am Fr, 16. März 2018 um 12:02 #

        Das beschreibt ganz gut die zwei unterschiedlichen Anwendungsmodelle und auch meiner Ansicht liegt der Fokus der beiden Projekte jeweils mehr auf der einen Seite wobei sie technisch weitgehend auch das jeweils andere Szenario bedienen können.

        Ich würde den Hauptunterschied darin sehen, was man unter einem "Container" versteht: Bei Docker liegt der Fokus auf der Virtualisierung eines (einzigen) Unix-Prozesses, der quasi mit einer zeitgemäßen Version eines chroot betrieben wird. Über das Dateisystem hinaus wird auch der Zugriff auf möglichst viele andere Resourcen kontrolliert eingeschränkt. Um die für eine Applikation nötige Linux-Umgebung bereit zu stellen, werden (mittels eines Overlay-FS-Treibers) in der Regel mehrere Schichten übereinandergelegt: Z.B. das Dateisystem-Image eines "minimales" Linux und das einer Applikation. Diese Images werden in Repositories bereitgestellt wobei vermerkt ist, welche "Unterfütterung" jeweils erwartet wird. Die einzelnen Images werden in der Regel automatisch von einem Build-Tools mittels eines "Rezepts" erstellt, das die nötigen Schritte beschreibt. Auch auf der obersten Ebene wird man die Konfiguration der Anwendung an den Einsatzzweck durch ein solches Rezept beschreiben.

        Auf diese Weise kann man theoretisch seine Infrastruktur jederzeit anhand dieser Rezepte neu aufbauen, z.B. um Updates durchzuführen. Jedenfalls so lange, wie es keine Kompatibilitätsprobleme bei neuen Versionen der Komponenten und auch der ganzen Build-Umgebung gibt. Wenn man jeden Tag viele Container aufbaut und wieder einstampft, ist der Return-On-Invest entsprechend hoch.

        Wenn man bei einem "Container" eher an einen virtualisierten Rechner denkt, dann ist man näher an der Sichtweise von LXC. Auch hier kann man einzelne Applikations-Prozesse in einer definierten Umgebung starten, aber im Fokus steht eher dass man den init-Prozess einer Linux-Distribution startet, wozu nahezu unverändert die nomalen Installationsquellen benutzt werden. Es entsteht also eine Virtualisierung auf Operating-System-Ebene; dem Userland-Teil wird ein Kernel sowie eine kontrollierte Auswahl von Resourcen präsentiert. Man arbeitet mit diesem virtuellen Rechner dann "wie gewohnt", d.h. mal logt sich entweder auf einer virtuellen Konsole oder über ssh ein und installiert und administriert dann auf beliebige Art und Weise, z.B. auch per Hand. Man kann Resourcen auf verschiedenen Ebenen übergeben: Man z.B. kann einen Datei-System-Ast per "bind-mount" zur Verfügung stellen. Man kann aber auch den Zugriff auf ein Block-Device hereinreichen und das Linux im Container betreibt den Dateisystem-Treiber. Ein Netzwerk kann man über virtuelle Netzwerkkarten ankoppeln oder über die Zugriffserlaubnis auf physikalische Netzwerkkarten des Hosts. Auch für andere Resourcen wie Video, Audio etc. kann man sowohl eine Virtualisierung als auch eine "Physikalisierung" erreichen. Je höher abstrahiert die Resourcen sind, desto leichter fällt der "Transport" eines solchen Containers auf einen anderen Host.

        Wenn man schon bestehende "Rechner" (bare metall oder schon voll-virtualisiert) in einer leichtgewichtigen Virtualisierung überführen will, dann passt LXC vermutlich besser. Denn sobald man die Konfiguration der benötigten Resourcen definiert und eingerichtet hat sollte man die bestehende Installation weitgehend übernehmen können. Denn ab dem Punkt wo beim Booten der "Runlevel 3" erreicht wird, bleibt beim Betrieb im LX-Container alles unverändert gegenüber vorher.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung