Developer

Aktuelle Themen

OpenShift Deployment mit dem fabric8-maven-plugin

Das Thema DevOps ist allgegenwärtig und viele Entwicklerteams sehen sich mit der Tatsache konfrontiert, dass sie ihre Anwendungen nicht nur bauen, sondern auch selbst betreiben müssen. Äußerst beliebt ist dabei derzeit natürlich Kubernetes oder auch OpenShift als Plattform. Doch die händische Pflege von Deploymentkonfigurationen kann mühsam sein. Hier kommt fabric8 ins Spiel: mit dem fabric8-maven-plugin lässt sich das Deployment nahtlos in den Buildprozess integrieren.

Sinnvolle Basiswerte werden durch die bereits bestehenden Einstellungen aus der POM ergänzt und können bei Bedarf gezielt überschrieben werden. Aber auch schon vor dem Deployment hilft das Plugin, denn es unterstützt auch bei der Erstellung eines Docker-Images. Je nach Umgebung ist es aber bei OpenShift nicht möglich, direkt mit Docker zu kommunizieren. Stattdessen gibt es hier die Variante des Source2Image Builds, welcher ebenfalls von fabric8 unterstützt wird.

Da die Dokumentation (https://maven.fabric8.io/) nicht unbedingt den leichtesten Einstieg bietet, gibt es hier eine kleine Hilfestellung.

Vorbereitung

Zuerst binden wir das Plugin ein:

Jetzt greift bereits der „Zero-Config“ Modus von fabric8. Mit den Voreinstellungen erarbeitet das Plugin selbstständig einen Plan für das zu bauende Image. Rufen wir also nun mvn package fabric8:build auf, wird unser Jarfile mit dem fabric8-Basisimage zu einem Dockerimage gebaut. Da wir aber davon ausgehen, keinen Zugriff auf Docker zu haben, müssen wir die erste Konfiguration vornehmen:


Image bauen

Mit diesen Properties wechselt fabric8 in den OpenShift-Modus. Diesmal führt der Aufruf von mvn package fabric8:build zu einem OpenShift Binary Build. Das bedingt, dass die OC Tools installiert und mit dem Zielcluster verbunden sind. Ist der Buildvorgang erfolgreich, dann existiert nun ein ImageStream mit der artifactId im gewählten Namespace (dieser lässt sich mit auch mit -Dfabric8.namespace beim Aufruf ändern). Als Basisimage wird bei der S2I-Strategy standardmäßig fabric8/s2i-java:latest verwendet. Möchte man das ändern, lässt sich das in der Pluginkonfiguration bewerkstelligen:


Deployment

Im nächsten Schritt kümmern wir uns um die Deploymentkonfiguration. Mit mvn fabric8:resource generiert uns das Plugin eine Reihe von YAML Dateien unter target/classes/META-INF/fabric8/openshift für das Deployment, den Service und die externe Route.

Auch wenn viele der hinterlegten Werte eine gute Ausgangsbasis sind, wollen wir doch meistens die ein oder andere Anpassung vornehmen. Bei uns hat sich im Realfall die Kombination aus einzelnen Definitionen in einer YAML-Datei und dem maven-resources-plugin bewährt. Dabei legen wir beispielsweise folgende Anpassungen fest (unter src/main/fabric8/deployment.yaml):

Wir wollen also das Speicherlimit des Containers festlegen. Dank des maven-resources-plugin können wir dafür dann eigene Properties oder auch die bereits vorhandenen (wie z.B. artifactId) verwenden. Das schaffen wir mit folgender Anpassung der POM:

Fabric8 fügt dann unsere konkreten Einstellungen und die Standardkonfiguration zum Endergebnis zusammen. Auf diese Weise lässt sich gezielt nach gewohntem Muster alles so konfigurieren, wie man möchte. Alternativ dazu bietet das Plugin auch viele Konfigurationsmöglichkeiten über die POM direkt an; dies stellte sich bei uns jedoch als zu unübersichtlich heraus.

Zu guter Letzt können wir nun mit mvn fabric8:apply die erstellten Ressourcen im Cluster anwenden und damit unsere Anwendung deployen.

Ausblick

Dank des Plugins lässt sich der Deploymentvorgang schnell vereinfachen. Wir kratzen dabei jedoch nur an der Oberfläche – fabric8 bietet noch sehr viel mehr. Wird die eigene Anwendung beispielsweise mit Spring bzw. Spring Boot entwickelt, erkennt fabric8 dies und passt die Konfiguration entsprechend an – inklusive Healthchecks für Spring Boot Actuator. Der klassische Weg mit dem Docker Daemon funktioniert natürlich auch und über mvn fabric8:watch bietet das Plugin sogar ein automatisches Redeployment bei Änderungen im Workspace.

Wer nun Interesse gefunden hat, dem sei trotz des etwas holprigen Einstiegs die ausführliche Dokumentation ans Herz gelegt, ergänzt durch das Handbuch des docker-maven-plugin, welches in das fabric8-maven-plugin integriert ist. Hier lassen sich manchmal ein paar ergänzende Informationen finden.

Rest in peace Oracle JRE & JavaFX – long live OpenJDK & OpenJFX

Rest in peace Oracle JRE & JavaFX

September the 25th was not only Release Day of Oracle JDK11, it was also funeral day for Oracle’s JRE and JavaFX. Almost silently, Oracle approached one more step further to remove Java from our desktops. ;-)

