© fotoall, 123RF

Bei Platform as a Service (PaaS) stehen nicht einzelne virtuelle Rechner im Fokus, sondern ganze Umgebungen, in denen sich Anwendungen entwickeln und betreiben lassen. Red Hats Open Shift richtet sich an Unternehmen, die ein solch pflegeleichtes Konzept suchen.

Die meisten Cloudanbieter versuchen ihre Kunden mit Infrastructure as a Service (IaaS) zu ködern. Im Kern bietet sich da vor allem die klassische Virtualisierung von Computing-Dienstleistungen an: Der Kunde erhält Zugriff auf virtuelle Rechner in der Cloud, die er selbst konfiguriert. IaaS bietet damit die größtmögliche Flexibilität – egal um welchen Dienst es geht. In IaaS-Umgebungen lässt sich nahezu jede Anwendung betreiben.

Freilich hat die Medaille auch eine Kehrseite – die große Flexibilität geht mit hohem Verwaltungsaufwand einher. Der Kunde darf nicht nur konfigurieren, sondern er muss. Die Basis-Images, die in Clouds zum Einsatz kommen, sind meist Minimalversionen der jeweiligen Distributionen. Der gesamte Setup-Aufwand bleibt am Admin hängen.

Auf die Schnelle ist so ein Setup also nicht zu bewerkstelligen, und das schon gar nicht, wenn profunde Kenntnisse der Systemadministration fehlen. Darunter leiden besonders Entwickler: Sie brauchen einerseits eine passende Umgebung, um beispielsweise eine Java-Anwendung für den Betrieb in Tomcat zu bauen. Andererseits haben sie aber kein Interesse, sich um deren Setup zu kümmern.

PaaS als Alternative

Das mangelnde Interesse beruht oft genug auf dem Gefühl, nicht zuständig zu sein. Denn die Anwendung betreiben zu einem späteren Zeitpunkt in aller Regel andere Personen in anderen Teams. Der Entwickler muss nur wissen, ob sein Programm funktioniert. Der Admin will in der Lage sein, das Produkt zu managen. Das Konzept der Platform as a Service (PaaS) bringt Admins und Entwickler auf dem kleinsten gemeinsamen Nenner zusammen. Es ist ein hilfreicher Baustein für Devops-Konzepte.

Eine vorbereitete PaaS-Umgebung erlaubt das Starten neuer Entwicklungsumgebungen in Windeseile. Sie umfasst auch alle wichtigen Werkzeuge wie Git oder Jenkins. Continous Integration ist das Ziel: Aus den Quelltext-Repositories, in die ein Entwickler seine Änderungen einpflegt, entstehen unmittelbar virtuelle Systeme, in denen die Applikation für Tests lauffähig bereitsteht. Das Prinzip setzt passende Werkzeuge und Prozesse voraus, die ineinandergreifen.

Der letzte Schritt des Vorgangs ist das Ausrollen der Applikation in den produktiven Betrieb. Mit PaaS sinkt dabei der Aufwand auch für den Admin beträchtlich. Denn der muss zum Beispiel für einen fertigen LAMP-Stack samt lauffähiger Applikation im Grunde nichts mehr tun, außer den passenden Container zu starten. Red Hat bietet Open Shift als eine Plattform an, die PaaS als fertiges Produkt für Unternehmen liefert. Hält es, was die roten Hüte versprechen?

Open Shift in Varianten

Red Hat offeriert Interessierten mehrere Möglichkeiten, Open Shift zu nutzen. Die einfachste Variante sind eigene Gears – das ist in der Red-Hat-Diktion das Synonym für Container – in der öffentlichen Open-Shift-Cloud, die Red Hat selbst betreibt. Alle Funktionen, die der Artikel mit Bezug auf Open Shift bis hierhin erwähnt hat, sind dort integriert. Wer sich nur die Container-Seite von Open Shift anschauen möchte, ist mit dieser Option gut bedient: Die Einstiegshürden sind sehr niedrig, und in wenigen Minuten läuft die erste Plattform als Service.

Bis zu drei Applikationen lassen sich sogar kostenfrei betreiben, wer mehr Ressourcen benötigt, wechselt in den Bronze- oder Silber-Tarif. Ersterer ist noch immer grundsätzlich kostenlos, erlaubt aber das Buchen weiterer Leistungen gegen Aufpreis. Im Silber-Tarif ist obendrein Support enthalten (Abbildung 1).

