Docker-Inspektion, Teil 1

Die Docker-Entstehung und -Einsatzgebiete

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Der Erfolg von Docker beruht auf Tools und APIs, die das Verwenden, Erstellen, Verteilen und Verwalten von Containern in großen Stil vereinfachen und standardisieren.
Der Erfolg von Docker beruht auf Tools und APIs, die das Verwenden, Erstellen, Verteilen und Verwalten von Containern in großen Stil vereinfachen und standardisieren. (Bild: gemeinfrei + Docker / CC0)

„Docker“ hat sich in den letzten Jahren zur Standard-Containertechnik entwickelt und bietet gegenüber anderen Virtualisierungstechnologien vor allem beim Einsatz Cloud-nativer Apps, beziehungsweise der Bereitstellung von Applikationen auf Servern on premise und in der Cloud Vorteile.

Die Container-Software Docker wurde vom Unternehmen Dotcloud initial im März 2013 veröffentlicht. Schon Ende 2013 benannte sich Dotcloud aufgrund der großen Popularität der Software in Docker Inc. um und verkaufte Anfang August 2014 seinen PaaS-Dienst Dotcloud an die Berliner Firma Cloudcontrol, um sich ganz auf Docker zu konzentrieren. (Im April 2016 übernahm das Schweizer Unternehmen Exoscale Cloudcontrol und im August 2017 die A1 digital international GmbH, eine Tochter der Telekom Austria Group, den Schweizer Cloud Anbieter Exoscale.)

Der Gründer von Dotcloud, Solomon Hykes, war bis Anfang dieses Jahres auch CTO von Docker Inc., zieht sich aber aktuell aus dem operativen Geschäft zurück. Schon vorher hatte der langjährigen CEO Ben Golub Docker verlassen, so dass das Unternehmen seine Ausrichtung mehrfach änderte. Während essentielle Docker-Technologien wie die „Docker Engine“ nach wie vor frei zugänglich und in viele externe Produkte integriert sind, fokussiert man sich derzeit ganz auf den Enterprise-Sektor und die zentrale „Container-Library“. Das Unternehmen Docker vertreibt somit eigene kommerzielle Produkte wie „Docker Desktop“ und „Docker Enterprise“.

Schneller und wackeliger Erfolg

Obwohl Docker in mehreren Finanzierungsrunden insgesamt über 320 Millionen Dollar Risikokapital eingenommen hat, halten sich seit Monaten Gerüchte einer bevorstehenden Übernahme. Denn Docker arbeite nicht selbstständig gewinnbringend.

Schon im Verlauf des Jahres 2014 hatte Docker soweit an Bekanntheit und Popularität gewonnen, dass es in die Standardrepositorien von „Red Hat Enterprise Linux 7.0“ einfloss. Auch Open Suse übernahm die Software dann in sein Software-Repertoire.

Im Juli 2014 schlossen sich die Firmen Microsoft, Red Hat, IBM, Docker, Mesosphere, CoreOS und Saltstack dem von Google initiierten „Kubernetes“-Projekt an - mit dem Ziel, Docker-Container auf sämtlichen privaten, öffentlichen und Hybrid-Cloud-Umgebungen bereitstellen zu können. Docker verwendet seit der Version 1.0 die beiden offiziellen von der IANA zugewiesenen Port-Nummern 2375 für HTTP- und 2376 für HTTPS-Kommunikation.

Docker ist eigentlich keine eigenständige Virtualisierungs- oder Container-Technologie sondern eine Art Framework mit Tools und APIs, die das Verwenden, Erstellen, Verteilen und Verwalten von Containern in großen Stil vereinfachen beziehungsweise standardisieren. Docker setzte dazu ursprünglich auf bestehende Container-Technologien wie „LXC“ auf, verfügt inzwischen aber über eine eigene Container-Engine.

Alle Container können ....

Container gehören im Umfeld konkurrierender Virtualisierungsansätze zur Kategorie Betriebssystemvirtualisierung, im Gegensatz zur Vollvirtualisierung oder Paravirtualisierung. Die Virtualisierung auf Betriebssystemebene stellt den auszuführenden Applikationen die von diesen benötigen Laufzeitumgebungen virtuell innerhalb eines geschlossenen Containers zur Verfügung.

Entsprechende Konzepte sind in der Informatik seit Langem bekannt und werden auch mehr oder weniger komfortabel verwendet, etwa in „BSD Jails“ oder „Solaris Zones“. Für die auf dieser Weise isoliert startbaren Applikationen wird im Gegensatz zur Vollvirtualisierung kein eigenes Betriebssystem bereitgestellt und auch keine emulierte oder virtualisierte Hardware.

Bei der Betriebssystemvirtualisierung per Container ist es durchaus möglich, verschiedene Betriebssysteme oder verschiedene Versionen desselben Betriebssystems gleichzeitig als Gastbetriebssysteme zu betreiben.
Bei der Betriebssystemvirtualisierung per Container ist es durchaus möglich, verschiedene Betriebssysteme oder verschiedene Versionen desselben Betriebssystems gleichzeitig als Gastbetriebssysteme zu betreiben. (Bild: gemeinfrei / CC0)

Daher ist es bei der Betriebssystemvirtualisierung (Container) auch nicht unmöglich, verschiedene Betriebssysteme oder verschiedene Versionen desselben Betriebssystems gleichzeitig als Gastbetriebssysteme zu betreiben. Auch lassen sich in Containern prinzipiell keine Treiber laden.

Container machen Apps portabel

Der einzige Unterschied zum nativen parallelen Ausführen mehrerer Applikationen auf einem Server (App-Konsolidierung) besteht darin, dass jede Applikation im Container ihre eigene Laufzeitumgebung sieht und nutzt. Das macht die App portabel und die Bereitstellung mehrerer Apps in einer vorhandenen Umgebung sicherer.

Durch den Verzicht auf einen Hypervisor ist Containertechnik zudem besonders effizient im Umgang mit Ressourcen, in Bezug auf Prozessor-Last und beim Bedarf an Haupt- und Massenspeicher. Denn bei der Betriebssystemvirtualisierung ist immer nur ein Kernel, nämlich der Host-Kernel aktiv - im Unterschied etwa zu User Mode Linux (UML).

Der Aspekt der Portabilität ist dabei eine der wichtigsten der genannten Eigenschaften. Stellt man eine Applikation wie einen Web-Server auf einem klassischen Unix-System bereit, verteilen sich seine Dateien über das ganze Dateisystem des Hosts.

Fluffig und sicher

Ein anderes Problem, dass Container lösen, besteht im Auflösen beziehungsweise Erfüllen von Abhängigkeiten (Portabilität). Je nachdem in welcher Umgebung, mit welchen Tools und welchen Versionen zum Beispiel ein Web-Server „gebaut“ wurde, läuft er nicht ohne erheblichen Aufwand auf jedem System und ist damit im Cloud-Computing nicht zu gebrauchen.

Das untermauert das inzwischen berühmte Zitat von Solomon Hykes: „Shipping code to the server is hard.“ Vollvirtualisierung mit Hypervisor würde das Problem zwar lösen, ist aber viel zu schwergewichtig für Cloud-native Ansätze und Microservice-Architekturen.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

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.
Kommentar abschicken
copyright

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