Applikationsserver WildFly 17 hat Cloud und Kubernetes im Blick
WildFly 17 bringt einen Launcher für OpenShift sowie einen Kubernetes-Operator mit, die das Zusammenspiel mit der Cloud-nativen Welt angenehmer machen sollen.
- Björn Bohn
Der Java-Anwendungsserver WildFly ist in Version 17 erschienen. Das neue Release soll vor allem den Einsatz von WildFly in Cloud-Umgebungen im Fokus haben und bringt dafür einen eigenen Launcher für OpenShift sowie einen Kubernetes-Operator mit, die das Handhaben von WildFly-Applikationen in der Cloud einfacher machen sollen. Darüber hinaus gibt es eine Reihe an Änderungen in den Bereichen Clustering und Messaging.
Cloud, OpenShift und Kubernetes
Wer auf Red Hats Container-Plattform OpenShift setzt, kann jetzt WildFly-Applikationen mit dem Fabric8 Launcher erzeugen. Dabei handelt es sich um eine integrierte Entwicklerplattform zum Erstellen Cloud-nativer Applikationen und Microservices. Er soll Continuous Delivery für OpenShift-Applikationen ermöglichen. Ebenfalls neu ist der WildFly-Operator für Kubernetes beziehungsweise OpenShift, mit dem Entwickler auf dem WildFly-Applikationsserver erstellte Java-Applikationen überwachen und konfigurieren können.
Bei einem Operator handelt es sich um einen applikationsspezifischen Controller, der die Kubernetes-API erweitert, um Instanzen einer komplexen statischen Anwendung für Kubernetes-Nutzer zu ermöglichen. Sie nutzen im Grunde Kubernetes-Ressourcen, verfügen aber über applikationsspezifische Informationen, um häufige Aufgaben zu automatisieren. Der WildFly-Operator findet sich in der von Red Hat, AWS, Google Cloud und Microsoft gestarteten Registry OperatorHub.io,
Das WildFly-Team hatte in Version 16 mit Galleon ein neues Provisioning-Werkzeug eingeführt. Das noch als technische Preview vorliegende Tool soll die nächste Generation von source-to-image (s2i) für WildFly vorantreiben. In der kommenden Woche sollen wohl Images auf Basis von WildFly 17 in der Docker-Container-Registry Quay landen.
Clustering, Messaging, JDK 12 und 13
WildFly-Nutzer können in der neuen Version ein separates Subsystem zum Konfigurieren verteilter Web-Session-Manager einsetzen. Das soll Anwendern helfen, häufige Konfigurationsfehler zu vermeiden. Außerdem soll ein neuer verteilter Session-Manager auf Basis von HotRod das Offloading von Session Caching an einen externen Infinispan-Caching-Dienst verbessert haben.
Auf Seiten des Messaging verfügt WildFly 17 über ein verbessertes Messaging-Cluster hinter HTTP-Load-Balancer durch das Ausschalten von automatischer Topologie-Updates auf den Clients. Ebenso können Nutzer nun den Timeout des Embedded Messaging Brokers beim Öffnen von Journal-Dateien konfigurieren. Zusätzlich gibt es Erweiterungen der Einstellungen für Verbindungen an externe AMQ-Broker.
Neben den zahlreichen Änderungen verspricht WildFly 17 auch einen Support für das Java Development Kit (JDK) 12. Es soll größtenteils stabil laufen, da die Testsuite von WildFly nur einige wenige Fehler in selten genutzten Bereichen aufgeworfen hat. Darüber hinaus laufen bereits Tests gegen die ersten Early-Access-Versionen des JDK 13, die laut den WildFly-Machern gut zu laufen scheinen.
Weitere Informationen zu den Neuerungen bietet der Blogbeitrag zum Release. Eine vollständige Liste der Änderungen findet sich in den Release Notes. (bbo)
