FuseSource Community Day – Outil Fuse IDE et la stratégie Fuse Fabric

Le dernier compte-rendu de cette journée de conférences au FuseSource Community Day est sûrement la présentation qui m’a le plus interpelé.

Elle a été présentée par Charles Moulliard (@cmoulliard) et portait sur FuseFabric.

Comme les autres intervenants, Charles se trouve être lui-même commiteur actif sur différents projets de la fondation Apache tels que :

Il sera également l’auteur du livre “Apache ServiceMix and Karaf in Action” aux éditions Manning.

En fait, Fuse Fabric part du constat que les projets d’intégration sont difficiles à mener en raison de la complexité inhérente à leur nature même et, cela, plus particulièrement sur les phases d’installation, de configuration et d’exécution. De plus, ce constat est d’autant plus vrai quand le conteneur s’appuie sur OSGi.

Aussi, Fuse Fabric, qui est un projet open source encore en beta à ce jour, tente de répondre à cette problématique en visant à simplifier la configuration, le démarrage et le provisionnement des applications.

En effet, il propose, de manière non exhaustive :

  • le déploiement et la configuration distante puisque les configurations et les features sont :
    • transmises au travers du réseau,
    • distribuées entre les différentes machines,
    • et qu’il est aisément possible de les récupérer.
  • de fabriquer des services mais également de les découvrir ainsi que les endpoints déjà présents dans le système mais également de faire du load balancing et du fail over grâce à cette connaissance,
  • de fournir une unité de déploiement “intelligente” : en effet, en s’appuyant sur un fichier descripteur XML, il est possible de renseigner directement des archetypes maven qui ont un packaging de type OSGi et qui sont présentes sur le Repository Manager. Ces archetypes sont alors directement déployables.

Pour résumer, on peut dire que Fabric est, à la fois :

  • un annuaire distribué (registry),
  • un ensemble d’agents (qui se connectent à l’annuaire afin de récupérer les informations dont ils ont besoin,
  • un ensemble de profiles.

Suite à la présentation générale de Fuse Fabric, Charles nous a présenté plus précisément les différentes notions à connaitre afin de mieux appréhender les apports de Fabric.

Concernant l’annuaire, Fuse Fabric s’appuie sur Apache ZooKeeper pour fournir un service de coordination centralisé, distribué et hautement disponible.

Coté agents, ils sont déployés au sein d’Apache Karaf (il est également possible de les déployer dans ServiceMix). Suite à leur déploiement, ils scrutent alors l’annuaire, ce qui leur permet de récupérer des informations de ce dernier en s’appuyant sur JMX.

Enfin, le Profile a pour rôle le regroupement des informations de configuration et de contrôle de ce qui doit être déployé. C’est lui qui contient la logique et qui est utilisé par les agents. Il est à noter qu’un agent peut, bien évidemment, démarrer un ou plusieurs Profiles qui se trouvent être hiérarchisés puisqu’il est possible de leurs fournir une notion de père et de fils, mais également versionnés.

Ainsi, cela donne, dans un contexte d’utilisation :

  • démarrage d’une instance de Karaf (ou ServiceMix),
  • installation du registry,
  • définition des profiles et installation de ces derniers dans le registry,
  • création d’un agent local,
  • association du ou des profiles à l’agent,
  • démarrage de l’agent.

Charles nous a ensuite fait une petite démonstration qui a présenté un déploiement de routes Camel au sein du conteneur OSGi Karaf distant.

Conclusion

En conclusion, et j’espère que vous l’aurez compris au travers de ce petit compte-rendu, j’ai trouvé cette session très intéressante car Fuse Fabric offre beaucoup de possibilités quant aux déploiements et à la reconfiguration d’un système s’appuyant sur OSGi. En outre, chose que je n’ai pas précisée dans mon compte-rendu, les instances de Karaf se déploient automatiquement sur les machines cibles (via ssh) et l’agent est automatiquement démarré : cela permet donc d’envisager un déploiement automatisé dans le cadre d’une application distribuée (modulo le fait qu’il faut qu’elle repose sur OSGi… ;-)).

Dernier point que vous aurez peut être remarqué… : le titre stipule une présentation de FuseIDE que je n’ai pas retranscrit dans ce compte-rendu malgré une démonstration faite par Charles (et ce, même si elle était également très intéressante)…

Nombre de vue : 44

COMMENTAIRES 2 commentaires

  1. Je tiens tout d’abord a te féliciter et remercier de ce blog français qui introduit un peu plus en détail la stratégie de FuseSource Fabric. Comme tu l’as très bien résumé, nous avons mis en place une stratégie de registre distribué (Apache Zookeeper) dans lequel sont stockés les informations des agents déployés ainsi que les profils contenant les artefacts à déployer sur les agents. Notre démarche vise également a faciliter le déploiement à distance, le packaging et la mise en place des projets dans le cloud et l’utilisation de services élastiques (camel-fabric, distributed OSGI, …).
    Ce point que tu décris n’est pas très clair : “de fournir une unité de déploiement “intelligente” : en effet, en s’appuyant sur un fichier descripteur XML, il est possible de renseigner directement des archetypes maven qui ont un packaging de type OSGi et qui sont présentes sur le Repository Manager. Ces archetypes sont alors directement déployables.”

    Charles

  2. Khanh Maudoux dit :

    Merci Charles pour ce complément et cette clarification.
    Dans un article à venir, j’essaierai d’être plus exhaustif sur les concepts/notions de Fuse Fabric.

    Khanh Tuong

AJOUTER UN COMMENTAIRE