OpenShift vs. Docker

Docker führte den Siegeszug der Container-basierten Vir­tua­li­sie­rung herbei. Die Software ist eine grund­le­gen­de Tech­no­lo­gie zum Erzeugen und Ausführen von An­wen­dungs-Con­tai­nern. Docker wird zum Beispiel von einzelnen Ent­wick­lern auf dem eigenen Laptop ein­ge­setzt, um Ent­wick­lungs-Workflows zu stan­dar­di­sie­ren. OpenShift spielt am anderen Ende des Vir­tua­li­sie­rungs-Spektrums und deckt die ope­ra­ti­ven An­for­de­run­gen einer ganzen Or­ga­ni­sa­ti­on ab. Als Grundlage kommen öf­fent­li­che und private Cloud-Um­ge­bun­gen zum Einsatz.

Die beiden Tech­no­lo­gien sind kei­nes­falls direkte Kon­kur­ren­ten. In der Tat basierte OpenShift früher indirekt auf Docker und nutzt bis heute das Docker-Con­tai­ner­for­mat. Wir geben einen Überblick und gehen auf die Stärken und Schwächen sowie jeweilige Ein­satz­sze­na­ri­en ein.

In Online-Dis­kus­sio­nen oder Blog­bei­trä­gen stößt man immer wieder auf die Fra­ge­stel­lung: „OpenShift vs. Docker — was ist das bessere Tool für Container-Vir­tua­li­sie­rung?“ Auch wenn die Frage oft gestellt wird, handelt es sich um weit aus­ein­an­der liegende Tech­no­lo­gien. Sowohl OpenShift als auch Docker haben ihre Da­seins­be­rech­ti­gung und werden für ge­wöhn­lich kom­ple­men­tär ein­ge­setzt.

OpenShift- und Docker-Tech­no­lo­gien zu ver­glei­chen, ist in etwa so, als fragten wir: „Was ist besser, ein Auto oder ein öf­fent­li­ches Nah­ver­kehrs­sys­tem?“ Prin­zi­pi­ell haben beide eine ähnliche Aufgabe: Personen und Güter zwischen Orten bewegen. Auch Räder sind bei beiden Tech­no­lo­gien vorhanden. Jedoch handelt es sich um komplett un­ter­schied­li­che Grö­ßen­ord­nun­gen.

Im Gegensatz zu phy­si­schen Con­tai­nern handelt es sich beim vir­tu­el­len Pendant nicht primär um eine Trans­port­tech­no­lo­gie. Bedienen wir uns zum besseren Ver­ständ­nis einer bio­lo­gi­schen Analogie. Denn An­wen­dungs-Container und bio­lo­gi­sche Zelle haben viel gemeinsam. Es handelt sich bei beiden um eine in sich ge­kap­sel­te, nach außen ab­ge­schlos­se­ne, grund­le­gen­de Einheit „lebendig“ ge­wor­de­ner In­for­ma­ti­on.

In der belebten Welt vollzog sich die Evolution vom Einzeller zum mehr­zel­li­gen Or­ga­nis­mus. Und glei­cher­ma­ßen stellte sich im Vir­tu­el­len die Ent­wick­lung vom einzelnen Container zu or­ches­trier­ten Verbünden mit­ein­an­der in­ter­agie­ren­der Container ein. Auch die mit der Mehr­zel­lig­keit ein­her­ge­hen­den Her­aus­for­de­run­gen sind ähnlich zu denen, welche sich aus dem Zu­sam­men­spiel mehrerer Container ergeben.

Bio­lo­gi­sche Zellen und An­wen­dungs-Container müssen mit­ein­an­der kom­mu­ni­zie­ren. Je nach Bedarf müssen sie nach­wach­sen bzw. absterben. Die insgesamt zur Verfügung stehende Res­sour­cen müssen auf die einzelnen Einheiten auf­ge­teilt werden. All dies sollte wohl ko­or­di­niert sein, damit das Ge­samt­sys­tem auf sich wech­seln­de An­for­de­run­gen reagieren kann und dabei auf Dauer stabil bleibt. Ver­an­schau­li­chen wir uns die Spann­brei­te der Container-Vir­tua­li­sie­rung von Docker bis OpenShift an der folgenden Übersicht:

Wir sehen: Die Frage, was besser ist, lässt sich nur unter Hin­zu­zie­hung einer spe­zi­fi­schen Per­spek­ti­ve be­ant­wor­ten. Welcher der beiden Ansätze „besser“ ist, ist letzt­end­lich stark vom Stand­punkt abhängig. So verhält es sich auch mit dem Vergleich OpenShift vs. Docker.

Docker machte die Container-Vir­tua­li­sie­rung populär und ver­dräng­te weit­ge­hend die vormals vor­herr­schen­den vir­tu­el­len Maschinen (VM). Der Siegeszug der An­wen­dungs-Container re­vo­lu­tio­nier­te, wie An­wen­dun­gen gebaut, verpackt und aus­ge­führt werden. Denn Container sind eine stan­dar­di­sier­te Software-Einheit. Sie lassen sich überall dort pro­blem­los einsetzen, wo eine ent­spre­chen­de Container-Runtime vorhanden ist.

Im Gegensatz zu den vorher all­ge­gen­wär­ti­gen aber recht behäbigen vir­tu­el­len Maschinen sind Container leicht­ge­wich­tig. Auf einem Host lassen sich dutzende bis tausende von Con­tai­nern betreiben. Dieser inhärente Vorteil der Container-Vir­tua­li­sie­rung führte zur Ver­brei­tung ver­teil­ter Mi­cro­ser­vice-Ar­chi­tek­tu­ren. Anstatt eine mo­no­li­thi­sche Anwendung zu bauen, spaltet man den Funk­ti­ons­um­fang in einzelne Kom­po­nen­ten. Jede Kom­po­nen­te wird als Dienst („Service“) in einen eigenen Container verpackt. Die Container werden gestartet, und die Dienste kom­mu­ni­zie­ren über das Netzwerk mit­ein­an­der.

Der Mi­cro­ser­vice-Ansatz ist besonders praktisch für die Software-Ent­wick­lung, denn so lässt sich für jeden Dienst die dafür am besten ge­eig­ne­ten Tech­no­lo­gien nutzen. Anstatt an einzelne Pro­gram­mier­spra­chen und -pa­ra­dig­men gebunden zu sein, lassen sich diese zwischen den Diensten variieren. Da immer neue Tech­no­lo­gien hin­zu­kom­men, ist es so einfacher, einzelne Dienste neu zu im­ple­men­tie­ren.

Aus der Fähigkeit, mehrere gleich­ar­ti­ge Container aus einem Container-Image zu klonen, ergibt sich die Ska­lier­bar­keit des Ge­samt­sys­tems. Bei höherer Nachfrage werden zu­sätz­li­che Container gestartet, der be­tref­fen­de Dienst skaliert ho­ri­zon­tal. Dies bedingt jedoch ein System, welches die laufenden Container überwacht und bei Bedarf beendet, bzw. neue Container startet. Ferner müssen ein­ge­hen­de Anfragen an die einzelnen Container verteilt werden.

Mit der Ska­lier­bar­keit wächst ganz erheblich die Kom­ple­xi­tät des Systems. Zumindest gilt zu bedenken:

• Ent­ge­gen­neh­men der Anfragen per Load Balancer
• Verteilen der Aufgaben an die einzelnen Container
• Über­wa­chen des Zustands der Container-Instanzen
• Beenden und Starten neuer Instanzen
• Aufbau eines Netzwerks zwischen den Con­tai­nern
• Pflege der Container bzw. Images mit Updates, etc.

