Archives de Tag: WildFly

Tester Keycloak sur Amazon EC2

En voulant tester WildFly via Docker sur Amazon EC2 je suis tombé par hasard sur le projet Keycloak. Ce projet consiste à pouvoir gérer du SSO/une IDM entre différentes apps et/ou API REST. A la base il se déploie sur WildFly mais peut finalement être mis sur d’autres serveurs. Je vous laisse découvrir le projet via le screencast de 15 min.

Mais en fait le mieux de l’installer et le tester. Pour cela j’ai utilisé Amazon EC2 en étant dans la période de gratuité de 1 an de celui-ci mais en étant donc limité à des instances de type t2.micro (sur le lieu « US West (Oregon) ») mais qui suffisent pour des tests.

Voici le déroulé pour l’installation de Keycloak sur Amazon EC2 :

  • Connectez-vous sur la console d’administration d’Amazon Web Services et sélectionnez le service « EC2 ».
  • Cliquez sur « Launch Instance » et sélectionnez une image de type « Ubuntu Server 14.04 LTS ».
  • Sélectionnez votre type d’instance. Dans mon cas et pour rester dans le cadre de l’utilisation gratuite d’Amazon Web Services j’utilise une instance de type « t2.micro ». Cliquez ensuite sur « Next: Configure Instance Details ».
  • Pour ma part à ce stade je clique sur « Review and launch » mais vous pouvez à la place configurer d’autres paramètres comme notamment l’intégration de la machine à réseau déjà existant. Mais ce n’est pas là l’objectif de l’article.
  • L’écran affiche un résumé des propriétés de la nouvelle instance. Par défaut il y a un accès SSH all over the world (en supposant que vous ayez déjà configuré une clé SSH pour Amazon Web Service, voir içi). Attention, à ce stade il faut modifier les règles d’accès à l’instance en changeant « SSH » par « All TCP » pour que n’importe quel port soit accessible depuis Internet. Pour cela dans la partie « Security Groups » cliquez sur « Edit security groups » et changez « SSH » en « All TCP » puis cliquez de nouveau sur « Review and launch ». Vous pouvez enfin cliquer sur « Launch » et sélectionner une clé SSH pour y accéder en SSH.

Une fois ceci effectué votre instance est en cours d’initialisation. Cliquez sur « View Instances » et attendez 2 minutes …

Quand votre nouvelle instance est notifiée comme « Running » et non « Initializing » c’est que vous pouvez désormais y accéder via SSH en utilisant l’adresse réseau affichée dans la colonne « Public DNS ». Donc allons-y avec la commande ssh (avec l’adresse réseau fournie par Amazon EC2) :

> ssh -i ec2.pem ubuntu@ec2-54-148-255-72.us-west-2.compute.amazonaws.com
[…]
ubuntu@ip-172-31-38-59:~$

Maintenant que vous êtes connecté à votre instance EC2 vous pouvez installer docker mais aussi l’image Keycloak :

sudo apt-get install docker.io
[…] (une dizaine de secondes)
sudo docker pull jboss/keycloak
[…] (1 Go à télécharger en moins de 2 minutes)

A ce stade Docker est installé et l’image de Keycloak est prête (enfin presque). Pour la démarrer :

sudo docker run -it -p 80:8080 -p 9090:9090 jboss/keycloak

Si ensuite, dans votre navigateur préféré vous tapez l’URL (en fonction du DNS fourni par Amazon EC2) :

http://ec2-54-148-255-72.us-west-2.compute.amazonaws.com/auth/

Vous devriez alors avoir la page suivante :

keycloak_welcome

Maintenant pour accéder à la console d’administration de keycloak ce n’est pas possible de base car il faut que ce soit effectué via SSL/HTTPS. J’ai bien essayé de configurer Keycloak pour lui indiquer de passer malgré la non présence de SSL (utile avec proxy reverse comme Nginx ou Apache gérant lui même le SSL) en modifiant le fichier /opt/jboss/wildfly/standalone/deployments/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json via la commande (dans le conteneur jboss/keycloak) :

sed -i 's|    "admin|    "ssl-required": false,\n    "admin|' /opt/jboss/wildfly/standalone/deployments/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json

Mais cela ne semble pas marcher alors que le fichier est bien modifé Bon solution de secours j’utilises SSH avec une redirection de port :

ssh -i ec2.pem -L 3000:127.0.0.1:80 ubuntu@ec2-54-148-255-72.us-west-2.compute.amazonaws.com

En tapant dans un navigateur l’adresse http://127.0.0.1:300/auth/admin/ cela fonctionne enfin ! J’utilise le login et mot de passe admin/admin, Keycloak me demande de modifier ce mot de passe suite à une première connexion. Après cela j’ai enfin accès à la console de Keycloak.

Voilà maintenant vous pouvez jouer avec cette console afin de voir ce qu’elle propose comme fonctionnalités.

