Читать книгу Spring Boot - Mark Heckler - Страница 10

Vor langer, langer Zeit, als Application-Server über die Erde streiften, waren Deployments von Java-Anwendungen eine komplexe Angelegenheit.

Um eine funktionierende Anwendung mit z.B. Datenbankzugriff auf den Weg zu bringen – wie bei vielen Microservices heutzutage und fast allen Monolithen damals und heute –, müssten Sie Folgendes tun:

1 Installieren und Konfigurieren des Application-Servers

2 Installieren der Datenbanktreiber

3 Erzeugen einer Datenbankverbindung

4 Erzeugen eines Connection Pools

5 Kompilieren und Testen Ihrer Anwendung

6 Deployment Ihrer Anwendung und deren (meist zahlreichen) Abhängigkeiten auf dem Application-Server

Diese Liste geht übrigens davon aus, dass Administratoren die Maschine/virtuelle Maschine für Sie konfigurieren und Sie irgendwann einmal unabhängig von diesem Prozess die Datenbank erzeugt haben.

Spring Boot stellte einen Großteil dieses schwerfälligen Deployment-Prozesses auf den Kopf und fasste die genannten Schritte zu einem einzigen Schritt zusammen – vielleicht auch zwei, falls Sie das Kopieren oder Verschieben einer einzelnen Datei (mit cf push) als tatsächlichen Schritt betrachten wollen.

Spring Boot war nicht der Ursprung des sogenannten Über-JAR, hat es aber revolutioniert. Anstatt jede Datei aus dem Anwendungs-JAR und allen abhängigen JARs herauszukitzeln, sie dann zu einem einzigen Ziel-JAR zu kombinieren – ein Vorgang, der manchmal als Shading bezeichnet wird –, gingen die Entwickler von Spring Boot die Sache von einer ganz neuen Seite an: Was wäre, wenn wir JARs schachteln und dabei ihr vorgesehenes und übergebenes Format beibehalten könnten?

Das Schachteln von JARs anstelle des Shading behebt viele potenzielle Probleme, da uns keine etwaigen Versionskonflikte begegnen werden, wenn Abhängigkeit JAR A und Abhängigkeit JAR B jeweils eine andere Version von C benutzen; es lässt auch potenzielle rechtliche Probleme verschwinden, die auftreten, wenn man Software neu packt und sie mit anderer Software kombiniert, die eine andere Lizenz verwendet. Behält man alle abhängigen JARs in ihrem Ursprungsformat, dann vermeidet man ganz geschickt diese und andere Probleme.

Es ist außerdem trivial, den Inhalt eines ausführbaren JAR in Spring Boot zu extrahieren, sollten Sie dies wünschen. Unter bestimmten Umständen gibt es gute Gründe dafür, und ich werde darauf in diesem Buch eingehen. Für den Augenblick reicht es, zu wissen, dass das ausführbare JAR in Spring Boot für Sie da ist.

Das einzelne Spring-Boot-JAR mit all den Abhängigkeiten macht das Deployment zu einem Kinderspiel. Anstatt alle Abhängigkeiten zu sammeln und sicherzustellen, dass sie deployt werden, sorgt das Spring-Boot-Plug-in dafür, dass sie in das Ausgabe-JAR eingebunden werden. Ist das erledigt, kann die Anwendung überall ausgeführt werden, wo es eine Java Virtual Machine (JVM) gibt. Es reicht, dazu einen Befehl wie java -jar <SpringBootAppName.jar> auszuführen.

Da gibt es aber noch mehr.

Durch Einstellen einer einzigen Eigenschaft in Ihrer Build-Datei kann das Spring-Boot-Build-Plug-in dieses eine JAR vollständig (selbst) ausführbar machen. Immer noch unter der Voraussetzung, dass es eine JVM gibt, müssen Sie nun nicht die ganze lästige Zeile java -jar <SpringBootAppName.jar eintippen, sondern können die Ausführung mit einem einfachen <SpringBootAppName.jar> erreichen (natürlich müssen Sie hier Ihren eigenen Dateinamen einsetzen) – das war es auch schon. Einfacher geht es wirklich nicht.