All dies führt zu­sam­men­ge­nom­men zu einem massiven ad­mi­nis­tra­ti­ven Overhead. Und das ist noch nicht mal alles. Hinzu kommt noch die Pflege des ad­mi­nis­tra­ti­ven Systems selber. Auch diese Kon­trol­l­ebe­ne, welche all die oben genannten Punkte leistet, muss gepflegt, überwacht und mit Updates versorgt werden. Selbst­ver­ständ­lich soll es dabei auf Nut­zer­sei­te nie zu spürbaren Leis­tungs­ver­lus­ten kommen. Ferner muss die Si­cher­heit des Ge­samt­sys­tems durch­gän­gig ge­währ­leis­tet sein.

Zu guter Letzt möchten wir auch noch die Mög­lich­keit nutzen, unsere Container-Cluster über In­fra­struk­tur-Grenzen hinweg zu or­ches­trie­ren. Spä­tes­tens ab diesem Punkt ist die Kom­ple­xi­tät des Systems so weit an­ge­wach­sen, dass sie für Menschen kaum noch zu be­wäl­ti­gen ist. Also werden spezielle Tools benötigt, welche Or­ga­ni­sa­tio­nen dabei helfen, der Kom­ple­xi­tät Herr zu werden. OpenShift und ver­gleich­ba­re Al­ter­na­ti­ven sind aus diesem Span­nungs­feld her­vor­ge­gan­gen.

Wie bereits erwähnt, handelt es sich bei OpenShift und Docker um weit aus­ein­an­der liegende Tech­no­lo­gien. Der Vergleich macht mehr Sinn wenn die Software „Ku­ber­netes“, auch bekannt als K8s, mit be­trach­tet wird. Denn der Schritt von Docker zu K8s ist ver­gleich­bar mit dem Übergang vom Einzeller zum mehr­zel­li­gen Or­ga­nis­mus. Und auf ähnlich Weise ist der Schritt von K8s zu OpenShift ver­gleich­bar mit dem Übergang vom einzelnen Or­ga­nis­mus zu einer Gruppe von Lebewesen. Schauen wir uns unter diesem Ge­sichts­punkt die zum Einsatz kommenden Tech­no­lo­gien erneut an:

Tat­säch­lich beruht OpenShift auf K8s, welches wiederum ur­sprüng­lich auf Docker beruhte. Erst in der jüngeren Ver­gan­gen­heit 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-Tech­no­lo­gie, mit der sich An­wen­dun­gen in Container verpacken bzw. An­wen­dungs-Container ausführen lassen. Mit Docker werden portable, in sich ab­ge­schlos­se­ne An­wen­dungs-Container erzeugt, welche in Cloud-Umgebung oder auf lokaler Re­chen­hard­ware aus­ge­führt werden können. Die Software stammt von der gleich­na­mi­gen Firma Docker Inc. Neben der kos­ten­frei­en Open Source Version bietet das Un­ter­neh­men ver­schie­de­ne kos­ten­pflich­ti­ge Produkte an.

Bei Docker handelt es sich mitt­ler­wei­le um drei Tools in einem:

1. Die Docker Engine, welche die Kern­funk­tio­na­li­tä­ten der Container-Vir­tua­li­sie­rung be­reit­stellt.
2. Docker Compose, eine Funk­tio­na­li­tät, mit der mehrere Container als Verbund or­ches­triert werden.
3. Docker Swarm, ein Modus, welcher die Or­ches­trie­rung von Container-Clustern über mehrere Hosts er­mög­licht.

Die Docker Engine wiederum besteht aus drei haupt­säch­li­chen Kom­po­nen­ten:

1. Der Docker Daemon, welcher als dockerd auf dem Host läuft.
2. Die Docker-API, welche vom Docker Deamon be­reit­ge­stellt wird. Der Docker Daemon wird über die API an­ge­spro­chen und gesteuert.
3. Das Kom­man­do­zei­len-Interface (CLI), welche als docker-Befehl ein­ge­setzt wird, um mit der Docker-API zu kom­mu­ni­zie­ren.

