OpenShift Einführung mit automatischen Deployments

Eine neue Applikation kann man doch gleich in der Cloud betreiben. Dabei sollte Automatisierung eine wichtige Rolle spielen und idealerweise bis zum Deployment angewendet werden; ganz im Sinne von CD. Im diesem Artikel wird beschrieben wie eine Spring Boot Application in eine OpenShift Instanz betrieben wird und dabei die Konfiguration so vorgenommen wird, dass jede Änderung des Source Codes automatisch zu einem neuen Build führt.

Überblick

OpenShift ist ein PaaS, basierend auf Kubernetes, und unterstützt neben dem Lebenszyklus einer Applikation (Build, Run, Scale) auch weitere Container Management Funktionalitäten wie z.b. Service Discovery, Routing, Monitoring und Loadbalancing. Es erweitert Kubernetes um

• Source Code Management mit Funktionalitäten für Build- und Deployment-Verwaltung
• Verwaltung von Images, inkl. deren Erstellung und Aufbewahrung im eigenen Registry.
• Sicherheit
• Netwerkinfrastruktur im Cluster-Umfeld

Eine detaillierte Einführung ist in der OpenShift Dokumentation [1] oder GitHub [2] zu finden. OpenShift kann lokal mit Hilfe von Minishift [3] ausprobiert werden; oder mit einem kostenlosem Account bei OpenShift.io. In diesem Artikel wird letzteres verwendet.

Konfiguration

Die neue Applikation wird in einem OpenShift Projekt bereitgestellt. OpenShifts Konzept Projekt basiert auf Kubernetes Namespace. Um eine neue Applikation in ein OpenShift Projekt bereitzustellen, wird ein Template erstellt, was alle notwendigen Objekte bereitstellt. Dadurch lassen sich ähnliche Applikationen einfach und einheitlich erstellen.

Das Template wird in eine YAML-Datei bereitgestellt und beinhaltet in unserem Fall folgende Objekte

• DeploymentConfig: Beschreibt das Deployment und klärt u.a. folgende Fragen

  • Wie viele Replikationen soll es geben?
  • Wie wird ein Deployment ausgelöst?
  • Wie sieht die Strategie zur Ablösung einer Vorgänger-Version beim Deployment?
  • Welche Ressourcen stehen zur Verfügung (RAM, CPU)?
  • Welche Quelle (Image) wird herangezogen?

• BuildConfig: Beschreibt den Transformationsprozess vom Source Code zum (Docker) Image. OpenShift unterstützt hier verschiedene Strategien, wie z.B. Source-to-Image (S2I), Docker Strategy oder Pipeline Strategy [4]. In dem Fall wird S2I verwendet und

  • ermittelt von GitHub den Source Code,
  • baut die Applikation mittels maven (relevante Maven Parameter werden mit angegeben),
  • anschließend wird ein Docker Image basierend auf "redhat-openjdk18-openshift" gebaut und ins interne Registry bereitgestellt.
  • Zusätzlich werden Auslöser registriert, so wird bei einer Code-Änderung in GitHub ein Build direkt angestoßen.
• Service: Services dienen als Fassade für alle Verbindungen zu einem Pod und definieren u.a. welche Ports aus dem Container erreichbar sein sollen. Ein Service ist für alle Pods zuständig, die einem bestimmten Label entsprechen.
• Route: Veröffentlicht einen Service über einen Hostnamen. Wenn kein Hostname angegeben wird generiert OpenShift einen. Die Verknüpfung zum Service wird mittels Servicenamen aufgebaut.

Um das Template für ähnliche Applikationen anzuwenden, werden jegliche Werte, die einen Namespace, Applikationsnamen, Secrets o.ä. repräsentieren, parametrisiert. Diese Parameter müssen bei der Erstellung der Applikationen mitgegeben werden.

# OC Login
$ oc login https://api.<region>.openshift.com --token=qo....

# Display current templates
$ oc get templates

# Create template
$ oc create -f .openshiftio/application-template.yaml

# Display current templates
$ oc get templates
NAME                     DESCRIPTION   PARAMETERS    OBJECTS
master-spring-template                 8 (1 blank)   5

# Create a new App using the template with setting parameters
oc new-app --template=master-spring-template -p APP_NAME=simple-data-provider -p SOURCE_REPOSITORY_URL=https://github.com/haf-tech/spring-samples  -p SOURCE_REF=master -p SOURCE_SUB_MODULE_DIR=simple-data-provider -p APP_HTTP_PORT=9021 -p WEBHOOK_GITHUB_SECRET=3... -p WEBHOOK_GENERIC_SECRET=9...

# Additional commands
# Delete a specific template
$ oc delete template master-spring-template

Das komplette Template ist in GitHub zu finden.

Build automatisch auslösen

Nun haben wir eine Applikation mittels einem Template eingesetzt. Dabei wurde das Deployment so konfiguriert, dass mittels einem WebHook ein Build ausgelöst werden kann. Es wurden zwei WebHooks eingerichtet:

• GitHub: Ein GitHub WebHook, so dass neue Commits zu einem neuen Build führen
• Generic: Ein generischer WebHook, für jegliche andere System-Integrationen

Beide WebHooks haben eins Gemeinsam, die Nutzung eines Secrets. Mit dem Secret Token kann verhindert werden, dass die Build-URL fälschlicherweise aufgerufen wird.

In GitHub lässt sich ein WebHook [5] für ein Repository unter Settings > Webhook einrichten. Die URL kann vom BuildConfig ermittelt werden:

# Retrieve buildConfig details, incl. WebHook URL for the bc name "simple-data-provider"
$ oc describe bc simple-data-provider

Name:		simple-data-provider
Namespace:	code-4
Created:	2 hours ago
Labels:		app=simple-data-provider
Description:	Build configuration with Source strategy from GitHub
Annotations:	openshift.io/generated-by=OpenShiftNewApp
Latest Version:	2

Strategy:	Source
URL:		https://github.com/haf-tech/spring-samples
Ref:		master
ContextDir:	simple-data-provider
Source Secret:	cd-github
From Image:	ImageStreamTag openshift/redhat-openjdk18-openshift:1.2
Output to:	ImageStreamTag simple-data-provider:latest

Build Run Policy:	Serial
Triggered by:		ImageChange, Config
Webhook Generic:
	URL:		https://api.<region>.openshift.com:443/apis/build.openshift.io/v1/namespaces/code-4/buildconfigs/simple-data-provider/webhooks/<secret>/generic
	AllowEnv:	false
Webhook GitHub:
	URL:	https://api.<reegion>.openshift.com:443/apis/build.openshift.io/v1/namespaces/code-4/buildconfigs/simple-data-provider/webhooks/<secret>/github

Die URL und den Secret kann dann nun in GitHub eingetragen werden.

Jeder neue Commit führt dann unverzüglich zur Ausführung eines neuen Builds:

[caption id="attachment_342" align="aligncenter" width="722"] ] [/caption]

Fazit

Basierend auf ein OpenShift Template lassen sich sehr einfach neue Applikationen bereitstellen. Dabei wird für jede Applikation mehrere Objekte eingerichtet, neben den Objekten für's Routing auch ein Build Configuration, mit der Information das mittels einem WebHook ein Build ausgelöst werden kann. Dadurch lässt sich ohne weiteres Zutun eine neue Version bauen und einsetzen.

In der Regel besteht der Build Prozess aus mehreren Schritten wie z.B. Ausführung verschiedener Tests, Qualitätsanalysen, Security Checks usw. Diese Schritte werden heutzutage mittels einem Build Pipeline beschrieben. OpenShift unterstützt als Build Strategy auch Pipelines. Dies wird in einem späteren Artikel vorgestellt.

Bis dahin erfreuen wir uns über die automatische Bereitstellung; was als Basis für weitere Konfigurationen und Automatisierungen dient.

GitHub: https://github.com/haf-tech/spring-samples

Referenzen

• [1] https://docs.openshift.org/latest/welcome/index.html
• [2] https://github.com/openshift/origin
• [3] https://docs.openshift.org/latest/minishift/index.html
• [4] https://docs.openshift.org/latest/devguide/builds/buildstrategies.html
• [5] https://developer.github.com/webhooks/