Wie sich die Besonderheiten der Arbeit mit Anwendungsservern am OpenLiberty-Beispiel ändern

Hallo Habr!

Die Rede von Sebastian Dashner bei einem Java-Treffen im Moskauer Büro von IBM (eine Aufzeichnung einer ähnlichen Leistung) veranlasste mich, mich mit leichten Anwendungsservern, insbesondere OpenLiberty, vertraut zu machen. Und dann dachte ich:

1. Was sind die Vorteile eines leichten Anwendungsservers?
2. Wie ändert sich die Spezifität der Arbeit bei ihrer Verwendung?
3. Warum einen Anwendungsserver in einen Container packen?

Bei der Beantwortung dieser Fragen stellte ich fest, dass es zu diesem Thema nicht viele öffentliche Informationen gibt. Deshalb habe ich beschlossen, diese hier zu sammeln und zu systematisieren.

Ich poste die Ergebnisse unter dem Schnitt.

Was sind die Vorteile eines leichten Anwendungsservers?

Früher galten Java EE-Anwendungsserver für Unternehmen (wie JBoss AS, Oracle WebLogic und IBM WebSphere AS) als schwergewichtiges und umständliches Design, insbesondere in Bezug auf Start- und Bereitstellungszeiten. Die Cloud-Technologie erfasst jedoch einen immer größeren Teil der Branche, und die Anforderungen an Anwendungsserver ändern sich.

Und jetzt kommen anstelle von voll ausgestatteten Enterprise-Anwendungsservern schnelle, modulare, kleine Anwendungsserver, die sich auf eine bestimmte Aufgabe konzentrieren: Thorntail , Payara Micro - die jüngeren Brüder WildFly und Payara; Meecrowave ist ein leichter JAX-RS + CDI + JSON-Server. KumuluzEE ist ein Server, mit dem Sie Java EE mithilfe von Node.js, Go und anderen erweitern können.

Diese Liste enthält auch OpenLiberty - einen Open Source-Anwendungsserver (gemäß EPL-1.0 verteilt), der die neuesten Java EE / Microprofile-Standards unterstützt, auf denen WebSphere Liberty ausgeführt wird.


Lassen Sie uns sehen, welche Vorteile wir durch die Bereitstellung der Anwendung in einem Container mit OpenLiberty erzielen können. (Sie müssen eine beliebige Java-Version installiert haben. Weitere Schritte müssen im wlp-Verzeichnis ausgeführt werden.)

Geschwindigkeit:

Geschwindigkeit ist der wichtigste Indikator für eine Cloud-Anwendung, denn damit eine Cloud-Anwendung die wachsende Last schnell skalieren, verwalten und bewältigen kann, muss sie in Sekunden gestartet werden. Ein leichter Anwendungsserver kann dies tun. Laden Sie zur Überprüfung den OpenLiberty-Server herunter und führen Sie bin / server run aus ( vollständige Liste der Befehle ):

$ bin/server run  defaultServer (Open Liberty 19.0.0.6/wlp-1.0.29.cl190620190617-1530)  Java HotSpot(TM) 64-Bit Server VM  1.8.0_212-b10 (ru_US) [AUDIT ] CWWKE0001I:  defaultServer . [AUDIT ] CWWKZ0058I:   dropins  . [AUDIT ] CWWKF0012I:     : [el-3.0, jsp-2.3, servlet-3.1]. [AUDIT ] CWWKF0011I:  defaultServer      .  defaultServer   1,709 . 

Modularität und Flexibilität

Die meisten Anwendungen benötigen kein Java EE als Ganzes, sondern spezielle Standards, die am häufigsten in Unternehmensanwendungen verwendet werden. Dank OSGI können wir die benötigten Java EE- und / oder MicroProfile-Standards auswählen und alles andere ignorieren.

Deklarieren Sie beispielsweise JAX-RS aus Java EE und mpHealth aus Microprofile, indem Sie dem featureManager-Block usr / servers / serverName /server.xml einige Zeilen hinzufügen

 <?xml version="1.0" encoding="UTF-8"?> <server description="new server"> <!-- Enable features --> <featureManager> <feature>jsp-2.3</feature> <feature>mpHealth-1.0</feature> <feature>jaxrs-2.1</feature> </featureManager> <!-- To access this server from a remote client add a host attribute to the following element, eg host="*" --> <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" /> <!-- Automatically expand WAR files and EAR files --> <applicationManager autoExpand="true"/> </server> 

Dynamisches Update

Während der Entwicklung ändern sich Programmcode und Konfiguration ständig.
Der Anwendungsserver ist so konfiguriert, dass Änderungen überwacht werden, und konfiguriert die Anwendung bei Bedarf im laufenden Betrieb neu und stellt sie bereit. Zum Beispiel eine Reaktion auf die jüngsten Änderungen:

 [AUDIT ] CWWKG0016I:    . [AUDIT ] CWWKG0017I:      0,475 . [AUDIT ] CWWKF0012I:     : [cdi-2.0, jaxrs-2.1, jaxrsClient-2.1, jndi-1.0, json-1.0, jsonp-1.1, mpHealth-1.0, servlet-4.0]. [AUDIT ] CWWKF0013I:     : [servlet-3.1]. [AUDIT ] CWWKF0008I:     0,476 . 

Bildgröße und Montage

Die Größe der Anwendungsserver hat sich erheblich verringert und ermöglicht Ihnen nun die Bereitstellung
Jede Anwendung auf einem separaten Anwendungsserver zum Verpacken in Containern bietet die größte Flexibilität. Darüber hinaus seit Das Image besteht aus Ebenen. Beim Zusammensetzen und Verteilen von Artefakten wird nur die Anwendungsebene kopiert, das Betriebssystem, die Laufzeit und der Anwendungsserver werden zwischengespeichert.

Dockerhub verfügt über vorgefertigte Images, die einen vorkonfigurierten OpenLiberty-Server enthalten. Wir werden eine davon verwenden und eine Docker-Datei erstellen:

 FROM open-liberty COPY usr/servers/defaultServer /opt/ol/wlp/usr/servers/defaultServer ENTRYPOINT ["/opt/ol/wlp/bin/server", "run"] CMD ["defaultServer"] 

Lassen Sie uns das Bild zusammenstellen:

 docker build -t app . 

Führen Sie es als Container aus:

 docker run -d --name app -p 9080:9080 app 

Überprüfen Sie das Ergebnis http: // localhost: 9080 / health /



So stoppen Sie den Container:

 docker stop app 

Es gibt viele weitere Szenarien für die Verwendung des Containers, und im Allgemeinen ist dies eine Gelegenheit für einzelne Artikel. Kehren wir also zu den Fragen zurück.

Wie verändert sich die Spezifität der Arbeit?

Paketpaket

Das Container-Image darf nur einmal erfasst und dann in allen Umgebungen ausgeführt werden. Daher wird empfohlen, jede Anwendung zusammen mit dem Anwendungsserver zu sammeln. Dies vereinfacht den Lebenszyklus und die Bereitstellung von Anwendungen und passt perfekt in die moderne Welt der Containertechnologie.

Montage

Jetzt ist es nicht mehr erforderlich, verschiedene technische Blöcke in separate Archive zu packen. Die gesamte Geschäftslogik sowie die Webdienste und End-to-End-Funktionen sind in einer einzigen War-Datei zusammengefasst. Dies vereinfacht die Installation des Projekts sowie den Montagevorgang erheblich. Sie müssen die Anwendung nicht mehr in mehrere Hierarchieebenen packen und dann erneut in eine Serverinstanz entpacken.

Starten

Während des Erstellungsprozesses werden sowohl der Anwendungsserver als auch die Anwendung selbst zum Image hinzugefügt. Die mögliche Konfiguration von Datenquellen, Laufwerken oder Servermodulen wird auch während des Erstellungsprozesses durch Hinzufügen spezieller Konfigurationsdateien festgelegt. Alle Konfigurationsunterschiede sollten nicht innerhalb der Anwendung, sondern von außen verwaltet werden. Daher sollte die Anwendung nicht in einem bereits ausgeführten Container bereitgestellt, sondern in der Phase der Image-Assemblierung im automatischen Bereitstellungsverzeichnis hinzugefügt werden, um sie beim Start des Containers zu starten.

Funktionserweiterung

Container, Bereitstellungs- und Skalierungssysteme, Überwachungsdienste und Servicegitter gaben uns die Möglichkeit, Erkennung, Überwachung, Verwaltung, Authentifizierung, Skalierung, Ablaufverfolgung und Stabilität über der Anwendung zu konfigurieren, eine große Menge an Logik transparent auf eine andere Ebene zu übertragen, die Anwendung zu vereinfachen und ihre Entwicklung zu vereinfachen.

Warum einen Anwendungsserver in einen Container packen?

Indem Sie einen Anwendungsserver in einen Container packen, geben Sie jedem Team die Möglichkeit, seinen Anwendungsserver unabhängig zu konfigurieren und sich auf die Implementierung von Funktionen zu konzentrieren. Dies spart Entwicklern Zeit bei manuellen Vorgängen, Middleware und verschiedenen Genehmigungen.

Als Bonus erhalten Sie die Möglichkeit, die Vorteile von Containern und allen darauf basierenden Werkzeugen voll zu nutzen. Die Anwendung ist einfach zu verwalten und zu skalieren, zu aktualisieren und zu automatisieren, um Artefakte ohne Ausfallzeiten zusammenzustellen und bereitzustellen.