Mobile-Menu

OpenShift On-Premise OpenShift Container Plattform 3.4 installieren

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten |

Die Container-basierte PaaS-Lösung „Red Hat OpenShift Container Platform“ lässt sich im eigenen Rechenzentrum installieren und betreiben. In diesem Teil unseres OpenShift-Workshops zeigen wir, wie solch ein On-Premise-Ansatz aussehen kann.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH
Die On-Premise-Installation von OpenShift 3.4 erfordert komplexe Vorbereitungen.
Die On-Premise-Installation von OpenShift 3.4 erfordert komplexe Vorbereitungen.
(Bild: Red Hat)

Mit Zielsetzung, Konzept, Struktur und Architektur der Red Hat OpenShift Container Platform haben wir uns bereits in den ersten beiden Teilen dieses Workshops beschäftigt. Die Public-Cloud-Variante dürfte aber nicht jedes Unternehmen ansprechen, so dass wir näher auf die On-Premise-Installation eingehen wollen.

Red Hat OpenShift Container-Plattform unterstützt die beiden Installations-Methoden „Quick“ und „Advanced“. Während sich die Quick-Methode vor allem zur schnellen Evaluierung der OpenShift-Container-Plattform eignet, kommt für ein Development- und/oder Production-Setup meist die Advanced-Methode zum Einsatz.

Mit der letzteren Variante erhalten Unternehmen die größte Kontrolle über ihr Setup und ihre Umgebung. Welche Methode Unternehmen letztendlich wählen sollten, hängt von folgenden Faktoren ab:

  • Wieviele Hosts werden im Cluster benötigt? Hierzu stehen verschiedene Setup-Szenarien wie z. B. „Single Master and Multiple Nodes“, „Single Master, Multiple etcd and Multiple Nodes“ oder „Multiple Master Using Native HA“ (High Availability, Hochverfügbarkeit) zur Verfügung.
  • Wieviele Pods werden im Cluster benötigt?Die Red Hat OpenShift Container Plattform unterstützt maximal 1000 Nodes pro Cluster, 250 Pods pro Node, bzw. 10 Pods pro Core und insgesamt 120000 Pods pro Cluster.
  • Ist Hochverfügbarkeit erforderlich? Für Fault Tolerance z. B. ist HA die empfohlene Technik. In diesem Fall ist z. B. das Setup-Szenario „Multiple Master Using Native HA“ das passende.

Ferner besteht beim „Installationstyp“ die Möglichkeit, zwischen einer RPM-basierten und eine Container-basierten Installation zu wählen. Letzteres ist zwar inzwischen die bevorzugte Methode, es stellen aber letztendlich beide Methoden eine voll funktionsfähige Container-Platform-Umgebung zur Verfügung.

Wie bereits erwähnt lässt sich die OpenShift Container Platform auf physischen oder virtuellem Servern installieren. Letztere können im eigenen Rechenzentrum laufen oder bei Amazon Web Services (AWS), Google Compute Engine (GCE) oder Microsoft Azure. Red Hat stellt dazu in seinem Blog sehr hilfreiche Referenzarchitekturen zur Verfügung.

Wir demonstrieren in den folgenden Teilen das Setup auf Basis mithilfe VMware vSphere virtualisierter Server im eigenen Rechenzentrum. Bei der eigentlich Installation leistet Ansible wertvolle Unterstützung.

In diesem Teil der Workshop-Reihe geht es vorerst „nur“ um das Vorbereiten der Open-Shift-Master-Hosts sowie der OpenShift-Nodes. Hiermit ist gemeint, welche Repos unter Red Hat Enterprise Linux 7 (RHEL) oder RHEL Atomic Host einzubinden und welche Basis-Pakete zu installieren sind, etwa zur Bereitstellung von Docker.

Voraussetzungen

Zum Ausprobieren und/oder Installieren der OpenShift Container Platform sind folgende Voraussetzungen zu beachten. An erster Stelle benötigt man eine aktive Subskription von OpenShift Container Platform im eigenen Red-Hat-Account. Bei den infrastrukturellen Voraussetzungen gilt Folgendes:

  • Der Master Node benötigt entweder RHEL 7.3 mit der Installations-Option „Minimal“ oder RHEL Atomic Host 7.3.2. In Zusammenarbeit mit Docker 1.12 würde jedoch auch ein containerisiertes RHEL 7.2 funktionieren. Dabei lässt sich der Master-Node wahlweise physisch oder als virtuelle Maschine im eigenen Rechenzentrum bzw. als Instanz in der eigenen Cloud betreiben, alternativ dazu auch bei einem Public-Cloud-Anbieter wie AWS. Die Maschine benötigt zwei Rechenkerne (physisch oder virtuell, also CPUs oder vCPUs), mindestens 16 Gigabyte (GB) RAM und wenigstens 40 GB Diskspace für das Filesystem mit /var.
  • Die Nodes dürfen ebenfalls wahlweise physisch, virtuell oder als Cloud-Instanz laufen. Auch für das Betriebssystem gilt das gleiche wie für den Master-Node. Zwingend ist aber hier, dass der „NetworkManager“ in Version 1.0 oder höher läuft. Die Nodes kommen mit einer CPU/vCPU, 8 GB Arbeitsspeicher und 15 GB Harddisk für das Filesystem inkl. /var aus. Außerdem sind mindestens 15 GB nicht allockierter Festplattenplatz als Storage-Backend für Docker erforderlich. Dessen Konfiguration erläutern wir in einem folgenden Beitrag.
  • Aktuell speichert die OpenShift Container Platform Image-, Build- und Deployment-Metadaten in etcd. Sollen im Rahmen des Szenarios „Single Master, Multiple etcd and Multiple Nodes“ weitere externe etcd-Nodes zum Einsatz kommen, benötigen diese mindestens 20 GB Festplattenplatz für etcd-Daten. Nähere Informationen zu den Hardware-Anforderungen der etcd-Nodes finden sich auf Github. Unternehmen, die mit einer großen Anzahl an Images, Builds und Deployments planen, sollten etcd unbedingt auf Maschinen mit ausreichend Arbeitsspeicher platzieren, die zudem mit SSDs ausgestattet sind.

