Plateforme BigData (Cloudera) sur un Cloud: automatisation avec Cloudify

Le Big Data est un sujet incontournable chez FastConnect: pour élargir son business, il est maintenant critique d’élargir son champ de vision à l’aide des données externes et les données non-structurées et sous-exploitées.
Hadoop et son écosystème répond à ces challenges, et cette plateforme Big Data devient de plus en plus mature grâce aux différents éditeurs comme Cloudera, HortonWorks, MapR ou Pivotal.

Mais la mise en œuvre de cette plateforme constitue aussi un challenge:

  • Pour répondre à des problèmes complexes, la communauté a développé plusieurs outils indépendants: Sqoop, Flume, HBase, HDFS, etc.
    La multiplicité de ces outils rend le déploiement plus complexe.
  • Pour traiter des volumes conséquents, le déploiement de la plateforme doit se faire sur plusieurs nœuds. De plus, on veut pouvoir augmenter ou réduire le nombre de nœuds de manière élastique en fonction du besoin.
  • Avec un grand nombre de nœuds, on est sujet à plus de risque de pannes, ce qui nécessite une attention particulière sur la HA (High Avaibility / Haute Disponibilité)

L’article présent traite de l’automatisation à l’aide de Cloudify du déploiement et de la configuration sur un Cloud d’une telle plateforme, basée sur la distribution Cloudera de Hadoop.

Besoins

une plateforme BigData configurée

Nous souhaitons effectuer des traitements sur un gros volume de données et obtenir par exemple des statistiques sur un fait, ou encore faire des prédictions. Oui on souhaite faire du “BigData”, et il nous faut une plateforme adéquate déployée et configurée. Une solution serait de se servir de la plateforme pré-installée que propose Cloudera sous forme d’une machine virtuelle “All-in-One”

Oui mais… j’ai vraiment beaucoup de données!!

Ça se corse un peu! Le volume est énorme, tout stocké sur une seule machine ne me permettra pas de bénéficier de la réduction du temps de traitement que nous offre la faculté de distribution du traitement. On voit là une limite du mode StandAlone (All-in-One): il nous faut une plateforme en architecture “distribuée, et donc plusieurs machines qui servirons de DataNode / TaskTracker (Nœud de stockage de données et de traitement ).

Je n’ai pas assez de budget..

Oui c’est vrai, il faut du budget pour s’offrir une plateforme comportant plusieurs serveurs. Pourquoi ne pas se tourner vers le Cloud? En effet, avec la particularité IaaS du Cloud Computing, il est désormais possible d’obtenir de l’infrastructure (machines virtuelle en l’occurrence) et de payer en fonction de la durée d’utilisation. Ainsi plus besoin d’une plateforme de serveurs physiques, car il est possible de louer des machines virtuelle (VMs) à l’heure chez un fournisseur ( Amazon EC2 par exemple ) ce qui ne nécessite pas forcement un gros budget au départ ;)

Oups… j’ai fait une erreur lors de la configuration: trop longue et répétitive :|

Le fait de louer des VMs pour un certain temps et de les détruite après, entraîne la réinstallation et la reconfiguration de la plateforme chaque fois que le besoin se pose. Cette opération est longue et répétitive quand elle est effectuée manuellement. Aussi, les risques d’erreurs de configuration sont grands. Automatiser le processus permet d’être sûr d’avoir les mêmes configurations d’un déploiement à l’autre, et de gagner considérablement en temps.

Cloudify est un outil qui permet d’effectuer une telle tâche: nous n’avons plus qu’à décrire les procédures d’installation et de configuration de la plateforme, et d’exécuter le tout quand bon nous semble avec une seule ligne de commande: install-application cloudera

Nous pourrons aussi jouir des autres fonctionnalités de Cloudify telles que:

  • Multi-cloud : le prototype hébergé chez un fournisseur public (Amazon EC2 par exemple) pourra être migré facilement sur l’infrastructure interne (Openstack, ou bare metal par exemple)
  • Custom Command : pour automatiser des tâches d’administrations sur l’ensemble des nœuds
  • Gestion du cycle de vie de l’application: pour la gestion de crash (fail over)
  • Élasticité: possibilité d’ajouter à chaud des nœuds DataNode+TaskTracker en cas de besoin
  • Monitoring: avoir une vue d’ensemble du cluster, en connaître la charge et ainsi anticiper l’ajout de nouveaux nœuds

L’application cloudify-cloudera

Cloudify-cloudera est le nom que nous avons donné à l’application Cloudify qui permet de faire tout ce qui a été cité plus haut. Le Cloud utilisé ici est Amazon EC2 (mais Cloudify est Multi-Cloud: cela fonctionne aussi bien sur OpenStack, sur un environnement de développement avec VirtualBox, ou même un datacenter traditionnel [sans virtualisation]).

Les recettes dans leur état actuel permettent d’obtenir une plateforme BigData composée d’un Cloudera Manager et d’une distribution Hadoop repartie sur deux types de noeuds : Master et Slave. Un service de base de données MySQL est aussi disponible en cas de besoin. En plus de la distribution Cloudera, nos recettes sont capables de déployer un MongoDB en mode Sharding afin d’y effectuer du MapReduce.

archi cluster cloudera on demand

Nous nous servons de Cloudera Manager (CM) pour configurer les composantes de la plateforme. CM expose une API REST pour permettre son pilotage programmatiquement, dans notre cas, par des scripts Groovy exécutés par Cloudify.

Les Briques (noeuds) et services installés

L’application installe quatre principaux middlewares :

  • Cloudera Manager
  • Cloudera distribution of Hadoop
  • La base de données MySQL : optionnelle
  • La base de données MongoDB: Sous forme de cluster (mode sharding).

L’installation et l’implémentation de ces services se font sur des instances de machines, appelées nœuds du cluster.

Les services Cloudera supportés sont:

ZOOKEEPER, HDFS, MAPREDUCE, OOZIE, HIVE, HBASE, SQOOP, FLUME, HUE

Le concept de Hadoop veut lui-même que l’on dispose principalement de deux entités ou types de rôle : le maître (Master) (NameNode, JobTracker) et l’esclave (Slave) (DataNode, TaskTracker). Le service MongoDB étant déployé en mode sharding, il est nécessaire pour son architecture de lui fournir aussi deux types d’instances : master et slave. MySQL quant à lui sera déployé sur une instance de machine propre à elle.
Si nous récapitulons, nous pouvons dire que notre système sera composé principalement de quatre types de noeuds (service Cloudify).