So, just before the end of 2018, I think it’s not too late to say:

„Goodbye Oracle’s JRE and JavaFX bundles. It was a pleasure working with you folks.“  

What happened?

Oracle JDK Migration Guide provides some Significant Changes in JDK 11 Release:

Mehr

Neue Features in Angular Material 7

Angular Material

Angular gehört zu den verbreitetsten Frontend Frameworks auf dem Markt. Angular bietet die Option ihre Layout-Library „Angular Material“ zu verwenden.

Angular Material steht unter MIT-Lizenz und adaptiert die Standards des Material Designs für Angular. Dabei erscheint eine Nutzeroberfläche im Stil des Material Designs.

Angular Material bietet viele vordefinierte UI Elemente wie beispielsweise: DatepickerTabellenCardsMenüsSlideruvm.

Mehr

WebAssembly: die Zukunft der Webapps?

Vielleicht haben Sie schon von WebAssembly (kurz: Wasm) gehört, denn immerhin gibt es zumindest die WebAssembly Community Group (W3C) schon seit April 2015. Inzwischen ist Wasm in der Version 1.0 verfügbar.
Doch was ist Wasm genau und wofür braucht man das? In diesem Blogbeitrag erfahren Sie alles dazu!

Was ist WebAssembly?

WebAssembly is a binary instruction format for a stack-based virtual machine.
Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

Kurz gesagt: WebAssembly ist ein neuer Typ Code. Er ermöglicht es Webanwendungen in C/C++ oder Rust zu implementieren und diese (fast – in einer Sandbox) nativ im Browser auszuführen. Dabei kann es auch in Kombination mit HTML/CSS verwendet werden [1].

Warum möchte man Webapps in einer maschinennahen Sprache implementieren und ausführen?

Gute Frage! Denn um Logik auf Webseiten zu implementieren, gibt es doch schon JavaScript? Wie wir aber alle wissen, ist JavaScript vergleichsweise leider sehr langsam. Das macht sich vor allem bei komplexen Webanwendungen wie z.B. bei der 3D Visualisierung im Browser bemerkbar.

Deshalb sind vor allem folgende Gründe dafür verantwortlich, dass es Wasm gibt:

  • Performance
  • Performance
  • Performance
  • und Performance [2] [3]

 

In folgender Demoanwendung kann man sehr gut selbst den Unterschied sehen, spüren und ausprobieren: WebAssembly VS JavaScript

  1. Link öffnen und oben rechts auf den Debug-Monitor klicken, bis die blaue FPS-Anzeige zu sehen ist
  2. Über das DropDown oben rechts kann zwischen Wasm und JS gewechselt werden
  3. Darunter kann die Anzahl der animierten Menschen erhöht/verringert werden

Im aktuellen Google Chrome Canary (Version 72.0.3610.0) erhalte ich z.B. bei 20 Menschen mit JS gerade mal ~13 FPS, mit Wasm ~30 FPS. Das sind mehr als 100% Performance-Steigerung!

Wie funktioniert WebAssembly im Browser?

Um den geschriebenen C/C++ Code zu WebAssembly zu kompilieren, gibt es emscripten. Mit emscripten kann über folgenden Befehl der Code zu Wasm kompiliert werden:

emcc hello.c -s WASM=1 -o hello.html

Um das ganze im Browser auszuführen, muss die jeweilige Browserengine auch Wasm unterstützen. In Chrome übernimmt das Ausführen von Wasm beispielsweise der Chrome Native Client in einer Sandbox.

Wer noch tiefer einsteigen möchte: https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/

Welche Browser bzw. Browserengines unterstützen WebAssembly?

WebAssembly Browserunterstützung

Man mag es kaum glauben, aber da sind sich alle (wichtigen) Browser (nicht Internet Explorer) einig: https://caniuse.com/#feat=wasm

Wird WebAssembly der Nachfolger von JavaScript?

Nein. Wasm ist als „schnelle Ergänzung“ für JavaScript gedacht [4].
Wasm wird in Zukunft parallel existieren und voraussichtlich nur bei besonders komplexen Webanwendungen zum Einsatz kommen (Rechenintensive Anwendungen, 3D, etc.).

 

Quellen:

[1] https://blog.logrocket.com/webassembly-how-and-why-559b7f96cd71

[2] https://www.lucidchart.com/techblog/2017/05/16/webassembly-overview-so-fast-so-fun-sorta-difficult/

[3] https://medium.com/samsung-internet-dev/performance-testing-web-assembly-vs-javascript-e07506fd5875

[4] https://de.wikipedia.org/wiki/WebAssembly

Einsatz der Content Security Policy (CSP)

Die Content Security Policy (CSP) ist ein Sicherheitskonzept, um Cross-Site-Scripting-Attacken (XSS) und andere Angriffe in Browsern zu verhindern. XSS beschreibt das Einbetten eines schädlichen Codes in einen anderen vermeintlich sicheren Kontext.

Durch die CSP werden beim Ausliefern der Webseite oder Webanwendung zusätzliche Meta-Tags übermittelt, die festlegen, welche „Vorgänge“ verhindert werden sollen. So kann z.B. das Ausführen von JavaScript-Dateien oder das Einbinden von Bildern, wenn diese nicht vom selben Server oder nicht von einer bestimmten Quelle stammen, unterbunden werden. Welche Inhalte gesperrt und welche erlaubt sind, wird durch die Angabe der Content-Security-Policy und dessen Parametern definiert.

Mehr