Auf Kubernetes basierende Platform as a Service Container-Orchestrierung mit Red Hat OpenShift

Anbieter zum Thema

OutSystems

Red Hat GmbH

Ein Kubernetes-Cluster mit Docker-Containern zu pflegen ist keine ganz triviale Angelegenheit. Red Hat OpenShift setzt sich über diesen Kosmos und vereinfacht die Verwaltung von Clustern und vor allem das Deployment von Anwendungen.

Docker hat sich als Container-Plattform durchgesetzt und Kubernetes als Orchestrierungswerkzeug. Insbesondere Kubernetes verlangt im Alltag aber viele kleinteilige Aktionen und eine Menge Fachwissen über Cluster und deren „innere Werte“. Die aktuell vielleicht populärste Schnittstelle zu Kubernetes/Docker ist das bereits vorgestellte Rancher, das ein ähnliches Leistungsspektrum anbietet.

Der wohl größte Unterschied zwischen OpenShift und Rancher: Rancher legt sich über ein reguläres Kubernetes-Cluster und erlaubt weiterhin die Steuerung über native Kubernetes-Tools – Sie können sich also auch wieder von Rancher trennen. OpenShift setzt hingegen auf ein eigenes Tooling, eine Rückkehr zum Vanilla-Kubernetes ist nicht möglich.

Rancher ist zudem ein reines Open-Source-Projekt. OpenShift hingegen meint genau genommen eine ganze Produktreihe, die neben diversen PaaS-Angeboten die quelloffene „Origin Community Distribution of Kubernetes“ (OKD/Origin) beinhaltet. Nicht ganz unwichtig für den (erstmaligen) Test einer Container-Orchestrierung: Rancher lässt sich in wenigen Stunden aufsetzen, OpenShift verlangt bisweilen einige Tage.

Generell ist der Einstieg in OpenShift deutlich aufwändiger, nicht zuletzt wegen der eher suboptimalen Dokumentation. Mit IBM/Red Hat und den PaaS-Angeboten im Hintergrund steht jedoch reichlich Support zur Verfügung. Wie Sie OpenShift über das ebenfalls quelloffene Projekt OpenShift CodeReady Containers dennoch mit geringem Aufwand anspielen können, erläutern wir weiter unten.

OpenShift Container Platform

Die eigentliche Anwendung ist die quelloffene OpenShift Container Platform (OCP). Sehr vereinfacht gesagt ist es eine Erweiterung der Kubernetes-Funktionen, um Abläufe zu vereinfachenund zu automatisieren. Dabei kommen Red-Hat-Technologien zum Einsatz, auch aus dem darunter liegenden Red Hat Enterprise Linux.

Entsprechend läuft OpenShift offiziell auch nur unter RHEL, CentOS und Fedora. Die Plattform lässt sich sowohl auf eigener Infrastruktur als auch bei diversen Cloud-Anbietern einrichten, etwa Microsoft Azure, was den Installationsprozess auf wenige Klicks reduziert.

OCP ist eine vollständige Plattform, zum Erstellen, Anbieten und Verwalten von Microservices und orientiert sich konzeptionell an den üblichen Grundbausteinen:

• Image: Nur lesbare Abbilder von Root-Dateisystemen als Grundlage für Container.

• Container: Aktive, laufende Instanz eines Images als Grundlage für Pods.

• Pod: Ein oder mehrere Container auf einem Host, zusammengeschlossen, mit gemeinsamem Speicher.

• Service: OCP-interner Load Balancer; ermöglicht Kommunikation zwischen Anwendungen.

• Route: Dient als externer Load Balancer und exponiert Services für den Zugriff von außen (Nutzer).

• Application: Die eigentliche Anwendung.