Abbildung 1: Im Silber-Tarif von Open Shift ist auch Support enthalten.

Wer sich mit einer Public Cloud nicht anfreunden kann, sondern die Gewissheit braucht, dass Open Shift auf eigener Hardware und nur für die eigenen Zwecke läuft, der findet in der Spielart Open Shift Dedicated womöglich eine Alternative zur öffentlichen Installation. Auch beim Dedicated-Modell geht es um eine von Red Hat gehostete Plattform, diese steht den jeweiligen Kunden aber exklusiv zur Verfügung. Der Anbieter kümmert sich um die Hardware sowie die Software; die Verantwortlichkeit des Nutzers beginnt erst dort, wo es um den Betrieb von Gruppen von Containern (Pods) geht, die ihrerseits die Platform as a Service bilden.

Mindestens 48000 US-Dollar kostet ein solches Setup, hinzu kommen möglicherweise noch Zusatzgebühren, etwa für mehr Traffic oder für die Bereitstellung weiterer Applikationsnodes [1]. Verglichen mit den Kosten, die allein die Hardware eines solchen Setups verursachen würde, ist das allerdings ein durchaus vertretbarer Preis.

Wer aus irgendwelchen Gründen nicht nur exklusive Hardware braucht, sondern darüber hinaus auch die Plattform selbst betreiben möchte, der greift zu der Version Open Shift Enterprise.

Selbst gebaut

Damit lässt sich eine Open-Shift-Installation auch im eigenen Rechenzentrum realisieren. Die gesamte Kontrolle verbleibt dann beim betreibenden Unternehmen, Red Hat steht allerdings mit Support zur Seite, ohne den die Enterprise-Edition von Open Shift gar nicht zu bekommen ist. Über die Preise für eine solche Enterprise-Lizenz schweigt Red Hat sich auf der Website von Open Shift [2] vornehm aus, wie üblich dürfte der zu zahlende Preis aber ohnehin von den gewährten Rabatten abhängen. Wer sich an den Red-Hat-Vertrieb wendet, erhält für das Produkt jedenfalls auf Wunsch eine Eval-Lizenz.

Shift hin zu Docker

Die erste Version der Open-Shift-Umgebung erschien 2011, mittlerweile ist die Lösung bei Version 3 angekommen. Unter der Haube hat sich dabei einiges verändert: Insbesondere beim Thema Virtualisierung unternahm der Hersteller diverse Experimente, bevor er in der aktuellen Version bei Docker [3] und Kubernetes [4] gelandet ist.

Die damit realisierte Lösung ist sinnvoll: Docker fungiert als der Quasi-Standard, wenn es um Container-Virtualisierung geht, Kubernetes ist ein Management-Framework, das die Verwaltung von Docker-Containern auf einer große Anzahl an Servern ermöglicht. Open Shift ist damit eine Komplettlösung: Zur Umgebung gehört das Betriebssystem der Hosts genauso wie alle Komponenten, die darauf laufen und den Betrieb von Apps auf Container-Basis erlauben.

Ausdrücklich im Paket enthalten sind also auch die Schnittstellen hin zum Nutzer, etwa APIs oder GUIs. Über diese steuert der Admin das Ausrollen von Containern, sodass die gewünschten Dienste innerhalb von Open Shift laufen. Hinzu kommt das Thema Entwicklung: Open Shift verspricht Entwicklern eine vollständige, einfache Umgebung, bei der die Container-Entwicklung und die Nutzung darin laufender Applikationen eng verzahnt sind. Der ganze Weg von einer Idee bis zur Applikation im Produktivbetrieb ist darin abgebildet.

Konkret bedeutet das: Im ersten Schritt schreibt der Entwickler in einer schon durch Open Shift bereitgestellten Umgebung seinen Code. Dann checkt er ihn in ein Versionsverwaltungssystem ein, bei Open Shift ist das Git. Per Mausklick entsteht aus einem Container-Abbild (der so genannten Cartridge) und dem Code des Entwicklers automatisch eine komplette virtuelle Umgebung, in der alle wichtigen Komponenten enthalten sind (Abbildung 2). Falls die Anwendung neben dem obligatorischen Webserver noch andere Dienste braucht, zum Beispiel eine Datenbank, lässt sich auch diese aus Open Shift heraus zusammen mit der Applikation starten.

