Les IDE Cloud

Depuis plusieurs années les IDE Cloud font parler d’eux. La première fois que j’ai entendu ce terme et assisté à une démonstration, c’était pour Eclipse CHE, outil créé en 2014 par les équipes Codenvy. Cette démonstration était impressionnante mais de part mes activités du moment, je ne m’y suis pas intéressé davantage. L’utilisation d’un outil annexe pour modifier mes projets GitLab ou GitHub n’a peut-être pas aidé.

L’intégration de GitPod

Lors de la consultation de projets hébergés sur GitLab, j’ai aperçu dans l’été 2021 un nouveau bouton “GitPod” apparaître à côté de celui permettant d’ouvrir le Web IDE de GitLab. C’est à partir de ce moment que j'ai pu découvrir et tester une première fois cet outil. Une très bonne première impression !

J’ai ensuite vu cet article de blog sur le site GitLab détaillant les avantages et les bienfaits de l’intégration de GitPod sur la plateforme DevOps, me donnant tout simplement la curiosité d’en savoir plus.

GitLab a depuis longtemps un “Web IDE” intégré, permettant facilement de modifier des fichiers sans quitter son navigateur. Pour mettre à jour de la documentation, des fichiers textes, des fichiers yaml ou encore des fichiers properties, cela convenait parfaitement. GitLab n’a d’ailleurs pas la prétention de faire de cet outil un IDE pour le développement.

C’est pour cela que ces deux options sont complémentaires et disponibles sur GitLab :

Pour les projets stockés sous GitHub, ce bouton est également disponible après avoir activé l’extension Chrome ou Firefox.

Mais qu’est ce que GitPod ?

GitPod met à disposition des environnements de développement dans le Cloud. A partir d’une connexion via son compte GitLab, GitHub ou BitBucket, vous pouvez profiter de l’offre gratuite qui permet d’avoir 4 workspaces en parallèle et 50 heures d’utilisation par mois. Ce qui permet d’avoir une bonne approche de l’outil. Et si vous craignez qu’un raccourci malencontreux clôture l’onglet et vous fasse perdre vos modifications en cours, je vous rassure, le workspace est accessible jusqu’à 30 minutes après fermeture.

L’environnement de développement est basé sur Vscodium, la version open source de Vscode. L’IDE est donc familier à la plupart des développeurs.

GitPod dans son utilisation

L’utilisation de GitPod est assez simple. L’accès se fait via un bouton au niveau de votre projet Git et la première approche est simple d’utilisation.

Comment cela fonctionne-t-il ?

L’éco-système que vous apercevez devant vous est un environnement Cloud, basé sur une image Docker gitpod/workspace-base. Cette image contient un lot d’utilitaires, notamment Git, vous permettant de pousser vos modifications dans votre projet Git, npm et maven . Une bonne base pour commencer un développement !

Ensuite le logo Docker sur le menu de gauche est également disponible. Vous pouvez donc utiliser des containers pour travailler avec une base de données ou un autre composant par exemple.

Le système d’extensions de Vscode est également disponible. Une liste assez fournie est initialement à notre disposition.

Une autre fonctionnalité, les ports. Votre environnement Cloud mis à disposition par GitPod est privé et l’accès à vos applications en cours de développement n’est pas possible initialement. L’ouverture de ports va permettre tout simplement de mettre à disposition des points d’entrées sur votre workspace.

Ainsi un npm run, va permettre d’ouvrir le port 4200 et vous verrez l’application que vous développez. Un “localhost” sur le Cloud !

Si je résume, je viens de vous présenter rapidement qu’une configuration de base vous permet d’avoir un écosystème de développement ressemblant à celui de votre ordinateur.

Du Dév java dans Vscode ?

Avec l’arrivée de Quarkus, les équipes de Red Hat ont développé une extension Vscode Java et j’avoue que c’est assez bluffant. On retrouve des commandes de base : organisation des imports, complétions, etc, bref développer en Java dans Vscode est désormais possible sans que ce soit une contrainte.

Le nombre de “Javaistes” développant au quotidien sur Vscode est assez faible mais je pense qu’il est en constante augmentation. L’outil Vscode est plus léger qu’Intellij ou qu’Eclipse et le mécanisme d’extensions permet d’arriver à la hauteur des deux IDE Java historiques.

La configuration de l’environnement Quarkus

La plupart de mes projets sont développés en Java, et mes projets personnels se basent sur Quarkus. Si vous n’avez pas vu passer la version 2.0 de ce framework - que je vous conseille fortement - une CLI (Command Line Interface) est disponible. De base GitPod ne possède pas cet outil.

Alors comment faire ? Etant donné qu’un terminal est disponible, il serait possible d’installer en ligne de commande la CLI de Quarkus. Bien sûr ! Mais le faire à chaque démarrage d’un workspace ? et si une personne se joint à moi pour travailler sur ce projet, elle devra également faire cette installation ? Non ! Ce n’est clairement pas le but.

Habituellement, lors du démarrage sur un projet, la première étape consiste à lire de la documentation technique pour pouvoir installer les bons outils avec la bonne version si possible. Vous savez, ce fameux Read That F*** Manual (RTFM) 😅. Un des points forts des environnements Cloud est d’avoir la possibilité de stocker la configuration des projets. Cela évitera à chaque nouvelle personne arrivant sur le projet de devoir le faire sur son poste. Gain de temps évident et source d’erreur écartée. Cela ne vous arrive jamais de vous tromper dans la version de npm ou maven sur un projet ? et bien moi si. Surtout avec des projets en architecture microservices où un retard dans la version de Java est présent sur certains microservices.

L’installation de la CLI

La CLI Quarkus s’installe de plusieurs manières. Celle que je préfère consiste à passer par l’outil Jbang qui peut lui-même s’installer par Sdkman.

Pour permettre d’avoir ces commandes exécutées de base lors de l’ouverture de projet, on pourrait les exécuter dans le bloc “task” de GitPod ou alors passer par une image Docker préalablement créée. J’ai testé les deux solutions et le rendu final est identique. La première solution permet d’avoir un workspace exécuté et disponible plus rapidement. Cependant la définition de l’image est sur un autre projet Git.

La seconde solution est par conséquent plus longue à mettre en place le workspace mais la configuration du projet est dans le projet lui-même.

La configuration de GitPod

Avec GitPod, la configuration du projet est présente dans le projet lui-même, au niveau du fichier .gitpod.yml. On peut y renseigner plusieurs éléments comme :

• l’image docker de base
• des scripts à exécuter au démarrage
• les ports ouverts
• des extensions

Et cela va permettre de mettre “clé en main” un projet, super pratique !

Le Dockerfile

De base, un projet ouvert via GitPod est ouvert dans un contexte Docker créé à partir d’une image de GitPod (gitpod/workspace-full ou gitpod/workspace-base). Mais il est possible de se créer son propre environnement, soit à partir d’une image présente dans un hub, soit à partir d’un fichier Dockerfile présent dans votre projet.

Task

La balise “task” permet de saisir des actions à réaliser lors de l’ouverture de votre environnement GitPod. Cela est pratique pour éviter d’effectuer des commandes qu’on a l’habitude de faire à chaque fois qu’on arrive sur un projet. Vous voyez de quoi je parle ? Un mvn clean install ou un npm install. On peut également choisir de lancer plusieurs tâches successives ou en parallèle. Plusieurs terminaux peuvent être ouverts à l’aide de l’attribut openMode.

Les ports

Pour les ports, une API Quarkus utilise les ports 8080 et 5005 pour le debug. Vous pouvez les ajouter dans votre fichier .gitpod.yml :

Les extensions

L’extension ‘redhat.java’ citée précédemment est la principale pour faire du développement Java. Il est possible d’ajouter d’autres extensions, comme Gitlens, GitLab mais là, c’est du bonus 😅

