Nouvelle version du driver VirtualBox pour Cloudify

Je voulais vous annoncer la sortie de la nouvelle version 1.2 du driver VirtualBox pour Cloudify: https://github.com/fastconnect/virtualbox-cloudify-driver

Release note:

  • Compatible avec Cloudify 2.2 (ne fonctionne plus pour 2.1)
  • Compatible avec VirtualBox 4.1 et 4.2

En attendant une explication plus détaillée de l’installation du driver, voici une première version: https://github.com/fastconnect/virtualbox-cloudify-driver/issues/1

Les nouveautés de Mule 3

Mule 3 apporte un nombre important de nouveautés par rapport a mule 2.
Parmi celles-ci on retrouve principalement :

  • l’ajout de la notion de flow
  • l’ajout de Mule Studio avec un environnement de developpement graphique
  • l’ajout d’un data mapper graphique

Flow

Un « Flow » est un mecanisme simple et flexible qui permet d’orchestrer des services en utilisant les capacités sophistiquées de Mule ESB.

Un Flow est composé d’un « Message Source » et d’un enchaînement de « Message Processor ». Par rapport à l’utilisation des « Services », qui définissent explicitement les phases d’inbound et d’outbound d’un composant, ce qui limite la flexibilité, les « Flows » ne définissent rien explicitement. On peut configurer dans un même « Flow » les différentes étapes nécessaire à la résolution de la problématique et ainsi éviter d’agréger des services ensemble à l’aide des « vm transport » ou des « chaining router ».
flow_mule

Mule Studio

http://www.mulesoft.com/sites/all/themes/mulesource/images/products/xml-mule-flows.png

Mule Studio est un environnement de développement intégré basé sur Eclipse. Il permet de développer, débugger et déployer des applications Mule ESB. Il laisse le choix au développeur d’utiliser l’environnement graphique ou d’éditer les fichier xml à la main.

L’environnement graphique permet au développeur de disposer des blocs afin de créer des Mule Flows qui sont à la base des applications Mule. D’un simple drag and drop, il est possible de créer une séquence d’événement pour traiter les messages. Chaque bloc peut être configurer à l’aide d’une boite de dialogue grâce à des champs d’options.

http://blogs.mulesoft.org/wp-content/uploads/2011/03/mule-studio.png

Toutefois il reste possible d’éditer les fichiers de configuration xml à la main. Les développeurs peuvent facilement changer de mode d’édition car Mule Studio synchronise les relations et les paramètres des différents composants.
Mule Studio améliore l’éditeur xml en y apportant l’auto-complétion intelligente (listes des composants, listes des options pour un composant, …) grâce à une liste déroulante qui se met à jour en temps réel en fonction du contexte.

http://blogs.mulesoft.org/wp-content/uploads/2011/06/Screen-shot-2011-06-27-at-3.07.12-PM.png

Data Mapper

http://www.mulesoft.com/sites/all/themes/mulesource/images/products/data-mapping-capabilities.png

Mule Data Mapper est entièrement intégrer à Mule Studio

  • Transformation visuelle des données
  • Génération des meta-données à partir de schémas ou d’un échantillon de données
  • Les formats de données supportés sont XML, JSON, CSV, POJOs, and Excel
  • Des transformation plus complexes peuvent être appliquées en utilisant des règles, des recherches et des capacités d’édition plus avancée.

Bonus

La vidéo de présentation de Mule 3:

Les 5 mercenaires du Devops au Devoxx France

Du 18 au 20 avril 2012 s’est tenu la première édition du Devoxx France. A cette occasion, j’ai eu la chance de découvrir le mouvement Devops grâce à la présentation de ses 5 mercenaires que sont :

Devops est une contraction de Développeur et Opérationnel. Ce mouvement tente de réconcilier les développeurs et les opérationnels.