Abbildung 2: Per Mausklick zur Applikation: Die Auswahl einer Applikation in Open Shift genügt, um zu einer funktionierenden Lösung zu kommen.

Wie alle aktuellen Red-Hat-Produkte basiert Open Shift auf Enterprise Linux 7 (RHEL). Das gilt zumindest für den klassischen Ansatz: Ab Version 3.1 bietet Open Shift nämlich auch Unterstützung für Red Hats Atomic Platform. Dabei handelt es sich um ein ebenfalls auf RHEL beruhendes System, das speziell für den Betrieb von Containern optimiert ist. In mancher Hinsicht unterscheidet sich die Atomic-Variante deutlich von einem normalen RHEL, etwa dadurch, dass verschiedene Systemdienste nicht in Form von RPM-Paketen, sondern als eigene Container ausgeführt sind.

Das klassische RHEL ist freilich die sinnvollere Lösung, wenn bereits Infrastruktur für den Betrieb von RHEL im Rechenzentrum vorhanden ist – etwa funktionierende Automatisierung. Atomic eignet sich hingegen eher für neue Installationen auf der grünen Wiese, die den Overhead eines kompletten RHEL nicht in Kauf nehmen wollen.

Open Shift Origin als Schaltzentrale

Die Kernkomponente von Red Hat Open Shift ist Open Shift Origin. Die Namen sind sich zwar ähnlich, doch es handelt sich um zwei unterschiedliche Dinge: Bei Origin laufen alle Fäden zusammen, es ist die technische Basis des Produkts. Red Hat Open Shift ist hingegen die fertige PaaS-Plattform, deren wichtiger Bestandteil Origin ist. Origin erledigt in Open Shift alle Aufgaben, die unmittelbar mit der Entwicklung und dem Ausrollen von PaaS-Stacks zu tun haben. Dazu gehört die Verwaltung der Quellen genauso wie das Anlegen von Containern auf Basis von PaaS-Anwendungen.

Zwischen Open Shift 2 und Open Shift 3 hat Red Hat die Software gewissermaßen auf den Kopf gestellt: Version 2 funktionierte noch auf Basis von Brokern und Gears, was Red-Hat-Sprech für die Verteilung von Containern auf Hosts war. Die gesamte Technik war eine Eigenentwicklung. Open Shift 3 ist dagegen komplett auf Docker getrimmt: Die Image-Verwaltung fußt auf Docker und kann etwa auch Docker-Hubs nutzen, um Basis-Images von dort zu beziehen. Weil Docker selbst nicht Cluster-fähig ist, garniert Red Hat es mit Kubernetes von Google. Wie funktioniert das im Detail und worauf lassen Admins sich ein? Ein genauerer Blick ist hier nötig.

Kubernetes unter der Haube

Das von Google erfundene und seither weiterentwickelte Projekt Kubernetes ist eine Cloudumgebung, die auf Container-Virtualisierung mit Docker fußt (Abbildung 3). Prinzipiell ist sie deshalb mit Open Stack oder Cloud Stack vergleichbar, doch im Detail sind große Unterschiede erkennbar. Einer dieser Unterschiede ist, dass die Kubernetes-Architektur insgesamt zwar kompliziert ist, aber noch immer deutlich weniger komplex als die von anderen Clouds. Obendrein bietet Kubernetes keine Unterstützung für andere Virtualisierungsmethoden als Docker-Container. Denn das Docker-Konzept ist in Kubernetes integraler Bestandteil des Designs.

Abbildung 3: Open Shift ist eine PaaS-Lösung, die auf Docker und der Cloudumgebung Kubernetes basiert und diese um diverse Funktionen erweitert.

Eine Kubernetes-Cloud besteht aus zwei Node-Typen: Die Master-Server sind die Controller des Setups, die den Betrieb von Containern auf den einfachen Nodes koordinieren. Die Master-Server betreiben verschiedene Dienste, etwa ein API für den Zugriff von Clients, das gleichzeitig auch die Verwaltung der Benutzer innerhalb der Kubernetes-Cloud übernimmt http://5. Der Scheduler wählt anhand der ihm bekannten Daten Nodes aus, auf denen neue Container landen. Obendrein spielt der Replikations-Controller eine Rolle: Er ermöglicht das Skalieren in die Breite. Wenn die für einen Zweck gestarteten Container mit ihrer Last nicht mehr zurechtkommen, startet der Replikations-Controller neue Container. Das passiert automatisch, wenn die jeweilige Umgebung dafür konfiguriert ist.

In Kubernetes ist klar dokumentiert, was die Lösung unter einem Container versteht – denn Container sind stets applikationsspezifisch. Im Idealfall läuft innerhalb eines Containers nur eine einzelne Applikation. Weil Setups in aller Regel mehr als einen Dienst enthalten, hat Google in Kubernetes die so genannten Pods implementiert: Ein Pod ist eine Gruppe von Containern, die zum gleichen Setup gehören. Alle Container eines Pod starten zusammen und laufen auf demselben Knoten des Setups.

Dieses Prinzip eignet sich ideal für Platform as a Service: Selbst wenn für eine Umgebung mehrere Dienste notwendig sind, lassen sie sich in Open Shift zusammenhängend starten. Denn Open Shift gibt die Anfrage einfach an Kubernetes weiter, das die nötigen Arbeiten dann im Hintergrund erledigt. Letztendlich ist es angesichts dieser Tatsachen nur logisch, dass Red Hat den eigenen Unterbau von Open Shift 2 verworfen und sich an Kubernetes gehängt hat.

Netzwerk und persistenter Speicher

Kubernetes nimmt Open Shift zwei weitere Probleme ab: Netzwerk und Speicher. An beide stellen Cloudumgebungen besondere Ansprüche. Das Netz muss sich etwa aus der Umgebung heraus konfigurieren lassen und darf nicht von der Netzwerkhardware vor Ort abhängen. Container zweier Kunden, die auf demselben Blech laufen, dürfen trotzdem nichts voneinander merken.

Kubernetes bietet dafür sein Software Defined Networking (SDN), das auch auf externe Lösungen wie Open Vswitch zurückgreifen darf. Den Traffic mit der Außenwelt wickelt Kubernetes ebenfalls automatisch ab, sodass der Admin das Thema von seiner To-do-Liste streichen kann. Der Kunde darf sich darauf verlassen, dass seine gestarteten Container eine Netzwerkverbindung haben und miteinander kommunizieren können.

Speicher ist in Clouds ein Dauerthema: Kubernetes geht davon aus, dass ein Container sich jederzeit erneut ausrollen lässt. Persistenter Speicher ist für den durchschnittlichen Container daher nicht vorgesehen. Der Alltag zeigt, dass er manchmal trotzdem nötig ist: Eine Datenbank mit Kundendaten ist das perfekte Beispiel. Kubernetes kann persistenten Speicher verwalten und an Container anhängen, der Nutzer muss das aber ausdrücklich anfordern. Diese Option schleift Open Shift in sein API durch, sodass sich Container für PaaS mit persistentem Speicher versorgen lassen.

Nach diesem Lobgesang auf Kubernetes stellt sich die Frage, wieso Admins sich nicht direkt mit Kubernetes beschäftigen sollten, statt den Umweg über Open Shift zu nehmen. Tatsächlich ist Kubernetes sehr gut für PaaS geeignet, doch in der von Google angebotenen Version ist die Umgebung im Rohzustand. Das bedeutet, dass der Admin sich um ihr Setup genauso selbst kümmern muss wie um die Ausstattung der Umgebung mit passenden Applikationen. Ebenso fehlt alles, was Deployments in Kubernetes für Entwickler erleichtert, also etwa die direkte Anbindung an Git.

Genau hier hat Red Hat den Mehrwert gefunden, der Open Shift den Kunden schmackhaft machen soll: Red Hat erweitert Kubernetes nicht nur um eine Installationsroutine und schicke grafische Werkzeuge, sondern rückt auch mit einer LKW-Ladung voller Container an, die für Open Shift optimiert sind. Beachtlich ist außerdem die Integration in Entwicklungsprozesse, die über Git realisiert ist.

Die Installation

Wer Open Shift in der Enterprise-Edition im eigenen Rechenzentrum betreiben will, hat zunächst die Installation vor sich. Red Hat lässt hier nichts anbrennen: Der »atomic-openshift-installer« bringt das Programm auf die einzelnen Knoten eines Setups, wenn diese mit RHEL 7 vorinstalliert sind. Das Programm braucht eine Konfigurationsdatei, die Werte wie die beteiligten Nodes und deren IP-Adresse erfragt. Hier legt der Admin fest, wer Kubernetes-Master ist und welche Knoten später gewöhnliche Kubernetes-Nodes sein werden. Sogar unbeaufsichtigte Installationen sind so kein Problem.

Wem selbst das noch zu viel Aufwand ist, dem steht die “containerisierte” Installation zur Verfügung: Mehrere Container enthalten dann die für Open Shift relevanten Komponenten, die lokal als Container starten. Einfacher geht es kaum.

Skriptsprachen, Datenbanken, Web

Ist Open Shift erst einmal eingerichtet, stehen die potenziellen PaaS-Apps im Mittelpunkt. Die heißen bei Red Hat noch immer Gear – ein Gear meint also einen Container. In Sachen Images geht Red Hat erkennbar in die Vollen: Das Unternehmen hat in Form des Open-Shift-Hub einen Klon zum Docker-Hub geschaffen. Darin bieten die roten Hüte diverse so genannte Cartridges an, mit denen Umgebungen etwa für PHP, Ruby oder Java und viele andere Technologien per Klick in Open Shift starten. Cartridges stehen für sämtliche relevanten Skript- und Programmiersprachen zur Verfügung. Direkt aus dem Hub [6] heraus lassen sich VMs in Red Hats öffentlicher Open-Shift-Cloud starten (Abbildung 4).

Abbildung 4: Im Open-Shift-Hub stellt Red Hat Applikationen zur Verfügung, die sich auch als Erweiterung in Open Shift ausrollen lassen.

Wer einen Container stattdessen in einer eigenen Open-Shift-Instanz betreiben will, findet die Sourcen für deren Integration auf Github. Falls sich für das benötigte Framework weder bei Red Hat noch in der Community eine Cartridge findet, bleibt noch die Möglichkeit, sie selbst zu schreiben. Im Netz finden sich diverse Anleitungen, wie das geht. Weil ein eigener API-Dienst Cartridges in Open Shift realisiert, ist auch dessen Dokumentation [7] lohnende Lektüre.

Neben Containern für Entwicklungsumgebungen stellt Red Hat solche für Datenbanken bereit, etwa für MySQL 5.6 oder PostgreSQL 9.4. Auf Basis solcher Templates rollt der Admin die Datenbank zusammen mit den Applications-Containern aus, sodass gleich nach dem Start alle benötigten Dienste arbeiten.

Die Champions League der Container sind jene, die ein Anbieter sich von Red Hat zertifizieren lässt [8]: Red Hat überprüft dann nicht nur, ob diese den technischen Standards entsprechen, sondern verpflichtet den Hersteller auch zu Support und Sicherheitsupdates. Red Hat selbst stellt auch zertifizierte Container zur Verfügung, für die dieselben Versprechen gelten.

Dienste, die sich in einer Open-Shift-Installation nicht als Gear ausrollen lassen, bindet Open Shift über den Marketplace ein. Dort registrieren sich Hersteller mit ihren Produkten. Interessant ist das typischerweise für die Unternehmen hinter anderen “As a Service”-Angeboten: ElephantSQL bietet etwa PostgreSQL as a Service und Clear DB hat ein ähnliches Angebot für MySQL. Beide Anbieter betreiben den Dienst selbst und geben lediglich Credentials aus, über die der Dienst letztlich zu erreichen ist.

Wenn ein Modul für den Marketplace von Open Shift vorliegt, lässt sich der jeweilige Dienst direkt in die eigene PaaS einbinden, und zwar über die Open-Shift-Werkzeuge, also nahtlos. Daher ist der Marketplace eine sinnvolle Ergänzung zu Open Shift – und auch weil viele exotische Dienste verfügbar sind, etwa Rabbit-MQ as a Service (Cloud AMQP) oder Keen IO, das Trending für Clouddienste übernimmt.

Hochverfügbarkeit für Controller

Ein typisches Kubernetes-Setup hat offensichtliche Schwächen, gerade wenn es um den Master-Knoten geht, er ist ein Single Point of Failure. Zwar führt sein Ausfall nicht automatisch dazu, dass alle Container abstürzen oder ihre Verbindung zum Internet verlieren. Sehr wohl ist es bei ausgefallenem Master-Knoten aber unmöglich, vorhandene Container zu verwalten oder neue anzulegen.

Red Hat erweitert Kubernetes in Open Shift deshalb um ein Konzept für Hochverfügbarkeit. Weil die Firma alle Entwickler beschäftigt oder beschäftigt hat, die den Linux-HA-Stack entworfen haben, fiel die Wahl dabei logischerweise auf diesen: Pacemaker und Corosync im Tandem sorgen dafür, dass der Ausfall eines Master-Knotens in Open Shift in wenigen Sekunden durch den Start der benötigten Dienste auf einem anderen Host kompensiert wird.

Open Shift bietet ein eigenes API und erfüllt damit die Mindestanforderung an eine Anwendung im Cloudkontext. Wer die Dienste der Plattform in Anspruch nehmen will, tut das wahlweise über ein eigenes Webinterface – die Web Console – oder nutzt dafür den Kommandozeilen-Client »rhc« . Der Funktionsumfang der beiden Ansätze ist praktisch identisch, sodass die eigene Präferenz alleine den Ausschlag gibt.

Gewohntes Bild für Entwickler

Die bisher vorgestellten Aspekte von Open Shift beziehen sich mehrheitlich auf die Installation und den Betrieb des Clusters sowie der Container darin. Doch Open Shift ist kein Operations-Tool, sondern wildert in Devops-Gefilden: Auch Entwickler finden in der Lösung viele angenehme Eigenschaften.

Devops im Open-Shift-Kontext bedeutet, dass die Plattform auf Wunsch nicht nur Gears und Gruppen von Gears mit spezifischen Umgebungen und Diensten startet. Sie ist obendrein auch in der Lage, in diesen automatisiert Anwendungen auszurollen. Die Application ist in Open Shift eine eigene Verwaltungseinheit, und Gears sind zu logischen Gruppen zusammengefasst, die den Namen der Applikation haben.

Direkt zu Open Shift gehört ein Git-Server: Entwickler legen in Open Shift eine Applikation an und wählen aus, welche Eigenschaften diese hat (etwa “braucht MySQL” und “nutzt PHP”). Danach checken sie das – leere – Git-Verzeichnis, das zu dieser Applikation gehört, lokal aus und nehmen ihre Veränderungen vor. Über das Git-Verzeichnis lassen sich alle Aspekte dieser Applikation bestimmen. Wenn die lokalen Veränderungen fertig sind, folgen ein Commit per Git und ein anschließender Push zurück zu Open Shift. Der sorgt im letzten Schritt dafür, dass die Änderungen des Git-Ordners im Container aktiv werden.

Ein unverzichtbares Werkzeug für kontinuierliche Entwicklung ist Jenkins, das neuen Code in einer Vielzahl von vorher festgelegten Testfällen auf Herz und Nieren prüft. Wer seine Änderungen nicht direkt aus der Entwicklung in einen Container pushen möchte, kann in Open Shift deshalb Jenkins als doppelten Boden einziehen. Bevor der Code in einem Container ausgerollt wird, durchläuft er dann zuvor die in Jenkins definierten Tests. Wer neben Jenkins auch andere Werkzeug zur Codekontrolle nutzen möchte, tut das über die so genannten Hooks (Abbildung 5): Für jede Applikation kann er direkt im Git-Verzeichnis Aktionen festlegen, die Open Shift nach einer Veränderung in der Applikation ausführt.

Abbildung 5: Mit Hilfe von Hooks lassen sich vor dem Bauen des Containers, während des Vorgangs oder vor und während des Deployments Aktionen starten.

Fazit

Open Shift beeindruckt durch gute Funktionalität und Schnörkellosigkeit. Das Produkt leistet, was der Hersteller verspricht: Wer Platform as a Service will, macht sich den Alltag durch den Einsatz von Open Shift auf jeden Fall leichter. Purem Kubernetes ist Open Shift klar überlegen: Vor allem die fertigen und vom Hersteller sogar zertifizierten Container für spezifische Umgebungen sind dafür wichtig. Sehr attraktiv ist das Produkt aber auch, weil es sich in Entwicklungsprozesse gut integrieren lässt und den Weg, den der Quelltext vom Entwickler bis zum abschließenden Ausrollen im Produktivbetrieb nimmt, erheblich verkürzt. Wer bereits über den Einsatz von Kubernetes im eigenen Unternehmen nachgedacht hat, sollte sich Open Shift jedenfalls genauer ansehen.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.