Vorbereitung des Master-Hosts

Startpunkt für das Aufsetzen einer OpenShift Container Platform Envrionment ist das Einrichten des Master-Nodes. Dieser muss wie bei Red Hat üblich mit dem „Red Hat Subscription Manager“ (RHSM) im Content-Delivery-Network registriert werden. Das klappt mit

subscription-manager register --username=<user_name> --password=<password>

Die für diesen Account verfügbaren Subscriptions zeigt der Parameter „list“. Verfügt man über eine gültige Subscription für die Container-Plattform (dazu zählt auch die nach Anlegen eines Red-Had-Kontos frei verfügbare Testversion), sollte sich diese über den Befehl

subscription-manager list --available --matches '*OpenShift*'

ausfindig machen lassen. Die hierbei angezeigte Pool-ID hängt man dann per „attach“-Option an den subscription-manager-Aufruf an:

subscription-manager attach --pool=<pool_id>

Um nicht beim Installieren der für den OpenShift-Master-Node benötigten Pakete über irgendwelche Altlasten etwaiger Vorinstallationen in RHEL zu stolpern, empfiehlt es sich, zunächst mit

subscription-manager repos --disable="*"

sämtliche für RHSM aktivieren Repositories zu deaktivieren und dann mit „yum repolist“ (bzw. bei Verwendung des neuen dnf-Paketmanagers mittels „dnf repolist“) eine frische Paketliste anzeigen zu lassen. Dazu muss man wissen, dass der subscription-manager eigene Werkzeuge zum Aktivieren und Deaktivieren von Repos mitbringt, welche in der Datei „redhat.repo“ stehen.

Optional kann man Repositories aber auch mit den Kommandos „yum-config-manager“ bzw. „dnf config-manager“ aktivieren oder deaktivieren, sofern das Paket „yum-utils“ respektive °dnf-utils“ installiert ist. Noch verbleibende Repositories kann der Nutzer daher am schnellsten mit

yum-config-manager --disable <repo_id>(dnf config-manager --disable <repo_id>)

deaktivieren oder schlicht und einfache ALLE mit

yum-config-manager --disable \*(dnf config-manager --disable \*)

Ist das geschehen, werden der Reihe nach wieder folgende drei Paketquellen für OpenShift Container Platform Version 3.4 aktiviert:

subscription-manager repos --enable="rhel-7-server-rpms" \ --enable="rhel-7-server-extras-rpms" \ --enable="rhel-7-server-ose-3.4-rpms"

Diese Paketquellen müssen eingebunden sein, um später einen RHEL-7-Host in einen OpenShift-Master-Noder verwandeln zu können.
Diese Paketquellen müssen eingebunden sein, um später einen RHEL-7-Host in einen OpenShift-Master-Noder verwandeln zu können.
(Bild: Thomas Drilling)

Danach können die für den Betrieb als OpenShift-Master benötigten Tools und Basis-Binaries installiert werden. Bei einem RHEL 7.3-Host geschieht das mit ….

yum install wget git net-tools bind-utils iptables-services bridge-utils bash-completion(dnf install wget git net-tools bind-utils iptables-services bridge-utils bash-completion)

Wie üblich aktualisiert man die bestehende Paket-Basis anschließend mit “yum update“ bzw. „dnf upgrade“.

Ferner wird noch das Paket „atomic-openshift-utils sowohl von der Quick- als auch von der Advanced-Installations-Methode benötigt. Es installiert die „OpenShift-Container-Platform“-Utilities”, die unter anderem auch von einer Installation/Konfiguration mittels Ansible Playbooks herangezogen werden.

Die wichigsten Binaries für den OpenShift-Betrieb.
Die wichigsten Binaries für den OpenShift-Betrieb.
(Bild: Thomas Drilling)

Im Folgenden kann bei der Verwendung von dnf einfach der yum-Befehl entsprechend ersetzt werden:

yum install atomic-openshift-utils

Damit RHEL stets auf der korrekten Version von Atomic und Docker operiert, empfiehlt Red Hat darüber hinaus, die beiden folgenden *-excluder-Pakete zu installieren:

yum install atomic-openshift-excluder atomic-openshift-docker-excluder

Diese ergänzen Einträge in der „exclude“-Directive der jeweiligen „/etc/yum.conf“-Datei jedes Hosts bei deren Installation. Folgendes Kommando entfernt die „atomic-openshift”-Pakete von der exclude.Liste jedes Hosts im Verlauf der Installation:

atomic-openshift-excluder unexclude

Für die Installation auf Basis vom RHEL-Atomic-Host-7 ist zunächst sicherzustellen, dass das System auf dem aktuellen Stand ist. Das Upgraden gelingt mit dann mit

atomic host upgrade

Danach ist das System mit

systemctl reboot

neu zu starten. Sind die Basis-Pakete für OpenSHift installiert, kann man sich der Docker-Installation auf sämtlichen Masten und Nodes zuwenden, wie in Teil vier unserer Workshop-Reihe beschrieben.

(ID:44598398)

Weiterführende Inhalte