Docker Container Keiner kommt an Container-Technik, also Docker, vorbei
Seit 2013 spielt die Container-Technik „Docker“ IT-Abteilungen, IT-Manager und die Analysten schwindelig. Zeit für eine Bestandsaufnahme: Wie weit sind Docker-Container tatsächlich in der Realität der Unternehmens-IT angekommen?
Anbieter zum Thema
Container-Technologien etwa von Docker oder CoreOS können Unternehmen darin unterstützen, Services zu flexibilisieren und schneller bereitzustellen. Das ist der Hauptgrund, warum sich CTO CEOs und SysOps-Teams im Unternehmen heute für Container begeistern. Docker steht aber ursprünglich in einer anderen Historie und dominiert noch längst nicht die App-Bereitstellung.
Erwartungen an die Container-Technik
Knapp drei Jahre sind seit dem ersten Release von Docker, das in 2013 noch von der dotCloud Inc. initiiert wurde, vergangen. Im Oktober des gleichen Jahres firmierte die dotCloud Inc. im Erfolgssog von Docker in Docker Inc. um und widmet sich seitdem ausschließlich der Weiterentwicklung von Docker sowie dem Ausbau des Docker-Ökosystems. Wohl kaum eine andere Open-Source-Technologie hat in den letzten Jahren in so kurzer Zeit so rasant verbreitet und Popularität gewonnen.
Der phänomenale Erfolg von Docker, beziehungsweise der Betriebssystem-Virtualisierung ist nicht nur aus wirtschaftlicher Sicht bemerkenswert, schaut man etwa auf die rund 120 Millionen US-Dollar Venture-Kapital, die bis heute in die Docker Inc. geflossen sind. Die sind vorrangig ein Indiz für die enorme Erwartungshaltung, welche die Branche mit der Verbreitung der Container-Technologie verbindet. Nicht selten klafft aber bei derart gehypten Technologien eine Lücke zwischen Erwartung und Realität.
Mitreden
Bei Docker beziehungsweise Containern ist es aber in der Tat so, dass sich nahezu jedes größere Unternehmen heute mit der Einführung von Container-Technologie – sei es nun Docker oder ein Konkurrenz-Produkt – in irgendeiner Form auseinandersetzt. Bei vielen CTOs stehen Container ganz oben auf der Agenda. Dabei geht es vor allem um die Optimierung von Geschäftsprozessen, auch wenn Container-Technologie in der Realität meist eher „von unten“, also durch Mitarbeiter, vor allem Entwickler ihren Weg in die Unternehmen findet.
Warum? Container-Technologien erlauben es Entwicklern, sich quasi auf Knopfdruck „Umgebungen“ zu verschaffen, für deren Bereitstellung sie sonst im Unternehmen nicht nur langwierige Genehmigungs- und Beschaffungsprozesse durchlaufen, sondern auch die erforderlichen Voraussetzungen hinsichtlich Hard- und Software schaffen müssten.
Durch das Verwenden vorgefertigter Container-Umgebungen, idealerweise direkt auf dem eigenen Notebook müssen Entwickler im Idealfall nicht einmal irgendjemanden fragen. Sicher hätten sie das mit Hilfe von LXC & Co auch schon früher tun können, allerdings vereinfacht Docker das Schnüren und Bereitstellen von Containern mit standardisierten Tools, Verfahren und API erheblich.
An sich nicht neu
Dass Container-Technologie auch schon 2013 nicht neu war, hat sich inzwischen sogar bei Analysten, Beratern und Nicht-Technikern herumgesprochen. Schaut man nur auf den Kern der Technik ist die Sache einfach: Unter Containern versteht man eine komplette Laufzeitumgebung, die in einem einzigen Paket bereitgestellt wird. Das kann wahlweise eine komplette Betriebssystemumgebung für sich oder nur eine einzelne Anwendung sein, die aber Ihr gesamtes Ökosystem an Abhängigkeiten, Bibliotheken, Dateien und Konfigurationsdaten mitbringt. So nutzen Hoster und Provider schon lange vor Docker Betriebssystemvirtualisierung in Form von Technologien und Produkten wie „Linux Container“ (LXC) oder „Parallels Virtouzzo“/“OpenVZ“, etwa zum Bereitstellen von Linux-basierten virtuellen Servern.
Container versus VMs
Container haben zunächst den Vorteil, dass sie im Vergleich zu virtuellen Maschinen (VMs) deutlich kompakter sind. Vergegenwärtigt man sich, dass in der Praxis virtuelle Maschinen häufig als Laufzeitumgebung für eine Anwendung zum Einsatz kommen, ist die Idee auf eine Container-Strategie zu wechseln nachvollziehbar. Immerhin beansprucht jede VM samt der darin laufenden Anwendungen ein vollständiges Betriebssystem; bei Containern hingegen teilen sich sämtlicher Container einen Betriebssystemkern mit anderen Containern.
Daher verbrauchen Container weniger Rechenleistung und Speicherplatz. Die verwendete Container-Technologie muss lediglich für eine ausreichend sichere Isolierung der einzelnen Container voneinander sorgen. Dieser Punkt ist nicht nur objektiv enorm wichtig, sondern im Hinblick auf die Integration von Containern mit mandantenfähigen Cloud-Umgebungen auch ein subjektives KO-Kriterium für die Enterprise-Tauglichkeit von Containern.
Was macht Docker anders?
Was aber zeichnet Docker aus und warum tut seit 2013 alle Welt so, als hätte das Team um Co Founder Solomon Hykes und CEO Ben Golub den Stein der Weisen gefunden? Als Vorabfazit lässt sich festhalten, dass die Docker Inc. einerseits zur rechten Zeit am rechten Platz war. Zudem wird die Verwendbarkeit von Containern durch eigene Container-Formate sowie APIs praktisch standardisiert. Im Endeffekt lassen sich mit Docker Container viel einfacher und schneller nutzen, als mit LCX oder OpenVZ.
Docker ist gilt zudem sicherer als etwa Virtuozzo oder OpenVZ. Daran haben Technologien aus den Linux-Kernel wie „cgroups“ und „namespaces“ großen Anteil. Docker verwendet diese Eigenschaften, um Ressourcen wie Prozessor, Arbeitsspeicher Netzwerk oder Block-Geräte voneinander zu isolieren, die ja vom gleichen Kernel bereitgestellt werden. Echte Isolation im Sinne von Schutz wird dagegen erst mit „SELinux“ oder „AppArmor“ erreicht.
Container sind also mitnichten ähnlich sicher, wie VMs, auch wenn das von Container-Herstellern mitunter behauptet wird. Während zum Beispiel Angriffspfade mit VMs „nur” eine Verwundbarkeit in einer von 32 Kernel-Syscalls (Hypervisor Schnittstelle) finden und ausnutzen müssten, sind es bei Containern (also im Prinzip bei Prozessen) mehr als 300 Syscalls, von denen einer verwundbar sein muss.
Sicher oder nicht
Trotzdem erlauben es Container, dass sich Applikationen im Prinzip vollständig von der jeweiligen Umgebung trennen, einschließlich der Prozesse, Dateisysteme und des Netzwerks. Sie lassen sich damit autonom einsetzen. Allerdings kann cgroups nur die Ressourcen begrenzen oder priorisieren, die ein Prozess/Container nutzt, hilft aber nicht beim so genannten „Noisy Neighbour Problem“.
Der Ausdruck beschreibt das in Cloud-Computing-Infrastrukturen bekannte Problem, dass jeder Co-Tenant theoretisch die verfügbaren Netzwerkbandbreiten, den Disk-I/O oder CPU-Ressourcen kannibalisieren kann, zu Lasten anderer Tenants. Namespaces dagegen dienen der Reduzierung der Sichtbarkeit von Komponenten oder OS-Objekten. So „sieht“ sich ein Container nur selbst und keine anderen Prozesse des Hosts.
In den frühen Releases basierte Docker im Kern noch direkt auf LXC. Inzwischen hat Docker eine eigene Container-Engine. LXC oder Virtuozzo dagegen haben außerhalb des Hostings-Umfelds nie eine vergleichbare Popularität und Verbreitung erlangt.
Das passende Ökosystem
Docker ist zudem zu einem Zeitpunkt auf der Bildfläche erschienen, als sich abzeichnete, dass die Einsetzbarkeit von Containern, etwa als Fundament für Cloud-native Apps weit über das Hosting-Umfeld hinausgeht. Die Docker-Entwickler haben zudem früh erkannt, dass sich nicht nur mit dem Bereitstellen der entsprechenden Technologie Geld verdienen lässt, sondern auch mit dem Etablieren eines Ökosystems an Tools und Frameworks mit einem Container-Marketplace im Zentrum.
Docker selbst wird auch nicht müde zu betonen, die Verwendbarkeit von Containern mit seinen Standardisierungsbemühungen erheblich vereinfacht zu haben. Ein wie auch immer gearteter Container-Standard erleichtert es Unternehmen, einmal geschnürte Container über Betriebssystem- und Cloud-Grenzen hinweg weitergeben können.
Standards
Dies ist aber nur die halbe Wahrheit. Faktisch ist Docker kein abgestimmter Standard, sondern eher ein defacto Standard, den Docker als Firma gerne vorgeben würde. Ein Container-Standard hingegen, an dem zahlreiche Firmen übergreifend arbeiten, ist die Open Container Initiative (OCI).
In der Vision von Docker sind nämlich noch viele Fragen ungeklärt. Um zum Beispiel produktive Business-Workloads laufen zu lassen, muss unter anderem auch die Möglichkeit des Support gewährleistet sein. Steckt beispielsweise in einem Image ein Betriebssystem A vom Hersteller B, muss Hersteller B auch für den Betrieb auf Z seine Support-Freigabe geben.
Und auch die Portabilität hat ihren praktischen Grenzen. Theoretisch muss zwar auf der Zielplattform nur eine Docker-Engine vorhanden sein, was mit nahezu jedem Linux-System der Fall ist, allerdings verändert sich auch Docker selbst mit jeder Docker-Version derzeit noch sehr stark. Am Zielsystem muss also eine jeweils passende Docker Version vorhanden sein. Trotzdem gehört die Portierbarkeit zu den wichtigsten Eigenschaften und ist neben dem Ökosystem aus Container-Management-Werkzeugen und Container-Marktplatz einer der Schlüsselfaktoren für die den Einsatz, sofern Portablilität und Support/Zertifizierung für Enterprise Kunden Hand in Hand gehen.
Docker und die Cloud
Trotzdem kann auch die Portierbarkeit allein nicht erklären, warum Investoren binnen drei Jahren Hunderte Millionen Dollar in ein Startup pumpen, das lediglich eine schon lange bekannte Technologie besser handhabbar gemacht hat. Ein Grund ist, dass Docker schlicht zur richtigen Zeit verfügbar war.
Nachdem mittlere und große Unternehmen die Konsolidierung ihrer Rechenzentrumsinfrastruktur auf virtuelle Server abgeschlossen haben, Server-Virtualisierung also Business-as-usal ist, geht es für die meisten Organisationen in der zweiten Stufe der Transformation ihrer IT-Prozesse. Das geht einher mit der Frage, ob Desktop-Virtualisierung oder Server-based-Computing die logische Konsequenz auf dem Weg zu einer Self-Service-gesteuerten Verdienstleistung ihrer IT sind oder nur ein Zwischenschritt in die Cloud, sei es nun SaaS, IaaS oder PaaS.
Auf jeden Fall erscheint Enterprise-Containertechnik zu einem Zeitpunkt auf der Bildfläche, zu dem Cloud-Technologien nicht nur hinsichtlich der notwendigen Backbone-Infrastruktur (etwa Bandbreitenverfügbarkeit und Kosten), sondern auch hinsichtlich der Service-Modelle als ausgereift gelten und in großem Variantenreichtum verfügbar sind. So ist der Weg zu Cloud-nativen Apps nicht mehr weit, bei denen Container ihre Stärken ausspielen können - sofern Container-Entwickler einen Weg finden, auch statusbehaftete Apps in Container zu verfrachten.
Derzeit müssen Cloud-native Apps zur Containerisierung in der Regel neu geschrieben werden, während es persistenter Storage heute auch Non-cloud-nativen Apps (Stateful Apps) erlaubt, in Containern zu laufen. An persistenten Storage war in der Anfangszeit von OpenStack und anderen Cloud-Systemen gar nicht zu denken.
Container-Ökosysteme
So ist Docker heute auch weit mehr als nur Plattform für das Deployment von Applikationen auf Basis von Containern. Docker war Initialfunke für eine beispiellose Dynamik in der Open-Source-Community, in der binnen kurzer Zeit ein riesiges Ökosystem aus Werkzeugen und Lösungen rund um Docker und Container-Technologie entstanden ist, wie Management-Frameworks, Benutzeroberflächen, App-Markplätze und Monitoring-Tools. Trotzdem ist Docker heute nicht konkurrenzlos. Das liegt daran, dass Docker neben den geschilderten weitere Schwachstellen aufweist und auch noch nicht alle Anwendungsgebiete ausgereizt sind.
Integration
Eines der früheren Probleme von Docker, die Gewährleistung der Vertrauenswürdigkeit von Containern im Kontext der Container-Herkunft, darf zwar mit der seit gut einem halben Jahr verfügbaren „Trusted Registry“-Technik zusammen mit unterschriebenen Containern als gelöst gelten, die Integration mit bestehenden führenden Infrastruktur-Umgebungen wirft aber noch Fragen auf.
Noch nicht zufriedenstellend gelöst sind beispielsweise die Auswertung von Log-Dateien, die Integration ins Monitoring, Recovery-Konzepte für den Ernstfall (Backup / Restore), die Einbindung in eine Configuration Management Database (CMDB), in ein Software Lifecycle Management oder Patching. Immerhin lässt sich Docker schon heute mit mehr oder weniger Aufwand mit Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, IBM Bluemix, OpenStack Nova, Puppet, Salt, Chef oder Red Hat Ansible integrieren.
Docker und die PaaS
Zudem harmoniert Docker auch mit Platform-as-a-Service-(PaaS-)-Umgebungen wie Cloud Foundry oder Apprenda, sowie mit anderen Container-Plattformen wie „Red Hat Openshift Origin“. Hierbei darf man aber nicht übersehen, dass entsprechende Initiativen nicht von Docker ausgehen. Support bieten die Hersteller der jeweiligen Lösung.
Docker ist und bleibt eine Open-Core-Company, deren Open Core von anderen Herstellern in ihrer Software verwendet wird. Die vielfältigen Verknüpfungspunkte machen aber deutlich, dass gemeinsame Standards für Container-Formate und Laufzeitumgebungen äußerst wichtig sind.
So wurde beispielsweise schon 2015 unter dem Dach der Linux Foundation die Open Container Initiative (OCI) ins Leben gerufen, ein Konsortium sämtlicher Technologieführer der digitalen Gesellschaft, wie Red Hat, AWS, Google, Mesosphere, Pivotal, Cisco, IBM, Microsoft, Intel, Oracle und VMware. Die Initiative hat zum Ziel, gemeinsame Standards zu etablieren und konkurrierende Entwicklungen wie zum Beispiel „CoreOS“/ „Rocket“ einzufangen und kompatibel zu halten.
Microservice-Architekturen und Cloud-natives Development
Relativ spät dagegen hat sich Docker der Orchestrierung von Containern zugewandt, die unter anderem eine wichtige Rolle bei der Skalierung von auf mehreren Containern basierenden Apps und Services spielt. Erst 2015 hatte Docker dazu eigenen Lösungen, wie „Machine“, „Swarm“ und „Compose“ vorgestellt, obwohl zum Beispiel das Orchestrierungswerkzeug „Google Kubernetes“ zu diesem Zeitpunkt bereits weit fortgeschritten war. Dass sich die Container-Technologie hervorragend für Microservice-Architekturen nutzen lässt oder als Fundament für das Cloud-native App-Deployment, haben auch Unternehmen wie Red Hat früh erkannt (siehe: Container-Technik von Red Hat).
*Der Autor
Thomas Drilling ist freie IT-Fachjournalist und Berater. Auf DataCenter-Insider schreibt er seinen eigenen Blog: „Drillings Open-Source-Eck“
Artikelfiles und Artikellinks
(ID:44418859)
