Seit Anfang 2019 ist Red Hat OpenShift in der Version 4 verfügbar. Die Version 3 (genauer 3.11) ist noch bis 2022 offiziell unterstützt [1]. Wir haben das stark überarbeitete Produkt frühzeitig unter die Lupe genommen und erste Erfahrungen gesammelt. Inzwischen betreiben wir die erste produktive Kundenumgebung auf Basis von OpenShift 4.1. Dieser Blog beschäftigt sich also mit unseren Learnings und beleuchtet ein paar Spezialitäten von OpenShift 4.

Die Basis

Red Hat hat mit dem Wechsel von OpenShift auf die Version 4 sehr grosse Änderungen eingeführt. Das zugrundeliegende Betriebssystem wurde mit Red Hat CoreOS ersetzt. Die OpenShift Nodes werden nicht mehr klassisch mit Ansible oder von Hand gepatched, CoreOS installiert die Updates “over the air”, vollständig selbstständig mit Hilfe von Ignition Configs.

Die OpenShift Komponenten, die bei der Version 3 noch als Prozess auf den Mastern oder als App in einem Pod betrieben wurden, finden sich heute in der Form eines Operators wieder. Red Hat setzt damit stärker auf die Kubernetes Standards und wird einige Eigenheiten los.

 

Was ändert sich?

Als System Integrator kann nur sehr bedingt auf die Erfahrungen mit OpenShift 3 zurückgegriffen werden. Die Installation und Integration von OpenShift 4 ist nicht mehr mit der früheren Methode zu vergleichen. Der Konsument/Entwickler hingegen erhält immer noch die gleich ausgereifte und umfangreiche Lösung und muss sich nicht umstellen. Seine Möglichkeiten erweitern sich, ohne alte Gewohnheiten aufgeben zu müssen. Für den System Engineer und das Operations Team ändert sich dafür ALLES und zwar GRUNDLEGEND.

 

Der OpenShift Installer: Aus Red Hat Ansible wird HashiCorp Terraform

Die Installations-Routine von OpenShift 4 entstand mit dem Fokus auf Public Cloud Umgebungen und dem Ansatz der vollständigen Automatisierung. Der frühere ansible-installer für OpenShift 3 hat zwar auch sehr viel Automatisierung mitgebracht, die Basis-Infrastruktur (VMs, Netzwerke, Storage) musste jeder selber erstellen bzw. automatisieren. Diesen Umstand haben wir im Rahmen eines Kundenprojekts zu korrigieren versucht und waren damit erfolgreich. Dazu haben wir den Ansible Installer von Red Hat mit Terraform Code ergänzt. Das Ziel war eine von Grund auf automatisierbare Installation, die alle Komponenten miteinbezieht und auf den grossen Cloud Providern funktioniert.

Plot Twist: Kurz nach der Fertigstellung der ersten Version, die vor allem auf AWS fokussiert war, hat Red Hat die neuen Installationsmethoden für OpenShift 4 öffentlich gemacht (GitHub Repo auf public gesetzt).

 

 

Mit Erstaunen und gleichzeitiger Begeisterung mussten wir die vielen Parallelen erkennen, was unsere eigene, um Terraform erweiterte Version, in der Bedeutungslosigkeit verschwinden liess. Nichtsdestotrotz nutzen wir den Code immer noch bei einigen Kunden und werden das auch noch so lange tun, wie OpenShift 3 im Einsatz ist.

Natürlich funktioniert ein vollständig automatisierter Installer nur, wenn die Infrastruktur auch eine API dafür anbietet. Das machen die grossen Cloud Provider, aber auch Lösungen wie OpenStack oder VmWare. Der OpenShift 4 Installer kann vorerst aber nur mit AWS und VMware umgehen, braucht man etwas anderes, bleibt einem nur eine sehr mühsame und schlecht dokumentierte manuelle Installation übrig. Wir durften bisher nur letzteres umsetzen, obwohl zwei der Installationen auf VMware waren. Die automatisierte Installation hat einige Voraussetzungen, die sich nicht auf jeder VMware Plattform umsetzen lassen.

 

First Hand Experience & Learnings

Unser Kunde betrieb bis vor kurzem ein OpenShift 3.6. Mit der Gefahr eines auslaufenden Supports und mit dem Wissen, diverse Funktionen zu vermissen, wurde zuerst ein Update auf 3.11 angestrebt. Im Rahmen der konzeptionellen Arbeiten und bedingt durch einige Verzögerungen, wurde dann doch OpenShift 4.1 als Zielplattform definiert. Ein Upgrade von OpenShift 3.11 auf OpenShift 4.1 ist nur mittels Sidegrade möglich, ein Upgrade-Pfad steht nicht zur Verfügung.

OpenShift 4.1 hat noch nicht die Qualität, die wir uns von OpenShift 3.11 gewohnt sind. Die Bare Metal Installation setzt umfangreiches Know-How voraus und ausserdem eine “Hacker Attitude”. Die Gründe kurz zusammengefasst:

• Mangelnder Proxy Support bei Version 4.1**
• Grundlegende Änderung der DNS Struktur für Cloud Installationen
• DHCP zwingend erforderlich**

**lässt sich umgehen

Die Installation der Master und Worker Nodes auf VMWare mussten wir mittels Bare Metal Installation angehen [2]. Die direkte Anbindung an Vsphere war aus Sicherheitsgründen nicht möglich. Beim Bootstrappen der Nodes, musste darauf geachtet werden, dass eine fixe IP gesetzt ist. Ein DHCP war in diesem VLAN nicht verfügbar (wird vom Installer vorausgesetzt). Die CoreOS ISO wurde dabei mittels dracut boot Parameter übergeben [3]. Nach der CoreOS Installation ergänzten wir manuell die Proxy Konfiguration, da ohne kein Weg ins Internet führt. Eine offizielle Proxy Unterstützung kommt erst mit OpenShift 4.2, also hoffentlich noch dieses Jahr.

Die Bootstrap Node wird nur für die Installation der Master Nodes benötigt. Ab dann kümmern sich die Master Nodes um das Bootstrappen der Worker Nodes. Das Bootstrap System kann nach der OS Installation gelöscht werden.

Die gesamte Konfiguration des Clusters basierte ab jetzt auf Day 2 Deployments. D.h. dass alle weitere Konfigurationen wie bspw. Anbindung an ein LDAP oder einspielen der eigene CA und eines Zertifikats für den Ingress-Router, mittels der OpenShift API umgesetzt wird. Ein direkter SSH Zugriff auf den Nodes ist nur bei Troubleshooting oder in dringenden Fällen vorgesehen. Die Maschinen werden nach jedem SSH Login entsprechend in der API markiert, so dass zu jedem Zeitpunkt ersichtlich ist, auf welchem Node ein Shell Zugriff stattgefunden hat.

Für die Datenpersistierung stellte unser Kunde einen NFS Server zur Verfügung, auf dem wir mittels nfs-client-provisioner [4] ganze PVs durch OpenShift provisionieren liessen. OpenShift wird ab Version 4 inklusive Prometheus und Grafana installiert. Auch einen ELK Stack hochzufahren ist dank einfachem Deployment über Operatoren ein Kinderspiel [5].

Bei der Migration der Applikationen mussten wir wieder erfinderisch werden. Ohne die Hoheit über die DNS Zone ist eine Applikations-Migration eine grössere Herausforderung.  Wir wollten nicht alle Applikationen auf einmal migrieren, deshalb entwarfen wir eine Lösung, welche die Migration ohne weitere DNS Anpassungen möglich machte. Wir deployten einzelne Applikationen auf dem neuen Cluster und lenkten den Traffic mittels Socat-Proxies vom alten Cluster auf den neuen. Nach der erfolgreichen Migration, blieb nur die Anpassung des Wildcard DNS Eintrags und schon erreicht kein Traffic mehr die alten Cluster. Die Migration verlief ohne Probleme und Ausfälle.

 

Fazit

OpenShift 4 wird das beste OpenShift werden. Dazu müssen jedoch noch einige Stolpersteine aus dem Weg geräumt werden. Wir erhielten den Eindruck, dass Red Hat mit der Version 4.1 nur eine Beta Version veröffentlicht hat, um die stabile Version mit 4.2 in einigen Monaten nachzureichen. Auch wenn die Installation auf eine Cloudumgebung wie AWS jetzt schon viel einfacher ist, bleibt der grosse Teil der Schweizer Kundeninstallationen “on-prem”. Für den Schweizer Markt ist der starke Fokus auf Cloud Installation aktuell noch ein Hindernis.

Plant ihr ein OpenShift 4 Projekt oder eine Migration – kommt auf uns zu, wir wissen wie es geht.