Quarkus: eine lokale Umgebung für mehrere Services
Quarkus hat den Teil schon gelöst, den die meisten Frameworks schlecht machen: der Dev Mode lädt beim Speichern neu, und die Dev Services starten dir einen Container für die Datenbank, die du zu starten vergessen hast. Was er nicht löst, ist der Service nebenan, und auch nicht der nächste.
Wo der Dev Mode aufhört
- Er ist pro Service. Fünf Services sind fünf Terminals, fünf Dev Modes und sich zu merken, welchen Port jeder genommen hat.
- Die Dev Services sind ebenfalls pro Service. Jeder, der eine Datenbank will, bringt seinen eigenen Container mit. Das ist gut zum Isolieren und schlecht für einen Ablauf, in dem drei Services dasselbe Kafka-Topic lesen.
- Die URLs zwischen den Services bleiben deine Sache. Jede
@ConfigPropertyoder Basis-URL eines REST-Clients, die auf einen anderen Service zeigt, muss irgendwohin zeigen, wenn du nicht das ganze System startest. - Die Reihenfolge zählt weiterhin. Der Reload hilft nicht, wenn die Abhängigkeit beim Start des Aufrufers nicht geantwortet hat.
Was Aseptic hinzufügt
Aseptic erkennt einen Quarkus-Service an seinem Manifest und startet ihn als nativen
Prozess mit deinem Build-Werkzeug, wobei es die Konfiguration beim Start als
-D-Properties oder Umgebungsvariablen injiziert. Die URLs zwischen den Services
werden dort umgeschrieben, application.properties bleibt also exakt so, wie es
in git steht.
Ein Szenario ist der Ablauf: die beteiligten Services, die Reihenfolge, die sie brauchen, und wo jede Abhängigkeit aufgelöst wird —ein lokaler Service, eure gemeinsame Cloud-Umgebung oder ein Mock—. Kollidierende Ports werden remappt, und der neue Wert ist der, der den Aufrufern mitgeteilt wird.
Für die gemeinsame Infrastruktur startet Aseptic Kafka, Redis und PostgreSQL einmal in Docker, für das ganze Szenario, und lässt alle Services auf dieselbe Instanz zeigen. Das ist der Unterschied zu den Dev Services: ein Broker, den der Ablauf teilt, statt einem pro Service. Wenn du für einen bestimmten Lauf die Dev Services bevorzugst, hindert dich nichts daran: Aseptic startet deinen Service so, wie du es ihm sagst.
Bibliotheken, die du gleichzeitig änderst
Wenn die Funktion einen Service und eine deiner Bibliotheken umfasst, baut Aseptic die Bibliothek und verlinkt sie dort, wo Maven und Gradle sie auflösen, und baut und verlinkt sie bei Änderungen neu. Die Build-Datei des Verbrauchers wird nie geändert, und das Aufheben der Verknüpfung macht nur rückgängig, was Aseptic gesetzt hat.
Was es nicht tut
Es ersetzt den Dev Mode nicht, und sollte es auch nicht: beim Speichern neu zu laden ist Sache von Quarkus, und es macht das besser, als irgendein Starter es beitragen könnte. Es baut keine nativen Images und führt keinen Kubernetes-Cluster aus, alles, was du auf dieser Ebene prüfen musst, gehört also woandershin. Und es braucht Docker für die gemeinsame Infrastruktur.
Es ist in öffentlicher Beta, erscheint für Windows, macOS und Linux und ist kostenlos für private Nutzung.
Neben den Alternativen
Wenn deine Services schon containerisiert sind und mit Manifesten deployt werden, die du pflegst, geben dir Tilt und Skaffold eine Schleife in der Form der Produktion. Die Seite Docker-Compose-Alternativen deckt das ganze Feld ab.
Es gibt Entsprechungen dieser Seite für Spring Boot und für Node.
Häufige Fragen
Reicht mir der Dev Mode von Quarkus nicht?
Für einen Service ist er hervorragend. Was der Dev Mode nicht löst, ist, wer die anderen startet, in welcher Reihenfolge und wogegen: sobald der Ablauf durch drei Services geht, bleibt dieser Teil deiner.
Bricht Aseptic den Hot Reload von Quarkus?
Nein. Der Service wird als nativer Prozess mit seinem eigenen Befehl gestartet, der Hot Reload ist also der gewohnte.
Kann ich Quarkus mit Services eines anderen Stacks mischen?
Ja. Die Engine trägt keine Logik einer bestimmten Technologie: jeder Stack hat sein Profil, und sie können in einem Szenario koexistieren.