Unser Weg zu Managed OpenShift 4

Red Hat OpenShift 4

Diesen Sommer hat Red Hat OpenShift 4 veröffentlicht. Auf den ersten Blick handelt es sich bei der neuen Major Version um eine stetige Weiterentwicklung von OpenShift 3 mit relativ überschaubaren Änderungen für den Anwender. Schaut man jedoch unter die Haube, dann erkennt man schnell ein vollständig überarbeitetes OpenShift. Der Blogpost von Benjamin Affolter auf dem APPUiO Blog untersucht die Änderungen von OpenShift 4 und beschreibt sie im Detail.

Mit dem nachfolgenden Artikel möchten wir hinter die Kulissen unseres Managed OpenShift Angebotes schauen und erklären, was wir alles zu tun haben, um unseren Managed Service mit OpenShift 4 anbieten zu können.

Vorteile von OpenShift 4

Red Hat verspricht mit Version 4 von OpenShift unter anderem folgende Verbesserungen:

• Neuer Installer
• Komplett automatisierte Operations, Wartung und Konfiguration mittels Operators
• Integration von Operator Hub
• Aktuelle Versionen von Kubernetes

Um die Vorteile und auch Auswirkungen zu verstehen, müssen wir einen Schritt zurückgehen und uns OpenShift 3 anschauen.

Managed OpenShift 3 – Was ist alles dabei?

Zum Verständnis ein kurzer Überblick, was unser bisheriger Managed OpenShift 3 Service alles beinhaltet (nicht abschliessend):

• Architektur Engineering und Aufbau des OpenShift Cluster auf nahezu beliebiger Infrastruktur (Cloud, On-Premise)
• Monitoring aller Cluster-relevanten Komponenten zur Sicherstellung des Betriebs
• Regelmässiges Backup der Cluster Konfiguration inkl. Sicherstellung der Integrität des Backups
• Wöchentliche Wartung aller Systeme, Einspielung von Softwarepatches und Konfigurationsverbesserungen auf allen Clustern
• Automatisierung aller Arbeiten mittels Ansible (Konfiguration, Wartung, Updates, Upgrades, Installation, Sanity Checks und vieles mehr)
• Integration in unser zentrales Kundenportal für einen Überblick über den Zustand des Clusters und weiterer Funktionen
• Umfangreiche Dashboards in Grafana
• Enge Zusammenarbeit mit dem Red Hat Support u.a. zur Lösung von Bugs in OpenShift
• Unterhalt diverser interner Lab Cluster um Änderungen an produktiven Clustern testen zu können
• Bereitstellung von Persistentem Storage mittels Gluster
• Management und Pflege des Betriebssystems Red Hat Enterprise Linux für die OpenShift Master und Nodes
• Ausbildung von System Engineers um OpenShift betreiben zu können

Alle diese aufgelisteten Punkte sind seit der allerersten Version von OpenShift 3 entwickelt worden und werden täglich von unseren VSHNeers weiterentwickelt.

Status Quo VSHN Systeme

Aus technischer Sicht sieht unsere heutige Systemlandschaft in etwa so aus (Kurzübersicht):

• Puppet für das lokale Betriebssystem Management aller VMs (Systemkonfiguration, Aufrechterhaltung des definierten Zustandes) und Inventarisierung aller Systeme und Services
• Icinga2 fürs Monitoring aller Betriebssystem Parameter innerhalb der VM, aber auch sehr umfangreiche Checks aller OpenShift Cluster Komponenten. Icinga2 wird durch Puppet konfiguriert und orchestriert.
• Ansible zur Installation und Konfiguration von OpenShift, zur regelmässigen Wartung und für vieles mehr
• BURP für konsistente Datenbackups inkl. Cluster Konfiguration, konfiguriert und orchestriert durch Puppet
• Gluster für Persistent Storage, verwaltet mittels Ansible

Über die Jahre haben sich unzählige Ansible Playbooks gesammelt und unser ganzes Wissen und die Automatisierung steckt in diesen Playbooks. Wir pflegen unseren eigenen Fork vom offiziellen OpenShift Ansible Repository, um schnell auf eventuelle Bugs reagieren zu können. Diesen Fork halten wir regelmässig auf dem aktuellen Stand mit Upstream.
Puppet kümmert sich nicht nur um die lokale Betriebssystem Konfiguration, sondern steuert auch viele wichtige Komponenten wie das Monitoring und Backup System. Zudem haben wir mittels der PuppetDB ein stets aktuelles Inventar aller von uns gemanagten Systeme inkl. detaillierter Versionsangaben der installierten Komponenten. Dies ist auch in unserem Kundenportal integriert und wird zur automatischen Verrechnung unserer Managed Services verwendet.
Die von uns entwickelten Monitoring Plugins für Icinga2 decken nahezu jedes von uns bis heute entdeckte Problem mit OpenShift ab und melden uns, wenn etwas mit dem Cluster oder einer Komponente davon nicht mehr in Ordnung sein sollte.
Unsere Systemdokumentation und die Anleitung zum Betrieb von OpenShift umfassen mehrere dutzend Wiki Artikel.

Managed OpenShift 4 – Was gibt es für VSHN zu tun?

Aus Sicht des System Engineering ist OpenShift 4 ein komplett neues Produkt. Für VSHN bedeutet das, dass wir einen grossen Teil der genannten Punkte vollständig neu entwickeln müssen.
Ein paar Beispiele:

• Die Installation und Konfiguration von OpenShift 4 basiert nicht mehr auf Ansible, sondern auf einem eigenen Installer (benutzt im Hintergrund Terraform) und die Konfiguration geschieht mittels In-Cluster Operators. Unsere Ansible Playbooks für OpenShift 3 können zum grössten Teil nicht mehr für OpenShift 4 verwendet werden.
• Als Betriebssystem kommt nicht mehr Red Hat Enterprise Linux zum Einsatz, sondern Red Hat CoreOS, dass sich komplett anders verhält. Puppet kann so nicht mehr eingesetzt werden und wie oben beschrieben müssen wir andere Wege finden für die Inventarisierung, Orchestrierung und Verrechnung der Umsysteme.
• Unsere Monitoring Plugins für Icinga2 sind nicht mehr mit OpenShift 4 kompatibel und das Monitoring Konzept mit Icinga2 passt nicht mehr auf die überarbeitete Architektur der Plattform. Das bedeutet für uns eine Neuentwicklung unseres Monitoring Konzepts.
• Das Backup System BURP kann nicht mehr in der heutigen Form eingesetzt werden, ein neues Backup System muss erarbeitet werden.

Dies ist keine abschliessende Liste, es gibt noch viele weitere Details in unserer Systemlandschaft, die angepasst werden müssen.

Der Weg in die Produktion

Für uns als Managed Service Provider ist Stabilität und Skalierbarkeit das A und O und keine Verhandlungssache. Das bedeutet, dass wir uns die notwendige Zeit nehmen müssen, um alle Änderungen und Eigenheiten für einen produktiven Betrieb von OpenShift 4 zu lernen. Die Anpassung und das Erarbeiten der notwendigen Tools und Prozesse für den Betrieb dutzender Cluster benötigt viel Zeit und Engineering Aufwand. Wir haben aber bereits früh begonnen und konnten schon erste Erfahrungen mit OpenShift 4 sammeln. Die Erfahrungen stimmen uns sehr zuversichtlich, dass OpenShift 4 seine Versprechen für einen stark vereinfachten Betrieb einhalten kann.
Die aktuelle Version OpenShift 4.1 hat aber auch noch ein paar Einschränkungen. Hier eine kleine Auswahl, was uns aufgefallen ist:

• Kein Support für Proxies
• AWS und VMware sind die einzigen unterstützten IaaS Provider mit OpenShift 4.1 (aktuelle Version zum Zeitpunkt dieses Artikels)
• Installation auf nicht unterstützten und nicht-Cloud Plattformen ist sehr fragil
• Container Storage nur über CSI

Viele IaaS Provider sind zum jetzigen Zeitpunkt noch nicht bereit für OpenShift 4. Wir stehen jedoch in engem Kontakt mit unseren IaaS & Cloud Partnern wie cloudscale.ch, Exoscale, Swisscom und AWS, um die Kompatibilität herstellen zu können, damit wir auch mit OpenShift 4 künftig einen reibungslosen Betrieb anbieten können.
OpenShift 4.1 erinnert uns teilweise an die Anfangszeiten von OpenShift 3, damals benötigte es auch einige Zeit, bis OpenShift 3 für den Produktivbetrieb bereit war.
Wir sind aber sehr zuversichtlich, dass die offenen Punkte noch gelöst werden können und freuen uns auf die 4. Generation von Red Hat OpenShift!

Weitere Infos

Unsere Freunde von Adfinis SyGroup haben in ihrem Blogpost „OpenShift 4 – Learnings aus der ersten produktiven Umgebung“ ihre ersten Erfahrungen mit OpenShift 4 beschrieben, dies deckt sich sehr gut mit unseren bisherigen Beobachtungen.
Wenn du mehr zum Thema OpenShift und Kubernetes erfahren willst, empfehlen wir dir unseren Artikel „Was ist eine Kubernetes Distribution und was sind die Unterschiede zwischen Kubernetes und OpenShift“ oder schau dir die Impressionen vom Red Hat Forum Zürich 2019 an, wo wir mit APPUiO wieder als Sponsor mit einem Stand vor Ort waren.

APPUiO – Swiss Container Platform

Mit APPUiO.ch haben wir eine auf Red Hat OpenShift basierende Schweizer Containerplattform geschaffen, auf der wir Managed Services als PaaS-Lösung (Platform-as-a-Service) auf beliebiger Infrastruktur anbieten können: public, dedicated, private und on-premises. Auf Basis bewährter Open Source Konzepte wie Docker und Kubernetes entwickelst, betreibst und skalierst du eine Anwendung nach deinen Bedürfnissen. Mit APPUiO können deine Applikationen sowohl auf Public Clouds als auch unternehmensintern betrieben werden. Die Plattform wurde 2015 von den beiden IT-Spezialisten Puzzle ITC und VSHN AG ursprünglich für die Professionalisierung der internen IT entwickelt. Heute wird APPUiO bereits von etlichen Kunden produktiv eingesetzt und wird von einer starken Community gestützt.

Wie können wir helfen?

Durch unsere Erfahrung im Betrieb von OpenShift Clustern rund um die Welt bieten wir Managed OpenShift Cluster auf nahezu jeder Public, Private oder On-Premise Cloud an. Wir helfen gerne bei der Evaluation, Integration und Betrieb und unterstützen mit unserer langjährigen Kubernetes Erfahrung. Kontaktiere uns, abonniere unseren Newsletter und folge uns auf Twitter (@vshn_ch und @APPUiO) oder wirf einen Blick auf unsere Services.
Wir freuen uns auf dein Feedback!