OpenShift vs. Docker

Docker führte den Siegeszug der Container-basierten Virtualisierung herbei. Die Software ist eine grundlegende Technologie zum Erzeugen und Ausführen von Anwendungs-Containern. Docker wird zum Beispiel von einzelnen Entwicklern auf dem eigenen Laptop eingesetzt, um Entwicklungs-Workflows zu standardisieren. OpenShift spielt am anderen Ende des Virtualisierungs-Spektrums und deckt die operativen Anforderungen einer ganzen Organisation ab. Als Grundlage kommen öffentliche und private Cloud-Umgebungen zum Einsatz.

Die beiden Technologien sind keinesfalls direkte Konkurrenten. In der Tat basierte OpenShift früher indirekt auf Docker und nutzt bis heute das Docker-Containerformat. Wir geben einen Überblick und gehen auf die Stärken und Schwächen sowie jeweilige Einsatzszenarien ein.

In Online-Diskussionen oder Blogbeiträgen stößt man immer wieder auf die Fragestellung: „OpenShift vs. Docker — was ist das bessere Tool für Container-Virtualisierung?“ Auch wenn die Frage oft gestellt wird, handelt es sich um weit auseinander liegende Technologien. Sowohl OpenShift als auch Docker haben ihre Daseinsberechtigung und werden für gewöhnlich komplementär eingesetzt.

OpenShift- und Docker-Technologien zu vergleichen, ist in etwa so, als fragten wir: „Was ist besser, ein Auto oder ein öffentliches Nahverkehrssystem?“ Prinzipiell haben beide eine ähnliche Aufgabe: Personen und Güter zwischen Orten bewegen. Auch Räder sind bei beiden Technologien vorhanden. Jedoch handelt es sich um komplett unterschiedliche Größenordnungen.

Im Gegensatz zu physischen Containern handelt es sich beim virtuellen Pendant nicht primär um eine Transporttechnologie. Bedienen wir uns zum besseren Verständnis einer biologischen Analogie. Denn Anwendungs-Container und biologische Zelle haben viel gemeinsam. Es handelt sich bei beiden um eine in sich gekapselte, nach außen abgeschlossene, grundlegende Einheit „lebendig“ gewordener Information.

In der belebten Welt vollzog sich die Evolution vom Einzeller zum mehrzelligen Organismus. Und gleichermaßen stellte sich im Virtuellen die Entwicklung vom einzelnen Container zu orchestrierten Verbünden miteinander interagierender Container ein. Auch die mit der Mehrzelligkeit einhergehenden Herausforderungen sind ähnlich zu denen, welche sich aus dem Zusammenspiel mehrerer Container ergeben.

Biologische Zellen und Anwendungs-Container müssen miteinander kommunizieren. Je nach Bedarf müssen sie nachwachsen bzw. absterben. Die insgesamt zur Verfügung stehende Ressourcen müssen auf die einzelnen Einheiten aufgeteilt werden. All dies sollte wohl koordiniert sein, damit das Gesamtsystem auf sich wechselnde Anforderungen reagieren kann und dabei auf Dauer stabil bleibt. Veranschaulichen wir uns die Spannbreite der Container-Virtualisierung von Docker bis OpenShift an der folgenden Übersicht:

Wir sehen: Die Frage, was besser ist, lässt sich nur unter Hinzuziehung einer spezifischen Perspektive beantworten. Welcher der beiden Ansätze „besser“ ist, ist letztendlich stark vom Standpunkt abhängig. So verhält es sich auch mit dem Vergleich OpenShift vs. Docker.

Docker machte die Container-Virtualisierung populär und verdrängte weitgehend die vormals vorherrschenden virtuellen Maschinen (VM). Der Siegeszug der Anwendungs-Container revolutionierte, wie Anwendungen gebaut, verpackt und ausgeführt werden. Denn Container sind eine standardisierte Software-Einheit. Sie lassen sich überall dort problemlos einsetzen, wo eine entsprechende Container-Runtime vorhanden ist.

Im Gegensatz zu den vorher allgegenwärtigen aber recht behäbigen virtuellen Maschinen sind Container leichtgewichtig. Auf einem Host lassen sich dutzende bis tausende von Containern betreiben. Dieser inhärente Vorteil der Container-Virtualisierung führte zur Verbreitung verteilter Microservice-Architekturen. Anstatt eine monolithische Anwendung zu bauen, spaltet man den Funktionsumfang in einzelne Komponenten. Jede Komponente wird als Dienst („Service“) in einen eigenen Container verpackt. Die Container werden gestartet, und die Dienste kommunizieren über das Netzwerk miteinander.

Der Microservice-Ansatz ist besonders praktisch für die Software-Entwicklung, denn so lässt sich für jeden Dienst die dafür am besten geeigneten Technologien nutzen. Anstatt an einzelne Programmiersprachen und -paradigmen gebunden zu sein, lassen sich diese zwischen den Diensten variieren. Da immer neue Technologien hinzukommen, ist es so einfacher, einzelne Dienste neu zu implementieren.

