Cassandra est aujourd’hui un acteur majeur des systèmes de gestion de base de données, que l’on parle de systèmes traditionnels ou de systèmes NoSQL. Notre RSE open-source, Tatami, est d’ailleurs développé au dessus de cette technologie.
Aussi, lorsque nous avons déployé Cloud Foundry en interne nous avons étudié la possibilité d’intégrer Cassandra et Cloud Foundry via le mécanisme de service broker. Rien n’était alors disponible en open-source et nous voulions remédier à cela : IH Cassandra Service Broker est notre réponse à ce manque.
IH Cassandra Service Broker est un service broker open-source développé par Ippon permettant d’intégrer Cassandra en tant que service Cloud Foundry en introduisant la notion de KaaS : Keyspace as a Service. Il est mis à disposition de la communauté via un dépôt GitHub dédié :
https://github.com/ippontech/ih-cassandra-service-broker
L’accès à un cluster Cassandra est bien entendu la condition sine qua non à l’utilisation de ce service broker. Le schéma suivant permet de mieux situer les différents acteurs. IH Cassandra Service Broker ne couvre que le bloc rouge, les 2 autres étant des prérequis à son utilisation.
Un service broker est un service web permettant aux applications hébergées d’interagir avec un service dans le cadre d’une offre. Il n’est pas en charge de l’accès à ce service mais a pour responsabilité d’associer sur demande une application à une offre…. Source : /2014/09/24/les-services-sous-cloud-foundry-partie-1-kesako/
Sous le capot
IH Cassandra Service Broker s’appuie sur les fonctionnalités d’identification et d’autorisation proposées par Cassandra. Cependant, ces fonctionnalités sont désactivées par défaut et il est donc nécessaire de les activer avant utilisation. Cela s’effectue via le fichier cassandra.yaml et les options de configuration suivantes :
authenticator: AllowAllAuthenticator authenticator: PasswordAuthenticator #authorizer: AllowAllAuthorizer authorizer: CassandraAuthorizer
Je vous conseille toutefois de consulter la documentation en ligne sur l’identification et l’autorisation avant de vous lancer.
Une fois ces fonctionnalités actives, le service broker requiert l’accès à un compte utilisateur disposant de droits élevés. Il doit ainsi être capable de créer et de supprimer keyspaces et utilisateurs et d’affecter et de révoquer des permissions.
Pour sa mécanique interne, IH Cassandra Service Broker utilise un keyspace dédié, cf_cassandra_service_broker_persistence, qui contiendra le nécessaire à l’implémentation d’un service broker. Ainsi il contient
- la liste des keyspaces gérés par le broker,
- les utilisateurs managés,
- et les permissions associées.
Oui mais
IH Cassandra Service Broker hérite des limitations de Cassandra lorsqu’on active les mécanismes d’identification et d’authentification. Ainsi :
- tous utilisateurs peuvent voir la liste des keyspaces;
- les schémas des keyspaces sont visibles par tout le monde;
- les données ne sont cependant visibles que par les utilisateurs accrédités.
On commence quand?
Vous pouvez d’ores et déjà récupérer les sources du broker sur GitHub et l’utiliser comme bon vous semble sur votre propre instance Cloud Foundry. Il suffit pour cela de suivre les indications contenues dans le README.
Pour un déploiement plus assisté, IH Cassandra Service Broker servira de support au 3ème article sur les services sous Cloud Foundry.
Si vous ne pouvez pas attendre, il vous est possible d’utiliser gracieusement l’instance de Cloud Foundry mise à disposition par Ippon Hosting :
IH Cassandra Service Broker y est déployé et exploite un cluster Cassandra dédié aux développeurs.