Avec ces différentes notions, vous pouvez créer une configuration pour votre projet et la customiser pour avoir votre configuration “idéale”. Cette configuration sera mise à disposition des personnes qui interviennent sur votre projet. Pour l’aspect communautaire et open source, c’est tellement pratique. Pensez à ajouter un bouton “GitPod” dans le readme de votre projet pour indiquer aux visiteurs de votre projet qu’une configuration toute prête de votre projet est disponible !

Pour ajouter ce bouton, il suffit d’ajouter ce type code :

Ce fichier de configuration est désormais parfait pour mon projet et mon cas d’utilisation. Mais il me sera également utile pour mes futurs projets Quarkus et pourquoi pas à ceux qui comme moi veulent faire du Quarkus sur GitPod. Mais pour faciliter la réutilisation de cette configuration, un template est nécessaire.

Les templates

GitPod met à disposition dans son projet GitHub des projets templates. Cela permet d’avoir des configurations initiées pour des projets comme flutter, python, nextjs, etc.

A l’heure actuelle, je n’avais pas repéré de template pour Quarkus, c’était une bonne raison de l’initier !

Mon image Quarkus

Pour créer ce template, j’ai créé et déclaré un Dockerfile qui se base sur l’image gitpod/workspace-full.

L’installation de Sdkman se fait facilement par cette commande : curl -s "https://get.sdkman.io" | bash.

Puis celle de Jbang :

bash -c "source $HOME/.sdkman/bin/sdkman-init.sh && \
    yes | sdk install jbang && \
    rm -rf $HOME/.sdkman/archives/* && \
    rm -rf $HOME/.sdkman/tmp/* "

et celle de la CLI Quarkus : bash -c '$HOME/.sdkman/candidates/jbang/current/bin/jbang app install --fresh --force quarkus@quarkusio'.

Avant cette dernière commande une subtilité est à préciser, celle de faire faire confiance au projet Quarkus pour installer un outil via Jbang :

bash -c '$HOME/.sdkman/candidates/jbang/current/bin/jbang trust add [https://repo1.maven.org/maven2/io/quarkus/quarkus-cli/](https://repo1.maven.org/maven2/io/quarkus/quarkus-cli/)'

Et voila une image Docker contenant la CLI de Quarkus 🎉.

Voici le fichier Dockerfile final :

FROM gitpod/workspace-full
USER gitpod
ARG JAVA_VERSION="11.0.9.j9-adpt"

# install sdkman
RUN curl -s "https://get.sdkman.io" | bash
RUN bash -c "source $HOME/.sdkman/bin/sdkman-init.sh && \
    yes | sdk install jbang && \
    rm -rf $HOME/.sdkman/archives/* && \
    rm -rf $HOME/.sdkman/tmp/* "

# install jbang 
RUN bash -c '$HOME/.sdkman/candidates/jbang/current/bin/jbang --version'
RUN bash -c '$HOME/.sdkman/candidates/jbang/current/bin/jbang trust add https://repo1.maven.org/maven2/io/quarkus/quarkus-cli/'

# install quarkus cli
RUN bash -c '$HOME/.sdkman/candidates/jbang/current/bin/jbang app install --fresh --force quarkus@quarkusio'

Le .gitpod.yaml

Le fichier .gitpod.yaml est finalement très simple. Il contient les déclarations de :

• l’image personnalisée décrite ci-dessus,
• l’ouverture des ports 8080 et 5005 pour le port de l’API et celui de debug,
• les extensions mentionnées précédemment.

🐛La CLI de Quarkus propose une commande pour ouvrir la Dev UI. Cette commande est actuellement en erreur, du fait de l’absence de l’outil xdg-open permettant d’ouvrir le navigateur par défaut de votre poste. Étant dans une image Docker sur le Cloud, cet outil n’est pas disponible. J’ai initié cette issue pour échanger sur ce cas d’usage.

Ce template permet d‘avoir un modèle de configuration de projet Quarkus sous la main. Je l’utilise pour la plupart de mes projets personnels et répond à mes attentes. Si vous avez des remarques ou suggestions, n'hésitez pas à me les remonter.

Ce template est disponible sur mon repository GitHub.

Une version anglaise de cet article est disponible sur Tealfead.