Docker-Einführung, Teil 1

Container – Idee, Architektur und Use Cases

| Autor / Redakteur: Thomas Drilling / Stephan Augsten

Wo genau bei Docker der Unterschied zwischen Containern und Images liegt, wollen wir uns in diesem Workshop-Teil ansehen.
Wo genau bei Docker der Unterschied zwischen Containern und Images liegt, wollen wir uns in diesem Workshop-Teil ansehen. (Bild: Docker)

Rund um Docker hat sich ein breites Ökosystem an Lösungen von der eigenen Container-Engine bis zur Orchestrierung von Container-Clustern entwickelt. Im ersten Teil unserer Docker-Serie befassen wir uns mit den Vorzügen von Containern im Allgemeinen.

Die meisten IT-Administratoren und Spezialisten kennen das. Man stolpert beinahe wöchentlich über neue IT-Trends und Themen, bei denen man das Gefühl hat, dass wieder mal eine neue Sau durchs Dorf getrieben. Der betreffende Hype werde sich entweder zeitnahe wieder legen oder schlimmstenfalls als alter Wein in neuen Schläuchen entpuppen.

Das unbestimmte Gefühl verführt dann meist dazu, auf dem status quo des bisherigen IT-Know-hows zu verharren; denn nicht nur der Mensch im Allgemeinen, sondern vor allem auch der IT-Admins im Besonderen gilt eher als träge. Daraufhin wird das fortlaufenden Medien-Bombardement z. B. zu Docker erstmal für ein paar Monate ignoriert und in der öffentlichen Diskussion vertritt man standhaft weiter seine traditionelle Sichtweise.

Dabei ist gerade der IT Administrator mehr als jeder andere an IT-Technologie Interessierte in der Pflicht, neue Entwicklungen zwar durchaus kritisch zu hinterfragen, sie aber ab einem Zeitpunkt x auch zu evaluieren und bei Erfolg zu adaptieren. Das Erkennen dieses Zeitpunktes beschäftigt IT-Administratoren häufig ein Leben lang und ist ein schwieriger Prozess, insbesondere wenn Technologien wie Cloud Computing, Big Data, IoT und Container offensichtlich auch weitreichende gesellschaftspolitische und soziale Konsequenzen haben.

Apps für Server

Viele Admins geht es sogar mit Containern. Vor fünf Jahren als alter Hut abgetan, finden sich IT-Spezialisten z. B. nach einem Jobwechsel oder in einem neuen Projekt (Freelancer) schnell in der Situation wieder, dass sich bestimmte Technologien im Verlauf der eigenen Trägheitsphase eben doch von der trendigen Nischenlösung zum De-facto-Standard gemausert haben.

Trotzdem müssen wir für die folgenden Teile unserer Docker-Einführung nicht bei Adam und Eva anfangen, da die meisten IT Administratoren in etwa wissen, was Container sind und wie sie sich beispielsweise von VMs unterscheiden. Zudem ist es auch nicht schwierig, einzelne Docker-Container auf einem Docker-Host zum Laufen zu bekommen.

Schließlich wurde Docker ja gerade dazu konzipiert, die Verwendung von im Linux-Kernel vorhandener Container-Technik wie Linux Containers, cgroups, namespaces und capabilities besonders einfach zu gestalten. Inspiriert wurde dies durch schon seit Jahrzehnten bekannten Technologien aus der Unix-Welt wie Solaris Zones oder BSD Jails.

Wozu Container-Technik?

Die eben genannten Formen der Virtualisierung hatten und haben primär zum Ziel, Prozesse auf iX-Systemen voneinander und vom root-System zu isolieren. Stellt man beispielsweise einen Webserver als Gastanwendung auf einem klassischen Unix-System bereit, verteilen sich nicht nur dessen Dateien (und Abhängigkeiten) querbeet über das Dateisystem des Hosts mit reichlich Konfliktpotenzial. Der Prozess des Webservers selbst ist dann auch nur einer von vielen in der Prozess-Hierarchie des Hosts und in keiner Weise von anderen Host-Ressource isoliert.

Der Unterschied zwischen einer Virtuellen Maschine und einem Container.
Der Unterschied zwischen einer Virtuellen Maschine und einem Container. (Bild: Drilling)

Gerade bei einem öffentlich erreichbaren Webserver stellt dies ein Sicherheitsproblem dar. Das ist auch der Grund dafür, dass man moderne Applikationen in der Regel jeweils auf einem eigenen Server bereitstellt. Das Problem etwaiger Ressourcen-Verschwendung auf dem Host wird dabei zuverlässig z. B. durch Virtualisierungstechnik gelöst, wobei allerdings die erzielbare „Packdichte“ bei virtuellen Maschinen (1:10) weit unter dem Wert liegt, der mit leichtgewichtigen Containern möglich ist.