Publicités

JHipster

Hier j’ai parlé de Spring Boot qui fait parti des projets Hype du moment pour tout développeur Java. En fait la problématique c’est comment démarrer rapidement un projet web (ou autre) ? Spring Boot répond à ce besoin de pouvoir faire un site web ou une API Rest (ou encore une fois autre) en quelques lignes de code.

Cependant en parallèle Node.JS est devenu très populaire car le Javascript est devenu très populaire (Node.JS c’est du Javascript coté serveur ET en asynchrone : bonus XXL).

Mais voilà Spring Boot est un bon départ mais après il reste à faire une interface avec Angular JS (ça aussi c’est Hype, enfin surtout pour un backoffice ou une application de gestion, mais en tout cas j’adore), mais aussi lier à une une base de données (MongoDB c’est Hype, MySQL/PostgreSQL c’est aussi pas mal pour structurer ses données), loguer, mesurer, déployer, etc …

La solution ? Le projet JHipster ! Il s’agit d’un projet géré via yeoman c’est à dire qu’il faut installer Node.JS (tiens encore lui) et d’installer yeoman via npm, le gestionnaire de package de Node.JS pour enfin avoir la commande yo afin de faire un petit yo jhipster et de répondre à toute ses questions (choisir sa base de données, son gestionnaire de package, la manière d’identifier un utilisateur, etc.). JHipster consiste à la fois à du code Java (une API Rest + des templates délivrés à Angular JS) mais aussi à une interface de type SPA avec Angular JS, BootStrap, etc avec l’utilisation, en bonus de très bonnes librairies comme Metrics ou Swagger.

Jusqu’à maintenant je connaissais les archétypes maven, notamment le kickstart de Spring 4 MVC ou encore les quickstarts de JBoss ou encore JBoss Forge mais aucun ne faisait du fullstack en alliant le monde Java (via Spring) et le monde Javascript (via Grunt/Bower/etc.). C’est donc chose faite via JHipster et en plus via une SSII français aka Ippon Technologies (société auquelle j’avais postulé en 2008, je regrette parfois de ne pas avoir accepté la proposition finale). Le site web lié explique très bien comment cela fonctionne, comment l’installer, comment le déployer, etc. Bref, bravo. Après certaines choses ne me conviennent pas (je suis très difficile) à savoir que je préfère utiliser un serveur Java EE plutôt que tomcat et donc d’utiliser des DataSource(s) (tomcat peut le faire) l’utilisation de JTA/JPA et si possible de JAX-RS (via Jersey ou RestEasy) voir plus si possible (qui peut le plus peut le moins).

Donc JHipster est une très bonne base pour un projet Hype, mais, comme toujours, demande de l’ingénierie pour l’adapter à son propre contexte.

Note à part : JHipster fonctionne sous WildFly 8.1 il suffit juste de ne pas intégrer les librairies tomcat-*.jar dans le WAR généré. Par contre je ne suis pas arrivé à intégrer Spring Boot en tant que module dans WildFly. Donc le WAR fait plus de 50Mo et n’est pas allégeable avec WildFly. Si le serveur d’intégration continue est en entreprise mais que le déploiement est dans un cloud privé alors cela est problématique de transférer 50 Mo à chaque déploiement … A travailler.

Spring Boot

J’utilise Spring depuis maintenant 3 ans (depuis ma formation en DIF en fait) et en voulant moderniser nos sites web écrit en Spring 3.x je suis tombé sur le projet Spring Boot.

Le principe premier de Spring Boot est de pouvoir démarrer un projet en quelques lignes de code … avec Spring. Il y a même eu un tweet (donc maximum 140 caractères) qui est un code pouvant lancer un serveur web et répondre sur une URL. De la même façon une API Rest minimaliste pourrait donc aussi tenir dans un tweet.

Note à part : si vous connaissez node.js cela ne vous rappelle rien ? On dirait que Spring Boot est une réponse au succès de node.js et à la création « les doigts dans le nez » d’un site web ou d’une API Rest en un rien de temps. Spring Boot permet même de lancer une ligne de commande un serveur web exécutant un code minimaliste ou de créer un livrable prêt à lancer un serveur web en production. Spring Boot s’inscrit dans le la notion de RAD dans l’univers web.

Pourquoi Spring Boot et non simplement Spring (ou Spring MVC pour un site web) ? A cause de la configuration … Spring est très bien pour délivrer des petits bouts fonctionnels mais l’agglomération de tout ces petits bouts est couteux. Là où intervient Spring Boot est qu’il détecte ces petits bouts et les configurent au mieux que possible.

Mais comment les détecte t-il ? Via les librairies présentent dans le classpath ! Par exemple si dans votre projet vous mettez (comme moi) la librairie freemarker alors il se dit qu’il faut configurer Spring MVC afin qu’il puisse utiliser des templates freemarker et que ces mêmes templates sont dans /templates/ (vis à vis du classpath).

