Cloudbees : petit tour d’horizon

06 mars 2012
Par 

Le “cloud” : derrière ce terme se cache un monde vaste disposant d’un écosystème bien complexe.

En effet, il existe 3 grandes familles de solutions de type “cloud” qui pourraient être résumées en ces quelques termes :

  • Le IaaS (Infrastructure As A Service) qui permet de fournir l’hébergement des serveurs.
  • Le PaaS (Platform As A Service) qui permet de fournir clé en main l’environnement d’exécution pour les applications.
  • Le SaaS (Software As A Service) qui offre un panel de services dans lesquels il est possible de piocher.

Dans cet article nous allons donc nous intéresser plus précisément au PaaS et au SaaS en faisant un rapide tour d’horizon des solutions proposées par la société Cloudbees.

Présentation de CloudBees

CloudBees propose deux services DEV@Cloud et RUN@Cloud.
DEV@Cloud offre, pour sa part, un service de type SaaS (Software As A Service) qui offre un environnement de développement, de construction et de test en s’appuyant sur le cloud.
DEV@Cloud permet :
  • de collaborer avec d’autres personnes en s’appuyant sur des SCM/DVCS comme SVN ou Git,
  • de construire, tester et déployer de manière continue avec Jenkins,
  • de tester l’application web cible en s’appuyant sur le service à la demande SauceLab,
  • de contrôler la qualité du code en s’appuyant sur Sonar,
  • de gérer les artéfacts en utilisant Artifactory.
RUN@Cloud fournit, quant à lui, un ensemble d’outils permettant de simplifier le processus de déploiement d’une application Java dans le cloud. Il correspond à un service de type PaaS (Platform As A Service).

(Crédit : CloudBees)

En fait, l’une des grandes forces de l’offre de CloudBees est l’écosystème varié qu’il propose au travers d’un ensemble de SaaS qui permettent de bénéficier d’une facilité d’utilisation et d’intégration poussée à l’extrême.

(Crédit : CloudBees - Date 01/03/2012)

Exemple d’utilisation pratique

Pour bien montrer les possibilités offertes par CloudBees, je vais prendre un exemple plus ou moins fictif… ;-)

Scénario

Pour de sombres raisons que ne n’exposerai pas ici, je souhaite développer une application web (que j’appellerai Application B – comme back – ) qui expose des services web en REST, qui stocke des données dans une base de données MySQL mais également dans MongoDB.

Je souhaite également offrir une application web (que j’appellerai Application F – comme front – ) qui communique avec mon Application B via web services. Cette Application F a pour rôle d’offrir une interface web basée sur une technologie quelconque (Apache Struts, Spring MVC, Play!, Tapestry, Servlet de base, …).

L’Application B sera également accessible via web services pour des applications tierces comme des applications smartphone. Coté code, c’est elle qui sera garante des objets pivots utilisés par l’Application F et par les applications clientes tierces.

N’ayant pas d’infrastructures disponibles (au sens serveur du terme) et ne connaissant pas la charge susceptible de venir interagir avec mes différents serveurs, base de données ou MongoDB, j’ai donc un fort besoin de scalabilité.

Enfin, l’équipe de développement pouvant être susceptible de grossir, je souhaite disposer d’une solution d’usine logicielle à moindre coût (c’est à dire sans avoir besoin de monter les serveurs ni à maintenir un serveur d’intégration continue, une ferme d’agent de build, un serveur Git (avec la problématique classique de backup), un repository manager (et sa sauvegarde) ainsi qu’un parc de serveurs sur lequel faire mes tests et tester de manière intégrée l’avancement de mes développements.

Bien sûr, mes applications tendront à respecter un maximum les standards (au sens technologique du terme) et s’appuieront sur un conteneur de servlets ou serveur d’application le plus “out of the box” possible.

Utilisation de CloudBees

Vous l’aurez compris, l’étude de cas précédemment décrite s’appuiera sur l’offre offerte par CloudBees qui, comme par hasard ;-), fourni tout ce dont j’ai besoin (et bien plus…! ).

Utilisation de DEV@Cloud

Une fois inscrit à CloudBees, je vais donc initier mes 2 repositories (un pour l’application F et un pour l’application B) Git en allant dans la rubrique Repositories.

Suite à cela, il me suffit de configurer mon serveur d’intégration continue en allant dans la rubrique Jenkins Build, puis en cliquant sur Nouveau Job :

Après avoir peuplé ma configuration de Job en précisant un build basé sur Maven 3, un JDK 1.6, l’adresse du repository Git et la volonté de vouloir scruter l’outil de gestion de version et déployer les artifacts sur le repository privé, il n’y a qu’à sauvegarder.

En réitérant l’opération pour l’Application F et en renseignant comme valeur “Application B” à la rubrique “Construire à la suite d’autres projets“, le serveur d’intégration continue est configuré.

Il est à noter que j’ai choisi, ici, de ne pas déployer mes artifacts sur Archiva via le service JFrog.

Utilisation de RUN@Cloud

Concernant l’environnement de déploiement et d’exécution de nos petites applications, rendons nous maintenant dans la rubrique Applications puis cliquons sur Add New Application :

A cette étape, il est uniquement possible de choisir une solution “PaaS” de type conteneur de Servlets (qui, utilise derrière un Tomcat 6.0.32 au moment de l’écriture de ces lignes).

Une fois cette étape effectuée, il est alors possible de configurer son environnement :

En l’occurrence, il est possible de choisir en un clic de bénéficier des SaaS New Relic et Papertrail Logs qui permettent respectivement de superviser son application et d’agréger les logs des applications lorsqu’ils sont déployés sur plusieurs instances.

En fait, lorsque plusieurs instances sont utilisées lors du déploiement, un load balancer est utilisé en mode round robin (il me semble… mais d’autres options seront sûrement disponibles dans un futur proche) et a, à sa charge, le rôle de distribuer la charge sur les différentes instances.

Pour l’Application F, il suffit de réitérer cette opération afin de disposer d’un environnement cible d’exécution.

Concernant la configuration de la base de données, dans la rubrique Applications, il suffit de cliquer sur Add New Database et de configurer la base. Suite à cela, la configuration nécessaire est fournie et peut être utilisée pour configurer l’Application B :

Enfin, la dernière étape de notre environnement d’exécution consiste à configurer le service offert par MongoHQ pour disposer d’un MongoDB : pour ce faire, dans la rubrique des Services, il suffit de cliquer sur MongoHQ et de suivre les instructions :

Il est alors possible de visualiser la configuration de l’instance de MongoDB afin de configurer l’Application B.

Une fois ces différentes opérations effectuées et après avoir renseigné les bons paramètres de l’Application B au niveau des fichiers persistence.xml et des drivers MongoDB, il faut maintenant indiquer à notre SaaS DEV@Cloud de déployer nos applications sur nos environnements cibles.

Pour ce faire, il suffit de retourner sur la configuration du Job Jenkins adéquate et de cocher la bonne checkbox :

C’est alors que toute la beauté de la chose se produit après avoir lancé le build : l’application est déployée sur le “Cloud“!

Conclusion

Ainsi, à travers un cas d’utilisation très simple, on a pu constater que les solutions DEV@Cloud et RUN@Cloud permettaient de mettre à disposition un environnement complet qu’il soit de développement ou d’exécution.

En effet, les solutions de CloudBees font preuve d’une facilité d’utilisation déconcertante, surtout quand on connait le temps que cela peut prendre d’avoir à maintenir une ferme d’agents de build ou d’avoir à administrer les différents serveurs (que ce soit ceux de l’usine de développement – Jenkins, Repository Manager, … – ou ceux de l’environnement d’exécution – de tests, recettes ou productions -).

Cela peut s’expliquer par les partenariats qu’a signé CloudBees avec les différentes solutions de SaaS tels que :

  • XWiki,
  • JFrog,
  • SauceLab,
  • MongoHQ,
  • New Relic,
  • PaperTrail Log,
  • SendGrid,

Cet article n’avait pour objectif que de montrer un aperçu des possibilités offertes. Toutefois, de nombreux points n’ont pas été abordés dans cet article :

  • le SDK de Cloudbees qui permet de déployer directement depuis un poste de développement (ou autre),
  • la possibilité de renseigner les configurations (accès base de données, accès MongoDB, …) de l’environnement d’exécution au travers de fichiers descripteurs qu’il est possible de sélectionner,
  • les infrastructures utilisées en dessous (Amazon EC2, OVH, …),
  • la possibilité d’accéder à des ressources non déployées sur le “Cloud“,
  • ainsi que quelques trucs et astuces qu’il est possible d’utiliser… mais je dois sûrement oublier de nombreux points… ;-)

A noter également que CloudBees permet de déployer sur JBoss AS 7.01 pour le support de la stack JEE 6 Web Profile.

Pour aller plus loin…

2 réponses à Cloudbees : petit tour d’horizon

  1. Bruno Borghi dit :

    Intéressant!
    Sais-tu comment Cloudbees fonctionne concrètement avec OVH ?

  2. Khanh Maudoux dit :

    Salut Bruno,

    Concernant le fonctionnement de Cloudbees sur OVH, il existe la possibilité d’utiliser AnyCloud Deployment pour choisir de déployer sur OVH :
    http://www.cloudbees.com/pricing-anycloud-deployment.cb
    Le plus simple est peut être que tu regardes cette piste.

    A+

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>