[CloudBees] Déployer sur Google App Engine avec le même numéro de version que dans le Pom.xml Maven

cloudbees-logo

Connaissez-vous CloudBees ? C’est un outil super (Une de ses fonctionnalités, les ClickStart, présentée ICI), qui est dans la mouvance des PaaS, et qui a la particularité de proposer un service qu’ils appellent « Dev@Cloud ». Concrètement qu’est ce que c’est ? Un repository Git privé, un Jenkins rien que pour nous, qui nous permet de builder, ou de déployer nos projets Java ou NodeJS sur leur partie « Run@Cloud » (concrètement des instances Amazon). Bref, CloudBees fournit une usine de développement pour de l’intégration continue. (Nous pouvons bien entendu brancher notre Jenkins vers n’importe quel repository git, genre Github).

Depuis quelques temps, CloudBees permet de déployer aussi sur Google App Engine, et c’est à cette fonctionnalité que nous allons nous intéresser.

Une fois que nous nous sommes authentifiés à travers https://appengine.cloudbees.com/index.html, il suffit de suivre le workflow pour déployer son application immédiatement.

Configuration Jenkins

Allons voir ce qui se passe, et comment Jenkins déploie sur Google App Engine.
Un plugin est là, en post-build, pour faire le boulot.

jenkins-appengine

Le Besoin

Nous voyons que nous pouvons surcharger le numéro de version de l’application. Par défaut dans la configuration CloudBees, le numero de version est surchargé par le numéro de build. C’est à dire qu’à chaque fois que l’on build son application, une nouvelle version est déployée sur Google App Engine. Bon, pourquoi pas…

Mais nous avons un POM.xml qui contient déjà un numéro de version du projet. Comment l’utiliser ?

Solution

Première étape : enlevons la surcharge faite par Jenkins (cf capture d’écran). Dans ce cas-là, c’est le numéro de version contenu dans le fichier appengine-web.xml qui sera utilisé.

<application>monapplication</application>
    <version>${appengine.app.version}</version>
    <threadsafe>true</threadsafe>
</appengine-web-app>

Au moment du build Maven, nous remplissons automatiquement la variable appengine.app.version avec le numéro de version du projet. Pour ce faire, dans le POM.xml, nous définissons simplement:

<properties>
    <appengine.app.version>${project.version}</appengine.app.version>
    <appengine.target.version>1.8.1</appengine.target.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 </properties>

Dans l’idée, ça devrait fonctionner.

Problème : Google App Engine n’accepte ni les majuscules, ni les « point » dans ses numéros de version. Autant dire que 1.0.0-SNAPSHOT ne colle pas trop à la spécification 🙂
https://developers.google.com/appengine/docs/java/config/appconfig?hl=fr )

Solution : Utilisation du plugin maven gmaven-pugin, dans la phase « Initialize », pour changer un peu le numéro de version afin qu’il soit accepté par Google App Engine.

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.5</version>
    <executions>
        <execution>
            <!--<id>properties</id>-->
            <phase>initialize</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>
                    <!-- version pattern : 1.0.2-snapshot -->
                    project.properties["appengine.app.version"] = project.version.replace(".","-").toLowerCase()
                </source>
            </configuration>
        </execution>
    </executions>
 </plugin>

On remplace les point par des tirets, le tout en minuscule et nous voilà App Engine Compliant.

Conclusion

Maven est tout à fait capable de gérer différents profils, des configurations, et il est de notre intéret de garder cette logique pour gérer son versioning. Un petit plugin muni d’un script Groovy pourra nous aider à passer quelques obstacles simplement.

LB.

Rechargement à chaud et Développement Google App Engine / Maven

appengine mavenGoogle App Engine est une plateforme vraiment sympa. En plus d’être multi-langage (Python, Java, Go et Php), App Engine fournit tout un tas de services appréciables, tels qu’un DataStore intégré, un BlobStore, une gestion de Cache, un service d’envoi de mail et j’en passe… Retrouvez la liste complète ici : https://developers.google.com/appengine/docs/java/apis

Bref, C’est un PAAS complet et performant, qui a fait ses preuves en production.

Mais parlons maintenant de confort de développement.

Je suis développeur Java, et j’essaye autant que possible d’avoir des projets standardisés autour d’un outil de build, au hasard Maven. A priori, tout va bien, Google fournit le plugin qui va bien. Si l’on suit les instructions et que l’on construit correctement son projet, tout devrait bien se passer. Plus qu’à lancer en local mon serveur et ses services associés :

