Offline-Installation von Red Hat OpenShift mit Hilfe von orcharhino

Im letzten Jahr hat sich Kubernetes als Industriestandard für Containerplattformen herauskristallisiert. Mittlerweile gibt es einige auf Kubernetes basierende Plattformen, die mit einem eigenem Interface und vorkonfigurierten Diensten sowie Zusatzfeatures angeboten werden. Immer häufiger kommt beispielsweise die von Red Hat „OpenShift“ getaufte Containerplattform zum Einsatz.

Warum OpenShift offline installieren?

In vielen Unternehmen sind Entwicklungs- und Testumgebungen in eigene Netzwerke abgekapselt und somit gesichert. Dadurch ist weder ein Zugriff auf‘s noch vom Internet möglich. Schon die übliche Installation von OpenShift ist etwas komplex. Mit dem Anspruch, die Umgebung offline aufzusetzen, erhöht sich die Komplexität noch einmal deutlich.

Wir haben‘s ausprobiert und zeigen, welche Dinge es bei der Offline Installation zu beachten gilt. Verwendet haben wir dazu OpenShift mit dem entsprechenden Ansible-Installer und unserem Tool orcharhino:

Was ist OpenShift?

OpenShift ist eine Containerplattform von Red Hat, basierend auf Kubernetes.

OpenShift Origin und OpenShift Enterprise

Davon existiert – wie bei Red Hat üblich – sowohl eine Enterprise-Variante mit einem Subskriptionsmodell (OpenShift Enterprise) als auch eine Open-Source-Variante (OpenShift Origin).

In OpenShift Origin werden neue Features integriert und sobald diese stabil funktionieren in die Enterprise-Variante aufgenommen. Neben den üblichen Features einer Containerplattform wie die Mandatenfähigkeit, Hochverfügbarkeit, Orchestrierungstools sowie integrierten Diensten für Logging und Monitoring, bildet eine Ansammlung von Entwicklertools das besondere Feature von OpenShift.

Entwicklerfunktionen und Source-to-Image-Builds

Diese reicht von einem integrierten, containerisierten Jenkins über Webhooks für git-Repositories bis hin zu OpenShifts Source-to-Image-Builds (S2I). Mit S2I können Entwickler ihren Code in einem git-Repository direkt an OpenShift geben. Dafür können sie das entsprechende Entwicklungsframework verwenden. Geben sie dieses nicht an, entscheidet OpenShift anhand der Dateiendungen, welches Framework genutzt wird.

Anschließend startet OpenShift ein Basis-Image mit dem entsprechenden Framework. Im nächsten Schritt wird nun das Git-Verzeichnis geklont, die Anwendung gestartet und das daraus resultierende Container-Image in die integrierte OpenShift-Registry gespeichert.

orcharhino als Mirror für Repositories und Container-Images

Das zweite verwendete Tool ist orcharhino, basierend auf Foreman und Katello (ähnlich wie Redhat Satellite 6). Damit können Repositories synchronisiert und als Mirror bereitgestellt werden. In diesem Fall werden sowohl yum-Repositories als auch Container-Images für die Installation von OpenShift benötigt. Zusätzlich können Debian-Distributionen und SLES versorgt werden.

Lifecycle-Environments und Content Views

Mit den entsprechenden Lifecycle-Environments und Content Views können die Versionsstände eingefroren und festgesetzt werden. Dadurch werden stabile Paketstände für den produktiven Betrieb bereitgestellt. Über entsprechend angebundene Hypervisor können direkt die benötigten Server aufgesetzt werden. Ebenso sind baremetal-Lösungen möglich. Anschließend können über die integrierten Configuration Management Tools alle Server direkt auf die OpenShift-Installation vorbereitet werden.

Voraussetzungen für die Offline-Installation von OpenShift

Bei einer Offline-Installation muss gewährleistet sein, dass alle Repositories und Pakete verfügbar sind. Über orcharhino werden diese bereitgestellt.

Repositories, Pakete und Container-Images bereitstellen

Neben den Paketen müssen auch die Container-Images synchronisiert werden. Diese sind nötig, wenn OpenShift in der containerized-Variante installiert werden soll. Genauso ist das für entsprechende Dienste, die in OpenShift nach der Installation laufen sollen, notwendig.

OpenShift-Dienste für Metriken, Logs, Registry und Routing

Zu diesen Diensten gehört die Bereitstellung von Metriken, Verwaltung der Logs, einer Registry und des HAProxies für das Routing.

Container-Images mit orcharhino synchronisieren

Bei der Synchronisation von Container-Images mit orcharhino wird die Repostruktur verändert. Dadurch ändert sich die Namensgebung der Images.

Aus:

registry.access.redhat.com/openshift3/ose-haproxy-router:v3.7.46

wird mit orcharhino:

orcharhino.atix.demo:5000/ATIX-production-openshift_content-container_images-ose-haproxy-router:v3.7.46

gemäß folgendem Schema:

:5000/----:

Image-Namen im Ansible-Inventory berücksichtigen

Die verwendeten Quellen der Images sowie ihre veränderte Repostruktur gilt es nun noch im Ansible-Inventory für die Offline-Installation zu berücksichtigen. Anschließend kann OpenShift in einer Umgebung ohne direkten Internetzugriff aufgesetzt werden.

orcharhino als Registry für OpenShift verwenden

Dafür ist eine Verwendung von orcharhino als Registry notwendig. Für die Basis-Images kommen dann die folgenden Parameter für die Installation dazu:

openshift_docker_additional_registries=orcharhino.atix.demo:5000 
oreg_url=ATIX-production-openshift_content-container_images-ose-${component}:${version}

OpenShift in komplexen Offline-Umgebungen betreiben

Dabei ist es möglich, OpenShift über mehrere Netzwerke aufzuspannen. Beispielsweise können Test- und Entwicklungsumgebung getrennt sein, aber mit den gleichen Master-Servern verwaltet werden. Analog dazu können neue Umgebungen in eine bestehende Offline-Umgebung aufgenommen und Upgrades von bestehenden Installationen durchgeführt werden.

Dabei gilt: Je komplexer die Anforderungen, desto mehr muss beachtet werden. Die Grundzüge sind hier dargestellt – weitere Details sind stark davon abhängig, in welcher Umgebung und mit welchen Anforderungen die Containerplattform aufgesetzt wird.

Unterstützung bei der OpenShift-Offline-Installation

Bei Fragen zum Blogbeitrag oder wenn Sie Unterstützung bei der Installation einer komplexen OpenShift-Umgebung benötigen, können Sie sich jederzeit bei uns melden!