Aus der Fähigkeit, mehrere gleichartige Container aus einem Container-Image zu klonen, ergibt sich die Skalierbarkeit des Gesamtsystems. Bei höherer Nachfrage werden zusätzliche Container gestartet, der betreffende Dienst skaliert horizontal. Dies bedingt jedoch ein System, welches die laufenden Container überwacht und bei Bedarf beendet, bzw. neue Container startet. Ferner müssen eingehende Anfragen an die einzelnen Container verteilt werden.

Mit der Skalierbarkeit wächst ganz erheblich die Komplexität des Systems. Zumindest gilt zu bedenken:

• Entgegennehmen der Anfragen per Load Balancer
• Verteilen der Aufgaben an die einzelnen Container
• Überwachen des Zustands der Container-Instanzen
• Beenden und Starten neuer Instanzen
• Aufbau eines Netzwerks zwischen den Containern
• Pflege der Container bzw. Images mit Updates, etc.

All dies führt zusammengenommen zu einem massiven administrativen Overhead. Und das ist noch nicht mal alles. Hinzu kommt noch die Pflege des administrativen Systems selber. Auch diese Kontrollebene, welche all die oben genannten Punkte leistet, muss gepflegt, überwacht und mit Updates versorgt werden. Selbstverständlich soll es dabei auf Nutzerseite nie zu spürbaren Leistungsverlusten kommen. Ferner muss die Sicherheit des Gesamtsystems durchgängig gewährleistet sein.

Zu guter Letzt möchten wir auch noch die Möglichkeit nutzen, unsere Container-Cluster über Infrastruktur-Grenzen hinweg zu orchestrieren. Spätestens ab diesem Punkt ist die Komplexität des Systems so weit angewachsen, dass sie für Menschen kaum noch zu bewältigen ist. Also werden spezielle Tools benötigt, welche Organisationen dabei helfen, der Komplexität Herr zu werden. OpenShift und vergleichbare Alternativen sind aus diesem Spannungsfeld hervorgegangen.

Wie bereits erwähnt, handelt es sich bei OpenShift und Docker um weit auseinander liegende Technologien. Der Vergleich macht mehr Sinn wenn die Software „Kubernetes“, auch bekannt als K8s, mit betrachtet wird. Denn der Schritt von Docker zu K8s ist vergleichbar mit dem Übergang vom Einzeller zum mehrzelligen Organismus. Und auf ähnlich Weise ist der Schritt von K8s zu OpenShift vergleichbar mit dem Übergang vom einzelnen Organismus zu einer Gruppe von Lebewesen. Schauen wir uns unter diesem Gesichtspunkt die zum Einsatz kommenden Technologien erneut an:

Tatsächlich beruht OpenShift auf K8s, welches wiederum ursprünglich auf Docker beruhte. Erst in der jüngeren Vergangenheit kam es zur Trennung von Docker und K8s. Schauen wir uns im Folgenden die beiden Extreme des Spektrums — OpenShift vs. Docker — im Detail an.

Docker ist eine Open Source-Technologie, mit der sich Anwendungen in Container verpacken bzw. Anwendungs-Container ausführen lassen. Mit Docker werden portable, in sich abgeschlossene Anwendungs-Container erzeugt, welche in Cloud-Umgebung oder auf lokaler Rechenhardware ausgeführt werden können. Die Software stammt von der gleichnamigen Firma Docker Inc. Neben der kostenfreien Open Source Version bietet das Unternehmen verschiedene kostenpflichtige Produkte an.

Bei Docker handelt es sich mittlerweile um drei Tools in einem:

1. Die Docker Engine, welche die Kernfunktionalitäten der Container-Virtualisierung bereitstellt.
2. Docker Compose, eine Funktionalität, mit der mehrere Container als Verbund orchestriert werden.
3. Docker Swarm, ein Modus, welcher die Orchestrierung von Container-Clustern über mehrere Hosts ermöglicht.

Die Docker Engine wiederum besteht aus drei hauptsächlichen Komponenten:

1. Der Docker Daemon, welcher als dockerd auf dem Host läuft.
2. Die Docker-API, welche vom Docker Deamon bereitgestellt wird. Der Docker Daemon wird über die API angesprochen und gesteuert.
3. Das Kommandozeilen-Interface (CLI), welche als docker-Befehl eingesetzt wird, um mit der Docker-API zu kommunizieren.

Die Docker Engine ist nativ unter Linux beheimatet. Ferner steht mit „Docker Desktop“ ein einfach zu installierendes Paket für Mac und Windows bereit. Docker Desktop vereinfacht das Setup und umfasst eine grafische Benutzeroberfläche. Ferner sind weitere von Docker stammende Technologien, wie Docker Compose, enthalten.

Docker hat sich im vergangenen Jahrzehnt als Standard für die Container-Virtualisierung etabliert. So wundert es nicht, dass die Software auf den verschiedensten Betriebssystemen läuft. Docker lässt sich relativ einfach installieren, und auch der Einstieg in die grundlegende Funktionalität geht leicht von der Hand. Praktisch ist vor allem die ungeheure Bandbreite vorgefertigter Container-Images. Diese enthalten Softwareumgebungen für Entwicklung und Produktion und lassen sich von öffentlichen Container-Registries beziehen. Verglichen mit OpenShift handelt es sich bei Docker um eine weitaus weniger komplexe Technologie.