Es ist also (soweit noch nicht geschehen) allerhöchste Eisenbahn, sich selbst Container-technisch auf den aktuellen Wissensstand zu bringen. Nicht wenige Administratoren werden sogar feststellen, dass solch einfache Use Cases wie das Bereitstellen von Apps auf einzelnen Container-Hosts, häufig initial von Entwicklern adoptiert und praktiziert, in vielen Unternehmen schon längst verdrängt wurden.

Thematisch sind wir mit PaaS, Microservices, Cloud-native Apps und Container-Orchestration im Allgemeinen schon viel weiter; allesamt Technologien, die bei vielen Public-Cloud-Anbietern still und leise zur Service-Grundlage mutiert sind – auch in Kombination. Nutzt man beispielsweise in AWS ein Machine-Learning-Framework wie Sagemaker, wird der benötigte Computer-Cluster zwar auf Basis von Jupiter-Notebook-Instanzen betrieben, die einzelnen Algorithmen werden allerdings über Container provisioniert.

Fassen wir das Ergebnis über den Sinn und Zweck von Containern schon vorweg zusammen, sind folgende Eigenschaften für Container (speziell Docker-Container) essenziell und werden in den folgenden Teilen aufgeschlüsselt: Die Prozess-Isolation sorgt für eine zuverlässige Customer-Segregation, während das Konzept der Images sich für die Portabilität von Docker-Containern verantwortlich zeichnet. Der im Vergleich zu VMs wesentlich geringere Ressourcenverbrauch sorgt derweil für eine hohe Packungsdichte bei der Server-/Apps-Konsolidierung.

Dies resultiert in den folgenden vier Vorteilen des Einsatzes von Docker zum Bereitstellen von Apps auf Servern, egal ob manuell oder in einer Deployment-Pipeline:

  • 1. Flexibilität
  • 2. Portabilität
  • 3. Performance
  • 4. Effizienz

Prozess-Isolation

Die durch Container-Technik ermöglichte Kapselung der Runtime bei der Bereitstellung von Applikationen gehört zu den wichtigsten Eigenschaften von Containern. Bekräftigt wird dies durch das inzwischen nahezu berühmte Zitat von Solomon Hykes, CTO & Founder von Docker: „Shipping code to the server is hard.“ Und damit hat er Recht.

Schaut man sich heutige Applikationen an, so bestehen diese nicht mehr nur aus einem einzigen Binary, das man einfach auf den Server kopiert. Eine komplette Anwendung besteht aus einer Vielzahl unterschiedlicher Module, Services (etwa Webserver), Microservices, Bibliotheken, Datenbanken, Laufzeitumgebungen und vielem mehr.

Container sind allgemein eine Technik, um Prozesse auf einem Server (Container-Host) voneinander zu isolieren. Steckt man so eine Applikation mit allen ihren oben geschilderten Abhängigkeiten und Eigenschaften in einen Container, „sieht“ dieses Programm nur noch einen ganz kleinen Ausschnitt des Dateisystems. Ihm wird vorgegaukelt, es liefe alleine im System, beispielsweise sieht es nur die Prozesse, die im eigenen Container laufen.

Die Prozesshierarchie innerhalb eines Containers.
Die Prozesshierarchie innerhalb eines Containers. (Bild: Drilling)

Die Separierung/Abkapselung erfolgt dabei weder auf Hypervisor-Ebene wie bei einer virtuellen Maschine noch im Container selbst, sondern im Kernel des Host-Betriebssystems. Somit hat der Container aus seinem „Inneren“ heraus quasi keine Möglichkeit festzustellen, dass er ein Container ist, weil die abgeleitete Prozess-Hierarchie ganz normal mit der PID 1 für den Init-Prozess „/sbin/init“ beginnt. Neben dem Teilen des Host-Betriebssystems haben einzelne Container zusätzlich auch die Möglichkeit, sich einzelne Libraries zu teilen.

Performance bei Containern

Dies führt zu einer weiteren Reduzierung des gesamten Overheads mit dem Ergebnis, dass Container im Vergleich zu VMs sehr viel schneller starten, in der Regel im Bereich von Sekunden statt Minuten, was das dem Entwickeln agiler, skalierbarer Architekturen förderlich ist. Das Starten eines Containers ist damit nicht viel aufwändiger, als das Starten eines Prozesses in einem Linux-System.

Neben der kürzeren Startzeit profitieren Container zudem von einer besseren Performance, da keine virtuelle Hardware emuliert werden muss. Allerdings entfällt damit auch der Vorteil von VMs, einer direkten Kapselung auf Hypervisor-Ebene; das Ressourcen-Sharing auf Linux-Kernel-Ebene mit Hilfe von Technologien wie namespace und cgroups gilt allgemein als weniger sicher.

Trotzdem ist prinzipiell jeder Container sein eigenes abgeschlossenes System mit eigenem Root-Filesysten, eigener Prozessen-Hierarchie, eigenem Memory, eigenes Devices und falls gewünscht eigenen Netzwerk-Ports. Bei Bedarf kann der Nutzer auch externen Storage in jeden Container hinein mounten und nutzen.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45408991 / Container & Virtualisierung)