Aus Anwendungssicht sieht es vereinfacht also aus wie üblich: Der Zugriff auf eine Applikation (etwa ein Apache-Server) erfolgt über die IP eines Pods, praktisch also die angegebene Route (etwa http://httpd-example-myproject.apps-crc.testing auf der Testplattform). In der Praxis ist das Einrichten eines solchen Servers ziemlich trivial: Über den eingebauten App-Store (Developer Catalog) läuft alles mit ein paar Klicks, ein Import via Git, Image, Dockerfile oder YAML/JSON ist ebenfalls möglich.

In OpenShift gibt es zudem Operators (spezielle Kubernetes-Controller), die aus dem integrierten „OperatorHub“ eingerichtet werden können. Dabei handelt es sich um Add-ons auf Cluster-Ebene, die sich um die Verwaltung von Apps kümmern. Beispielsweise kann ein Cluster-Admin aus dem OperatorHub den Grafana-Operator installieren, woraufhin ein Entwickler über den Developer Catalog die Grafana-App einrichten kann.

Soweit zum Konzept. Vielleicht fragen Sie sich, was OpenShift denn überhaupt bringt, im Vergleich zum reinen Kubernetes. Es sind vor allem die Vereinfachungen, die schnell ins Auge fallen. Die Einrichtung von Clustern über die Plattform ist deutlich simpler, gleiches gilt für das Aufsetzen von Anwendungen über den App-Store und auch Standardaufgaben im Bereich DevOps: die allgemeine Verwaltung und der Einstieg fallen hier einfacher.

Insbesondere die grafische Bedienung über die Web-GUI ist für viele Nutzer angenehmer. Die GUI lässt sich, mit ein wenig Erfahrung mit Containern/Clustern, weitgehend intuitiv nutzen. Neue Cluster, Pods, Apps und sonstige Ressourcen sind meist nur ein paar Klicks entfernt. Dennoch wird bei einigen Erweiterungen ein wenig manuelle Arbeit in Config-Dateien verlangt.

Alternativ lässt sich OpenShift auch über das CLI-Werkzeug „oc“ bedienen, quasi das OpenShift-Equivalent zum Kubernetes-Standard „kubectl“. Und genau hier zeigt sich ein großer Unterschied, der eher gegen OpenShift spricht: Kubernetes ist ein recht reifes System, das von der Cloud Native Computing Foundation (CNCF) betreut wird, die wiederum zur Linux Foundation gehört, und arbeitet mit möglichst vielen Standard-Tools. OpenShift hingegen kocht an einigen Stellen ein eigenes Süppchen und konzentriert sich eher auf den großen Einsatz in Unternehmen.

An einigen Stellen geht das sehr gut auf, an anderen weniger. So ist die Dokumentation zu OpenShift alles andere als optimal. Im Dezember 2019 wurde mit dem 4er Release zudem vieles so weit umgestoßen, dass etliche Artikel von Dritten im Netz schlicht nicht mehr funktionieren. Und auch die Berichte über Fehler bei Installation, Updates und Betrieb sind recht zahlreich. Vornehmlich ist OpenShift aber sicherlich auf den PaaS-Betrieb ausgelegt, so dass die Vorteile beim reinen Betrieb durchaus gegeben sind.

CodeReady Containers

Bis Version 3 war die Standardvorgehensweise zum lokalen Testen von OpenShift das Tool minishift, seit Version 4 läuft es über OpenShift CodeReady Containers. Dabei gibt es recht hohe Systemanforderungen und einige Punkte zum Abarbeiten. Ob der ständigen Änderungen ist es schwierig vorauszusagen, wie lange dieser Weg so funktioniert, derzeit und auf einem frischen System läuft es einwandfrei.

Am Ende haben Sie eine komplette OCP-Test-Installation auf einem einzelnen Rechner und können nach Belieben Cluster und Apps aufsetzen. Voraussetzungen: Für den Bare-Metal-Test benötigen Sie RHEL, CentOS oder Fedora in einer aktuellen Version – hier kam Fedora zum Einsatz, wobei dies als Bleeding-Edge-Distribution eigentlich nicht die beste aber modernste Wahl ist. Außerdem werden 4 CPUs und 8 Gigabyte Arbeitsspeicher (rein für die Verwaltung) auf echter Hardware verlangt.

In virtuellen Maschinen läuft CodeReady Containers nicht ohne weiteres, da es selbst auf Virtualisierung basiert. Schließlich müssen Sie sich noch ein Red-Hat-Entwicklerkonto einrichten, da Sie nur dort den Download finden und zudem einen Token benötigen.

Die Einrichtung Schritt für Schritt:

1. Intel-Virtualisierungstechnologie im BIOS aktivieren; standardmäßig nicht immer aktiviert.

2. Heruntergeladene CRC-Datei entpacken und crc-Binary nach „/usr/local/bin“ kopieren.

3. Virtualisierung in Fedora einrichten und starten:

4. CRC einrichten (Ausgabe enthält Login-Informationen und Anweisungen!):

5. Einloggen und testen per CLI:

6. Aufruf der Weboberfläche (Anmelden mit Login-Informationen aus Schritt 4):

Mit dem letzten Schritt landen Sie in der Weboberfläche im Browser. Um hier nun eine Test-App, den Apache-Server zu installieren, gehen Sie wie folgt vor:

• 1. Legen Sie als Administrator unter „Home/Projects“ ein Projekt „Projekt1“ an.

• 2. Rufen Sie „Home/Projects/Workloads“ auf.

• 3. Klicken Sie auf den „add other content“-Link im Hauptbereich.

• 4. Wählen Sie anschließend „From Catalog“ und dort „Apache HTTP Server (httpd)“, dann „Create“.

• 5. Vergeben Sie einen Namen für die App und geben Sie das aufgeführte „Sample repository“ als „Git Repo URL“ an – erstellen Sie dann über den „Create“-Knopf.

• 6. Klicken Sie anschließend auf die eben erstellte Anwendung und warten Sie ein paar Minuten, bis etwaige Fehlermeldungen verschwunden sind.

• 7. Öffnen Sie rechts den Reiter „Resources“ und folgen Sie dem Link unter „Routes“.

Falls Sie sich mal verirren: Sie erreichen den Link zu Ihrer Anwendung über folgenden Klickpfad: „Home → Projects → PROJEKTNAME → Workloads → APPNAME → Resources“. Wenn alles geklappt hat, erreichen Sie über diese Route eine simple, statische HTML-Seite.

Von diesem Punkt an lässt sich eigentlich ganz gut mit OpenShift herumexperimentieren – immer noch die beste Möglichkeit, eine Software kennen zu lernen. Die initiale Einrichtung ist nicht wirklich intuitiv oder auch nur gut erklärt; aber sobald es einmal läuft, läuft es rund.

Ein Tipp zum Schluss: Ein wenig Geduld ist hilfreich, je nach verfügbaren Ressourcen dauert das Starten, Stoppen und Einrichten von OCP, Clustern, Pods und Apps ein wenig – zwei Minuten Stillstand oder Fehlermeldungen sind nicht selten.

(ID:46488363)