Cloudera Manager : (code : cdh4-manager)

Représente une instance de Cloudera Manager. Ceci permet d’administrer l’ensemble du cluster via une interface Web.

Master CDH : (Code : cdh4-master)

Nœud sur lequel seront installés les composantes NameNode, JobTracker, et tout autre service ou composante de service Cloudera qui implémente une division Master/ Slave, à l’instar de MongoDB (partie Master).

Slave CDH : (Code : cdh4-slave)

Nœud sur lequel seront installés les composantes DataNode, TaskTracker, et tout autre service ou composante de service Cloudera qui implémente une division Master/ Slave, à l’instar de MongoDB (partie Slave).

MySQL : (Code : mysql-cdh4) sur lequel sera installé le middleware MySQL.

web-ui-cloudify

Opérations annexes et/ou d’administrations

Backup / Restauration HDFS

Une problématique assez fréquente est la sauvegarde des données potentiellement résultantes des traitements effectués à la fin de l’utilisation du cluster, de façon à les réimporter une prochaine fois pour continuer les traitements.

Deux custom commands ont été développées et implémentées aux noeuds de type cdh4-master pour cet usage. La commande backup prend en paramètre le nom du répertoire à sauvegarder sur Amazon s3 ; la commande de restauration prend en paramètre le nom de la sauvegarde à restaurer.
Il est à noter que le nom de fichier à persister sur S3 est généré de façon intelligente selon un pattern « hdfs-backup-yyy-mm-dd~hh.mm.ss » ce qui permet de s’y retrouver très rapidement lorsqu’on cherche à restaurer une sauvegarde précise.
L’invocation de ces commandes via le Shell Cloudify se fait de la façon suivante :

Invoke cdh4-master s3HdfsBackup /test
// Sauvegarde un répertoire HDFS /test dans un repertoire « hdfs-backup-yyy-mm-dd~hh.mm.ss »

Invoke cdh4-master s3HdfsRestore /hdfsBackups/hdfs-backup-yyy-mm-dd~hh.mm.ss /test
 // Restaure le contenu du répertoire s3 hdfs-backup-yyy-mm-dd~hh.mm.ss dans un répertoire /test du HDFS

Une autre façon de faire est d’exploiter le montage des EBS d’Amazon dans Cloudify: on aurai pu démonter les EBS en cas de destruction du Cluster, pour les re-monter lorsqu’on a besoin à nouveau du Cluster. Ce mécanisme est d’ailleurs nécessaire pour ne pas perdre les données en cas de crash d’une VM.

Mongo sharding

Possibilité offerte via custom commands d’activer le sharding sur des bases de données et collections MongoDB.

Conclusion

Au terme de cet article, nous avons présenté quelques besoins qui se posent concernant la gestion d’une plateforme BigData et les solutions que nous y avons apportées, se résumant en l’automatisation du déploiement et de la configuration. Le déploiement opéré par Cloudify est multi-cloud, c’est-à-dire que le prototype développé sur Amazon (pour des raisons de budget) pourra être migré facilement sur votre plateforme Openstack interne. De plus nous bénéficions des fonctionnalités d’auto-réparation offerte par Cloudify (remplacement et reconfiguration des composants en panne).

L’utilisation de l’application développée est aisée. Le projet n’est pas clos, nous continuons d’y ajouter des fonctionnalités et améliorations. Quelques évolutions à venir :

  • Possibilité d’utiliser des EBS comme support de stockage: ce qui rassurerait l’utilisateur quant à la sauvegarde de ses données
  • Custom command pour ajout / suppression de services cloudera
  • Combiner Puppet / Cloudera: Puppet permettra de gagner en temps et en performance pour tout ce qui est installation et déploiement, tandis que Cloudify gérera les dépendances entre les services et la configuration du cluster une fois le tout installé.
  • Custom command pour importer / exporter des Job Oozie au format XML,

On démontre ici une fois de plus, la puissance de l’association BigData + Cloud, ainsi que les nombreuses possibilités que nous offre l’outil Cloudify.

Gatling – Test de charge et cloudification

Dans le cadre du développement de l’application FastContest et de son déploiement dans le cloud d’Amazon avec Cloudify, nous avons souhaité effectuer des tests de charge automatisés afin :

  • d’évaluer la charge maximale que notre application pouvait soutenir
  • de dimensionner les machines du Cloud sur lesquelles nous déployons
  • de mettre en exergue les faiblesses de notre application
  • de jouer des scénarios définis automatiquement avec plusieurs centaines de joueurs concourants et ainsi de vérifier la bonne intégrité des données à l’issue

Nous avons choisi d’utiliser Gatling, un outil de test de charge open-source, qui permet d’écrire les scénarios de test sous forme de codes élégants et concis.

Arborescence de Gatling

Le dossier d’installation de Gatling est organisé selon l’arborescence suivante :

  • /results : Contient les résultats des benchs sous format web
  • /bin : Contient les scripts permettant de lancer Gatling
  • /target : Contient les fichiers issus de la compilation de nos scénarios + cache
  • /conf : Contient les fichiers de configuration (niveau de log…)
  • /user-files : Contient les fichiers .scala de définition des scénarios
  • /lib : jar de gatling

Des scénarios implémentés en Scala

À la différence de JMeter qui dispose d’une interface graphique pour la définition des scénarios de simulation et de ses paramètres, Gatling propose une API écrite en Scala. Contre-intuitivement, il est assez élégant et aisé de définir des scénarios en Scala plutôt que via une interface graphique, surtout qu’il n’est pas nécessaire d’être un ninja en Scala pour réaliser ses premiers scénarios. Gatling propose une multitude de fonctionnalités dont les basiques seront présentées plus loin.
La documentation complète est disponible à ce lien.
Les scénarios sont placés dans le dossier /user-files/simulations. Voici, typiquement, un scénario implémenté en Scala :

val scn = scenario("User play")
  .feed(myCustomFeeder)
  .exec(
     http("register")
      .post("/user/register")
      .param("email", "${email}")
      .param("password", "${password}")
      .param("pseudo", "${pseudo}")
      .headers(headers_1)
      .check(status.is(200)))
  .pause(0 milliseconds, 100 milliseconds)
  .repeat(10) {
    feed(csv("question_answer.csv").circular)
      .exec(
        http("answer")
         .post("/response")
         .param("questionId", "${questionId}")
         .param("answerId", "${answerId}")
         .headers(headers_1))
      .pause(0,5)
  }

Dans ce cas, Gatling va effectuer une requête post /user/register avec les paramètres email et password (défini dans un fichier séparé), et vérifiera que la réponse a bien un status 200. Enfin, après une pause de 0 à 100 ms, Gatling effectue 10 requêtes /response avec une pause de 0 à 5 sec entre chaque. Les paramètres sont fournis par un “feeder” qui permet de factoriser des variables au sein d’un fichier CSV par exemple (pour plus d’infos, suivez le lien)
Pour apprendre à écrire un scénario avec Gatling, il y a le tutorial officiel.

Exécution de bench

Pour lancer un scénario il suffit d’exécuter le script gatling.sh ou .bat selon l’environnement qui se trouve dans le dossier /bin. Gatling va compiler automatiquement les classes Scala puis vous demande de choisir le scénario à exécuter. À l’issue de la simulation, un rapport web est généré automatiquement à partir du fichier de log. Il contient toutes les métriques mises en forme de façon graphique grâce à la librairie Javascript HighChart.

Un exemple de rapport :

Cloudification

Afin d’effectuer des tests de charges proches des conditions réelles nous avons cloudifié Gatling en automatisant son installation et son exécution sur les VM d’Amazon.
Grâce à Cloudify, nous pouvons désormais lancer les tests de charge à partir d’Internet et sur autant de machine que nous voulons. Les recipes sont relativement simples puisqu’il s’agit essentiellement de télécharger et de dézipper le dossier d’installation de Gatling. Les scénarios sont uploadés avec la recipe, ils doivent donc être déplacés dans le répertoire /simulation de Gatling.
L’exécution du bench s’effectue grâce à une custom command “executeBench” dont le premier paramètre est le nom du scenario à exécuter et le second, le nom que l’on donne à cette simulation. La custom command lance alors le test de charge pour toutes les instances de Gatling sur chaque VM. Les rapports sont donc générés individuellement sur chaque VM.

Pour obtenir un rapport unique, on pourrait scripter la récupération de tous les résultats générés, leur fusion et la regénération d’un nouveau rapport global.
Le rapport est ensuite poussé sur S3 soit automatiquement, soit via une custom command (pushResult).

À travers ce use-case de Cloudify, nous montrons, une fois encore, sa simplicité et sa commodité d’utilisation en automatisant complètement la chaîne : déploiement, installation et exécution de tests de charge à partir du Cloud Amazon EC2.

Conclusion

L’un des avantages le plus important de Gatling est sans conteste sa capacité à générer des rapports graphiques de qualité à l’issue de chaque simulation. De cette façon, le testeur a immédiatement accès aux résultats de manière visuelle, sans post-traitement supplémentaire.
De plus, l’écriture des scénarios de test de façon fonctionnelle en Scala peut faciliter la lisibilité du test. Surtout grâce aux feeders qui permettent de factoriser les paramètres dans des fichiers à part.

Enfin, le lancement des tests via des simples commandes de script rend sa cloudification aisée.

Mise en production d’une application dans le Cloud: gestion du déploiement par Cloudify

Le déploiement dans le Cloud possède quelques difficultés propres dont nous allons discuter dans cet article. Nous aborderons en particulier l’automatisation des déploiements qui permet de gagner en agilité mais aussi de diminuer sa facture pour un environnement qui ne fonctionne pas en 24×7.

Dans cet article nous expliquons comment l’outil devops Cloudify nous a permis d’automatiser le déploiement de notre application et de tous les middlewares dont il dépend. Il nous a permis aussi d’automatiser certaines tâches d’administration telles que les backups de la base de données. De plus, Cloudify offre des fonctionnalités de monitoring, d’auto-réparation et d’auto-scaling qui permettent d’adapter notre application dynamiquement.

Contexte

Devoxx France, le salon de développeurs qui se tenait une fois de plus à Paris cette année 2013, a compté parmi ses sponsors FastConnect. Dans une optique d’animation de notre stand, nous avons développé une application mobile nommée Fastcontest, un quiz en ligne avec des cadeaux pour les gagnants.

Pour sa réalisation, nous avons mis en œuvre plusieurs des technologies dont nous avons l’expertise au sein du pôle Cloud de FastConnect : Java, Spring, HTML5, méthodologie Scrum, bases NoSQL, Cloudify, etc. Le déploiement en production a été effectué grâce à Cloudify sur Amazon EC2 (le choix d’un cloud publique s’imposait du fait de la faible qualité de l’accès Internet dans nos locaux…) Le quiz, en plus d’offrir une activité ludique sur notre stand, nous a permis de montrer notre savoir faire, en particulier dans le domaine du Cloud Computing.

FastContestArchitecture

Cloudi-quoi?

Cloudify ! C’est une solution open source permettant de fabriquer son custom PaaS (une PaaS factory) éditée par GigaSpaces Technologies.
Cet outil permet d’effectuer un ensemble de tâches relatives au déploiement d’une application sur un cloud et à la gestion du cycle de vie de cette dernière. Il permet notamment :

  • l’automatisation du déploiement via des recettes (recipes)
  • une portabilité sur plusieurs cloud (EC2, OpenStack, Azure, etc. ou un data center “classique”) via la configuration d’un driver
  • la gestion des dépendances entre les différentes composantes de l’application
  • du monitoring
  • la gestion du failover et de l’élasticité
  • des tâches d’administration (via des custom commands)

Toutes ces routines sont décrites dans différents scripts/recettes (recipes). Dans le cadre de notre application, nous utilisons majoritairement le langage de programmation Groovy, mais nous nous servons aussi quelques fois de scripts Bash.

Le principal outil entre le développeur et le cloud où il déploie est le shell Cloudify. Il existe aussi une interface Web très ergonomique qui permet notamment de visualiser toutes les recettes, l’état des déploiements, les alertes et les métriques remontées par le monitoring applicatif.

Mais on ne saurait parler de scripts sans toutefois parler de tests et de debug ! Mais comment faire ? Faut-il utiliser le cloud d’Amazon chaque fois que nous voulons tester nos scripts ? Même en phase de développement et compte tenu de son coût ? Ce sont là des questions que nous nous sommes posées lors de cette phase du projet. Nous évoquerons la solution adoptée un peu plus bas dans l’article.