Malgré l’arrivé des méthodologies Agiles dans la plupart des structures, le monde des développeurs et des opérationnels reste scindé en deux. D’un coté, nous avons les développeurs qui fournissent aux opérationnels un « livrables », pendant que les opérationnels tentent de déployer le dit livrable.
Très souvent, la définition du livrable n’est pas la même que l’on se trouve du point de vue du développeur ou de l’opérationnel.
L’une des recommandations du DevOps est de définir un livrable compréhensibles par les deux parties.
Pendant la présentation, les 5 mercenaires nous montrent une forme de livrable depuis un Jenkins. Les livrables sont des packages natifs, des RPMs en l’occurrence.
Cette forme de livrable  :
  • est auto-suffisante
  • peut être facilement déployé
  • peut être rollbacké
  • est archivable
  • est configurable

Dans leur exemple, ils proposent de livrer des RPMs contenant le conteneur Tomcat ainsi que le War de l’application. Cela permet aux développeurs de maintenir une configuration du conteneur répondant aux besoins de leur application.

Une partie du déploiement de l’application peut être configurable et/ou laissée à la main des opérationnels afin de configurer les éléments dédiés aux environnements de production (mot de passe de la base de données, etc…).
Les RPMs peuvent être construits par Jenkins et mis à disposition des opérationnels sur un dépôt Maven.
Les opérationnels peuvent alors aller chercher une version spécifique du livrable pour le déployer, voir même utiliser Jenkins; ou tout autre outil de Build continu.
En allant même un peu plus loin, il est possible de configurer le Jenkins afin de déployer régulièrement l’application. Nous parlons alors de déploiement continu.
Cette approche permet
  • une meilleur entente entre les opérationnels et les développeurs
  • d’améliorer la qualité du livrable
  • d’augmenter la satisfaction des utilisateurs

Cependant, la mise en place de cette recette miracle peut rencontrer quelques difficultés :

  • Une résistance forte du au choc culturel. Toutes les structures ne sont pas prête à accepter une étroite collaboration entre les opérationnels et les développeurs.
  • Généralement, il est fortement recommandé d’avoir une application qui pratique déjà l’intégration continu. Oui, ça peut peut-être faire sourire, mais les applications qui pratiquent l’intégration continue ne sont pas aussi courantes.

GigaSpaces Document API and JAXb

I wrote this article and the plugin that ships with it last year when GigaSpaces 8.0 was released and realized that I never finally published both the sources and article so here it is!

GS8 introduced a new way to store data in a flexible manner: the space document.

Document is an evolutive object storage that allow users to dynamically add or remove properties and even dynamically add indexes on any property.

Some of my clients uses XML to model their data and where quite happy to be able to seamlessly be able to make evolve their Space object as easily (or even more easily) as their XML schema.

As this need sounded quite interesting to me I build a small plugin for JAXb that allows to generate Document compliant classes directly from your XML Schemas.

You can download the source code and test it from here: https://github.com/fastconnect/jaxb-gigaspaces

Nouveau driver VirtualBox pour Cloudify

Je travaille beaucoup avec Cloudify ces derniers temps: ce produit merveilleux me permet de déployer un cluster MongoDB ou Hadoop en quelques minutes (et pas en quelques heures ou jours…)
Je réalise pas mal de présentations sur ces sujets, avec des démos, donc j’ai besoin de créer de nouveaux clusters très rapidement.
Grâces au Cloud et aux IaaS comme Amazon EC2, je peux déployer un gros cluster avec de nombreux serveurs. Mais pour cela, il me faut une connexion internet chez le client chez qui je fait la démo: et ça, c’est mission impossible!

Cloudify permet de créer un Cloud local sur mon portable, mais cela pose quelques problèmes:

  • Je suis sous MacOS X, et certaines Recipes ne fonctionnent que sous Linux
  • Quand je créé un cluster MongoDB, et que j’utilise le même port pour chaque instances, ce n’est pas un problème si ces instances sont sur des machines différentes… mais avec le « Cloud local », j’ai des conflits de ports…
  • etc.

J’ai alors décidé de créer un vrai Cloud sur mon portable pour pouvoir faire mes démos sans connexion Internet. Ainsi, je peux simuler un déploiement proche de la réalité.
Mon portable possède 16Go de RAM, donc je peux créer plusieurs machines virtuelles (pas trop non plus, mais assez pour une démo).
Pour ce faire, j’ai d’abord essayé d’installer OpenStack, mais c’est plutôt complexe à installer/configurer, surtout sur MacOS.