Die Docker Engine ist nativ unter Linux be­hei­ma­tet. Ferner steht mit „Docker Desktop“ ein einfach zu in­stal­lie­ren­des Paket für Mac und Windows bereit. Docker Desktop ver­ein­facht das Setup und umfasst eine grafische Be­nut­zer­ober­flä­che. Ferner sind weitere von Docker stammende Tech­no­lo­gien, wie Docker Compose, enthalten.

Docker hat sich im ver­gan­ge­nen Jahrzehnt als Standard für die Container-Vir­tua­li­sie­rung etabliert. So wundert es nicht, dass die Software auf den ver­schie­dens­ten Be­triebs­sys­te­men läuft. Docker lässt sich relativ einfach in­stal­lie­ren, und auch der Einstieg in die grund­le­gen­de Funk­tio­na­li­tät geht leicht von der Hand. Praktisch ist vor allem die ungeheure Band­brei­te vor­ge­fer­tig­ter Container-Images. Diese enthalten Soft­ware­um­ge­bun­gen für Ent­wick­lung und Pro­duk­ti­on und lassen sich von öf­fent­li­chen Container-Re­gis­tries beziehen. Ver­gli­chen mit OpenShift handelt es sich bei Docker um eine weitaus weniger komplexe Tech­no­lo­gie.

Die größten Nachteile von Docker ergeben sich aus dem or­ga­ni­schen Wachstum der Software über die Jahre. Was als Container-Vir­tua­li­sie­rung begann, hat sich heut­zu­ta­ge zu einer mo­no­li­thi­schen Plattform ent­wi­ckelt, die zu viel auf einmal macht. Mit Docker Swarm und Docker Compose geht der Einsatz von Docker weit über die ur­sprüng­li­chen Ziele hinaus. Im Vergleich zu modernen Ansätzen ist Docker relativ schwach in Bezug auf Si­cher­heit und Per­for­mance.

Stark auf­ge­stellt ist Docker heut­zu­ta­ge vor allem als Tool für die Software-Ent­wick­lung. Lokale Ent­wick­lungs­um­ge­bun­gen werden samt der ein­ge­setz­ten Tools und Workflows als Container gekapselt. Die dabei erzeugten Images lassen sich zwischen Ent­wick­lern teilen und legen die Grundlage für stan­dar­di­sier­te, re­pro­du­zier­ba­re Ent­wick­lung.

Ferner dient Docker als Basis für darauf auf­bau­en­de Tech­no­lo­gien. Ent­wick­lungs-Tools wie DDEV und Lando nutzen Docker, um die lokale Ent­wick­lung zu ver­ein­fa­chen. Mit Platt­for­men wie Portainer und Mirantis (vormals Docker En­ter­pri­se) stehen mächtige Tools zur Container-Or­ches­trie­rung zur Verfügung.

Wie bereits erwähnt, spielt OpenShift am oberen Ende des Container-Spektrums. OpenShift wird zum Aufbau ver­teil­ter, ska­lie­ren­der An­wen­dungs- und Ent­wick­lungs­um­ge­bun­gen nach dem Platform-as-a-Service-Modell (PaaS) ein­ge­setzt. Die Software stellt eine komplette Aus­füh­rungs­um­ge­bung bereit, in der Container deployt, aus­ge­führt, verwaltet und or­ches­triert werden. Die in­te­grier­ten Werkzeuge ver­ein­fa­chen moderne Ent­wick­lungs- und De­ploy­ment-Workflows.

