OXiane est un organisme de formation, principalement à destination des développeurs, mais d’une façon plus générale, dans le domaine de l’IT. Un problème récurrent pour nous est l’environnement de formation que nous mettons à disposition des participants.
Au fur et à mesure de l’évolution des pratiques et des avancées technologiques, nous sommes passés du formatage / réinstallation de la machine, au déploiement d’une VM VirtualBox sur le laptop mis à disposition, à une solution CloneZilla… Les problèmes sont toujours les mêmes :
- Comment avoir un environnement à jour ?
- Comment avoir un environnement propre et pas pollué par la dernière formation?
- Comment fournir d’une formation à l’autre des environnements différents ?
- Comment faire en sorte de ne pas y passer trop de temps ?
- Comment faire en sorte que cela ne coûte pas un rein quand on lance une nouvelle formation ?
Avec la généralisation des formations à distance, il nous a fallu soit faire confiance à la machine du participant (c’est souvent une mauvaise idée…), soit fournir des machines virtuelles accessibles au travers d’internet. Mais là, se pose le problème des règles de sécurité mise en place par les entreprises des participants.
Sans entrer dans les détails des raisons sur les choix qui ont été fait, nous mettons aujourd’hui en place – pour les formations à destination des développeurs – une infrastructure basée sur Coder, qui permet d’avoir un VSCode hébergé chez un provider Cloud et accessible simplement au travers d’un browser.
Il a fallu ensuite vérifier que toutes les formations qui nous animons peuvent effectivement être réalisées sur ces environnements. Et là, nous avons eu des problèmes avec la formation Quarkus Essentiel.
Quarkus propose en mode de développement un outil extrêmement utile pour les développeurs, la dev-ui. C’est une UI très agréable qui sert de portail pour explorer, debugger et interagir avec l’application que vous êtes en train de développer (*).
Mais cette UI, faite pour le développeur, est très sécurisée, et il était impossible de l’utiliser sur nos environnements.
Comment fonctionnent nos environnements ?
Les VMs que nous mettons à disposition sont des VMs qui sont hébergées chez AWS, et qui font tourner un VSCode server. On s’y connecte soit au travers d’un VS Code installé en local, soit au travers d’une IHM Web qui tourne dans un browser ; c’est cette solution qu’on essaie d’utiliser au maximum, car elle ne dépend que du browser installé sur le poste du participant.
Lorsque vous lancez l’application que vous développez dans la VM, si celle-ci est une application serveur, elle écoute sur un port. VS Code propose de mettre en place une redirection de port, de façon à ne pas exposer directement le port en question, et de permettre d’y accéder au travers d’une URL HTTPS. Si votre application écoute sur le port 8080, il met en place une redirection sur un chemin /@cmarchand/quarkus.dev/apps/code-server/proxy/8080/.
Donc, si votre application sait traiter des requêtes sur http://localhost:8080/hello, il faudra lui envoyer, depuis le browser de votre machine locale, une requête sur https://xyz.fmt.oxiane-institut.com/@cmarchand/quarkus.dev/apps/code-server/proxy/8080/hello. Et tout cela fonctionne très bien ! Il est même très simple de copier l’adresse de redirection :
Problème avec la dev-ui
Simplement, avec la dev-ui, cela ne fonctionne pas, et pour plusieurs raisons :
- Par défaut la dev-ui ne répond qu’aux requêtes envoyées sur
localhost - La dev-ui ne fonctionne que quand le context-root est
/
Donc, quand on attaque la dev-ui sur https://xyz.fmt.oxiane-institut.com/@cmarchand/quarkus.dev/apps/code-server/proxy/8080/q/dev-ui/, on commence par récupérer une erreur 303 (See Other), avec une redirection, qui est en l’occurence générée par VSCode server. Ce point est facilement corrigible, il existe une propriété de configuration de la dev-qui qui permet de spécifier sur quelles adresses la dev-ui écoute : quarkus.dev-ui.hosts. Donc, il faut ajouter une entrée dans le fichier application.properties :
quarkus.dev-ui.hosts=xyz.fmt.oxiane-institut.com
Et cette fois, quand on accède de nouveau à la dev-ui, oh miracle, la page se charge ! … enfin presque…
La page référence de nombreux fichiers JS, au travers d’une importmap, et toutes les références externes sont accédées en chemin absolu, c’est à dire sur le context-root /. Et là, évidemment, cela ne fonctionne pas.
Fort heureusement, les gens de chez Quarkus sont vraiment très réactifs ! J’ai créé une issue sur github, et en moins d’une semaine Phillip Kruger a développé l’évolution. Et il y a maintenant une nouvelle propriété de configuration de la dev-ui qui permet de spécifier le context-root ! quarkus.dev-ui.context-root ! Donc, le fichier application.properties devient :
quarkus.dev-ui.hosts=xyz.fmt.oxiane-institut.com
quarkus.dev-ui.context-root=/@cmarchand/quarkus.dev/apps/code-server/proxy/8080
Et cette fois, on accède bien à la dev-ui, complètement, et on peut profiter de toutes les fonctionnalités !
Mais comment ne pas pourrir le repo git ?
Le problème, c’est que le fichier application.properties est un fichier qui contient la configuration de l’application, et qu’on y a mis des informations de configuration qui concernent uniquement le développement, et encore, pour un seul développeur ! Un autre développeur devra définir d’autres valeurs pour ces propriétés, car il développera sur une autre VM.
Fort heureusement, avec Quarkus, on peut définir les propriétés à plusieurs endroits, et en particulier à partir d’un fichier .env situé dans le répertoire courant. On déplace donc ces propriétés dans un fichier .env situé à la racine de repo, on exclue ce fichier des commit en le déclarant dans le .gitignore, et tout fonctionne !
Conclusion
On est jamais aussi confortablement installé que sur sa machine locale, avec son IDE préféré, mais parfois, les contraintes font que ce n’est pas possible (je pense aux entreprises où les règles de sécurité sont draconiennes, comme le secteur militaire ou certaines banques). Et il faut donc s’adapter.
Ici, coder, en exposant un VSCode au travers d’un simple browser, sur une URL en HTTPS, sur un nom de domaine bien identifié, permet – parfois en demandant quelques exceptions à nos clients – de pouvoir mettre à disposition des participants des environnements de développement qui sont performants, efficaces, et relativement peu contraignant.
Les équipes Quarkus – et particulièrement Phillip Kruger – ont parfaitement géré la demande d’évolution, et j’attends avec impatience la prochaine release de Quarkus pour que ce soit effectivement disponible pour tout le monde (ici, j’ai buildé Quarkus en local pour que cela fonctionne). Merci à eux !
Retrouver nos formations Quarkus :
Quarkus – niveau intermédiaire