Die größten Nachteile von Docker ergeben sich aus dem organischen Wachstum der Software über die Jahre. Was als Container-Virtualisierung begann, hat sich heutzutage zu einer monolithischen Plattform entwickelt, die zu viel auf einmal macht. Mit Docker Swarm und Docker Compose geht der Einsatz von Docker weit über die ursprünglichen Ziele hinaus. Im Vergleich zu modernen Ansätzen ist Docker relativ schwach in Bezug auf Sicherheit und Performance.

Stark aufgestellt ist Docker heutzutage vor allem als Tool für die Software-Entwicklung. Lokale Entwicklungsumgebungen werden samt der eingesetzten Tools und Workflows als Container gekapselt. Die dabei erzeugten Images lassen sich zwischen Entwicklern teilen und legen die Grundlage für standardisierte, reproduzierbare Entwicklung.

Ferner dient Docker als Basis für darauf aufbauende Technologien. Entwicklungs-Tools wie DDEV und Lando nutzen Docker, um die lokale Entwicklung zu vereinfachen. Mit Plattformen wie Portainer und Mirantis (vormals Docker Enterprise) stehen mächtige Tools zur Container-Orchestrierung zur Verfügung.

Wie bereits erwähnt, spielt OpenShift am oberen Ende des Container-Spektrums. OpenShift wird zum Aufbau verteilter, skalierender Anwendungs- und Entwicklungsumgebungen nach dem Platform-as-a-Service-Modell (PaaS) eingesetzt. Die Software stellt eine komplette Ausführungsumgebung bereit, in der Container deployt, ausgeführt, verwaltet und orchestriert werden. Die integrierten Werkzeuge vereinfachen moderne Entwicklungs- und Deployment-Workflows.

Als Unterbau von OpenShift kommt eine spezielle Kubernetes (K8s) Distribution zum Einsatz. Diese lässt sich über Cloud- und Infrastruktur-Grenzen hinweg deployen, wobei eine konsistente Nutzererfahrung erzielt wird. Die K8s-Kernfunktionalität wird um Sicherheits- und Monitoring-Features ergänzt und fußt auf zentralisiertem Policy-Management. So wird über die Softwarelandschaft einer gesamten Organisation hinweg ein hoher Qualitätsstandard gewährleistet.

Zunächst bändigt OpenShift die operative Komplexität, welche mit der Administration selbstverwalteter K8s-Cluster einhergeht. So lassen sich mehrere K8s-Cluster über die Grenzen öffentlicher und privater Cloud-Infrastrukturen hinweg zentralisiert verwalten. Dem PaaS-Ansatz folgend können firmeneigene Entwickler über eine Web-Schnittstelle selbsttätig Ressourcen für ihre Projekte anfordern. Integrierte Tools und Workflows für Continuous Integration und Continuous Delivery (CI/CD) runden den Funktionsumfang ab und führen zu drastisch gesenkten Auslieferungszeiten.

Unter der Haube setzt OpenShift auf eine spezielle K8s-Distribution zur Orchestrierung der Container und Cluster. Ursprünglich baute K8s auf Docker als Container-Runtime auf. Mittlerweile wurde diese Abhängigkeit aufgelöst; stattdessen kommt das „Container Runtime Interface“ der Open Container Initiative (CRI-O) zum Einsatz. Daraus ergeben sich Vorteile in Bezug auf Sicherheit und Performance.

Generell überzeugt OpenShift mit den integrierten Sicherheitsvorkehrungen. Mit „Quay“ steht eine speziell abgesicherte Container-Registry zur Verfügung. Durchgängige Autorisierung und Authentifizierung begrenzt den Zugriff der Nutzer auf die einzelnen Bereiche des Systems. Die Möglichkeit, einzelne Cluster in verschiedenen geographischen Regionen zu hosten, erlaubt eine bessere Compliance in Hinsicht auf Datenschutz und Datenhoheit.

OpenShift läuft nur auf speziellen Betriebssystemen von Red Hat, wie „Red Hat Enterprise Linux CoreOS“ (RHCOS) und „Red Hat Enterprise Linux“ (RHEL). Die Installation gilt als ausgesprochen aufwendig. So kann die Einrichtung für größerer Projekte mehrere Wochen in Anspruch nehmen. Aufgrund der strengeren Sicherheitsvorkehrungen lassen sich nicht alle Container-Images der öffentlichen Registries nutzen.

Auf Basis von OpenShift werden Firmen-eigene Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS) und Containers-as-a-Service (CaaS) implementiert. Dabei liegt der Fokus ganz klar auf großen Organisationen. Für einzelne Entwickler ist OpenShift definitiv zu groß und zu schwer zu handhaben.

Auch wenn der direkte Vergleich OpenShift vs. Docker schwer fällt, lassen sich einzelne Eigenschaften der beiden Technologien gegenüberstellen. Der Vollständigkeit halber nehmen wir wiederum Kubernetes (K8s) in den Vergleich mit auf: