Après sa formation d’ingénieur à l’ESME Sudria en 2005, où il a aussi enseigné à temps partiel jusqu’en 2012, Romain Pelisse mit l’Open Source et le logiciel libre au centre de sa carrière. Après dix ans de consulting autour des technologies Java (JBoss et son écosystème) et Linux, d’abord chez Atos Origin puis chez Red Hat, il rejoint le département R&D et l’équipe de maintenance logicielle autour de JBoss EAP.
Au-delà de ses contributions dans le monde Java (notamment sur les projets Wildfly, PMD et Bugclerk), Romain est aussi passionné par Linux, Git, Ansible et Bash, qui sont des sujets récurrents de ses articles dans GNU/Linux Magazine.
Aujourd’hui, on ne peut que sourire en se rappelant que, à la fin des années 2000, Git était encore vu comme un outil trop « gruik », réservé à quelques codeurs « hardcore », généralement concentrés sur le développement du noyau Linux.
Si le code est la matière première de tout développeur, il utilise aussi de nombreux outils pour travailler celle-ci. Comme tout artisan ou technicien, c’est souvent la bonne connaissance ainsi que la bonne maîtrise de ces outils qui vont lui permettre de non seulement effectuer son travail avec efficacité et de manière confortable, mais aussi parfois d’accomplir de véritables exploits, qui auraient été humainement impossibles sans l’outillage approprié. Faisons donc ici l’inventaire de ces outils, et du rôle que chacun joue dans le quotidien d’un développeur.
Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.
Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.
Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.
Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.
Et, si, en une ligne de commandes, on pouvait reconstruire son serveur JEE pour qu’il soit configuré, sur mesure, pour les besoins des applications qu’il embarque ? Et si on pouvait aller encore plus loin, en distribuant l’ensemble, assemblé sous la forme d’un jar exécutable ? Et si on pouvait même déployer le tout, automatiquement, sur OpenShift ? Grâce à Wildfly Glow [1], c’est possible ! Tout du moins, pour le serveur JEE open source Wildfly [2]. Démonstration dans cet article.
Automatiser entièrement le déploiement d’un cluster Red Hat AMQ Streams est possible… en utilisant Ansible et sa collection dédiée au produit. Démonstration par l’exemple.
Dans la maintenance applicative, mais aussi dans l’ensemble du cycle de vie d’un projet, les suites de tests unitaires sont la clé de voûte de la stabilité du logiciel. Ils permettent la détection, dès leur introduction, de toute forme de régression ou de changement de comportement et facilitent ainsi non seulement sa maintenance, mais aussi son évolution. Si c’est tellement important et utile, pourquoi n’ajoutons-nous pas de telles suites pour tester nos scripts « Shell » ? Démonstration avec l’outil Bats !
