Skip to content

OpenShift Einführung mit automatischen Deployments

2018 Mai 13
by Haf

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.

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:

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:

Log-Ausgabe vom Build

Auszug Log-Ausgabe mit Informationen über den Initiator

 

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.

GitHubhttps://github.com/haf-tech/spring-samples

Referenzen

 

Share it!
  •  
  •  
  •  
  •  
  •  
  •  
No comments yet

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS