Les services sous Cloud Foundry : Partie 2 – Implémenter un service broker

Avec “Les services sous Cloud Foundry : Partie 1 – kesako?” nous découvrions que les services sont d’une importance capitale pour tout opérateur Cloud Foundry. Il s’agit réellement d’un travail d’intégration et d’une composante importante dans l’avantage concurrentiel d’une installation Cloud Foundry.

Voyons maintenant comment mettre à disposition un service dans Cloud Foundry via la création d’un service broker dédié.

Avant d’aller plus loin : les questions qu’il faut se poser

De quelle manière vais-je déployer mon service ?

Un service broker n’est rien sans le service associé – MySQL, PostgreSQL… – et il convient de prévoir les moyens par lesquels un service sera adressable depuis Cloud Foundry. Les possibilités sont multiples :

• hébergement en interne ;
• hébergement dans le “cloud” ;
• appel à un prestataire externe.

Vous êtes libre.

Est-ce que le service que je veux mettre à disposition est transposable directement en service Cloud Foundry ?

Ici la réponse n’est pas simple mais on peut distinguer deux cas de figure :

• Votre service peut fonctionner en mode multi-tenant : il est alors directement transposable.
• Votre service ne peut pas fonctionner en mode multi-tenant : c’est compliqué mais peut-être pas impossible.

Pour rappel, multi-tenant est un principe d’architecture permettant à un même logiciel de servir plusieurs entités simultanément tout en assurant cloisonnement des données et sécurisation de l’information. Ainsi, un système de base de données comme MySQL est par design multi-tenant car il permet de gérer des droits utilisateurs sur un ou des ensembles de données.

A l’inverse, le moteur de recherche Elasticsearch ne dispose pas de fonctionnalités de ce type et il convient d’abord d’étudier la mise au point de mécanismes annexes – par l’instrumentation de la création d’instance par exemple – avant de songer à une intégration à Cloud Foundry.

Où déployer mon service broker ?

Vous avez votre libre-arbitre et ce choix n’est pas définitif. Ainsi vous pouvez commencer petit lors de vos développements en effectuant le déploiement en tant qu’application Cloud Foundry par exemple et au fur et à mesure migrer vers une infrastructure dédiée si le besoin se fait sentir.

Quel langage/framework utiliser ?

Cela s’apparente souvent à une guerre de religion et heureusement Cloud Foundry n’impose aucune contrainte à ce niveau. Vous pouvez utiliser le langage de votre choix pour peu qu’il autorise la création de services web. Des plus classiques comme Java, Python, Ruby, PHP aux plus récents comme Go, Scala ou Node.js. La seule véritable contrainte est de pouvoir implémenter la Service Broker API, API dédiée à la communication entre Cloud Foundry et les services broker.

La Service Broker API

Cette API, en soit assez succincte, décrit cinq types d’opérations :

• récupération du catalogue ;
• création d’une instance ;
• binding de l’application avec l’instance ;
• unbinding de l’application ;
• suppression de l’instance.

C’est Cloud Foundry – et plus spécifiquement le Cloud Controller – qui ira communiquer avec le service broker au travers de cette API. Bien que la documentation en ligne se suffise à elle-même pour les détails d’implémentation, je vous propose quand même une explication de texte ci-après.

Récupération du catalogue

GET /v2/catalog

Il s’agit ici de fournir à Cloud Foundry une description des offres mises à disposition par le service broker. Lorsque l’administrateur Cloud Foundry déploie ou met à jour un nouveau service, Cloud Foundry interroge cette URL du service broker. L’enregistrement est l’étape consistant à déclarer le service broker à Cloud Foundry. Elle est à l’initiative de l’administrateur Cloud Foundry.

Ce catalogue prend la forme d’un contenu JSON qui décrira :

• les services pris en charge par ce service broker ;
• les offres disponibles – ou plans – pour chacun des services.

Notons cependant qu’un service broker n’est pas forcément dédié à un service en particulier et que chacun des services qu’il propose peut l’être via plusieurs offres. C’est ainsi que l’on retrouve souvent sur les Pivotal Web Services des services proposant à la fois une offre gratuite ainsi que des offres plus performantes mais payantes.

Création de l’instance

PUT /v2/service_instances/:id

Lorsque la demande de provisionnement est reçue par le service broker celui-ci effectue les opérations qui lui sont nécessaires pour mettre à disposition un service dans le cadre d’une offre. A ce moment, la notion d’applications n’existe pas. Les opérations à effectuer sont à la discrétion du service broker et relatives à l’offre concernée. Pour illustrer le propos on peut imaginer qu’un service broker MySQL se charge de la création d’une base de données dédiée lors de la demande de création d’une instance. S’il supporte plusieurs offres celles-ci pourraient être matérialisées par l’application de quota au niveau du serveur MySQL.

En retour, Cloud Foundry attend uniquement une URL d’accès. Cette URL, optionnelle, permet d’implémenter l’accès à un tableau de bord spécifique à votre service via l’API Cloud Foundry.

Notons que mise à part cette URL (optionnelle), Cloud Foundry n’attend aucune autre donnée de la part du service broker. Il sera à la charge du service broker de pouvoir faire l’association entre l’id d’instance fourni par Cloud Foundry et la ou les ressources qui lui sont associées. Il faudra donc prévoir au sein du service broker, un mécanisme permettant de faire cette association.

Binding

PUT /v2/service_instances/:instance_id/service_bindings/:id

Cloud Foundry émet une requête de binding lorsque l’utilisateur désire associer une application à une instance de service. Le cas d’usage typique ici est la création d’un utilisateur de base de données ainsi que l’ouverture des droits correspondant à l’instance du service. À partir de cette requête le service broker doit :

• Retrouver l’instance cible correspondant à l’instance_id.
• Générer des identifiants qui seront liés à l’id de binding.
• Ouvrir les droits d’accès entre l’instance cible et les identifiants générés.
• Renvoyer à Cloud Foundry le nécessaire pour permettre à l’application d’utiliser cette instance.

Pour revenir à notre exemple de base de données il s’agit donc pour le service broker de :

• Retrouver le serveur et la base de données cible correspondant à l’instance_id.
• Générer un couple identifiant/mot de passe qui sera associé à l’id de binding. Le service broker doit également implémenter les mécanismes nécessaires pour être capable de fournir ces données d’identification sur demande.
• Permettre à l’identifiant en question d’accéder à la base de données – on pense ainsi à la commande GRANT-.
• Fournir au service broker des informations permettant à l’application de se connecter à la base de données. Cloud Foundry n’impose ici aucune contrainte et le service broker est libre de renvoyer ces informations sous n’importe quelle forme. Ainsi, une URL de connexion JDBC est aussi valide qu’une liste de clés/valeurs. L’application sera seule maître dans la consommation de ces informations.

Unbinding

DELETE /v2/service_instances/:instance_id/service_bindings/:id

L’utilisateur Cloud Foundry décide que son application n’a plus besoin d’accéder à un service. Dans ce cas, Cloud Foundry émet une demande d’unbinding au service broker cible. Il sera à sa charge d’implémenter les mécanismes nécessaires pour empêcher l’application d’accéder à l’instance cible. Il s’agit cependant de supprimer uniquement l’accès d’une application à une instance de service. Cette instance peut tout aussi bien être réutilisée plus tard pour une autre application.

Dans le cadre de notre exemple de base de données, le service broker supprimerait les accès de l’utilisateur en réception d’une requête d’unbinding.

Suppression

DELETE /v2/suervice_instances/:id

Sur demande utilisateur, Cloud Foundry demande de libérer les ressources mises en oeuvre dans le cadre d’une instance de service. Charge ici au service broker de faire le nécessaire pour cela. Comme souvent, Cloud Foundry n’impose aucune contrainte ici. La ressource en question peut aussi bien être réellement supprimée que juste désactivée. C’est à la discrétion du service broker et en rapport avec l’offre en question.

Notre service broker de base de données supprimerait ici la base de données correspondante.

La théorie c’est bien mais par où commencer ?

Si vous décidez de vous lancer dans la création d’un service broker, le mieux est d’abord d’utiliser les implémentations disponibles sur GitHub à titre d’exemple. Les 4 projets que je vous propose démontrent plusieurs choses :

• que l’on peut supporter un même service – dans notre cas MySQL – avec des services broker distincts;
• que la technologie utilisée a finalement peu d’importance même si l’on retrouvera le plus souvent du Ruby on Rails et du Java;
• que la définition d’un service n’est pas figée et que l’on peut intégrer bien plus de choses que l’on pourrait croire, ici GitHub par exemple;

cf-mysql-service-broker

Une application Ruby on Rails implémentant un service broker plutôt complet pour MySQL. Il sert de base à l’offre packagée Pivotal MySQL Dev.

cf-mysql-java-broker

Le pendant de cf-mysql-service-broker mais en Groovy au dessus de Spring Boot. Il couvre un périmètre moins étendu et est plus simple à appréhender.

github-service-broker-ruby

Un service broker au dessus de Sinatra – Ruby – pour s’interfacer avec GitHub.

spring-service-broker

Il ne s’agit pas d’un service broker en soit mais d’un starter kit basé sur Spring MVC pour le développement d’un service broker.

Techniquement, vous avez juste un ensemble d’interfaces à implémenter pour coder votre propre logique. Le reste des éléments est soit générique, soit configurable.

Et maintenant?

Vous avez développé votre propre service broker ? Ou vous voulez utiliser un service broker prêt à l’emploi sur GitHub? Rendez-vous dans quelques jours avec le 3e article de cette série dédiée aux services sous Cloud Foundry.