Als Unterbau von OpenShift kommt eine spezielle Ku­ber­netes (K8s) Dis­tri­bu­ti­on zum Einsatz. Diese lässt sich über Cloud- und In­fra­struk­tur-Grenzen hinweg deployen, wobei eine kon­sis­ten­te Nut­zer­er­fah­rung erzielt wird. Die K8s-Kern­funk­tio­na­li­tät wird um Si­cher­heits- und Mo­ni­to­ring-Features ergänzt und fußt auf zen­tra­li­sier­tem Policy-Ma­nage­ment. So wird über die Soft­ware­land­schaft einer gesamten Or­ga­ni­sa­ti­on hinweg ein hoher Qua­li­täts­stan­dard ge­währ­leis­tet.

Zunächst bändigt OpenShift die operative Kom­ple­xi­tät, welche mit der Ad­mi­nis­tra­ti­on selbst­ver­wal­te­ter K8s-Cluster ein­her­geht. So lassen sich mehrere K8s-Cluster über die Grenzen öf­fent­li­cher und privater Cloud-In­fra­struk­tu­ren hinweg zen­tra­li­siert verwalten. Dem PaaS-Ansatz folgend können fir­men­ei­ge­ne Ent­wick­ler über eine Web-Schnitt­stel­le selbst­tä­tig Res­sour­cen für ihre Projekte anfordern. In­te­grier­te Tools und Workflows für Con­ti­nuous In­te­gra­ti­on und Con­ti­nuous Delivery (CI/CD) runden den Funk­ti­ons­um­fang ab und führen zu drastisch gesenkten Aus­lie­fe­rungs­zei­ten.

Unter der Haube setzt OpenShift auf eine spezielle K8s-Dis­tri­bu­ti­on zur Or­ches­trie­rung der Container und Cluster. Ur­sprüng­lich baute K8s auf Docker als Container-Runtime auf. Mitt­ler­wei­le wurde diese Ab­hän­gig­keit aufgelöst; statt­des­sen kommt das „Container Runtime Interface“ der Open Container In­itia­ti­ve (CRI-O) zum Einsatz. Daraus ergeben sich Vorteile in Bezug auf Si­cher­heit und Per­for­mance.

Generell überzeugt OpenShift mit den in­te­grier­ten Si­cher­heits­vor­keh­run­gen. Mit „Quay“ steht eine speziell ab­ge­si­cher­te Container-Registry zur Verfügung. Durch­gän­gi­ge Au­to­ri­sie­rung und Au­then­ti­fi­zie­rung begrenzt den Zugriff der Nutzer auf die einzelnen Bereiche des Systems. Die Mög­lich­keit, einzelne Cluster in ver­schie­de­nen geo­gra­phi­schen Regionen zu hosten, erlaubt eine bessere Com­pli­ance in Hinsicht auf Da­ten­schutz und Da­ten­ho­heit.

OpenShift läuft nur auf spe­zi­el­len Be­triebs­sys­te­men von Red Hat, wie „Red Hat En­ter­pri­se Linux CoreOS“ (RHCOS) und „Red Hat En­ter­pri­se Linux“ (RHEL). Die In­stal­la­ti­on gilt als aus­ge­spro­chen aufwendig. So kann die Ein­rich­tung für größerer Projekte mehrere Wochen in Anspruch nehmen. Aufgrund der stren­ge­ren Si­cher­heits­vor­keh­run­gen lassen sich nicht alle Container-Images der öf­fent­li­chen Re­gis­tries nutzen.

Auf Basis von OpenShift werden Firmen-eigene Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS) und Con­tai­ners-as-a-Service (CaaS) im­ple­men­tiert. Dabei liegt der Fokus ganz klar auf großen Or­ga­ni­sa­tio­nen. Für einzelne Ent­wick­ler ist OpenShift definitiv zu groß und zu schwer zu handhaben.

Auch wenn der direkte Vergleich OpenShift vs. Docker schwer fällt, lassen sich einzelne Ei­gen­schaf­ten der beiden Tech­no­lo­gien ge­gen­über­stel­len. Der Voll­stän­dig­keit halber nehmen wir wiederum Ku­ber­netes (K8s) in den Vergleich mit auf: