Effizienter entwickeln in der PaaS Architektur von OpenShift 3.4

Entwicklungsprojekte lassen sich mit einer PaaS-Umgebung beschleunigen und produktiver machen. Wir haben uns die Container-Plattform Red Hat OpenShift genauer angesehen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Setzt man bei der Entwicklung auf eine „Platform as a Service" (PaaS), so sollte sie neben einer hohen Verfügbarkeit auch dynamische Skalierbarkeit und eine automatische Provisionierung bieten. Ferner sollte sich die Plattform wahlweise in privaten, öffentlichen und hybriden Clouds betreiben lassen.

Red Hats OpenShift-Plattform war ursprünglich als PaaS gestartet, versteht sich aber heute (spätestens seit der Version 3) primär als Container-Runtime-Plattform, die PaaS-Elemente beinhaltet. Allerdings ist der Begriff „Platform as a Service“ ohnehin nicht eindeutig definiert und kommt in vielerlei Kontexten vor. Bringt man PaaS auf einen kleinsten gemeinsamen Nenner, reden wir von einem Set an Web-APIs für gehostete Anwendungen.

Was ist OpenShift ?

Mit OpenShift können Unternehmen auf Basis von Docker und Kubernetes eine eigene PaaS aufbauen. Deren Hauptmerkmal besteht darin, dass Entwickler einfach ihren Code schreiben und ohne sich um Operations-Aspekte kümmern zu müssen, fertig gebaute Applikationen erhalten, die direkt auf der PaaS laufen. OpenShift kümmert sich selbständig darum, Docker-Container zu bauen und diese skaliert zu betreiben.

Entwickler können sich also mit OpenShift ganz auf das Erstellen, Betreiben und Verwalten ihrer Anwendungen konzentrieren, wie das Entwickeln einer Programmlogik, Benutzeroberfläche oder des benötigten Datenbank-Unterbaus und müssen sich nicht mehr um Infrastruktur-Aspekte kümmern, wie z. B. das Anpassen von Betriebssystem-Images oder das Erstellen einer Firewall-Konfigurationen.

Virtual Networking mit Docker und OpenShift

Funktionsweise von OpenShift 3.4

In der Theorie – so der Marketingansatz von Red Hat – arbeiten Entwickler auf Basis von OpenShift schneller und produktiver; denn im Gegensatz zur Arbeitsweise in einer traditionellen IT-Umgebung sind Entwickler z. B. bei Aspekten wie der Provisionierung der benötigten Umgebungen nicht mehr auf die interne IT angewiesen, die z. B. die benötigten Server und Anwendungen beschaffen und bereitstellen muss.

Das geht zwar in modernen virtualisierten Rechenzentren deutlich schneller als mit physischen Systemen, frisst aber zumindest im Hinblick auf die erforderlichen Genehmigungsprozesse trotzdem personelle Ressourcen und damit Zeit – zumal dann, wenn keine Self-Service-Infrastruktur bereit steht. Allerdings steht bei OpenShift mehr als bei ähnlichen Lösungen vor allem der DevOps-Gedanke im Vordergrund und nicht so sehr, der Container-Bau. Letzteres ist eine notwendige Eigenschaft der OpenShift-PaaS aber nicht das Primärziel. Was bedeutet das?

DevOps mit OpenShift

Entwickler haben ihre Vorlieben, etwa in Bezug auf die verwendeten Tool-Chains, Frameworks und Bibliotheken. Beim Entwickeln für und in der PaaS hängen die zu verwendenden Bibliotheken und Frameworks zwar nicht mehr von der Zielplattform ab, wohl aber von den Libraries, die in der PaaS zur Verfügung stehen.

Zwar könnten Operations-Teams in OpenShift leicht alle möglichen Laufzeitumgebungen in den unterschiedlichsten Versionen containerisiert bereit stellen, die Idee des Zusammenbringens von „Dev“ und „Ops“ via OpenShift besteht aber gerade darin, den Wildwuchs im Unternehmen zu reduzieren und sich auf einen definierten Umfang verbindlicher Standards zu verständigen.

So oder so haben Entwickler in OpenShift den Vorteil, sich um Laufzeitumgebungen gar nicht kümmern zu müssen, bzw. gemeinsam mit dem Operations-Team z. B. per Knopfdruck austesten zu können, wie sich eine App in dieser oder jener Laufzeitumgebung verhält. Damit adressiert OpenShift gleichermaßen neu zu bauendende Cloud-Native-Anwendungen, unterstützt aber auch traditionelle Anwendungen, die deutlich mehr Anforderungen an die Infrastruktur stellen.

Unterstützte Cloud-Plattformen und Programmiersprachen

Die einschlägigen PaaS-Angebote einschließlich OpenShift sind im Vergleich zur Situation vor einem bis zwei Jahren deutlich ausgereifter. Hinsichtlich der unterstützten Programmiersprachen und Cloud-Plattformen sind sie zudem deutlich vielseitiger.

So unterstützt Red Hat OpenShift etwa sozusagen „im Auslieferungszustand“ Java EE 6, Ruby, Node.js, PHP, Perl und Python sowie eine breite Palette populärer Middleware-Komponenten wie JBoss und Datenbanken, darunter MySQL; MongoDB und PostgreSQL. Ferner unterstützt OpenShift die einschlägigen Entwicklung-Tools wie Eclipse, Jenkins oder Maven.

OpenShift On-Premise

OpenShift Container Plattform 3.4 installieren

Wohlbemerkt: hierbei handelt es sich hierbei um Komponenten, die OpenShift bei der installierbaren Version von Haus aus ausrollt, bzw. die in der Cloud- und Online-Version bereitstehen und die von Red Hat entsprechend unterstützt werden. Dabei liegt es selbstredend im Wesen der PaaS, dass sich Operations-Teams im Unternehmen mit OpenShift nach Belieben eigene Standards „zimmern“ können. Sollen im Unternehmen beispielsweise primär Object-Cobol- oder Lux-Anwendungen (LISP als JVM) entwickelt und betrieben werden, sorgt das Operations-Team in OpenShift für das erforderliche Fundament.

Darreichungsformen von OpenShift

Red Hat bietet OpenShift in vier Darreichungsformen und drei Konsumierungsmodellen an, nämlich

• 1. OpenShift Online, ein von Red Hat betriebener Public-Cloud-Online-Service.

• 2. OpenShift Container Platform (ehemals OpenShift Enterprise), eine installierbare Unternehmens-Version,

• 3. Open Shift Dedicated , eine wahlweise auf Amazon Web Services (AWS) oder Google Cloud Platform (GCP) gehostete Managed-Private-Cluster-Version von OpenShift sowie

• 4. OpenShift Origin, ein von Red Hat gefördertes Community-Projekt, dass wie für Red Hat üblich den Sourcecode von OpenShift der Allgemeinheit zugänglich macht.

Neuentwicklungen der Community-Version fließen nach deren Test und Stabilisierung mit zeitlicher Verzögerung in die Enterprise-Version ein. Für das Erstellen neuer Anwendungen in OpenShift stehen Entwicklern prinzipiell drei Möglichkeiten zur Verfügung, nämlich Browser-basiert, per CLI oder mit Hilfe einer IDE wie z. B. Eclipse.

Aufbau von OpenShift

Den grundsätzlichen Aufbau von OpenShift zeigt die nebenstehende Abbildung. Eigentlich zeigt das Bild nur die Sicht der Infrastruktur. OpenShift besteht im Kern aus einer Reihe von Nodes (hier rot gekennzeichnet), die Knoten auf denen die Workloads betrieben werden. Die Knoten laufen unter Red Hat Enterprise Linux, wobei ein oder mehrere Master Nodes (diese laufen ebenfalls unter RHEL) unter anderem die Koordination der Workloads übernehmen.

Der OpenShift Master Node kümmert sich um das Verwalten einer oder mehrerer Instanzen der Nodes und stellt für Entwickler über die implementierte RESTful API die Schnittstelle zur Kommunikation mit OpenShift zur Verfügung. Nur angedeutet ist zudem ein Service-Layer, der die Service-Adressierung ermöglich, d. h. ein Container auf Node 1 einen Service auf Node 2 finden und nutzen kann.

Die Workloads selbst heißen bei OpenShift „Pods“, sind aber letztendlich Docker-Container. Der Begriff Pod entstammt dabei der Kubernetes-Welt und kennzeichnet aus Sicht des Orchestrierungsframeworks die kleinste Entität, die Kubernetes wahrnimmt. Praktisch gesehen sind Pods Docker-Container, wobei ein Pod aber auch mehrere Container enthalten kann. Die Beziehung zwischen Docker-Image, Plain-Docker-Container und Pod zeigt nebenstehen Abbildung:

Ebenfalls nicht direkt abgebildet ist, dass die Knoten untereinander und mit dem Master über ein softwaredefiniertes Netzwerk (SDN) verbunden sind, das eine Knoten-übergreifende Kommunikation auf Basis logischer Netzwerke ermöglicht. Die Architektur aus Sicht des Kubernetes Clusters sieht dann eher so aus wie in folgender Abbildung. Gut erkennbar (rot) sind auch die Eintrittspunkte Dev/Ops und Visitors.

Der Routing-Layer ist in der Architektur-Abbildung ebenfalls nur angedeutet und besitzt in Bezug auf die Eintrittspunkte Visitor und Dev/Ops zwei essentielle Baugruppen, nämlich die Komponente „Router“ im Kubernetes-Cluster und der „Replication Controller“ im Master-Node, wobei letzterer im Wesentlichen für das Pod-Scaling verantwortlich ist.

Vorbereitungen für OpenShift 3.4

Docker-Setup für die OpenShift Container Plattform

Der Replication Controller stellt sicher, dass zu jeder Zeit eine bestimmte Anzahl Replicas von jedem Pod laufen, und instanziiert bei Bedarf die benötigten Pods. Laufen mehr Pods als gewünscht, löscht er so viele Pods wie nötig. Daher beinhaltet die Konfiguration des Replication Controllers die Anzahl gewünschter Replicas, welche sich zur Laufzeit anpassen lässt, eine Pod-Definition, die er beim Erstellen eine Replik heranzieht und einem „selector“, um die verwalteten Pods sicher zu identifizieren.

Ferner ist im Kubernetes-Cluster die pauschal als „Router“ bezeichnete Komponente zu erkennen, die sich zusammen mit der Service-Komponente um das Ingess-Routing kümmert. Die Router-Komponente in OpenShift Container Platform ist der sogenannte „ingress point“ für jeglichen externen Traffic, der irgendwelche Ziele innerhalb der Container-Plattform adressiert.

Die OpenShift Container Platform unterstützt dazu zwei Router-Plugins. Per Default kommt das HAProxy template router–Plugin zum Einsatz. Es nutzt das Image openshift3/ose-haproxy-router, um eine HAProxy Instanz parallel zum Template Router-Plugin in einem OpenShift Container zu starten.

Dazu muss man wissen, dass sämtliche OpenShift-Komponenten seit der Version 3 selbst Docker-Container sind. Es unterstützt HTTP(S) und TLS-Traffic bled Traffic via SNI. Die Container des Routers horchen am Netzwerkinterface des Hosts, aber nicht wie die meisten Container nur auf dessen privater IP. Vielmehr „proxied” der Router externe Routing-Anfragen zur IP des adressierten Pods, den er über den Service identifiziert, der mit der Route assoziiert ist. Die Komponente agiert also als Layer7-LB/Reverse-Proxy.

Setzt z. B. ein Feuerwerk an Web-Anfragen z. B. ein E-Commerce-App-Tier oder einen containerisierten LAMP-Stack unter Last, sorgt das mittels Kubernestes realisierte Load Balancing dafür, dass anfragende Nutzer und Services nichts davon mitbekommen, ob sie es mit fünf oder 5000 Webservern zu tun haben.

Fazit

Mit der OpenShift Container Platform können Unternehmen relativ einfach eine eigene Applikationsplattform implementieren, mit der sie Anwendungen in der Cloud entwickeln und betreiben können. Die Plattform selbst lässt sich bei OpenShift Container Platform wahlweise on premise oder in der Public-, Private- bzw. Hybrid-Cloud betreiben.

Beim On-Premise-Einsatz wird die OpenShift Container Platform auf Basis von Red Hat Enterprise Linux (RHEL) installiert. Diese könnte jedoch problemlos auch virtualisiert laufen. Die Virtualisierungsplattform muss dabei nicht zwingend Red Hat Virtualization (RHV) sein. Als Middleware unterstützt OpenShift Enterprise die JBoss Enterprise Application Platform 6 und ist für Java EE 6 zertifiziert. Vertrieben wird OpenShift Container-Plattform wie bei Red Hat üblich im Rahmen eines Subskriptionsmodells.

Manch ein Unternehmen möchte vielleicht eine eigene OpenShift-Plattform betreiben, scheut aber den Aufwand für Implementierung, Betrieb und Operations. Hier empfiehlt sich OpenShift Dedicated, ein von Red Hat verwalteter und wahlweise auf AWS oder GCE gehosteter Cloud-Service.

Der Unterschied zu OpenShift Online besteht darin, dass Unternehmen dann tatsächlich über ihre eigene PaaS verfügen. Sie müssen also keine Ressourcen mit anderen Unternehmen teilen und entscheiden auch selbst über den Service-Umfang und das „Coming Out“ ihrer PaaS.

OpenShift Container Platform installieren

Der Quick Installation Mode von OpenShift

(ID:44571776)