Mais, n’est-il pas trop « aggressif » dans sa manière de fonctionner ? Oui et non. C’est vrai que du coup Spring Boot est très ce qu’on appelle « opinionated » (terme très en vogue dans les framework web) c’est-à-dire qu’il gère les composants de la manière qu’il lui semble optimale mais sans que ce soit à votre manière. Cependant sa philosophie c’est d’être « opinionated » mais de pouvoir à tout moment prendre le dessus (la philosophie première de Spring en fait). Et justement il facilite la prise en main d’une fonctionnalité particulière.

Donc en clair il suffit de créer un projet Maven en déclarant que le pom parent est spring-boot-starter-parent et de choisir une dépendance avec un « starter » et hop … il suffit de créer un contrôleur comme le tweet ci-dessus puis de faire un

> mvn spring-boot:run

et on a un site web fonctionnel !

(cela peut aussi être fait avec Gradle, c’est selon l’environnement de travail)

Bon Spring Boot n’est pas que cela il y a de nombreuses autres fonctionnalités que vous pourrez consulter dans la documentation de Spring Boot.

Je dois quand même avouer, avec mon expérience de Spring, qu’il s’agit d’une facilité bienvenue. Combien de fois ais-je dû me demander commander intégrer tel ou tel composant dans Spring ?

Et puis pour aller encore plus loin, Spring Boot est assez bien intégré avec le Cloud. Donc, par exemple, développer une API Rest sur Heroku est « assez rapide ». Spring Boot donne toutes les instructions nécessaires pour un déploiement dans le cloud via les acteurs majeurs de la place. Voir içi (tiens d’ailleurs Google Application Engine n’est qu’en version Servlet 2.5 !).

Pour bien commencer avec Spring Boot et en français voici un article intéressant.

Alors en conclusion je dirais que Spring Boot est très intéressant surtout pour démarrer rapidement un projet (web/rest/batch/etc…) MAIS la contremesure c’est d’apprendre une surcouche de Spring (Spring Boot) en plus de Spring lui-même. Il y a de nouvelles annotations, de nouvelles classes, de nouvelles librairies, de nouvelles façon de faire mais il faut quand même connaître Spring pour, au fur à mesure, aller plus loin dans le développement. A coté il y a Java EE 7 … (que j’utilise déjà pour d’autres briques de notre système d’information). Quand je regarde le code de spring-boot-*.jar  (notamment spring-boot-autoconfigure-*.jar) je me dis que ce n’est plus la même manière de fonctionner qu’auparavant. Mais après tout Spring Boot est pour nous aider à démarrer un projet et non nous contraindre sur l’apprentissage de nouvelles annotations.

Dernier point (oui encore un) j’ai une appréhension sur la manière dont Spring Boot fonctionne : il analyse le classpath à la recherche de librairies (en faite de classes) permettant de déclencher certaines fonctionnalités (tiens au fait Java EE ne fait pas déjà cela ?). Cependant cette même gestion de classpath au sein de Java est problématique car non adaptée (à mon sens) à une gestion moderne de librairies. Je fais en fait référence à la JSR 277 (Java Module System) qui devrait modulariser Java mais qui est en cesse repousée (Java 9 ou Java 10 ?). Cela aura un impact assez lourd sur le ClassLoader de Java et du coup, par rebond, à Spring Boot.

Et puis aussi avec ce dernier point je dois préciser que j’utilise dès que je peux JBoss AS 7 / WildFly 8.1. Je trouve que c’est un superbe serveur d’application et le serveur web n’est plus tomcat (sur WildFly) mais Undertow que est extra-performant et fait partie des meilleurs serveurs mondiaux (par exemple, attention je suis conscient que cela dépend de beaucoup de paramètres et que node.js peut être plus performant, ou même d’autres !). Et concernant Sprint Boot cela fonctionne sous WildFly mais sous peu que TOUTES les librairies soient dans le WAR lui-même. Le problème ? C’est j’aime bien mettre les librairies sous forme de modules dans JBoss AS 7 / WildFly MAIS que du coup la gestion des classes de ces modules n’est pas celle attendue par Spring Boot et donc aucune fonctionnalité mise en module n’est détectée. Pourtant j’ai insisté pendant plusieurs jours (voir nuits) mais impossible à faire détecter les modules par Spring Boot (pour l’auto configuration) … J’en suis arrivé à la conclusion que Spring Boot fonctionne sous JBoss AS 7 / Wild Fly mais que toute librairie nécessaire doit être dans le WAR et que tout module ne sera pas détecté pour être auto-configuré. Donc retour aux FAT-WAR(s) que je déteste tant … ou alors je continue d’utiliser Spring en mode classique, à voir.