FastContest : les différentes briques

Revenons à notre mouton: notre application de Quiz. Elle est composée de trois tiers :

  1. une base de données
  2. une API REST pour les fonctions du jeu
  3. un front HTML5

L’API REST

L’API REST étant un projet Web, nous avons eu besoin d’un serveur d’application, en occurrence Apache Tomcat. Pour la base de données, nous avons choisi MongoDB dont nous avons l’expertise (nous sommes partenaire 10gen).

Le frontEnt Sencha

Nous avons opté pour le framework Sencha Touch pour développer le frontend mobile de notre application. Du point de vu serveur, l’application mobile est un contenu statique, nous avons choisi de l’héberger dans un serveur Apache HTTP.

Soulignons au passage que les tests de performance ont été effectués avec Gatling, pour lequel nous avons aussi créé une recette Cloudify. Nous publierons un article dédié sur ce sujet…

Si nous faisons un résumé des briques constitutives de notre application de quiz, nous recensons les services (tiers) suivants :

  • Une base de données NoSQL : MongoDB
  • Un serveur d’application : Apache Tomcat
  • Un serveur Web : Apache HTTPD avec mod_proxy_balancer pour des problématique de load-balancing et de redirection.
  • Gatling

Les Recipes Cloudify (recettes)

À chaque service correspond une recette, qui décrit un certain nombre d’informations et/ou de configuration dudit service :

  • L’identité du service sur le cloud : nom, icône, template de machine à utiliser, …
  • Le cycle de vie : on peut greffer n’importe quel comportement à chaque évenement (install, start, stop, …) via un script Groovy, Shell ou MS-DOS
  • Les custom commands : permettant de définir des actions que nous pourrons effectuer sur chaque instance du service après son déploiement. Exemples pour un service Tomcat : update du war, archivage des logs, …
  • Monitoring applicatif : Cloudify permet de remonter n’importe quel métrique. On peut l’afficher dans l’interface Web ou l’utiliser pour configurer une alerte ou une règle d’auto-scaling.
  • détection de panne : en cas de panne, Cloudify peut relancer le service défaillant automatiquement.
  • élasticité : le nombre d’instances d’un service peut varier dans le temps, suite aux pannes, auto-réparation ou bien pour répondre à un burst. Cloudify permet de définir des règles d’auto-scaling.

Voici un extrait de notre recette Tomcat :

service {
  name "tomcat"
  icon "tomcat.gif"
  type "APP_SERVER"
  // ...

  lifecycle {
    install     "tomcat_install.groovy"
    postInstall "tomcat_postInstall.groovy"
    preStart    "tomcat_preStart.groovy"
    //...
  }

  customCommands ([
    "updateWarUrl" : { warUrl -
      context.attributes.thisService["warUrl"] = "${warUrl}"
      return true
    },
    "updateWarFile" : "updateWarFile.groovy"
  ])
  //...
}

Une application, au sens de Cloudify, est un ensemble de services (ou tiers) ayant des dépendances entre eux. Déployer une application signifie donc déployer tous ses services, dans un ordre convenable, et assurer l’injection des informations requises entre chaque couche.

Voici un extrait de la recette de notre application FastContest :

application {
  name "fastcontest"
  service {
    name = "mongod"
    compute {
      template "MONGO_TEMPLATE"
  }
}
service {
  name = "apacheLB"
  compute {
    template "APACHE_TEMPLATE"
  }
}
service {
  name = "tomcat"
  dependsOn = [ "mongod", "apacheLB" ]
  compute {
    template "TOMCAT_TEMPLATE"
  }
}
//...
}

Nous pouvons constater dans cet extrait que le service « tomcat » dépend des services « mongod » et « apacheLB ». En effet, tomcat a besoin des paramètres provenant du service mongod (adresse IP de la VM sur laquelle il est déployé par exemple) pour rendre l’application – ou du moins l’API REST – fonctionnelle ; et devra enregistrer son « end-point » auprès du service ApacheLB afin que ce dernier puisse mettre à jour sa configuration de load balancing.

Coder des recipes : les aspects à prendre en compte

Tout au long du projet, nous avons identifié quelques aspects primordiaux à prendre en compte dans les recettes Cloudify.

La clarté du code :

La première règle de programmation s’applique aussi aux scripts : faire simple. Le code doit être clair aussi bien dans sa forme que dans son fonctionnement (KISS).

Sonar est un outil d’analyse de qualité du code source. Il existe un plugin pour Groovy. Aussi nous avons mis tous nos scripts dans notre software factory afin de profiter de nos outils préférés.

Opérations à automatiser :

Il est nécessaire de recenser au préalable les différentes opérations à effectuer. Il s’agit notamment de lister les configurations nécessaires et de déterminer à quel moment du cycle de vie du service les appliquer : postInstall, start, postStart, ou bien en tant que custom command appelée depuis un autre service.

Un exemple. Dans notre cas le service Tomcat a besoin de communiquer le end-point (IP + context) de notre API REST au serveur HTTPD qui sert aussi de load-balancer. Il faut noter que le nombre d’instances de Tomcat – et de notre API REST – est variable et peut même changer dynamiquement si l’on a configuré des règles d’autoscaling.

Pour ce faire, nous avons créé une custom command nommée « addEndPoint » dans la recette d’ApacheLB, et cette commande est appelée par chaque instance de Tomcat lors de leur phase postStart.

Les custom commands sont une fonctionnalité très importantes de Cloudify. Elles permettent de coder des tâches d’administration (dump des logs, etc.) mais aussi de gérer des événements pour mettre à jour sa propre configuration. Ceci nous mène à un autre point : l’adaptation des services…

Adaptation des services à l’environnement

Nous entendons par là que les recettes doivent permettre aux différents services de prendre en compte les éventuels changement dans leur environnement et mettre à jour le service en conséquence. Ceci est particulier à la dynamicité d’un environnement Cloud où l’on peut être amené à gérer un changement d’adresse IP ou l’augmentation du nombre d’instances…
Cette notion d’adaptation en elle même est très large, et intègre d’autres notions telles que le « failover » et la « scalabilité ».

Fail-over

On désigne par là la capacité du système à se remettre d’une ou plusieurs pannes. Cloudify nous facilite la tâche : grâce aux détecteurs de fautes que nous définissons dans le script de description du service, Cloudify génére une alerte et il est capable de lancer des actions réparatrices : simple redémarrage du service, réinstallation ou ré-déploiement de la machine et du service.

