Le framework Quarkus regroupe, uniformise et simplifie le développement Java. A mes yeux, il représente l’avenir de la plateforme Java.
Cet article démontre comment Quarkus simplifie la gestion des applications dites de « nouvelles générations » en mettant à profit Docker, un packaging universel et standard, et Kubernetes, l’orchestrateur de ces applications.
Je vous montrerai comment, en quelques commandes, une application Java Quarkus peut être mise à disposition dans un cluster Kubernetes. Pour cet exemple, je construirai une des applications quickstart de Quarkus pour la déploier vers mon cluster local microk8s sous Ubuntu.
Mon Objectif est de 10 secondes pour passer du code Java à l’exécutable géré par Kubernetes !
Je profite d’une expérience récente pour vous montrer, dans un cas pratique, les qualités de la solution ESB de WSO2. Pour le situer dans les produits de WSO2, ce bus est le coeur de l’ Enterprise Integration (Intermédiations de Systèmes) et de l’ API Management (Plateforme de partage d’API). En quelques mots, ce bus est spécialisé dans les intermédiations de services HTTP.
L’exemple que je vous propose est assez simple et est pour moi représentatif. Vous allez, je n’en doute pas, constater la lisibilité et la clarté des médiations réalisées avec cet ESB.
Le sujet que je vous propose est une API « utilisateur ». Elle présente des profils d’ utilisateurs. Elle puise ses données dans un annuaire Active Directory de Microsoft. Je ne m’attarde ici qu’à la médiation en tant que telle. Les outils WSO2 EI ou API Management portent d’autres fonctionnalités que je détaille pas dans cet article.
La conception de la route tient en 4 étapes:
initialisation de la connexion LDAP,
préparation de la requête,
construction de la réponse.
optionnel: la gestion d’erreurs.
Je vais dans la suite de cet article commenter cette API par étape, par bloc de code. Cela permettra de bien commenter chaque partie.
L’intégration continue est un classique dans les enjeux actuels de productivité des développements logiciels. Elle est répandue et maîtrisée pour les technologies comme Java.
Pour l’intégration des médiations ESB et API, cet aspect est plus délicat. Un projet d’ intermédiation est un ensemble de routes, elles-mêmes composées de sous-éléments tels que les demi-interfaces. Le CD/CD des bus d’entreprise ou des API finissent par être très riches. Il est alors difficile de gérer les déploiements de Projets qui englobent plusieurs médiations.
Pour m’être confronté à ce problème plusieurs fois, je vous propose une solution efficace qui se veut simpliste, basée sur le concept de séparation des cycle de vie, le tout sur des produits Open Source.
Openshift en local, Minishift, peut être enrichi avec quelques plugins. Je vous propose de les ajouter. Le plus intéressant est pour moi la console de supervision transverse: le dashboard Kubernetes.
Aujourd’hui, je m’attaque à la problématique d’Intégration et de Déploiement Continue avec OpenShift. Mes interrogations sont les suivantes: Qu’apporte une plateforme Docker ? Quels sont les gains en productivité ? Quels intérêts pour les développeurs ? pour les Ops ? Quelles contraintes sur un projet classique JEE ? Bref, pour m’aider à y répondre, j’utiliserai le superbe projet CI/CD Demo on OpenShift de Siamak Sadeghianfar comme base. Il est très complet, merci Siamak 😉 . Cependant je n’ai pas résisté à y apporté une touche personnelle suite à quelques envies et incompatibilités… Mon environnement Windows 10 et la finalisation de MiniShift en 1.0-rc2 en sont probablement la cause.
Objectifs
Mon objectif principal est d’ accélérer les déploiements des applications Java sur des environnements prêt à consommer. La finalité est de déployer une version stable d’une application JEE dans un environnement « STAGE » après l’avoir testée et évaluée.
Pour cela, les outils doivent me permettre un certain nombre d’actions sur le logiciel en cours de développement:
construire,
vérifier la qualité,
archiver,
déployer
exécuter
tester
mesurer.
Je vais utiliser 2 environnements différents, un pour les tests unitaires, l’autre pour les tests d’intégration. Openshift m’apportera son aide sur la gestion de ces environnements avec
leur définition,
le déploiement des machines,
le portage des instances.
Quand à l’intégration continue (construction, mesure et archivage), les outils opensource Jenkins, Sonar et Nexus sont mes amis 😉 .
Ma vision globale de la problématique de CI/CD est celle-ci:
Toutefois, une précision de vocabulaire s’impose.
La notion d’environnement dans OpenShift est appelé PROJET (un namespace kubernetes). Cela est similaire à un sous-réseau où les instances dockers (pods) peuvent communiquer entre elles.
Dans la suite de l’article, je parlerai d’environnement pour PROJET « OpenShift » et projet pour PROJET « Maven ».
Je regroupe ici mon paramétrage MiniShift commun à tous mes autres usages (API, ESB, Log, etc). Cette page sera mise à jour en fonction de mes besoins complémentaires 🙂 .
Voici ma très courte procédure d’installation de la solution d’API Management 
Je vous partage très simplement ma procédure d’installation de GrayLog sur Openshift Minishift.