mvn appengine:devserver

Mon projet se build, mon serveur se lance, ma jolie page HTML s’affiche, je suis content !

Habitude oblige, je laisse mon serveur tourner et je commence à modifier mes pages HTML. Sauvegarde, F5, et……. rien. Ma page n’est pas actualisée. Pourquoi ? Et bien le serveur App Engine qui est lancé se base sur votre dossier target généré par Maven. Et sans nouveau build, aucune raison que ce dossier n’évolue.

Alors comment faire pour profiter des fonctionnalités App Engine (datastore par exemple) en local, tout en pouvant développer son Front-End confortablement ?

L’objectif est d’arriver à découpler le Front et le Back End… Le serveur App Engine, qui contient les fonctionnalités du back-end qui nous intéressent, pourra être lancé une fois à l’aide de Maven, disons sur le port 8000. Pour configurer le port, il suffit de changer votre POM :

<plugin>
   <groupId>com.google.appengine</groupId>
   <artifactId>appengine-maven-plugin</artifactId>
   <version>${appengine.target.version}</version>
   <configuration>
     <port>8000</port>
   </configuration>
 </plugin>

Maintenant, nous allons ajouter un serveur qui nous servira le front, par exemple Jetty. Hop, on alimente le POM.xml avec le plugin qui va bien :

<plugin>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-maven-plugin</artifactId>
   <version>9.0.3.v20130506</version>
 </plugin>

On lance notre Jetty (qui lui se lancera sur le port 8080)

mvn jetty:run

On ouvre notre navigateur favori, on va sur localhost:8080 pour attaquer notre Jetty et si tout s’est bien passé, le site apparaît… On modifie l’index.html (par exemple), on sauvegarde, F5 sur le navigateur, et la modification est bien prise en compte, ouf !

Problématique : à un moment, votre front va vouloir parler au back, par exemple à travers une requête REST, L’objectif est donc d’appeler son serveur App Engine, qui se trouve sur un autre port. On fait un petit Hack dans son code Javascript pour appeler la bonne URL, on lance sa requête, et…. Erreur dans le navigateur, Requête Cross Domain non autorisée. Et oui, un navigateur ne lance pas de requêtes vers un autre site, question de sécurité ! Pour Chrome, il existe une solution simple, le lancer avec l’option

--disable-web-security

Mais ce n’est pas l’idéal. Pourquoi ? D’abord parce que cela compromet votre navigateur si vous l’utilisez pour vous balader sur le net. La seconde raison est que de toute façon ça vous oblige à avoir un petit hack dans votre code côté client pour faire pointer vos requêtes vers le bon port.

La Solution ? Apache 2 et un Reverse Proxy

Alors comment faire ? Ma solution est d’avoir un troisième serveur, en frontal, qui va décider vers qui envoyer vos requêtes vers App Engine ou Jetty. Pour ma part j’ai choisi Apache2 et son module Proxy / Reverse Proxy qui fait ça très bien. (Documentation officielle : http://httpd.apache.org/docs/current/mod/mod_proxy.html )

Pour résumer ma configuration Apache 2 : Un fichier apache2.conf qui écoutera le port 80

Listen 80

Et la définition d’un site (il faudra avoir chargé les modules adequat auparavant, cf documentation officielle) :

<VirtualHost localhost:80>
   ServerAdmin webmaster@localhost
   ServerName localhost

   ProxyRequests Off
   ProxyVia Off

   ProxyPass /_ah http://localhost:8000/_ah
   ProxyPassReverse /_ah http://localhost:8000/_ah

   ProxyPass / http://localhost:8080/ 
   ProxyPassReverse / http://localhost:8080/
</VirtualHost>

Maintenant, quand avec mon navigateur je vais sur http://localhost/, Je sais que toutes mes requêtes REST qui sont préfixées par « _ah » sont redirigées vers App Engine sur le port 8000 par le reverse proxy, le reste allant vers Jetty.

Mission accomplie 🙂

Conclusion

On résume.
J’ai un Apache frontal qui dispatch mes requêtes vers Jetty ou App Engine en filtrant les URL appelés grâce à un Reverse Proxy.

Maven Apache frontal

OK, j’entends d’ici la critique : il faut vraiment lancer 3 serveurs différents pour pouvoir développer confortablement un simple site Web hébergé sur App Engine ? Prenons le temps de relativiser, et intégrons le fait qu’App Engine transporte avec lui sa persistence, c’est déjà un service d’économisé.

Dans mon exemple, j’aurais pu aussi éviter de devoir lancer Jetty. En effet, si mon front-end est 100% statique, aucune JSP à compiler ni rien, je pourrais demander à Apache de me restituer directement mes fichiers statiques en configurant un Directory qui pointe vers mon projet dans le VirtualHost. Qui plus, mon Apache est démarré comme service, et une fois lancé il est fait pour être oublié !

Passer une heure à configurer tout ça est un sacrifice que je referai tant les services rendus sont appréciables, le résultat étant un projet buildable, intégrable dans une usine de développement continu, testable et facilement déployable dans un environnement puissant.

LB.

Instacode

Juste un petit pointeur vers un site que je  trouve rigolo : Instacode.es ! A quoi que ça sert ? A la mode Instragram, ce site va proposer d’appliquer quelques filtres stylés à des captures d’écran de code.

Deux choses que je trouve intéressantes :

  • Il existe un plugin IntelliJ, qui après sélection d’un bout de code, va l’envoyer à Instacode en pré-sélectionnant le bon langage. Simple, efficace.
  • L’interface cliente est faite en WebGL ! De la 3D pour appliquer ses filtres, faire pivoter son bout de code dans l’angle qui nous plait le plus, j’aime bien…

Pensez-y pour illustrer quelques slides un peu tristes !

64079

 

[Programatoo] Greenfoot, Kinect, et Ubuntu 64 bits !

GreenfootEn ce moment, un de mes hobbits (haha) dans le cadre de Programatoo, c’est de jouer avec Greenfoot. Mais qu’est ce donc? Et bien c’est un logiciel créé pour introduire le langage Java et la notion d’objets auprès d’apprentis développeurs. En quelques mots, il permet de définir en Java des objets (Actor) qui vont pouvoir évoluer dans un monde (World). C’est bien foutu, même si l’interface mériterait un petit coup de jeune.

L’un des intérêts de Greenfoot, c’est que l’on peut facilement le faire intéragir avec une Kinect ! Une API bien faite, et des exemples sont fournis pour arriver rapidement à un résultat sympa, et les enfants adorent le concept de la Kinect. Après tout, coder en jouant avec la position de sa main, sa tête ou ses pieds, c’est plutôt fun !

Bref, tout cela mériterait un article à part entière. Mais pour l’instant on va se concentrer sur la première étape: l’installation ! Pour Greenfoot, pas de soucis, ça s’installe bien, à l’aide d’installeurs automatiques dédiés à différentes plateformes.

Greenfoot et Kinect

Si l’on souhaite aller plus loin, avec pourquoi pas le branchement d’une Kinect, l’installation peut se corser. Je vais tâcher de donner quelques astuces pour mes soucis rencontrés, c’est à dire avec deux distributions Ubuntu 12.10, l’une 32bits, et l’autre 64bits. La documentation Greenfoot étant assez bien faite et complète, on arrive très vite sur un tutoriel :

http://www.greenfoot.org/doc/kinect/ubuntu.html

Dans le cadre de ma distribution 32 bits, le tutoriel est parfait, à deux détails prêts. A l’étape 0, les packages présentés n’étaient pas disponibles chez moi, j’ai remplacé libglut3-dev par libglui2c2

1
2
sudo apt-get install g++ libboost-all-dev libglui2c2
sudo apt-get install libwxbase2.8-dev libwxgtk2.8-dev wx-common

Le deuxième soucis que j’ai eu, c’est qu’une fois l’installation terminée, la Kinect n’était pas reconnue. Il suffit juste de recharger le module adequat :

1
sudo modprobe -r gspca_kinect

Et en 64 bits alors ?

Et bien là, n’essayez pas de suivre le tutoriel, cela ne fonctionnera pas. Le tutoriel est fait pour faire télécharger OpenNI, NITE et le driver en 32 bits (stockés sur le site de Greenfoot), il y aura forcément un problème de dépendance au moment de l’installation. Plusieurs solutions s’offrent alors à vous:

Une fois que OpenNI, NITE et le driver sont installés, il faut tout de même installer KinectServer qui fera la passerelle entre Greenfoot et OpenNI. Pour cela se référer à la fin du turoriel disponible sur le site de Greenfoot.
(A noter que je n’avais pas utilisé Simple-OpenNI à la base, mais l’installation manuelle de chaque élément, et pour la peine KinectServer n’arrivait pas à se connecter à la Kinect… Il faudrait que je comprenne pourquoi)
S
i la Kinect n’est pas reconnue à la fin de l’installation, pensez à recharger le module adequat, comme pour le mode 32bits.

Une fois que KinectServer est lancé, vous pouvez ouvrir Greenfoot puis les projets d’exemple fournis pour Kinect, qui sont une bonne base de travail !
Have Fun !

LB.

PS : Pour avoir une traduction récente et en Français de l’interface Greenfoot, vous trouverez votre bonheur sur mon compte Github !

CloudBees et Cloud-IDE en 11min28s

Vendredi 20 octobre s’est déroulé le traditionnel BOF (Birds of Feather, selon Wikipedia, « petit groupe de discussion informel crée dans le but de résoudre un problème ponctuel dans un groupe de travail ») chez SFEIR. Autrement dit, une quinzaine de geeks assemblés dans une salle pour discuter des derniers sujets qui les bottent… C’était l’occasion pour moi de rapporter à mes collègues une présentation vue lors de l’OSDC 2012 qui s’est déroulé la semaine dernière à Paris, par Sacha Labourey, CEO de CloudBees.

En quelques mots, l’OSDC, c’était un peu bizarre. En effet, s’adressant autant à des décideurs que des développeurs, le contenu des conférences était un peu bancal et l’on sentait bien que les conférenciers n’étaient pas toujours à l’aise… De plus les locaux bien que situés idéalement (Georges V à Paris,  excusez du peu…) n’étaient pas vraiment adaptés (salles trop petites, programme pas très clair, porte d’entrée des salles à côté des speakers, créneaux cours entre les conférences…). Pourtant, apparemment ce n’était pas faute de moyens…

Bref, revenons à nos moutons. J’avais déjà eu l’occasion de voir Sacha Labourey au Paris JUG pour nous parler de Cloud, et j’ai trouvé sa présentation une fois de plus pertinente. Mise à part la partie commerciale de son discours (encore une fois OSDC oblige…), il a terminé par une démonstration bluffante des dernières fonctionnalités de CloudBees, en particulier le ClickStart. Le ClickStart, qu’est ce que c’est ? Et bien c’est la possibilité de créer une usine de développement en un clic. Comprendre par là que CloudBees propose différentes configurations de projets Java par défaut (genre un projet Jax-RS / Backbone, un projet Clojure ou encore un classique Java EE6), et en un simple clic CloudBees va créer un repository Git avec un archetype du projet, un job Jenkins qui sera capable de compiler et déployer tout ça sur une instance de serveur, accompagné de sa base de données… Bref, du tout en un, fonctionnel, et personnalisable à posteriori (rediriger vers un repo Github, changer la bdd, et j’en passe…)

Sacha Labourey a beaucoup parlé de « scalabilité », de stabilité, de support de la part de personnes compétentes (petite pensée pour Nicolas De Loof). Moi j’aimerais surtout insister sur le fait que ce genre d’initiatives permet de ne plus se préoccuper d’infrastructure, et de ces tâches récurrentes qui font perdre un temps fou. Alors ok, le « barbu » technique trouvera très important de mettre en place toute son infrastructure soit-même, bien optimisée comme on le souhaite, et c’est surement vrai dans beaucoup de cas. Mais si l’on souhaite se concentrer sur le coeur du problème, sur l’idée elle-même et ne plus perdre de temps sur toutes les choses autour, pour moi les avancées CloudBees vont dans le bon sens. Bref, si je suis tout seul et je veux tester un concept rapidement, et bien c’est clairement la solution. Qui plus est c’est gratuit, ça marche impeccablement bien, et je vous encourage à tester tout ça par vous-même !

Ce vendredi, en 11min et 28s, j’ai donc tenté d’évangéliser mes collègues en reproduisant tout ça avec ma vision des choses. J’en ai profité pour découvrir Cloud-IDE qui est vraiment un outil  prometteur…

Et c’est visionnable sur Youtube ! (d’ailleurs n’hésitez pas, abonnez vous au flux SfeirTube pour toutes les présentations SFEIR !)

LB.