Il est donc important d’écrire des recettes prenant en compte cet aspect, afin de d’assurer le meilleur comportement possible dans tous les cas (leak applicatif, bug Tomcat, crash d’une VM, etc.)

Scalabilité

Une fois de plus, Cloudify nous fournit un énorme coup de main dans cette problématique. Il permet de gérer l’élasticité d’un service de deux façons :

  • Manuellement : Si nous avons défini notre service en tant que « service élastique », alors nous avons la possibilité, via le shell Cloudify, d’augmenter ou de diminuer son nombre d’instances (le paramètre « maxAllowedInstances » nous protège contre une mauvaise manipulation).
  • Automatiquement : Cloudify permet, par l’intermédiaire de règles d’autoScaling, de définir une politique qui permettra de jouer dynamiquement avec le nombre d’instances du service. En général la politique d’autoscaling se fonde sur une des métriques applicative que l’on monitore.

Cette liste n’est pas exhaustive, et s’agrandira certainement avec l’expérience.

Déployer en environnement de Développement / Test

Tester notre application directement sur Amazon EC2 peut se révéler extrêmement couteux. Rappelons que par défaut, Amazon facture les machines à l’heure et que tout heure commencée est due. C’est pourquoi il faut éviter de déployer son application sur Amazon, de l’éteindre, de corriger une ligne et de recommencer. Ce qui est pourtant si facile quand on a tout automatisé…

Pour répondre à cette problématique, un expert Cloud de FastConnect, Mathias KLUBA, a développé un driver VirtualBox pour Cloudify. Grâce à ce driver, nous pouvons donc créer un cloud de VM VirtualBox sur notre machine de développeur et tester ainsi nos scripts Groovy en toute tranquillité. Vous trouverez un article sur ce driver : Driver VirtualBox pour Cloudify.

Pour information FastConnect est en train de construire un cloud interne OpenStack qui servira notamment lors de nos développements internes. Si vous avez besoin d’expertise sur OpenStack, contactez-nous ;-)

En production

Pour le passage en production, nous déployons sur le cloud d’Amazon EC2. Et là, on se dit « Vive Cloudify !! » car pas besoin de changer quoi que ce soit dans nos recettes, on remplace le driver VirtualBox par le driver Amazon EC2 et tout fonctionne.

Automatiser les déploiements et certaines actions d’administration

Pour pouvoir déployer sur l’environnement de Production de manière automatisée, en prenant les derniers packages à déployer, nous avons utilisé Jenkins.
Grâce à des scripts Groovy dans Jenkins, et l’API REST de Cloudify, nous avons pu déployer en 1 click sur Amazon (et détruire en 1 click). La procédure est la suivante :

  • Le matin, on exécute le job “Deploy” pour déployer l’application en 1 click
  • Le soir, on exécute le job “Undeploy” qui va:
    • Exécuter la “custom command” Dump du service MongoDB. Cette commande va faire un Dump de notre base, zipper et stocker dans S3.
    • Exécuter “uninstall-application” pour détruire l’application et les VMs utilisées.
  • Le lendemain, on exécute le job “Deploy” pour re-déployer l’application, ce qui va:
    • Exécuter “install-application” pour déployer l’application sur Amazon EC2.
    • Exécuter la “custom command” RestoreDump du service MongoDB. Cette commande télécharge le dernier dump depuis S3 pour le restaurer.

Pour des problématiques de supports, Jenkins exécute aussi régulièrement des “dump” de la base ainsi que des logs.

Dans notre cas le volume des données était faible, aussi un simple dump de MongoDB était très efficace. Un SnapShot de l’EBS aurait été plus intéressant si le volume avait été plus important.
L’opération de Dump n’était pas nécessaire tout au long de la journée puisque nous utilisions un ReplicatSet pour la résilience (et Cloudify est capable de re-démarrer les instances et les VMs après un crash)… Mais nous ne voulions prendre aucun risque :)

Conclusion

Au terme de cet article, nous avons mis en œuvre un bon nombre de technologies et d’outils relatifs au Cloud, et avons vu les différentes possibilités qu’ils offraient.
Nous constatons en particulier, que le déploiement d’une application sur un cloud et la gestion de son cycle de vie sont véritablement simplifiés grâce à Cloudify. Cependant, le mot « simplification » ne doit pas nous nous entraîner à la relâche ! En effet, les recipes étant le cœur de toute ces procédures automatisées, il ne faut pas négliger l’effort nécessaire pour produire des recettes de bonnes qualités.

2013, année du PaaS

Bonne Année

Puisque la tradition permet de s’échanger les voeux pendant tout le mois de janvier, au nom de tout FastConnect, je souhaite une bonne année aux lecteurs de notre blog.

Ma Boule 8 magique

Alors que je butinais sur la toile j’ai remarqué que les voeux étaient pour beaucoup l’occasion d’effectuer des prédictions avantageuses pour l’année prochaine…

À mon tour, j’aimerais partager ma vision du futur des Systèmes Informatiques (SI). En 2013 nous prévoyons une explosion des projets autour du PaaS. Ce sentiment est fondé par les retours positifs de nos clients mais aussi par les analystes : Gartner Says Worldwide Platform as a Service Revenue Is on Pace to Reach $1.2 Billion.

Qu’est-ce que le PaaS

Les offres SaaS et IaaS sont globalement plus anciennes, plus matures et mieux comprises. Par exemple Salesforce, fournisseur d’offres SaaS, a été créé en 1999 et Amazon a lancé son offre EC2 en 2006.

GIF - 39.7 ko

Remarquons au passage que la présentation de IaaS/PaaS/SaaS comme une pile technique du Cloud Computing est trompeuse car il est possible de construire une offre SaaS sans s’appuyer sur un PaaS (et cela a été fait puisque le SaaS est plus ancien).

Le SaaS est la fourniture d’une application (gestion des comptes clients, brms, etc.) via le réseau. Il s’agit pour le client de consommer le service dont il a besoin, via une interface et/ou une API et sans se préoccuper de sa mise en oeuvre.

Le IaaS est la fourniture d’infrastructure (stockage, serveurs, etc.) via le réseau. En générale le IaaS est implémenté grâce à des techniques de virtualisation, mais c’est bien plus. Un IaaS, comme tout “As A Service” doit offrir une grande agilité aux utilisateurs. Personnellement je me le représente comme un data center programmable.

Le PaaS est souvent dessiné comme une couche entre les deux autres… ou comme étant la virtualisation de la couche middleware. Bref c’est ce qui est au milieu :-) Si je compare l’informatique au bâtiment – comparaison fréquente – la construction d’une application serait du préfabriqué : les développeurs s’appuient en effet sur des briques “middlewares”. Le PaaS est la fourniture de ces briques “middlewares” via un réseau.

Le PaaS est donc un outil pour les développeurs qui utilisent dans leur travail quotidien des middlewares tels que les bases de données ou les serveurs d’applications.

Un PaaS pour quoi faire ?

Beaucoup d’entreprises ont commencé leur stratégie Cloud Computing en espérant diminuer les coûts de leur SI. Mais l’intérêt substantiel du Cloud Computing est de redonner de l’agilité au métier.

Il est très naturel d’envisager sa stratégie Cloud en commançant par le IaaS et le SaaS qui sont plus matures et mieux compris. Cependant nous, FastConnect, sommes convaincus que le PaaS est finalement la couche qui a le plus de valeur, en particulier pour les moyennes et grandes entreprises où les DSI sont très structurées et manquent souvent d’agilité.

Pour répondre à ce besoin d’agilité, le IaaS ne suffit pas. Qu’importe que l’on puisse déployer un serveur en un click si son achat est un processus toujours aussi difficile ou si l’on dépend d’une autre équipe peu agile pour l’installation d’un middleware.

L’objectif ambitieux du PaaS est de redonner de l’agilité au SI de bout en bout.

Typologie des PaaS

Le Gartner divise le marché du PaaS en :

  1. application platform services (aPaaS),
  2. cloud application life cycle management (ALM) services (almPaaS),
  3. cloud BPM platform services (bpmPaaS),
  4. cloud integration services (iPaaS)

Il s’agit pour l’essentiel de services middlewares particuliers (notons que la frontière entre le PaaS et le SaaS est finalement mince, un bon sujet de dispute pour nos experts à la machine à café).

Mais pour répondre à l’objectif ambitieux d’agilité, il est nécessaire de faire entrer tout le catalogue technique sous forme d’offres “As A Service” (toute ressemblance avec le SOA est purement fortuite). C’est la raison pour laquelle je crois beaucoup dans l’approche des solutions de PaaS Fabric tels que Cloudify, Tibco Silver Fabric ou OpenShift qui permettent de fabriquer son custom PaaS incluant tous les middlewares et services utilisés par l’entreprise. Ils permettent une grande souplesse d’intégration avec l’existant et, cerise sur le gâteau, évitent tout vendor locking.

Vers une agilité du SI de bout en bout

Finalement ce qui nous intéresse vraiment est de (re)donner au SI une agilité de bout en bout afin de permettre une agilité métier. Pour répondre à cet objectif très ambitieux l’organisation et les méthodologies doivent aussi être agiles.

Suivant cette tendance, la saison est au Continuous Delivery !

Déploiement automatisé

Plusieurs éditeurs proposent des outils afin d’aider à formaliser et automatiser les déploiements. Ces outils sont effectivement très efficaces pour réduire la distance entre les équipes de développement et de production qui ont des objectifs a priori contradictoires :

  • les développeurs agiles veulent livrer rapidement chacun de leur sprint sur leur environnement de test
  • la production veut maitriser les changements afin de diminuer les risques opérationnels.

L’objectif de ces outils est d’automatiser tous les déploiements, et de contrôler qui peut déployer quoi sur chaque environnement. De plus, par des mécanismes d’injection de configuration, ils aident le passage d’un environnement à un autre (DTAP). Les développeurs intègrent naturellement ces outils pour compléter leur chaine de compilation et de test continue. On parle de continuous delivery.

D’une manière générale ces outils savent déployer un WAR dans un Tomcat existant, mais ils ne savent pas déployer ce Tomcat juste avant. Ceci est particulièrement utile dans le cas des environnements de Tests qui ne fonctionnent que pendant une fraction de la journée. Le PaaS est la brique manquante qui permet cela.

Créer votre propre Usine de déploiement continu

Je vous invite évidemment à visiter notre nouveau site web et à lire nos offres Cloud
http://www.fastconnect.fr/fr/nos-offres/cloud

Nous proposons notamment de vous aider à mettre en place une usine de livraison continue fondée sur une usine GitHub/Jenkins/Nexus et un PaaS Fabric pour intégrer vos briques logicielles et middlewares particulières, et ceci en évitant le plus possible la rupture par rapport à vos habitudes et vos outils.

App-Store

New version of VirtualBox driver for Cloudify

I’m pleased to annonce the new version 1.2 of the VirtualBox driver for Cloudfy: https://github.com/fastconnect/virtualbox-cloudify-driver

Release note:

  • Compatibility with Cloudify 2.2 (no more with 2.1)
  • Compatibility with VirtualBox 4.1 and 4.2

I’m working on a good documentation of how to install and use this driver. In the mean time, here is a quick explanation: https://github.com/fastconnect/virtualbox-cloudify-driver/issues/1

New VirtualBox driver for Cloudify

I work with Cloudify a lot these days: it’s a powerful product to deploy a MongoDB or Hadoop cluster in few minutes instead hours or days.
I do a lot of presentations with a demo to my clients, so I need to create a new cluster very quickly.
Thanks to the Cloud, and IaaS platforms,as Amazon EC2, I can create a big cluster of multiple machines. But in this case, I need an Internet connection: that’s the problem.

So I can bootstrap a local Cloud with Cloudify, but that’s not what I need:

  • I’m using MacOS X, and some recipes only work on Linux
  • If I create multiple instances of MongoDB with the same port, it’s not a problem if it’s not on the same machine… but it is a problem with a local cloud
  • etc.

I decided to create a true Cloud on my laptop, so I can do my demos without an Internet connection, and I can simulate a true deployment.
My laptop has 16 Go of RAM, so I can create multiple virtual machines (not too much, but enough for a demo).
I first tried to install OpenStack on it, but it’s a little bit complicated, and didn’t work well on my MacOS.

In the mean time, when I need a Linux OS to do some specific stuff, I use Vagrant.
Vagrant is a wonderful tool to quickly create a new VM based on a template, and execute a bootstrap script on it.
It uses VirtualBox to create the VM, and people are creating a lot of “boxes” (VM templates, as AMI in Amazon): http://www.vagrantbox.es/

In fact, Vagrant can also create multiple VMs, and run Chef or Puppet recipes as a bootstrap script…
So, in theory, I can deploy my MongoDB/Hadoop cluster with that.
But it’s not as powerful as Cloudify:

  • You don’t have a global context for the deployment, so you can’t have service dependencies as in Cloudify
  • There’s no application monitoring, with fail-over or auto-scaling
  • Vagrant can only create VMs on your local machine, not on a remote server
  • There’s a lot of limitations in the deployment scripts, that’s why Cloudify uses Chef/Puppet, and why these tools won’t replace Cloudify

That’s why I decided to implement the VirtualBox driver for Cloudify: I have the power of Cloudify, and I can simulate a true deployment (with Linux OS etc.). And I can do it on my laptop without an Internet connection!

My driver is available here: https://github.com/fastconnect/virtualbox-cloudify-driver
To use it, you have to add it in the “overrides package” of Cloudify (see the Cloudify documentation ) and configure the driver as explained in the Readme.

This driver uses the VirtualBox WebService, so you have some prerequisite:

  • After installing VirtualBox, create a “HostOnlyInterface” that will be used by the VMs created by Cloudify
  • Configure the WebService to not use authentication: VBoxManage setProperty websrvauthlibrary null
  • Start the WebService: vboxwebsrv
  • Download a “box” from http://www.vagrantbox.es/ and put it in a specific folder
  • Configure the driver to specify the “boxes” folder, the name of the “HostOnlyInterface”, and the URL of the WebService.
    WARNING: the URL should use the IP of the HostOnlyInterface, because the VM with the Cloudify Manager needs to access to it to create other VMs

If you did all these steps correctly, you should be able to create your “local” Cloud with VirtualBox!

