Développement natif Kubernetes avec Quarkus et Eclipse JKube

Cet article explique ce qu’est le développement à distance Eclipse JKube et comment il aide les développeurs à créer des applications natives Kubernetes avec Quarkus.

Introduction

Comme mentionné dans mon article précédent, les microservices n’existent pas dans le vide. Ils communiquent généralement avec d’autres services, tels que des bases de données, des courtiers de messages ou d’autres microservices. En raison de cette nature distribuée, les développeurs ont souvent du mal à développer (et à tester) des microservices individuels qui font partie d’un système plus vaste.

L’article précédent examine certains défis courants du cycle de développement de la boucle interne et montre comment Quarkus, combiné à d’autres technologies, peut aider à résoudre certains de ces défis. Eclipse JKube Remote Development ne faisait pas partie des technologies mentionnées car elle n’existait pas au moment de la rédaction de l’article. Maintenant qu’il existe, il mérite certainement d’être mentionné.

Qu’est-ce que le développement à distance Eclipse JKube ?

Eclipse JKube fournit des outils qui permettent d’apporter des applications Java à Kubernetes et OpenShift. Il s’agit d’une collection de plug-ins et de bibliothèques permettant de créer des images de conteneurs et de générer et déployer des manifestes Kubernetes ou OpenShift.

Eclipse JKube Remote Development est une fonctionnalité de prévisualisation publiée pour la première fois dans le cadre d’Eclipse JKube 1.10. Cette nouvelle fonctionnalité est centrée sur Kubernetes, permettant aux développeurs d’exécuter et de déboguer des applications Java à partir d’une machine locale tout en étant connectés à un cluster Kubernetes. Cela revient logiquement à placer une machine de développement local dans un cluster Kubernetes. Les requêtes provenant du cluster peuvent être acheminées vers une machine de développement locale, tandis que les requêtes sortantes peuvent être renvoyées vers le cluster.

Vous souvenez-vous de ce diagramme du premier article utilisant les super-héros Quarkus ?

Nous utilisions auparavant Skupper comme proxy pour connecter un cluster Kubernetes à une machine locale. Dans le cadre de la version 1.10, Eclipse JKube supprime la nécessité d’utiliser Skupper ou d’installer l’un de ses composants sur le cluster Kubernetes ou votre machine locale. Eclipse JKube gère toutes les communications sous-jacentes vers et depuis le cluster Kubernetes en mappant Kubernetes Service ports vers et depuis la machine locale.

Développement à distance Eclipse JKube et Quarkus

La nouvelle fonctionnalité Eclipse JKube Remote Development peut rendre l’exemple des super-héros Quarkus très intéressant. Si nous voulions reproduire le scénario présenté dans Figure 1tout ce que nous aurions à faire est de reconfigurer le rest-fights l’application localement un peu, puis exécutez-la en mode de développement Quarkus.

Tout d’abord, déployez les super-héros Quarkus sur Kubernetes. Ensuite, ajoutez la configuration Eclipse JKube dans le <plugins> rubrique dans la rest-fights/pom.xml déposer:

<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 du openshift-maven-plugin était la dernière version au moment de la rédaction de cet article. Vous voudrez peut-être vérifier si une version plus récente est disponible.

Cette configuration indique à OpenShift (ou Kubernetes) de proxy pour les requêtes allant à OpenShift Service nommé rest-fights sur bâbord 8082 à la machine locale sur le même port. De plus, il transmet les ports de la machine locale 8083, 8084, 8086, 9092et 4317 retour au cluster OpenShift et les lie à divers OpenShift Services.

La liste de code ci-dessus utilise le plugin JKube OpenShift Maven. Si vous utilisez d’autres variantes de Kubernetes, vous pouvez utiliser le plug-in JKube Kubernetes Maven avec la même configuration.

Si vous utilisez Gradle, un plugin JKube OpenShift Gradle et un plugin JKube Kubernetes Gradle sont également disponibles.

Maintenant que la configuration est en place, vous devez ouvrir deux terminaux dans le rest-fights annuaire. Dans le premier terminal, lancez ./mvnw oc:remote-dev pour démarrer le service de proxy de développement à distance. Une fois que cela démarre, passez au deuxième terminal et exécutez :

./mvnw quarkus:dev \
  -Dkafka.bootstrap.servers=PLAINTEXT://localhost:9092 \
  -Dmp.messaging.connector.smallrye-kafka.apicurio.registry.url=http://localhost:8086

Cette commande démarre une instance locale du rest-fights application en mode de développement Quarkus. Les requêtes du cluster arriveront sur votre ordinateur local. L’application locale se connectera à d’autres services sur le cluster, tels que le rest-villains et rest-heroes applications, le courtier Kafka, l’instance Apicurio Registry et le collecteur OpenTelemetry. Avec cette configuration, Quarkus Dev Services lancera une instance MongoDB locale pour l’application exécutée localement, illustrant comment vous pouvez combiner les services locaux avec d’autres services disponibles sur le cluster distant.

Vous pouvez apporter des modifications de code en direct à l’application locale pendant que les requêtes transitent par le cluster Kubernetes, jusqu’à votre ordinateur local et reviennent au cluster. Vous pouvez même activer les tests continus pendant que vous apportez des modifications locales pour vous assurer que vos modifications ne cassent rien.

La principale différence entre Quarkus Remote Development et Eclipse JKube Remote Development est que, avec Quarkus Remote Development, l’application s’exécute dans le cluster Kubernetes distant. Les modifications locales sont synchronisées entre la machine locale et l’environnement distant. Avec JKube Remote Development, l’application s’exécute sur la machine locale et le trafic circule du cluster vers la machine locale et revient vers le cluster.

Conclure

Comme vous pouvez le voir, Eclipse JKube Remote Development complète assez bien l’histoire de Quarkus Developer Joy. Il vous permet de combiner facilement la puissance de Quarkus avec Kubernetes pour aider à créer une meilleure expérience de développement, qu’elle soit locale, distribuée ou quelque part entre les deux.