En même temps, quand j’ai besoin de faire des choses spécifiques qui nécessitent un OS Linux, j’utilise Vagrant.
Vagrant est génial: il me permet de créer une nouvelle VM à partir d’un template, et la configurer à l’installation grâce à un script de bootstrap.
Pour créer les VM, Vagrant utilise VirtualBox, et ils existent de nombreuses « boxes » (template de VM, similaire à des AMI Amazon): http://www.vagrantbox.es/

En fait, je peux même créer plusieurs VM avec Vagrant, et exécuter Chef ou Puppet comme script de bootstrap…
Donc en théorie, je peux déployer un cluster MongoDB/Hadoop avec Vagrant.
Mais ce n’est pas aussi puissant que Cloudify:

  • Vagrant ne fournit pas un contexte global au déploiement, donc on ne peut pas faire de dépendances entre les services
  • Vagrant ne fournit pas de monitoring, de gestion du fail-over ou de l’auto-scaling
  • Vagrant ne peut créer des VM que sur la machine local, pas sur un serveur distant
  • Il y a plein de limitations au niveau des scripts de déploiement, c’est pourquoi Cloudify utilise Chef/Puppet, et que ces derniers ne remplacent pas Cloudify

Suite à ça, j’ai décidé d’implémenter mon propre driver VirtualBox pour Cloudify: je conserve la puissance de Cloudify, mais je peux simuler un réel déploiement (avec des VM Linux, etc.). Et surtout: je peux faire tout ça sur mon portable sans connexion Internet!

Vous pouvez trouver ce driver sur Github: https://github.com/fastconnect/virtualbox-cloudify-driver

Pour l’utiliser, il vous suffit de l’ajouter dans le « overrides package » de Cloudify (voir la documentation de Cloudify) et de configurer le driver comme expliqué dans le Readme.

Ce driver utilise le WebService de VirtualBox, il y a donc quelques prérequis:

  • Après avoir installé VirtualBox, il faut créer une « HostOnlyInterface » qui sera utilisée par les VMs de Cloudify
  • Il faut aussi configurer le WebService pour ne pas utiliser l’authentification: VBoxManage setProperty websrvauthlibrary null
  • Ensuite, démarrez le WebService: vboxwebsrv
  • Téléchargez une « box » depuis http://www.vagrantbox.es/, et placez la dans un répertoire qui va contenir toutes vos « boxes »
  • Enfin, configurez le driver. Il faut spécifier le chemin du répertoire qui contient les « boxes », il faut donner le nom de la « HostOnlyInterface », et il faut spécifier l’URL du WebService.ATTENTION: l’URL du WebService doit utiliser l’IP de la HostOnlyInterface, car elle doit être accessible par la VM qui va contenir le Manager de Cloudify

Si vous avez suivi ces étapes correctement, vous devriez pouvoir créer un Cloud « local » avec VirtualBox!

Comme le driver utilise le WebService de VirtualBox, ce dernier peut se trouver sur un serveur dédié.
VirtualBox n’est pas un vrai IaaS comme OpenStack, mais ça peut suffire dans certains cas, et vous pouvez installer une interface Web d’administration (http://code.google.com/p/phpvirtualbox/).

Lors de la réalisation de ce driver, j’ai rencontré un gros problème: je n’ai pas de serveur DNS pour mes machines virtuelles.
Ce qui veut dire que les VMs n’arrivent pas à se connaitre et communiquer entre elles.
Du coup, le driver configure la machine virtuelle juste après sa création: il configure la carte réseau, change le hostname et change le /etc/hosts.
Pour ce faire, il utilise le « VirtualBox Guests Addition », qui doit donc être installé sur les templates de VM (ce qui est le cas avec les « boxes », car Vagrant en a aussi besoin).
Avec ce « Guests Addition », un agent VirtualBox s’exécute au démarrage de la machine, et on peut l’utiliser pour effectuer des opérations comme la création de répertoires, ou l’exécution de programmes.

La bonne nouvelle, c’est que grâce à cet agent, on peut effectuer les mêmes opérations peut importe l’OS (Windows, Linux, etc.).
La mauvaise, c’est que le processus de configuration du réseau est différent suivant l’OS, et n’est pas le même sur Linux et Windows.
Pour le moment, le driver utilise des chemins et des commandes Linux (sed, etc.).
Du coup, le driver ne fonctionne que pour des machines virtuelles Linux, et il n’a été testé qu’avec Ubuntu

Le driver est OpenSource (APL), donc vous pouvez contribuer et ajouter vous même le support des VM Windows ! (et tester sur d’autres distributions Linux)

J’espère que ce driver puisse vous être utile, et puisse vous aidez à tester Cloudify sur votre poste local!
Vous pouvez trouver d’autres informations techniques sur le README sur Github:
https://github.com/fastconnect/virtualbox-cloudify-driver
Vous pouvez télécharger ce driver depuis notre repository Maven OpenSource.

Morning with MongoDB et MUG

Le 7 Novembre 2012 se sont déroulés 2 événements: le « Morning with MongoDB » et le « MongoDB User Group (Paris)« .

Morning with MongoDB

Vous pouvez retrouver les slides des présentations sur le site de 10gen.
Pour plus d’information sur l’événement, regardez ici.
L’agenda de cette matiné été le suivant:

  • Présentations de 10gen (MongoDB et BigData)
  • Présentations de cas d’utilisations des clients
  • Présentations de cas d’utilisations des partenaires (dont FastConnect!)

Je ne vais pas vous détailler toutes les présentations, mais juste quelques remarques qui me semble interessantes.

10gen ont parlé de la Roadmap, et on note les prochaines fonctionnalités pour la 2.4:

  • Intégration de Kerberos et LDAP/AD
  • Hash comme clé de répartition pour le Sharding
  • Moteur V8 pour le MapReduce
  • Recherche par intersection de polygones pour la recherche GeoSpatial
  • Amélioration du framework d’aggregation

Criteo et le Figaro on un usage commun: stocker des données de sources hétérogènes dans MongoDB grâce à la flexibilité du schéma. Pour Criteo, ils peuvent stocker dans une seule même base les catalogues de produits de plusieurs vendeurs, et pour le Figaro, ils peuvent stocker les données des différents sites web au même endroit.

Je remarque aussi un retour d’expérience qui revient fréquemment: grâce à des performances bien supérieurs aux RDBMS (dans leurs cas d’usages), MongoDB supprime la nécessité d’un cache, et la complexité qui va avec (gestion de l’eviction, mise-à-jour, etc.)

MongoDB s’avère être aussi efficace pour stocker les logs: en effet, les « Capped Collections » sont très utiles pour cet usage, et on peut choisir un niveau de « Write Concern » différent en fonction de l’importance du log (DEBUG, WARN, etc.)

Enfin, MongoDB et sa simplicité à mettre en place la réplication, sert à fournir des données à travers le monde (WAN).

Je vous laisse consulter les présentations ici, ainsi que ma présentation sur un cas d’usage MongoDB avec Hadoop:

MongoDB User Group

Ce MUG était orienté Cloud:

Nous avons eu une première présentation de la plateforme Cloud Scalr, et comment déployer et monitorer MongoDB dessus.

S’est suivie une présentation sur un retour d’expérience avec MongoDB sur le Cloud (Azure) par Pierre Couzy (Microsoft) et Yann Shwartz.
Cette session était très intéressante, car on découvre les pièges à éviter et les problèmes que l’on peut rencontrer dans des situations réelles.
J’ai beaucoup aimé cette présentation car elle recoupe beaucoup avec notre retour d’expérience avec MongoDB sur le Cloud. C’est pourquoi nous essayons de mettre en place ces bonnes pratiques sous la forme de scripts Cloudify!

Pour terminer, nous avons eu le plaisir d’accueillir Matt Bates qui nous a présenté le nouveau framework d’aggregation de la version 2.2 de MongoDB, ainsi que les futures évolutions.

Je remercie au passage les organisateurs du MUG, les hébergeurs et les différents speaker.

En conclusion, c’était une journée riche et interessante !