Because the driver is using the VirtualBox WebService, you can also run it on a dedicated server.
VirtualBox is not as powerful as OpenStack, but it could be enough in some cases, and you can have a WebUI to manage it (http://code.google.com/p/phpvirtualbox/).

I had one major problem when implementing the driver: I don’t have a DNS server for my Virtual Machines.
That means that the VMs are not able to know and communicate each other.
So the driver does a little setup after creating the VM: it setup the network card, updates the hostname and set the /etc/hosts.
To do it, it uses the VirtualBox Guests Addition, which should be installed in the VM template (it’s done on all “boxes”, because Vagrant needs it too).
With the Guests Addition, a VirtualBox agent is running on the guest VM, so we can do some operations on it, as creating folders or run processes.

The good news, is that this agent allows to do the same operations on any guest OS (Windows, Linux, etc.).
The bad news, is that the process to setup the network is OS specific: it’s not the same on Linux and Windows.
For now, to change the hostname and the hosts file, it uses Linux paths and Linux commands (sed, etc.)
So the driver only works with Linux Virtual Machines, and was only tested on Ubuntu.

The driver is OpenSource (APL), so feel free to contribute and add Windows Guest OS support! (or test with other Linux distributions)

I really hope this driver will help you to test Cloudify on your desktop!
You can find technical information in the README in Github:
https://github.com/fastconnect/virtualbox-cloudify-driver
You can download it from our OpenSource Maven repository.

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 !

Dématérialiser son application sous forme de services Clouds sans se lier à une plate-forme ou un fournisseur.

Le Cloud est un concept révolutionnaire qui transforme notre vision sur la façon de fournir des services informatiques à nos utilisateurs.
Les services Cloud sont dématérialisés et faciles d’accès, disponibles à la demande, élastiques, et nous permettent de ne consommer que ce dont nous avons besoin.

Mais quid de l’existant et de sa complexité ? Cela veut-il dire que la richesse applicative dont nous disposons déjà ne peut être fournie à vos utilisateurs en mode Cloud ? Et avons nous les outils nécessaires pour exposer nos nouveaux services dans le Cloud de manière portable, réversible et à coûts contrôlés ?

J’ai le plaisir de présenter une approche d’architecture basée sur des outils Open Source et des cas d’utilisation de clients ayant franchi le pas, à l’Open World Forum, Jeudi 11 Octobre à 15h30.
Voir ici pour le programme de ce track : http://openworldforum2012.sched.org/event/bcfdb68972df051b8d20be3977f86cf5

J’espère vous y retrouver nombreux.

Cette session vous éclairera sur les capacités de mise en place de services applicatifs Cloud, à travers l’utilisation de la plate-forme PaaS Cloudify (http://www.cloudifysource.org/), permettant de dématérialiser le socle d’exécution de vos applications, sans changement de code, ni lock in : “Any App, Any Cloud, Your Way”.

À cette occasion seront abordés les thèmes suivants :

  • Les bénéfices du PaaS – Platform as a Service
  • Automatisation et résilience pour améliorer le temps de mise à disposition des applications et les SLA applicatifs
  • Portabilité data-center, Cloud privé et Cloud publics
  • Cloudify et DevOps
  • Cas d’utilisation : L’intégration de Cloudify au sein d’un portail Appstore afin de délivrer des services applicatifs (Apps) à la demande, en plus de services d’infrastructure (Compute, Storage)
  • Cas d’utilisation : L’intégration de Cloudify au sein d’une plate-forme de livraison continue (continuous delivery) pour le développement et les tests d’une application d’analyse des réseaux sociaux
  • Déployer son application sur le Cloud

    Quelle application voulons nous déployer et pourquoi ?

    Lors de Devoxx nous avions un jeu concours sous forme de quiz en ligne, en plus d’animer le stand le but était de faire une démonstration de nos compétences dans le développement distribué et tout particulièrement dans le domaine du cloud computing.

    Le temps où l’on regardait le cloud avec des yeux curieux mais distants, mêlés d’une pointe d’appréhension vers cette « technologie de demain » arrive à sa fin. En effet le cloud computing arrive à maturité, ses contours sont mieux définis et de nombreux outils ont été développés afin de simplifier son utilisation et son apprentissage.

    C’est dans cette optique que nous avons conçu notre application de quiz en ligne, afin d’en faire une petite vitrine faisant la promotion de l’utilisation et des possibilités du cloud et plus particulièrement des offres PaaS qui nous semble avoir le plus de valeur pour le SI. Nous avons voulu montrer aussi quelques pratiques faciles à mettre en place pour que l’application soit portable et ne soit liée ni à un cloud ni à un paas-fabric spécifique et garde toute son indépendance. Nous voulons en quelque sorte démystifier le cloud et montrer que son utilisation n’est finalement pas si complexe et que le moment opportun est peut-être arrivé pour prendre le cloud en vol !

    Revenons en à notre application, c’est donc un quiz en ligne, elle est écrite en Java et utilise Spring MVC ainsi que la bibliothèque Jquery qui permet d’avoir un rendu optimal pour téléphone portable. Tomcat a été choisi pour le conteneur web et MongoDB comme base de données. Lors de Devoxx l’application tournait sur le cloud Amazon EC2 et plus précisément sur le data center “eu-west-1″ situé en Irlande, le déploiement étant automatisé via le paas-fabric Cloudify.
    Durant le développement et les tests nous déployons en local ou sur CloudFoundry. Déploiements rapides en local pour les premiers tests, puis déploiement sur Cloudfoundry pour les tests plus poussés, et enfin déploiement de production sur EC2 via Cloudify.

    C’est ce cheminement que avons retenu lors du développement de notre application et c’est celui que nous allons présenter ici.

    En développement …

    En phase de développement nous voulons voir si telle fonctionnalité marche comme attendue, où si telle page s’affiche comme l’on voudrait. Un simple déploiement local fait l’affaire : il suffit donc de lancer MongoDB et Tomcat et d’y déployer le WAR de l’application. Simple et rapide cette méthode a aussi l’avantage d’être réactive ; sous Eclipse on peut ainsi corriger une classe et le nouveau WAR est redéployé à chaud, permettant de voir tout de suite les conséquences de la correction.

    Déploiement sur CloudFoundry

    Mais notre ordinateur de développeur ne permet sûrement pas de faire tous les tests que nous souhaitons mener : tests de charge, de résilience, etc. Ou alors nous voulons faire des tests distants tout en gardant une certaine rapidité et simplicité de déploiement. CloudFoundry peut alors être la solution idéale, ce PaaS Open Source initié par vmware permet en effet avec peu de changement de code et très peu de configuration de déployer son application sur un ensemble de PaaS dont cloudfoundry.com (opéré par vmware) qui offre les avantages de simplicité et d’une vitesse de déploiement relativement rapide.

    Pour cela il suffit d’installer le plugin d’intégration de CloudFoundry dans Eclipse, de créer un compte (on peut créer un compte de test gratuitement), puis l’on est prêt à démarrer l’utilisation. On sélectionne alors les applications que l’on veux déployer, dans notre cas le quiz, puis l’on choisit l’url du site web et les services dont l’on dépend, ici MongoDB. Ensuite le déploiement sur cloudfoundry.com commence : le type de l’application est détecté automatiquement, dans notre cas un conteneur web est utilisé. Les services comme le conteneur web et MongoDB sont déjà pré-déployés sur le cloud, ce qui permet d’avoir un déploiement relativement rapide, dans notre cas une minute suffit.

    L’effort de configuration est très réduit, une grand partie est automatiquement prise en charge et cachée à l’utilisateur. Pour le quiz il a juste fallu remplacer le bean qui crée la connexion vers Mongo, au lieu de donner une IP on donne le nom du service Mongo précédemment déployé dans Cloudfoundry. Afin de gérer les différentes configurations nous avons utilisé les profiles Spring apparus avec Spring 3.1. Ainsi un profile « défaut » est utilisé pour le déploiement local dans Tomcat tandis qu’un profil « cloud » est automatiquement activé lors du déploiement sur CloudFoundry et nous avons créé un profil Cloudify pour les déploiements opérés par Cloudify. La contre-partie à la facilité d’utilisation de Cloudfoundry est qu’on a que peu de maîtrise sur les détails de configuration des services comme la version de Mongo où son tunning, de même pour le conteneur web.

    Déploiement en production sur Amazon EC2 à l’aide de Cloudify

    Notre application est maintenant prête à passer en production. Nous voulons pouvoir automatiser le déploiement sur le cloud sans pour autant être dépendant d’une solution donnée et en gardant une grande liberté de configuration, Cloudify devient alors un outil attractif. C’est un paas-fabric Open Source initié par GigaSpaces tout comme CloudFoundry mais leur philosophie est très différente, Cloudify tente de concilier le paas-fabric et les principes du dev-ops.

    L’idée est d’avoir une solution non intrusive qui gère tout le cycle de vie des applications et non pas seulement le déploiement, et ceci par exécution de recettes/scripts “à la chef (ou puppet)”, pouvant être écrits en groovy, bash ou bat. Cette utilisation des scripts rend l’utilisation de Cloudify plus complexe que CloudFoundry mais offre un niveau de contrôle et de configuration bien plus poussé. Des fonctionnalités supplémentaires sont en plus disponibles, un monitoring customisable des applications, le self-healing qui redémarre automatiquement les services en erreur ou encore l’auto-scaling en fonction de critères monitorés.

    L’intégration de Cloudify avec les différents clouds se fait via des drivers d’infrastructure, grâce à cela on est capable de déployer la même application avec la même configuration sur différents clouds public dont Amazon Ec2, Rackspace et Windows Azure ou privés comme OpenStack.
    C’est par ce biais que nous avons pu déployer notre quiz sur Amazon Ec2 en Irlande. Cloudify n’est pas intrusif, mais il faut tout de même s’adapter à la dynamicité de l’environnement. Dans notre cas on récupère les IPs des bases Mongo via une variable d’environnement qui est settée par Cloudify et qui est ensuite utilisée dans la config spring pour créer le proxy Mongo.

    Conclusion

    Au travers de cet exemple de développement et de déploiement d’une application de quiz en ligne nous avons voulu montrer un premier aperçu des possibilités et outils du Cloud et que ces différent(e)s méthodes et outils ne sont pas forcément concurrent(e)s
    mais peuvent être complémentaires. De même avec quelques bonnes pratiques il est facile d’avoir une application portable pouvant prendre en charge différentes configurations.

    Nous pensons qu’il est temps de lever les yeux vers le cloud car celui-ci est maintenant suffisamment accessible et mature pour devenir la solution idéale à un certain nombre des besoins et défis de l’informatique d’aujourd’hui et de demain.

    Le déploiement de notre quiz via CloudFoundry et Cloudify est illustré dans cette vidéo qui inaugure l’arrivée de la chaîne youtube FastConnectTV.

    De nouvelles vidéos sur le cloud vont y être ajoutées très prochainement !