Kubernetes-Native Development with Quarkus and Eclipse JKube
This article explains what Eclipse JKube Remote Development is and how can it help developers build Kubernetes-native applications with Quarkus.
简介
As mentioned in my previous article, Kubernetes-native inner loop development with Quarkus, microservices don’t exist in a vacuum. They typically communicate with other services, such as databases, message brokers, or other microservices. Because of this distributed nature, developers often struggle to develop (and test!) individual microservices that are part of a larger system.
The previous article examines some common inner-loop development cycle challenges and shows how Quarkus, combined with other technologies, can help solve some of the challenges. Eclipse JKube Remote Development was not one of the technologies mentioned because it did not exist when the article was written. Now that it does exist, it certainly belongs to be mentioned.
What is Eclipse JKube Remote Development?
Eclipse JKube provides tools that help bring Java applications to Kubernetes and OpenShift. It is a collection of plugins and libraries for building container images and generating and deploying Kubernetes or OpenShift manifests.
Eclipse JKube Remote Development is a preview feature first released as part of Eclipse JKube 1.10. This new feature is centered around Kubernetes, allowing developers the ability to run and debug Java applications from a local machine while connected to a Kubernetes cluster. It is logically similar to placing a local development machine inside a Kubernetes cluster. Requests from the cluster can flow into a local development machine, while outgoing requests can flow back onto the cluster.
Remember this diagram from the first article using the Quarkus Superheroes?
We previously used Skupper as a proxy to connect a Kubernetes cluster to a local machine. As of the 1.10 release, Eclipse JKube removes the need to use Skupper or install any of its components on the Kubernetes cluster or your local machine. Eclipse JKube handles all the underlying communication to and from the Kubernetes cluster by mapping Kubernetes Service ports to and from the local machine.
Eclipse JKube Remote Development and Quarkus
The new Eclipse JKube Remote Development feature can make the Quarkus Superheroes example very interesting. If we wanted to reproduce the scenario shown in Figure 1, all we’d have to do is re-configure the rest-fights application locally a little bit and then run it in Quarkus dev mode.
First, deploy the Quarkus Superheroes to Kubernetes. Then, add the Eclipse JKube configuration into the <plugins> section in the rest-fights/pom.xml file:
<plugin>
<groupId>org.eclipse.jkube</groupId>
<artifactId>openshift-maven-plugin</artifactId>
<version>1.11.0</version>
<configuration>
<remoteDevelopment>
<localServices>
<localService>
<serviceName>rest-fights</serviceName>
<port>8082</port>
</localService>
</localServices>
<remoteServices>
<remoteService>
<hostname>rest-heroes</hostname>
<port>80</port>
<localPort>8083</localPort>
</remoteService>
<remoteService>
<hostname>rest-villains</hostname>
<port>80</port>
<localPort>8084</localPort>
</remoteService>
<remoteService>
<hostname>apicurio</hostname>
<port>8080</port>
<localPort>8086</localPort>
</remoteService>
<remoteService>
<hostname>fights-kafka</hostname>
<port>9092</port>
</remoteService>
<remoteService>
<hostname>otel-collector</hostname>
<port>4317</port>
</remoteService>
</remoteServices>
</remoteDevelopment>
</configuration>
</plugin>
Version 1.11.0 of the openshift-maven-plugin was the latest version as of the writing of this article. You may want to check if there is a newer version available.
|
This configuration tells OpenShift to proxy requests going to the OpenShift Service named rest-fights on port 8082 to the local machine on the same port. Additionally, it forwards the local machine ports 8083, 8084, 8086, 9092, and 4317 back to the OpenShift cluster and binds them to various OpenShift Services.
|
The code listing above uses the JKube OpenShift Maven Plugin. If you are using other Kubernetes variants, you could use the JKube Kubernetes Maven Plugin with the same configuration. If you are using Gradle, there is also a JKube OpenShift Gradle Plugin and JKube Kubernetes Gradle Plugin available. |
Now that the configuration is in place you need to open two terminals in the rest-fights directory. In the first terminal, run ./mvnw oc:remote-dev to start the remote dev proxy service. Once that starts, move to the second terminal and run
./mvnw quarkus:dev \
-Dkafka.bootstrap.servers=PLAINTEXT://localhost:9092 \
-Dmp.messaging.connector.smallrye-kafka.apicurio.registry.url=http://localhost:8086This command starts up a local instance of the rest-fights application in Quarkus dev mode. Requests from the cluster will come into your local machine. The local application will connect to other services back on the cluster, such as the rest-villains and rest-heroes applications, the Kafka broker, the Apicurio Registry instance, and the OpenTelemetry collector. With this configuration, Quarkus Dev Services will spin up a local MongoDB instance for the locally-running application, illustrating how you could combine local services with other services available on the remote cluster.
You can live code changes to the local application while requests flow through the Kubernetes cluster, down to your local machine, and then back to the cluster! You could even enable continuous testing while you make local changes to ensure your changes do not break anything.
The main difference between Quarkus Remote Development and Eclipse JKube Remote Development is that, with Quarkus Remote Development, the application is running in the remote Kubernetes cluster. Local changes are synchronized between the local machine and the remote environment. With JKube Remote Development, the application runs on the local machine, and traffic flows from the cluster, into the local machine, and back out to the cluster.
Wrap-Up
As you can see, Eclipse JKube Remote Development compliments the Quarkus Developer Joy story quite well. It allows you to easily combine the power of Quarkus with Kubernetes to help create a better developer experience, whether local, distributed, or somewhere in between.
