258 VIEWS

Openshift: Service Discovery

22.06.2016

In meinem vorherigen Blogpost https://blog.doubleslash.de/neue-anwendungen-openshift-origin-erstellen/ habe ich eine kleine Beispielanwendung mit zwei Pods (Wildfly/MySQL) erstellt.

Das Wildfly Image unterstützt von Haus aus sogenannte ServiceDiscovery. Aber was ist das und wozu brauche ich das?

ServiceDiscovery beschreib bei Openshift eine Möglichkeit Services automatisch zu finden.

In Openshift werden IP Adressen dynamisch vergeben. Das bedeutet, dass ein Pod, der einmal verfügbar war einen Endpunkt im IP Bereich 10.168.* bekommt. Beim nächsten Start oder bei Skalierung wird ein neuer Endpunkt generiert und dem Container zugewiesen.

Somit kann ein Zusammenspiel von Containern nicht zuverlässig funktionieren. Ausserdem würde das Loadbalancing zum Container keinen Effekt haben, wenn es lediglich möglich ist einen Pod als Ziel zu konfigurieren.

Openshift stellt hier sogenannte Services als Bindeglied zwischen Routing und Container bereit. Ein Service bekommt wie ein Container eine IP. Diese ist jedoch in einem anderen Bereich (per Default 172.30.*). Der Vorteil der Service IP ist, dass diese einmal für die Laufzeit des Services vergeben wird. Über die eine Service IP wird auch das Loadbalanceing zum eigentlichen Pod durchgeführt.

Über nachfolgenden Befehl kann man sehen, dass die Beispielanwendung zwei Services beinhaltet (bitte vorher einen Login machen und in das Projekt „real-life-app“ wechseln). Für das Beispiel habe ich den Wildfly auf zwei Pods skaliert.

In der Übersicht sieht man zum einen die zugewiesene IP des Services und die IPs der Endpoints.

Um zu zeigen, wie die mysql Service IP im Wildfly über das Environmen ausgelesen werden kann, logge ich mich auf einen der Pods mit dem Befehl „oc rsh“ ein.

Alle Variablen, die aus einem Serice kommen haben folgendes Muster <SERVICE_NAME>_.

Der Wildfly geht beim Start her und analysiert die Environment-Variablen. Hier ein Auszug aus der Datei „/wildfly/bin/standalone.conf“ der dafür zuständig ist.

Die Datasource in der Datei /wildfly/standalone/configuration/standalone.xml wird ebenfalls über die Datei „/wildfly/bin/standalone.conf“ vor dem Start manipuliert, in dem mit „sed“ Platzhalter ersetzt werden.

Solange die Service IP verfügbar ist funktioniert das einwandfrei. Beim Wechsel der Service IP (passiert nur durch Neuanlage des Services) müssen lediglich die Wildfly Pods neu gestartet werden. Leider ergibt sich hieraus eine Reihenfolge was die Starts der Services angeht. Der MySQL Service muss vor dem Start der Wildfly Pods verfügbar sein.

Eine weitere Art der Service Discovery bietet Kubernetes im Zusammenspiel mit dem Cluster-Addon DNS. Hier wird zusätzlich ein DNS Server verwendet um Services unter ihrem Namen zu registrieren.

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*