Travail de fin d études Gestion de service cloud et standards ouverts

Transcription

1 Université de Liège Faculté des Sciences Appliquées Département d Electricité, Electronique et Informatique Travail de fin d études Gestion de service cloud et standards ouverts En collaboration avec la société Euranova Hervé KOENER Promoteur: Mr. Guy LEDUC Jury: G. Leduc, B. Donnet, L. Mathy, I. Frain Travail de fin d études présenté en vue de l obtention du grade de Master en sciences informatique, à finalité spécialisée en gestion Année académique

2

3 Université de Liège Faculté des Sciences Appliquées Département d Electricité, Electronique et Informatique Travail de fin d études Gestion de service cloud et standards ouverts En collaboration avec la société Euranova Hervé KOENER Promoteur: Mr. Guy LEDUC Jury: G. Leduc, B. Donnet, L. Mathy, I. Frain Travail de fin d études présenté en vue de l obtention du grade de Master en sciences informatique, à finalité spécialisée en gestion Année académique

4 Remerciements Je voudrais remercier mon promoteur de stage monsieur LEDUC Guy ainsi que mes maîtres de stage monsieur FRAIN Ivan et monsieur DUGAUTHIER Quentin Ma reconnaissance s adresse également à monsieur DEWALEFFE Dominique pour ses conseils lors de la rédaction du mémoire. Ainsi que toutes les autres personnes qui m ont apporté leur aide.

5 Table des matières INTRODUCTION CHAPITRE I État de l art Introduction Le cloud computing Représentation State Transfert (REST) La gestion des clouds Les plates-formes de gestion d infrastructures cloud Les Service Managers Comparaison des différents Service Managers Définition d un service Conclusion CHAPITRE II Introduction OCCI Conclusion CHAPITRE III Introduction Le modèle de données Description des types Service exemple Conclusion CHAPITRE IV Introduction Les cas d utilisation Diagrammes de séquence La base de données Le diagramme de classe Conclusion CHAPITRE V Introduction Technologies utilisées Prérequis... 68

6 Arborescence du Service Manager Manipulation du Service Manager Instanciation et manipulation du service exemple Manipulation de l API d OpenNebula Exécution des scripts sur les machines virtuelles Sécurité Conclusion CONCLUSION Bibliographie Etat de l art Problématique Conception duservice Manager Implémentation du Service Manager ANNEXES... 88

7 Liste des figures Figure 1: Décomposition de l'infrastructure-as-a-service Figure 2: Pile des infrastructures cloud Figure 3: Représentation des différents types de déploiement d'une infrastructure cloud Figure 4: Services fournis par le cloud computing Figure 5: Représentation d'un SAN Figure 6: Identification et représentation d'une ressource Figure 7: Architecture de Claudia Figure 8: Exemple Use Case Figure 9: AWS CloudFormation récupération de l'access KeyID et de L'AWS Secret Access Key Figure 10: Illustration du principe utilisé par AWS CloudFormation Figure 11: RightScale, demande de crédential Figure 12: RightScale, Multicloud Market Figure 13: Illustration du modèle de données de RightScale Figure 14: OCCI Core Figure 15: OCCI Infrastructure Figure 16: Exemple d'utilisation de Mixin dans OCCI Infrastructure Figure 17: Modèle OCCI Service Manager Figure 18: Diagramme d'état du type Service Figure 19: Diagramme d'état du type AutoScalingGroup Figure 20 : Diagramme d'objet d'une instance d AutoScalingGroup lié au Mixin Rule Template Figure 21:Diagramme d'objet d'une instance de Role lié au Mixin Script Template Figure 22:Description du service exemple Figure 23: Structure du service exemple Figure 24: Diagramme de séquence: Lister les fonctionnalités Figure 25: Diagramme de séquence: Créer une ressource Figure 26: Diagramme de séquence: Lier une ressource à une autre Figure 27: Diagramme de séquence: lier une ou plusieurs ressources à un mixin Figure 28: Diagramme de séquence: Exécuter une action sur une ressource Figure 29: Diagramme de base de données simplifié: description des liens entre les différentes ressources Figure 30: Diagramme de base de données simplifié: lien entre les ressources et les mixins Figure 31: Diagramme de classe simplifié (vue) Figure 32: Diagramme de classe simplifié (contrôleur) Figure 33: Diagramme de classe simplifié des classes internes Figure 34 : Description du service exemple Figure 35: Instanciation du loadbalancer Figure 36: Instanciation du Système de gestion de base de données Figure 37: Instanciation des serveurs web Figure 38: Instanciation du service Figure 39: Démarrage du service Figure 40: Arrêt du service Figure 41: Agrandissement du groupe d'autoscaling Figure 42: Réduction du groupe d'autoscaling Figure 43: Représentation d'une ressource de type Compute... 74

8 Figure 44: Envoi d une requête GET sur l ensemble des utilisateurs Figure 45: Envoi d une requête GET sur l ensemble de ressources de type Compute Figure 46: Envoi d une requête DELETE sur une de ressource de type Compute Figure 47: Etats d'une ressource de type Compute Figure 48: Modification de l'état d'une ressource Figure 49: Description du service exemple Figure 50: Structure du service exemple Figure 51: Configuration des groupes d'autoscaling pour le service exemple Figure 52: Représentation d'une ressource de type Compute Figure 53: Utilisation de la commande occi-storage avec l option list Figure 54: Envoi d une requête GET sur l ensemble des utilisateurs Figure 55: Envoi d une requête GET sur l ensemble de ressources de type Compute Figure 56: Envoi d une requête DELETE sur une de ressource de type Compute Figure 57: Etats d'une ressource de type Compute Figure 58: Modification de l'état d'une ressource... 51

9 Liste des tableaux Tableau 1: Comparaison des différents Service Managers Tableau 2: comportement de l interface en fonction des commandes http Tableau 3: Instances de Kind définis pour les ressources d'occi ServiceManager Tableau 4: Attributs du type Service Tableau 5: Actions applicables sur les instances de Service Tableau 6: Attributs du type AutoScalingGroup Tableau 7: Actions applicables sur les instances d AutoScalingGroup Tableau 8: Liste complète des cas d'utilisation du Service Manager Tableau 9: Arborescence du Service Manager... 69

10 INTRODUCTION Koener Hervé 10

11 L introduction de mon mémoire consiste à la présentation des objectifs et comment les atteindre. Je vais fournir une base théorique sur le cloud computing, afin d aider la compréhension du lecteur. Les services fournis par le cloud computing peuvent être divisés en trois catégories : Infrastructure-as-a-Service (IaaS): cette couche consiste à externaliser le matériel supportant les processus opérationnels(les serveurs, le stockage) tout en laissant un accès complet à celui-ci. Platform-as-a-Service (PaaS): le matériel (infrastructure) et le système d exploitation (plateforme) sont externalisés afin de jouir d un environnement middleware où l on fait abstraction de l infrastructure. Software-as-a-Service (SaaS): l utilisation de l application est vendue comme un service. Le client ne doit plus se soucier de l évolution de celle-ci. Mon mémoire se concentre sur la couche Infrastructure-as-a-Service (IaaS). Celle-ci peut être divisée en différentes sous-couches, chacune fournissant un certain degré d abstraction : La couche Gestion de service (Service Manager) : permet de faire abstraction de la configuration de base (par exemple : attribution d adresse IP) en gérant des services plutôt que des machines virtuelles. La couche Gestion d infrastructure (VEEM 1 ) : permet une gestion plus aisée des data centers (Par exemple : en facilitant le déploiement d une machine virtuelle sur un hôte physique). La couche Environnement virtuel (VEE 2 ) : permet de créer et de lancer des machines virtuelles. Service Provider Service Provider Service Provider Service Provider SMI CloudFormation Claudia, RightScale Service Manager VMI OpenNebula VEEM (VEE Manager) VHI Xen, KVM, VMWare, VEEHost (Hypervisor, VSJC) IaaS VEEHost (Hypervisor, VSJC) VEEHost (Hypervisor, VSJC) Figure 1: Décomposition de l'infrastructure-as-a-service 3 1 VEEM : Virtual Execution Environment Manager 2 VEE : Virtual Execution Environment 3 Ce schéma est basé le modèle proposé par Reservoir : Koener Hervé 11

12 Le principal problème du cloud computing est lié au manque de standard dans ce domaine. Cela provoque une incompatibilité entre les différents fournisseurs cloud et ne permet pas à un client de passer d un fournisseur à l autre sans risquer la perte de données ou de confidentialité. Ce problème porte le nom de «enferment propriétaire» (Vendor Lock-in). A l heure actuelle, il existe différents standards émergeants tel qu OCCI afin de résoudre ce problème. Cependant, ceux-ci ne couvrent que la couche gestion d infrastructure. L objectif principal de ce mémoire est de proposer une extension du modèle proposé par OCCI pour la couche Service Manager. La réalisation de cet objectif dépend de la réalisation de trois autres : l étude des Service Managers existant, l étude d OCCI et de son implémentation de référence (OpenNebula) ainsi que la définition de l extension du modèle OCCI pour la couche Service Manager. Le premier objectif concerne l étude des services managers existants tels que RigthScale, AWS CloudFormation afin d en ressortir les fonctionnalités essentielles et d en déduire des use cases utilisateurs. Son but principal est de donner une idée sur les fonctionnalités pouvant être supportées par l extension du modèle OCCI. Le second, consiste à étudier le modèle OCCI Core afin de pouvoir l étendre pour les Service Managers. Le dernier objectif consiste à développer un Service Manager implémentant l extension afin de la valider. Ce Service Manager doit pouvoir communiquer avec l API OCCI d OpenNebula afin de gérer un ensemble de machines virtuelles. Cet ouvrage est subdivisé en chapitres. A travers ceux-ci, le lecteur découvrira la démarche réalisée afin de proposer une solution pour résoudre le problème précédemment cité. Les chapitres de ce mémoire sont les suivants : Etat de l art : ce chapitre fournit au lecteur une base théorique sur le cloud computing et introduit les différents mécanismes utilisés lors la conception et de l implémentation du Service Manager. Il définit également un exemple service qui facilitera la compréhension du lecteur. Ce chapitre se focalise sur le premier objectif en comparant les différents Service Manager et en expliquant comment définir le service exemple sur ceux-ci Problématique : ce chapitre parle du problème d enfermement propriétaire (lock-in) et explique comment OCCI permet de résoudre en partie ce problème. Il parle également des limites du modèle OCCI Core. Ce chapitre correspond donc au deuxième objectif qui consiste à étudier le modèle OCCI Core. Extension d OCCI pour les Service Managers : dans ce chapitre, je définis le modèle OCCI Service Manager qui est une extension du modèle OCCI Core. Conception du Service Manager : ce chapitre explique les différentes étapes d analyse afin de concevoir un Service Manager basé sur le modèle OCCI Service Manager. Implémentation du Service Manager : ce chapitre se concentre sur l implémentation du Service Manager et explique comment instancier et manipuler le service exemple afin de valider le modèle OCCI Service Manager. Koener Hervé 12

13 CHAPITRE I État de l art Koener Hervé 13

14 Table des matières Introduction Le cloud computing Le principe Les services Extensibilité Disponibilité et fiabilité Intégrité Représentation State Transfert (REST) Les contraintes L interface client-serveur La gestion des clouds Les plates-formes de gestion d infrastructures cloud Amazon Web Services (AWS) OpenNebula Les Service Managers RightScale Cloud Management AWS CloudFormation Claudia Comparaison des différents Service Managers Définition d un service Exemple Use Case Définition d un service sous AWS CloudFormation Le template La Stack Définition d un service sous RightScale Ajout du fournisseur cloud Création des servertemplate Manipulation de l API Conclusion Koener Hervé 14

15 Introduction Comme son nom l indique, ce chapitre consiste à faire l état de l art sur le cloud computing. Je commencerai par vous expliquer son principe ainsi que les différents services qu il fournit. Je décrirai également l architecture REST car je me suis basé sur celle-ci pour réaliser mon mémoire. Les autres points seront plus spécifiques à mon mémoire. Ils se focaliseront sur les plates-formes de gestion d infrastructures cloud ainsi que sur les Service Managers. Ce chapitre se termine par la description d un exemple de service pouvant être déployé sur une infrastructure cloud et décrit son déploiement sur des Service Managers existant (AWS CloudFormation et RightScale). Le cloud computing Le principe Le cloud computing est un concept qui consiste à déporter sur des serveurs distants les ressources (principalement la puissance de stockage et de calcul) traditionnellement situées localement. Ces ressources sont alors fournies sous forme d un service plutôt que sous forme d un produit. Elles sont accessibles généralement via internet. L utilisation du cloud Computing permet notamment des économies d échelle car un nombre restreint de personnes peut gérer énormément de machines. De plus les machines composant le cloud sont similaires et leur architecture est optimisée afin d avoir les meilleures performances possibles. Cette économie d échelle engendre donc une diminution des couts. Ces services sont divisés en trois catégories : Infrastructure-as-a-Service (IaaS): le matériel supportant les processus opérationnels(les serveurs, le stockage) est externalisé mais le client dispose d un accès sans restriction à celuici comme s il se trouvait localement. Platform-as-a-Service (PaaS): le matériel (infrastructure) et le système d exploitation (plateforme), supportant l exécution d une application sont externalisés. Cela permet à une entreprise de jouir d un environnement middleware où l on fait abstraction de l infrastructure. Software-as-a-Service (SaaS): l application ainsi que ses mises à jour sont externalisées. De ce fait, l utilisation de l application est vendue comme un service, le client ne doit donc plus se soucier de l évolution de celle-ci. Client Software-as-a-Service (SaaS) Platform-as-a-Service (PaaS) Infrastructure-as-a-Service (IaaS) Serveurs Figure 2: Pile des infrastructures cloud Koener Hervé 15

16 Chacun de ces services peut également être déployé de trois manières différentes : Private cloud : les ressources sont supportées par une architecture cloud propriétaire et ne sont disponibles qu à un nombre limité de personnes (par exemple, le personnel d une entreprise). Public cloud : le service est proposé par un fournisseur pour un public général. Les clients payent alors en fonction de leur utilisation du service. Hybrid cloud : certaines ressources (généralement les plus sensibles) sont déployées sur une infrastructure privée (private cloud) et les autres sur une infrastructure publique (public cloud). Entreprise Hybrid Cloud Fournisseur Private Cloud Public Cloud Figure 3: Représentation des différents types de déploiement d'une infrastructure cloud. Les services Le cloud computing fournit différents services réduisant le coût de la gestion de l infrastructure informatique et facilitant son évolution. Ces services sont : L extensibilité des ressources La disponibilité La fiabilité L intégrité des données Extensibilité intégrité Cloud Computing Disponibilité fiabilité Figure 4: Services fournis par le cloud computing. Tous ces services forment les piliers du cloud computing et ils sont gérés de manière efficace grâce à des outils simples et performants tels que les plates-formes de gestion d infrastructures cloud ou les Service Managers. Koener Hervé 16

17 Extensibilité Le principal avantage du cloud computing est l extensibilité. Le client ne doit plus s en soucier et ne paye qu en fonction du temps d utilisation du service. L extensibilité est principalement fournie par la virtualisation. Celle-ci permet de rajouter des ressources très rapidement et très efficacement. La virtualisation consiste à lancer un ou plusieurs systèmes d exploitation sur un ou plusieurs ordinateurs à la place d avoir un système d exploitation par ordinateur. Les systèmes d exploitation s exécutent dans un environnement virtuel. Les principaux composants de cet environnement sont : La machine virtuelle : les ressources logicielles et matérielles (principalement la puissance de calcul) sont simulées. Le système d exploitation peut alors s exécuter comme s il s agissait d une machine physique. Le stockage virtuel : seule une partie de la puissance de stockage de la machine physique n est visible pour chaque machine virtuelle. Le réseau virtuel : seule une partie de la bande passante disponible et de l espace d adressage (adresse IP) n est disponible pour chaque machine virtuelle. Cela permet de communiquer avec une machine virtuelle comme s il s agissait d une machine physique connectée sur le réseau. La virtualisation offre d autres avantages tels qu une meilleure portabilité des services, une facilité pour démarrer de nouveaux serveurs ainsi qu une utilisation optimisée des serveurs physiques. Disponibilité et fiabilité Le cloud computing fournit également la disponibilité et la fiabilité. Ceci est réalisé par le biais de la répartition de charge et par le plan de continuité d activité. La répartition de charge est une technique permettant de distribuer le travail entre toutes les ressources disponibles. Cela est réalisé à l aide d un load balancer qui transmet à tour de rôle les requêtes à chaque ressource. Cette technique est largement utilisée pour minimiser le temps d accès aux bases de données et aux sites web. Grâce à l aide d un système de secours, le plan de continuité d activité a pour but de garantir la disponibilité de services fournis par une entreprise en permettant de redémarrer rapidement l activité en cas de crise majeure. Le cloud computing donne la possibilité de lancer des instances de serveurs (machine virtuelle) sur des serveurs éloignés physiquement. Ce procédé permet ainsi de garantir un certain niveau de disponibilité si un sinistre majeur touche une partie des serveurs physiques. Koener Hervé 17

18 Intégrité L intégrité des données est fournie grâce à des techniques de sauvegarde entre des bases de données physiquement éloignées l une de l autre. Plusieurs copies des données sont automatiquement réalisées afin de faciliter la restauration des données. Les principales techniques employées sont l utilisation de RAID ou de SAN. Le RAID est un ensemble de technique permettant de répartir les données sur plusieurs disques durs. Son but est l amélioration de la tolérance aux pannes et les performances du système. Il existe différents niveaux de RAID dont les principaux sont : Le RAID0 : les données sont réparties par bandes sur plusieurs disques sans redondance. Ce niveau permet une amélioration des performances d accès aux données. Le RAID1 : les données sont répliquées sur les différents disques et permettent l augmentation de la tolérance aux pannes matérielles. Le RAID5 : les données sont réparties par bandes sur plusieurs disques. La capacité de mémoire d un disque est utilisée pour stocker les informations de parités. Celles-ci vérifient la cohérence des données. Cette solution permet une amélioration des performances tout en augmentant la tolérance aux pannes. Le SAN est un réseau de stockage permettant de mutualiser les ressources de stockage et de faciliter les sauvegardes des données. Il est composé d un réseau de switch utilisant le protocole Fiber channel et d un système de stockage. Le SAN permet de rendre l espace disque évolutif à volonté par l ajout de baie de stockage ou de disque dur. Figure 5: Représentation d'un SAN Koener Hervé 18

19 Représentation State Transfert (REST) REST est un style d architecture d application pour les systèmes distribués tel que le web. Le but de l architecture REST est d optimiser certains aspects d une application pour les systèmes distribués. Ces aspects sont la séparation des tâches, la simplicité, la généricité ou les performances réseaux. Ce style d architecture consiste en une communication entre un client et un serveur. Le client envoie une requête au serveur, celui-ci la traite et lui envoie une réponse. Les requêtes et les réponses servent à lire ou modifier une ressource en utilisant une représentation de celle-ci. Une ressource est une chose qui a la capacité de changer au cours du temps. Une représentation quant à elle, est un document qui capture l état courant de la ressource. Chaque ressource est accessible à l aide d un Uniform Resource Identifier (URI). URI Identifie Représentation Metadonnées Content-Type :text/html, charset=utf-8 Ressource A Données <html> <head> <title>resource A</title> Représente Figure 6: Identification et représentation d'une ressource. Les contraintes L architecture REST décrit six contraintes à respecter : Client-serveur : une interface uniforme entre le client et le serveur doit être implémentée. Cela permet d implémenter indépendamment le client et le serveur, donc d améliorer la portabilité du code client et de simplifier l implémentation du serveur (puisqu il ne s occupe pas de l état du client). Interface uniforme : comme expliqué ci-dessus, une interface uniforme doit être implémentée afin de permettre à chaque partie d évoluer indépendamment l une de l autre. Sans-état : le serveur ne stocke pas l état du client. C est pourquoi, chaque requête envoyée au serveur contient toutes les informations nécessaires à un service. Cache : le client y stocke les réponses afin d augmenter les performances du système. Certaines réponses peuvent indiquer explicitement ou implicitement si l on peut ou pas les stocker afin d éviter la réutilisation de données inappropriées lors d une requête ultérieure. Koener Hervé 19

20 Système en couche : un client ne peut pas demander à communiquer directement à un serveur final. Des serveurs intermédiaires permettent d augmenter l extensibilité (proxy, load balancer) ou la sécurité. Client Side Scripting (optionnel) : le serveur peut étendre ou customiser temporairement les fonctionnalités du client en transférant du code exécutable (applet java, JavaScript). L interface client-serveur L interface uniforme, que toutes les interfaces REST doivent intégrer, est fondamentale car elle peut fournir un service RESTful. Cette interface doit permettre : L indentification des ressources : dans REST, tout ce qui peut être nommé est une ressource (un document, une image, un service temporaire ). Chaque ressource est identifiée par un identifiant unique appelé URI (Uniform Resource Identifier). La manipulation des ressources : quand un client possède une représentation de la ressource, il a assez d information pour pouvoir modifier ou supprimer la ressource. Le traitement des réponses : chaque réponse envoyée par le serveur possède assez d informations pour que le client sache comment les traiter. Par exemple, le content-type ou le MIME Type est utilisé afin de déterminer le type de fichier envoyé par le serveur. Hypermedia as the Engine of Application State (HATEOAS): le choix d un des liens d une représentation de ressource ou sa manipulation d une autre manière (si le type de fichier l autorise) permet au client de passer d un état à un autre. La gestion des clouds Le nombre de machines composant un cloud étant très élevé, des outils sont nécessaires pour les gérer. Ces outils permettent aux gestionnaires d infrastructure cloud d avoir un certain niveau d abstraction et ainsi de faciliter la gestion des datas centers. Ces outils permettent notamment d automatiser la sauvegarde de données et de faciliter la création de machines virtuelles. Les plates-formes de gestion d infrastructures cloud A l heure actuelle, différentes plates-formes permettent la gestion des datas centers qui fournissent l Infrastructure-as-a-Service. Ces plates-formes de gestion sont par conséquent des outils très utiles dans le domaine du cloud computing. Ils nécessitent néanmoins des connaissances techniques afin de créer des machines virtuelles comme par exemple savoir quelle est la capacité (puissance CPU, mémoire RAM) nécessaire pour faire tourner une application ou savoir quel OS installer. Il faut également configurer les différentes machines afin qu elles puissent communiquer entre elles ou avec le monde extérieur (internet). Amazon Web Services (AWS) Amazon Web Services est une des principales plates-formes de gestion d infrastructure cloud. Elle offre à ses clients la possibilité d avoir des ressources de calcul et de bases de données extensibles. Cette plate-forme utilise les data centers conçus à l origine pour supporter les services fournis par Amazon. L utilité se vérifie par la disponibilité immédiate de la capacité nécessaire au bon fonctionnement des services des clients et permet ainsi le lancement et l arrêt des instances de serveur (machine virtuelle) en fonction de leurs besoins sans se soucier de la capacité disponible. Le coût varie en fonction du temps d utilisation des ressources. Koener Hervé 20

21 AWS permet de faire fonctionner des systèmes nécessitant un niveau de disponibilité très élevé à l aide d instances lancées sur des serveurs physiquement distants. De plus, un client peut lancer ses machines virtuelles proche de sa zone géographique et ainsi améliorer la vitesse d accès à ses services, grâce aux nombreux data centers d Amazon répartis sur la surface du globe (US-East, US- West, EU, Tokyo, Singapore, São Paulo, Oregon). Les principaux services fournis par Amazon Web Services sont : Amazon Elastic Compute Cloud (EC2) pour la manipulation de ressources de calculs et Amazon Simple Storage Service (S3) pour la manipulation de ressources de stockage. OpenNebula OpenNebula est une plate-forme de gestion d infrastructure cloud open source. Elle est compatible avec le modèle OCCI et facilite donc le changement de fournisseur IaaS. OpenNebula a été conçu pour permettre aux gestionnaires de gérer de manière efficace des infrastructures cloud complexes et hétérogènes. Contrairement à AWS, OpenNebula n offre pas d infrastructure physique. Le client doit donc posséder son propre cloud privé ou disposer d un contrat avec un fournisseur d infrastructure cloud. Néanmoins, la plate-forme permet de gérer efficacement les ressources de calcul et de stockage. Les Service Managers Les Service Managers permettent de faire abstraction de la gestion détaillée des serveurs et des bases de données. L utilisateur ne manipule et ne gère plus que des services. Ceux-ci sont composés d ensemble de serveurs ayant un même rôle. Les principales fonctionnalités d un Service Manager consistent à l association d un rôle à un groupe d abstraction (groupe de serveur) et à la gestion des dépendances entre ces groupes (par exemple, en indiquant que le groupe composé de serveurs web dépend du groupe composé du load balancer). La configuration de base est également réalisée par le Service Manager (par exemple : l attribution d une adresse IP). Les services gérés par le Service Manager sont définis à l aide de templates. Ces documents permettent de décrire le rôle de chaque ressource et d y associer des règles d extension. Cela signifie que le client ne doit plus se soucier de savoir quand un serveur doit être rajouté pour préserver le niveau de disponibilité du service et facilite donc l extensibilité de ce service. Les Service Managers permettent également de gérer les infrastructures cloud de plusieurs fournisseurs différents. RightScale Cloud Management RightScale Cloud Management est un Service Manager qui permet aux organisations de déployer et de gérer facilement leurs applications critiques à travers des clouds publics, privés et hybrides. RightScale fait la liaison entre l application et les différentes infrastructures cloud. Cependant, ce Service Manager ne fournit l infrastructure que pour supporter ses services. Le client doit donc disposer d une infrastructure cloud. RightScale est compatible avec différents fournisseurs cloud publiques tel qu Amazon Web Service, Rackspace, SoftLayer, Logicwork ou encore Datapipe. RightScale est également compatible avec des clouds privés fonctionnant avec Eucaplyptus, CloudStack. Koener Hervé 21

22 AWS CloudFormation AWS CloudFormation permet aux développeurs et aux administrateurs de gérer de manière simple les ensembles de ressources liés à Amazon Web Service. Les clients ne doivent plus s occuper de l ordre de mise en service des différentes ressources ou de gérer les différentes dépendances. AWS CloudFormation permet d utiliser des templates pour créer et supprimer des ensembles de ressources en les considérants comme s il s agissait d une seule entité. AWS CloudFormation fournit l infrastructure cloud à ses clients, mais est limitée exclusivement à la gestion des infrastructures cloud d Amazon Web Service. Claudia Claudia est un Service Manager open-source permettant de gérer facilement des services entiers et de contrôler comment les étendre et les réduire de manière automatique. Chaque action réalisée sur un service est répliquée automatiquement sur chaque ressource composant ce service. Tout comme les autres Service Manager, Claudia est compatible avec les architectures privées, publiques et hybrides. Claudia ne fournit aucune infrastructure, le client doit donc disposer d une infrastructure cloud. A l heure actuelle, Claudia n est intégré qu avec OpenNebula mais son intégration prochaine avec EC2 5 est prévue également. Figure 7: Architecture de Claudia 6 5 Voir : Koener Hervé 22

23 Comparaison des différents Service Managers Si l on compare les différents Service Managers entre eux, ils permettent tous la définition et le déploiement des services. Une autre fonctionnalité importante est l autoscaling définie à l aide de la programmation d alerte. Cette fonctionnalité permet d étendre un service automatiquement de la manière la plus efficace possible (en fonction de la charge réseau, CPU, de l heure, ). Tableau 1: Comparaison des différents Service Managers Fonctionnalités RightScale AWS CloudFormation Claudia Définir un service Déployer un service Autoscaling Spécifier des alarmes Gérer la sécurité (firewall) Lancer des scripts Historique Spécifier des dépendances Tagguer les ressources Gérer l état des ressources Dans la suite de ce document, nous allons comparer plus en détail RightScale et AWS CloudFormation puisque contrairement à Claudia ils sont tous deux compatibles avec les produits d Amazon Web Service tel qu Amazon EC2 ou Amazon S3. Koener Hervé 23

24 Définition d un service La fonctionnalité principale d un Service Manager est la définition d un service. Nous allons comparer cette fonctionnalité sous AWS CloudFormation et RightScale à l aide d un exemple. Nous réutiliserons cet exemple tout au long de cet ouvrage afin de faciliter la compréhension du lecteur. Exemple Use Case Imaginons que l on veut déployer un service composé de : Un load balancer (nginx) Trois serveurs web (apache + php) Un SGBD (MySQL) Load balancer Serveurs web SGBD Figure 8: Exemple Use Case Pour pouvoir gérer ce service sur notre cloud, nous devons tout d abord le définir. Pour ce faire, il faut définir et configurer les instances de serveur (machine virtuelle) qui le composent. On peut également spécifier le moment de l augmentation ou de la réduction du nombre de ressources. Cela garantit la disponibilité du service. Nous allons maintenant définir ce service sous AWS CloudFormation et sous RightScale en utilisant leur API respective. Koener Hervé 24

25 Définition d un service sous AWS CloudFormation AWS CloudFormation est un Service Manager permettant de gérer l infrastructure cloud d Amazone. Pour lancer un service, il faut donc au préalable s inscrire à un ou plusieurs services d AWS (EC2, S3, ). Lors de l inscription à AWS CloudFormation, on reçoit Access KeyID et l AWS Secret Access Key, ceux-ci sont nécessaires pour l utilisation de l API d AWS CloudFormation. XXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Figure 9: AWS CloudFormation récupération de l'access KeyID et de L'AWS Secret Access Key Le template L élément principal d AWS CloudFormation est le template 7. C est à l aide de celui-ci que l on définit l entièreté d un service. Ce document rédigé au format JSON est composé de différentes sections : - AWSTemplateFormatVersion : indique la version du format utilisé (format actuel : ). - Description : décrit le contenu du template. - Parameter : permet de passer des informations au template lors de la création d une Stack. Ce sont principalement des informations qui sont spécifiques à un service (par exemple : le port TCP/IP d un serveur web) ou des informations dont on ne désire pas qu elles apparaissent dans le template (par exemple : le mot de passe administrateur). - Mapping : permet de faire correspondre une clé à un ensemble de paires nom-valeur par exemple pour spécifier une AMI 8 en fonction d une région géographique. - Resources : décrit les différentes ressources composant un service. - Output : permet de retourner des valeurs à un utilisateur (par exemple l url d un site web) lorsque la création de la Stack est terminée. Mise à part la section Ressources, toutes sont optionnelles. C est dans la section Ressources que l on définit et que l on configure toutes les ressources de notre service. 7 Une description détaillée de la structure d un template est disponible dans les annexes. 8 AMI : l Amazon Machine Image est un OS et un ensemble de logiciel préconfiguré permettant de créer une machine virtuelle sous Amazon EC2. Koener Hervé 25

26 Une ressource appartient à un type de ressource AWS 9 et peut posséder un certain nombre de propriétés. (Par exemple : la taille, le nom et le mot de passe administrateur de la base de données sont des attributs d une ressource de type AWS::RDS::DBInstance). La Stack Sous AWS CloudFormation, les services sont appelés Stack. Lorsque la rédaction du template est terminée, la Stack peut être créée. Pour créer la Stack et ainsi déployer le service, on peut utiliser l UI ou l API d AWS CloudFormation 10. Pour créer la Stack avec l UI, il suffit d aller dans l AWS Management Console, de cliquer sur nouvelle Stack et de fournir le nom de la Stack, une adresse (où recevoir les notifications), le template et les paramètres du template (si c est nécessaire). Pour créer la Stack à l aide de l API, il suffit d exécuter la commande suivante : &StackName=MyStack &TemplateBody=[Template Document] &Parameters.member.1.ParameterKey=AvailabilityZone &Parameters.member.1.ParameterValue=us-east-1a &AWSAccessKeyId=[AWS Access KeyID] &Version= &Timestamp= T15%3A30%3A30.000Z &SignatureMethod=HmacSHA1 &SignatureVersion=2 &Signature=[Signature] [Template Document] = Contenu du document servicemanager.template 11. [AWS Access KeyID] = l'aws Access Key ID fournis lors de l'inscription. [Signature] = Signature de la requête (Hash). 9 La liste des types de ressource AWS est disponible dans les annexes. 10 UI : User Interface, API : Application Programming Interface 11 Le document servicemanager.template est disponible dans les annexes. Koener Hervé 26

27 La figure 10 montre le principe utilisé par AWS CloudFormation pour définir le service. { "Resources":{ "LoadBalancer":{ "Type": "AWS::ElasticLoadBalancing::LoadBalancer", }, "WebServerGroup":{ "Type": "AWS::AutoScaling::AutoScalingGroup", }, "SGBD":{ "Type": "AWS::RDS::DBInstance", } } } Défini le service Défini les ressources CloudFormation EC2, S3, Crée les VMs Figure 10: Illustration du principe utilisé par AWS CloudFormation Koener Hervé 27

28 Définition d un service sous RightScale RightScale Cloud Management est un Service Manager permettant de gérer les infrastructures cloud. Il fait la liaison entre l application et les différentes infrastructures cloud. Afin de pouvoir lancer un service, il faut tout d abord s inscrire chez un fournisseur cloud (Amazon Web Service, Softlayer, ) sinon, posséder sa propre infrastructure cloud (Eucaliptus, CloudStack, ). Dans cet exemple, nous considérerons que l on possède déjà un compte AWS. Lorsque l infrastructure est disponible, nous pouvons nous inscrire à RightScale afin de recevoir notre userid. Ajout du fournisseur cloud En premier lieu, il faut ajouter le fournisseur cloud à RightScale en encodant les informations nécessaires à la communication entre RightScale et le fournisseur (Dans notre exemple, il faut encoder l'aws Account Number, l'aws Access Key ID et l'aws Secret Access Key). Cette manipulation ne peut être réalisée qu avec l UI. Figure 11: RightScale, demande de crédential. Création des servertemplate Sous RightScale, l api (1.0) ne permet pas de définir les ressources (CPU, RAM, type d image, boot script, règles d extension). Pour définir les ressources, il faut passer par l UI. On peut les définir soimême (en créant un servertemplate) ou télécharger des servertemplates existants sur le MultiCloud Marketplace. Figure 12: RightScale, Multicloud Market Un servertemplate doit être créé pour chaque type de serveur en y associant une MulticloudImage, des scripts (Boot, Operational, Decommission) et des alertes pour l autoscaling. Lorsque les servertemplates sont terminés, on peut créer le service (appelé deployment). Koener Hervé 28

29 Manipulation de l API Authentification Pour pouvoir utiliser l api, il faut tout d abord créer un cookie de connexion. La commande suivante permet de se connecter. Curl -k -c moncookie -u [ ]:[password] [ ] = L du compte RightScale [password] = Le mot de passe du compte RightScale [userid] = L id du compte RightScale Création du déploiement Sous RightScale, un service est appelé déploiement. Nous allons le créer pour ensuite y ajouter les différentes ressources qui le composent. curl -H 'X-API-VERSION:1.0' -b moncookie -d "deployment[description]=[description]" -d "deployment[nickname]=[nickname]" [description] = Description du déploiement. [nickname] = Nom du déploiement. Lister les serveurs templates Puisqu il est impossible de créer les servertemplates avec l api, nous allons lister ceux disponibles sur internet afin de connaitre l url de ceux qui seront utilisés pour configurer les serveurs. curl -k -b moncookie [userid] = L id du compte RightScale. Création d un serveur La dernière étape consiste à créer les serveurs composant le service. Lors de la création d un serveur, il faut lui associer un servertemplate et un déploiement. Comme nous connaissons l url des servertemplates nécessaire ainsi que celui de notre service, nous pouvons exécuter la commande ci-dessous afin de rajouter les serveurs à notre service. curl -k -H 'X-API-VERSION:1.0' -b moncookie -d "server[nickname]=[nom]" -d "server[server_template_href]=[templateurl]" -d "cloud_id=[cloudid]" -d "server[ec2_user_data]=myec2userdata" -d "server[deployment_href]=[deploymenturl]" [nom] = nom du serveur. [templateurl] = L url du template. Celui-ci correspond à l url de la configuration Koener Hervé 29

30 que l on veut (load balancer, serveur web, base de données). [cloudid] = L id du cloud AWS: (1=AWS US-East, 2=AWS EU, 3=AWS US-West, 4=AWS AP- Singapore,5=AWS AP-Tokyo,6=AWS US-Oregon,7=AWS SA-São Paulo). [deploymenturl] = L url du déploiement précédemment créé. [userid] = L id du compte RightScale. Cette commande doit être exécutée pour chaque type de serveur composant le service, c est-à-dire une fois pour le load balancer, une fois pour les serveurs web et une fois pour le SGBD. La figure 13, montre le modèle de données 12 utilisées par RightScale pour définir le service. Deployment 1 * Server 1 1 ServerTemplate * MulticloudImage Cloud 1 * 1 Image Défini les ressource RightScale Fournisseur Cloud Crée les VMs Figure 13: Illustration du modèle de données de RightScale 12 Le diagramme de classe expliquant en détail le modèle de données utilisées par RightScale est disponible dans les annexes. Koener Hervé 30

31 Conclusion Dans ce chapitre, j explique ce qu est le cloud computing et quels sont les services fournis par celuici. J ai également parlé des gestionnaires d infrastructures cloud permettant de gérer les ensembles de machines contenues dans le cloud. Ensuite, je définis les Services Managers et j explique leurs utilités. Je termine le chapitre en décrivant un exemple de service pouvant être déployé sur le cloud. Je montre également comment ce service pourrait être déployé sur AWS Cloud Formation et sur RightScale afin de savoir comment concevoir un Service Manager. Koener Hervé 31

32 CHAPITRE II Problématique Koener Hervé 32

33 Table des matières Introduction OCCI OCCI Core Spécification Découverte des ressources Extension du modèle OCCI Infrastructure Les ressources Les liens Les Mixins Les templates Interface HTTP Les opérations CRUD L interface de requête Manipulation des Mixins, Kinds, Ressources et Links Format des données Le mécanisme de filtrage Conclusion Koener Hervé 33

34 Introduction Le principal problème du Cloud Computing est le problème d enfermement propriétaire (vendor lock-in). Il se caractérise par le fait qu un client ayant mis en place son application sur le Cloud d un fournisseur X ne peut changer de fournisseur en écartant le risque de la perte de données ou de perte de confidentialité des données. Ceci est dû à l inexistence de standard permettant la compatibilité des différentes infrastructures Cloud. A l heure actuelle, il existe différents standards émergeants tels que CDMI pour la récupération de données dans le cloud, OVF pour le format de stockage sur disque des images de machine virtuelle ou encore OCCI permettant de gérer des Infrastructures cloud. Dans ce chapitre, nous allons nous focaliser sur OCCI et regarder comment ont été défini OCCI Core et OCCI Infrastructure. Cela nous aidera par la suite, à définir notre extension d OCCI pour les Service Managers (OCCI ServiceManager). OCCI L Open Cloud Computing Interface (OCCI) écrite par l Open Grid Forum (OGF) est une spécification open source utilisée afin de standardiser le Cloud Computing. C est à la fois un protocole RESTful et une API permettant de créer d autres API. L OCCI a été initialement créé pour fournir une API pour Infrastructure-as-a-Service (par le biais d OCCI Infrastructure). Cependant, le modèle OCCI Core peut être étendu pour supporter le PaaS et le SaaS. L OCCI a été créé principalement pour résoudre le problème d enfermement et donc permet à la fois à un client d avoir la possibilité de gérer des data centers hétérogènes ou de passer d un distributeur à l autre en écartant tous les problèmes de compatibilité ou de perte de données. Cette spécification explique comment un fournisseur IaaS peut délivrer les bases de données, les serveurs ou les ressources réseaux à travers une interface standardisée. L OCCI est divisé en trois catégories : OCCI Core : ce document spécifie l OCCI Core Model consiste en la structure de base de toutes applications utilisant cette spécification. OCCI Rendering : c est un ensemble de documents décrivant différentes interfaces permettant d accéder au modèle. Chacune de ces interfaces peut interagir avec l OCCI Core Model et supporte chaque extension de celui-ci. OCCI Extensions : c est un ensemble de documents décrivant les extensions de l OCCI Core Model. L OCCI fournit l interopérabilité en spécifiant des mécanismes communs pour la représentation, la découverte et la gestion des ressources pour lesquels l approche REST est utilisée. Les ressources sont accessibles et identifiées à l aide d URI et elles sont gérées par le biais des commandes http (GET, POST, PUT, DELETE), notamment pour exécuter les opérations CRUD (Create, Retrieve, Update, Delete). Koener Hervé 34

35 OCCI Core Spécification Le document OCCI Core décrit le modèle de données OCCI Core Model. Celui-ci spécifie comment les ressources sont représentées afin de permettre la gestion de services venant de différents fournisseurs. La figure 14 illustre le diagramme UML du modèle défini par le document OCCI Core. Figure 14: OCCI Core 13 Le cœur de l OCCI Core Model est le type Resource. Chaque ressource de l infrastructure cloud est un sous-type de Resource (par exemple, une machine virtuelle, un utilisateur ou un service). Ce type est complété par le type Link qui associe une instance de Resource avec une autre. Le rôle du type Link est donc, de lier les ressources entre elles. Ces deux types sont les sous-types d Entity et héritent donc de ses différents attributs Koener Hervé 35

36 Chaque Entity est identifiée par une instance unique de Kind. Kind est une spécialisation de Category. Il permet d identifier les différentes Entity et de connaitre les aptitudes de celles-ci (à l aide du type Action). Une Action est une opération pouvant être exécutée sur une ou plusieurs ressources. Une Action est identifiée à l aide d une instance de Category. Le type Mixin quant à lui, permet par le biais du type Entity de rajouter dynamiquement des aptitudes aux ressources et de découvrir la classification de celle-ci. Découverte des ressources En plus de la représentation des ressources, le modèle OCCI Core spécifie également comment découvrir les ressources et les opérations supportées par l implémentation. Celles-ci sont découvertes à l aide des instances de Kind qui décrivent tous les sous-types disponibles d Entity ainsi que leurs attributs et opérations. Une propriété fondamentale de l OCCI Core Model est qu il peut être étendu de manière à ce que chaque extension puisse être découverte par un client OCCI à l exécution. Ce qui signifie qu un client OCCI peut se connecter à une implémentation du modèle sans rien connaître à l avance et découvrir, durant l exécution, tous les sous-types de Resource et Link supportés par l implémentation. Par exemple, pour lister toutes les fonctionnalités d une implémentation du modèle utilisant l interface http, il suffit d accéder au chemin «/-/» en utilisant la commande «GET». Extension du modèle Il existe deux manières différentes d étendre le modèle OCCI Core : Créer des sous-types de Resource, Link ou Action : chaque sous-type de Resource ou de Link doit être identifié par une instance de Kind. Les sous-types d Action doivent, eux, être identifiés par une instance de Category et en plus, être liés à une instance de Kind ou de Mixin. Créer des instances de Mixin : de nouvelles instances de Mixin peuvent être définies afin d ajouter de nouveaux attributs ou de nouvelles aptitudes aux ressources de manière dynamique. Koener Hervé 36

37 OCCI Infrastructure OCCI Infrastructure est une API permettant l implémentation d une infrastructure-as-a-service en utilisant le modèle OCCI Core. Cette API étend le modèle pour permettre la création et la gestion de ressources de calcul (machine virtuelle), de stockage (disque dur virtuel) et de réseau (switch virtuel). Figure 15: OCCI Infrastructure 14 Les ressources Dans OCCI Infrastructure, il existe trois sous-types de Ressource : Compute : représente une ressource de calcul (machine virtuelle). Network : représente une ressource d interconnexion de type L2 (switch virtuel). Cette ressource peut être étendue par le Mixin IPNetwork afin de supporter les couches 3 et 4 (IP, TCP). Storage : représente une ressource de stockage de données (disque dur virtuel). Les liens Deux sous-types de Link sont définis et permettent la liaison entre les différentes ressources : StorageLink : connecte une instance de Compute à une instance de Storage. NetworkInterface : connecte une instance de Compute à une instance de Network. Ce lien peut être étendu par le Mixin IPNetworkInterface afin de supporter les couches 3 et 4 (IP, TCP) Koener Hervé 37

38 Les Mixins Afin de pouvoir supporter les couches 3 et 4 (IP, TCP) pour la ressource Networking et le lien NetworkInterface, OCCI Infrastructure définit deux instances de Mixin : IPNetworking : cette instance de Mixin permet aux ressources de type Network de supporter les couches 3 et 4 du modèle TCP/IP. IPNetworkInterface : cette instance de Mixin donne la possibilité aux ressources de type Compute d être connectées aux ressources de type Network à l aide d un lien supportant les couches 3 et 4 du modèle TCP/IP. Ces deux Mixins rajoutent trois nouveaux attributs : address : range l adresse du réseau (par exemple : /24 ou fc00::/7). gateway : adresse de la passerelle (par exemple : ou fc00::). allocation : mode d allocation des adresses (dynamic ou static). Les templates Le modèle OCCI Infrastructure définit également des Mixins permettant aux clients d appliquer rapidement et facilement des configurations aux types définis par le modèle. Ces Mixins sont appelés des templates. Il existe deux templates supportés par OCCI Infrastructure : OS Template : ce template permet à un fournisseur de spécifier quel système d exploitation doit être installé sur la ressource (par exemple : Ubuntu 10.11, Windows 7, ). Une implémentation ne supportant pas ce template ne fournit exclusivement que des ressources dénuées d environnement. Resource Template : ce template permet à un fournisseur de fournir des ressources préconfigurées (par exemple : small instance, medium instance, ). La configuration est décrite à l aide de l attribut «attributes» hérité du type Category. Koener Hervé 38

39 La figure 16 illustre une ressource de type Compute configurée à l aide des templates «OS Template» et «Resource Template». Figure 16: Exemple d'utilisation de Mixin dans OCCI Infrastructure 15 Interface HTTP OCCI utilise une API RESTful pour gérer les différentes ressources. Une interface de cette API utilise le protocole http. Chaque ressource est accessible par une URI (par l utilisation d une URL) suivant le schéma du modèle OCCI /par/ici?action=stop#xyz Schéma Autorité Chemin Requête Fragment Les opérations CRUD Les ressources sont manipulées à l aide d opérations CRUD correspondant, dans le protocole http, à l utilisation des commandes suivantes : Create : POST Retrieve : GET Update : POST/PUT Delete : DELETE 15 Koener Hervé 39

40 Le tableau 16 2 montre le comportement de l interface en fonction des commandes http utilisé. Tableau 2: comportement de l interface en fonction des commandes http Chemin GET POST POST (action Query =?action= ) Instance de ressource (/service /1) Collection de Kind (/service/) Collection de Mixin (/script_tlp/) Interface de requête (/-/) Renvoie la représentation de l instance. Renvoie une collection d instances de ressource.* Renvoie une collection d instances de ressource.* Renvoie les fonctionnalités de l implémentation.* *Supporte le mécanisme de filtrage. Met à jour partiellement l instance. Crée une nouvelle instance liée à ce Kind. Ajoute une instance de ressource à cette collection. Ajoute un Mixin défini par le client. Exécute une action. Exécute une action sur une collection d instances de ressource. Exécute une action sur une collection d instances de ressource. PUT Crée/Met à jour la ressource, en fournissant l entière représentation de celle-ci. Non défini. Met à jour la collection, en fournissant l entière représentation de celle-ci. DELETE Supprime l instance. Supprime un ensemble d instances de cette collection de Kind. Supprime un ensemble d instances de cette collection de Mixin. Non défini. Non défini. Supprime un Mixin défini par le client. L interface de requête L interface de requête permet de connaitre les aptitudes d une implémentation. Celle-ci doit être implémentée et se trouver à l emplacement «/-/». Comme décrit dans le tableau ci-dessus, un client peut récupérer tous les Mixins, Kinds et Actions à l aide de cette interface afin de pouvoir communiquer avec l implémentation. De plus, elle permet également au client de définir et de supprimer ses propres Mixins. Manipulation des Mixins, Kinds, Ressources et Links La manipulation des Mixins, Kinds, Resources et des Links se fait de la manière suivante : Example: GET /myserv/serv01 http 1.1 [commande] [URL de la cible] [version du protocole] Lorsque la commande GET est utilisée sur un ensemble de ressources, un mécanisme de filtrage peut être utilisé afin d être plus spécifique dans sa requête. 16 Ce tableau est une traduction du tableau1 du document «OCCI - RESTful HTTP Rendering» Koener Hervé 40

41 Format des données Les données transférées par une implémentation OCCI peuvent être représentées à l aide de trois formats 17 différents : text/plain: les données sont placées dans le corps du paquet : c est le format par défaut. text/occi : les données sont placées dans l en-tête du paquet et le corps doit contenir le mot «OK». text/uri-list : ce type est utilisé pour lister un ensemble de ressources (par exemple : une collection). L implémentation renverra juste une liste d url pointant vers les ressources demandées. Le client peut demander un format spécifique en ajoutant à l en-tête de la requête la ligne suivante : Accept: [nom du format] Le mécanisme de filtrage Le mécanisme de filtrage permet au client d être plus spécifique dans ses requêtes et de limiter la charge de données transférées. A l heure actuelle, le client peut uniquement filtrer les données sur base de l identifiant de catégorie (service, compute, os_tpl, ) et sur les attributs d une instance de ressource (state, ). Pour filtrer en fonction de la catégorie, le client doit fournir un identifiant valide. Pour filtrer en fonction d un attribut, le client doit fournir le nom de l attribut et une valeur pour celui-ci. Le filtre doit être au format text/occi 18. Par exemple : «X-OCCI-Attribute: state="active"». Conclusion Dans ce chapitre, j explique comment le modèle OCCI permet la résolution du problème d enfermement propriétaire (lock-in) en proposant un standard sur lequel chaque gestionnaire d infrastructure peut se baser. Néanmoins, il n existe à l heure actuelle aucune extension du modèle pour les Service Managers. Le prochain chapitre définira cette extension du modèle OCCI Core. Celleci se nomme «OCCI Service Manager». 17 Des exemples montrant l utilisation de ces formats sont disponibles dans les annexes 18 Le format text/occi est décrit dans le chapitre «Problématique» Koener Hervé 41

42 CHAPITRE III Extension d OCCI pour les Service Managers Koener Hervé 42

43 Table des matières Introduction Le modèle de données Les ressources Les liens Les Mixins Les Kinds Description des types Service AutoScalingGroup Group Dependence Rule Template Script Template Service exemple Conclusion Koener Hervé 43

44 Introduction Dans ce chapitre, je définis le modèle de données d OCCI Service Manager en me basant sur le modèle OCCI Infrastructure décrit dans le chapitre précédent. Ensuite, je détaillerai les types utilisés par OCCI Service Manager. Ce modèle est une extension d OCCI Core permettant la manipulation des services plutôt que des machines virtuelles. Tout comme OCCI Core, OCCI Service Manager se base sur l architecture REST. Afin de ne pas encombrer les tableaux, j ai décidé de remplacer l url « par «<schema>/». Le modèle de données Figure 17: Modèle OCCI Service Manager Les ressources OCCI Services manager est composé de deux principales ressources : Service : représente un service. AutoScalingGroup : représente un ensemble de ressources ayant le même rôle. Les liens OCCI Services manager définit également deux liens (sous-type de Link) afin de connecter les groupes d autoscaling avec le service ainsi que les groupes d autoscaling entre eux : Group : connecte une instance de Service à une instance d AutoScalingGroup. Dependence : connecte les instances d AutoScalingGroup entre elles pour représenter les dépendances entre les groupes. Koener Hervé 44

45 Les Mixins OCCI Service Manager définit également deux Mixins pour le type AutoScalingGroup : Script Template : permet de programmer le lancement de script au démarrage et à l arrêt d un AutoScalingGroup. Rule Template : permet au client de définir des règles d autoscaling. Les Kinds Une instance de Kind doit être assignée à chaque instance de sous-type de Resource et de Link (définit dans le modèle OCCI Core). Ces instances de Kind ne peuvent pas être modifiables et doivent être liées aux Kind de ressource ou de Link. Le tableau 3 décrit les instances de Kind de chaque ressource et lien d OCCI Service Manager. Tableau 3: Instances de Kind définis pour les ressources d'occi ServiceManager Nom Schéma Titre Kind Lié service <schema>/servicemanager# Service <schema>/core#resource autoscalinggroup <schema>/servicemanager# Groupe <schema>/core#resource d autoscaling group <schema>/servicemanager# Lien vers un groupe <schema>/core#link d autoscaling dependence <schema>/servicemanager# Dépendance entre <schema>/core#link les groupes d autoscaling script_tpl <schema>/servicemanager/autoscalinggroup# Script Mixin - rule_tpl <schema>/servicemanager/autoscalinggroup# Rule Mixin - Description des types Service Le type Service représente le service fourni au client. Service est un sous-type de Resource (défini dans le modèle OCCI Core) et est lié à l instance de Kind «<schema>/servicemanager#service». Les attributs du type Service sont décrits dans le tableau 4 : Tableau 4: Attributs du type Service Attribut Type Multiplicité Mutabilité Description occi.service.state Enum {active, inactive} 1 Immutable Etat courant du service Koener Hervé 45

46 Pour passer d un état à un autre, le modèle OCCI Service Manager définit trois actions applicables à une instance de Service : start, stop et restart. Ces actions sont définies par l instance de Kind «<schema>/servicemanager#service». De plus, chacune d entre-elles est identifiée par l instance de Category ayant comme attribut «scheme» : «<schema>/servicemanager/service/action#» et comme attribut «term» : le nom de l action (exemple : <schema>/servicemanager/service/action#start). Les actions applicables à une instance de Service sont décrites dans le tableau 5. Tableau 5: Actions applicables sur les instances de Service Nom de l action Etat cible Attributs start active - stop inactive - restart active (via stop et start) - La figure 18 illustre le diagramme d état du type Service. Figure 18: Diagramme d'état du type Service AutoScalingGroup Un service est composé de différents groupes d autoscaling ayant un certain rôle (Serveur Web, SGBD, Load Balancer). Chaque groupe d autoscaling peut correspondre à une ou plusieurs ressources. Par exemple, le groupe d autoscaling ayant le rôle de serveur web, sera composé uniquement de serveurs web. Si l on désire avoir des ressources d un autre type (par exemple, un serveur mysql) un autre groupe d autoscaling doit être créé. Tous les Mixins pouvant être associés à une ressource Compute du modèle OCCI Infrastructure, doivent pouvoir être liés aux instances d AutoScalingGroup. Ces Mixins correspondent à la configuration des différentes ressources composant ce groupe (par exemple : smallinstance, Ubuntu, ). Le type AutoScalingGroup peut également être étendu afin d automatiser l exécution de scripts, lors du démarrage et/ou à l arrêt d un rôle, à l aide du Mixin «Script Template». Le client peut également définir des règles d autoscaling à l aide du Mixin «Rule». Koener Hervé 46

47 AutoScalingGroup est un sous-type de Resource (défini dans le modèle OCCI Core) et est lié à l instance de Kind «<schema>/servicemanager#autoscalinggroup». Les attributs du type AutoScalingGroup sont décrits dans le tableau 6 : Tableau 6: Attributs du type AutoScalingGroup Attribut Type Multiplicité Mutabilité Description occi.autoscalinggroup.state Enum {active, 1 Immutable Etat courant du groupe inactive, execute} occi.autoscalinggroup.size Integer 1 Immutable Nombre d instance dans ce groupe. occi.autoscalinggroup.min Integer 1 Mutable Nombre minimal d instance occi.autoscalinggroup.max Integer 0..1 Mutable Nombre maximal d instance Pour passer d un état à un autre, le modèle OCCI Service Manager définit trois actions applicables à une instance d AutoScalingGroup : start, stop et restart. Trois autres actions sont également définies afin d exécuter des scripts et d augmenter ou de diminuer la taille du groupe : execute, increase et decrease. Ces actions sont définies par l instance de Kind «<schema>/servicemanager#autoscalinggroup». De plus, chaque action est identifiée par l instance de Category ayant comme attribut «scheme» : «<schema>/servicemanager/autoscalinggroup/action#» et comme attribut «term», le nom de l action (exemple : <schema>/servicemanager/autoscalinggroup/action#start). Celles-ci sont décrites dans le tableau 7. Tableau 7: Actions applicables sur les instances d AutoScalingGroup Nom de l action Etat cible Attributs start active - stop inactive - restart active (via stop et start) - execute aucun script = String increase aucun size = Integer decrease aucun size = Integer L action execute permet d exécuter un script bash sur chaque ressource du groupe. Les actions increase et decrease permettent de modifier le nombre d instances composant le groupe. Koener Hervé 47

48 La figure 19 illustre le diagramme d état du type AutoScalingGroup. Figure 19: Diagramme d'état du type AutoScalingGroup Group Un Service est lié à un AutoScalingGroup à l aide du type Group. Ce type de lien permet donc de savoir quels sont les groupes d autoscaling composant un service. C est un sous-type de Link (défini dans le modèle OCCI Core) et est lié à l instance de Kind «<schema>/servicemanager#group». Aucune action ni aucun attribut ne sont définis pour ce type. Dependence Les AutoScalingGroup sont reliés entre eux à l aide du type «Dependence». Celui-ci permet de représenter les dépendances entre les groupes d autoscaling (par exemple, un serveur web loadbalancé dépend d un load balancer. En effet, si ce dernier n est pas actif, le serveur web ne pourra jamais s y inscrire). Dependence est un sous-type de Link (défini dans le modèle OCCI Core) et est lié à l instance de Kind «<schema>/servicemanager#dependence». Aucune action ni aucun attribut ne sont définis pour ce type. Koener Hervé 48

49 Rule Template Rule template permet au client de spécifier des règles d autoscaling. Celui-ci s applique aux instances de type AutoScalingGroup. Rule template est une instance de Mixin (défini dans le modèle OCCI Core). Il possède obligatoirement deux attributs : scheme = «<schema>/servicemanager/autoscalinggroup#» ; term = «rule_tpl» Les attributs ajoutés par le Mixin Rule template sont décrits dans le tableau 6: Tableau 6: Attributs du Mixin AutoScaling Attribut Type Multiplicité Mutabilité Description occi.autoscalinggroup.url String 0..1 mutable Lien vers le fichier contenant les règles d extension occi.autoscalinggroup.rules String 0..1 mutable Ensemble des règles d extension Si rulesurl et rules sont fournis, seulement l attribut rules sera pris en compte. La figure 20 montre un exemple d utilisation du Mixin: rule_tpl : Mixin ws : AutoScalingGroup state = active size = 1 min = 0 max = 2 rules = "" url = term = rule_tpl scheme = /autoscalinggroup# related myrules : Mixin term = myrules scheme = Figure 20 : Diagramme d'objet d'une instance d AutoScalingGroup lié au Mixin Rule Template Les attributs en rouge ont été rajoutés par le Mixin «myrules». Koener Hervé 49

50 Script Template Script template permet au client de programmer le lancement de script au démarrage et à l arrêt d un groupe d autoscaling. Ce Mixin s applique aux instances de type AutoScalingGroup. Script Template est une instance de Mixin (défini dans le modèle OCCI Core). Il doit donc posséder deux attributs : scheme = «<schema>/servicemanager/autoscalinggroup#» ; term = «script_tpl» Les attributs ajoutés par le Mixin Script Template sont décrits dans le tableau 7 : Tableau 7: Attributs du Mixin Script Template Attribut Type Multiplicité Mutabilité Description occi.autoscalinggroup.script String 0..1 mutable Contenu du script occi.autoscalinggroup.url String 0..1 mutable Url vers le script occi.autoscalinggroup.type Enum {boot, 0..1 mutable Type du script operational, decommission} Si les attributs url et script sont fournis, seulement l attribut script sera pris en compte. Lorsqu une implémentation nécessite des attributs supplémentaires pour l exécution du script, cela peut être réalisé en utilisant l attribut «attributes» hérité du type Category. OCCI ServiceManager définit deux types d attributs pouvant être appliqués à un Script Template défini par l implémentation : Les attributs fixes : attributs ayant une valeur fixe (exemple : port = 80). Les attributs liés : attributs ayant une valeur en fonction d un attribut d un rôle lié à un certain mixin. Le mot clé Mx suivi du mixin et de l attribut sera entouré de crochets. Le mixin et l attribut doivent être séparés par une virgule. (exemple : iplb = Mx[ IP]) Une erreur sera envoyée au client OCCI si aucune dépendance de ce groupe (via un lien «Dependence») n est liée au Mixin défini par cet attribut. Koener Hervé 50

51 La figure 21 montre un exemple d utilisation du Template: script_tpl : Mixin ws : AutoScalingGroup state = active size = 1 min = 0 max = 2 script = "" url = type = boot iplb = Mx[ address] term = script_tpl scheme = autoscalinggroup# related apache : Mixin term = apachelb scheme = Figure 21:Diagramme d'objet d'une instance de Role lié au Mixin Script Template Les attributs en rouge ont été rajoutés par le Mixin «apache». Comme vous pouvez le voir ci-dessus, le Mixin «apache» a rajouté l attribut iplb par rapport au Mixin «script_tpl». Cet attribut sera utilisé pour inscrire les serveurs apache au load balancer. Service exemple Notre service exemple composé d un ensemble de serveurs webs (apache + php) reliés à un SGBD (MySQL) et un load balancer (nginx) peut être représenté à l aide du modèle OCCI Service Manager. Si la topologie du service est comme suit : Load balancer Serveurs web SGBD Figure 22:Description du service exemple Koener Hervé 51

52 La structure sur service exemple sera comme sur la figure 23. state = active Serv1 : Service g1 : Group g2 : Group g3 : Group loadbalancer : AutoScalingGroup state = active size = 1 min = 1 max = 1 webserver : AutoScalingGroup state = active size = 3 min = 1 max = 3 state = active size = 1 min = 1 max = 1 sgbd : AutoScalingGroup d1 : Dependence d2 : Dependence Figure 23: Structure du service exemple 19 Conclusion Dans ce chapitre, je définis l extension d OCCI Core pour le Service Manager. Celui-ci permet de faire abstraction des machines virtuelles et de manipuler des services ou des groupes d autoscaling. Ces derniers représentent des ensembles de machines virtuelles ayant un même rôle. L extension OCCI Service Manager hérite des différentes caractéristiques d OCCI Core comme le mécanisme de découverte des ressources. L interface http d OCCI Service Manager est la même que celle d OCCI Infrastructure. Les ressources peuvent donc être manipulées à l aide des verbes http : GET, POST, PUT et DELETE. La dernière partie de ce chapitre explique comment OCCI Service Manager pourrait être utilisé afin de créer un petit service composé de serveur web, d un load balancer et d une base de données. 19 La représentation complète du service exemple est disponible en annexes. Koener Hervé 52

53 CHAPITRE IV Conception du Service Manager Koener Hervé 53

54 Table des matières Introduction Les cas d utilisation Diagrammes de séquence Lister les fonctionnalités du Service Manager Créer une ressource Lier une ressource à une autre Lier une ou plusieurs ressources à un mixin Exécuter une action sur une ressource La base de données Le diagramme de classe Le modèle La vue Le contrôleur Les classes internes Conclusion Koener Hervé 54

55 Introduction Ce chapitre se focalise sur la conception du Service Manager. J y énumère les différents cas d utilisation de celui-ci et j explique les principaux cas à l aide de diagrammes de séquence. Je décris également la structure de la base de données à l aide de deux diagrammes. Enfin, je conclus ce chapitre en décrivant la structure de l application à l aide d un diagramme de classe. Les cas d utilisation Le Service Manager doit permettre à l utilisateur de définir puis de démarrer un service à l aide de requête http conforme à l interface http d OCCI Service Manager. La liste complète des cas d utilisation du Service Manager 20 est disponible dans le tableau 8. Tableau 8: Liste complète des cas d'utilisation du Service Manager Nom du cas d utilisation Lister les fonctionnalités du Service Manager Créer une ressource Détailler une ressource Supprimer une ressource Mise à jour partielle d une ressource Mise à jour complète d une ressource Exécuter une action sur une ressource Lier une ressource à une autre Lister les ressources d un certain type (kind) Supprimer toutes les ressources d un certain type (kind) Supprimer une ou plusieurs ressources d un certain type (kind) Mise à jour complète d une ou plusieurs ressources d un certain type (kind) Exécuter une action sur une ou plusieurs ressources d un certain type (kind) Lier une ou plusieurs ressources à un mixin Lister les ressources liées à un mixin Supprimer tous les mixins utilisateur Supprimer un ou plusieurs mixins utilisateur Mise à jour complète d une ou plusieurs ressources liées à un mixin Exécuter une action sur une ou plusieurs ressources liées à un mixin Dans la liste des cas d utilisation, une ressource peut être de type «service», «autoscalinggroup», «group» ou «dependence». 20 L explication détaillée des cas d utilisation ainsi que le diagramme UML complet est disponible dans les annexes Koener Hervé 55

56 Diagrammes de séquence Je vais maintenant décrire les principaux cas d utilisations 21 à l aide de diagrammes de séquence. Ceux-ci permettent de créer et de gérer des services tels que le service exemple utilisé tout au long de ce mémoire. Lister les fonctionnalités du Service Manager La première fonctionnalité consiste à afficher les fonctionnalités du Service Manager. Celui-ci, envoie la liste des mixins, des types de ressources (kind) ainsi que des actions pouvant être appliquées sur celles-ci. La figure 24 illustre le diagramme de séquence UML de ce cas d utilisation. Figure 24: Diagramme de séquence: Lister les fonctionnalités L utilisateur utilise la fonctionnalité en envoyant une requête html «GET» à l adresse «/-/». Lorsque l application principale reçoit la requête, elle envoie un message show à l objet de classe «RequestInterface_Controler». Ce dernier appelle la méthode getlist des différents managers. Les managers génèrent la liste demandée en communiquant avec la base de données. Lorsque les différentes listes sont reçues par l objet de classe «RequestInterface_Controler», celuici construit la réponse et l envoie à l application principale qui l envoie à l utilisateur. 21 La liste complète des diagrammes de séquence est disponible dans les annexes Koener Hervé 56

57 Créer une ressource Une des fonctionnalités principales consiste à créer une nouvelle ressource. Pour utiliser cette fonctionnalité, l utilisateur doit envoyer la représentation de la ressource à créer. La figure 25 illustre le diagramme de séquence UML de ce cas d utilisation. Figure 25: Diagramme de séquence: Créer une ressource L utilisateur utilise la fonctionnalité en envoyant une requête html «PUT» à l adresse correspondant au type de la ressource (par exemple : /service/). Lorsque l application principale reçoit la requête, elle envoie un message create à l objet de classe «Resource_Controler» (où Resource correspond au type de la ressource par exemple : «Service_Controler»). Ce dernier vérifie la validité de la requête et appelle la méthode create du manager correspondant à la ressource à créer. Le manager crée alors la ressource en l ajoutant dans la base de données. Enfin, l objet de classe «Resource _Controler» (où Resource correspond au type de la ressource par exemple, «Service_Controler»), appelle la méthode show du manager. La réponse envoyée par le manager servira à construire la réponse qui sera envoyée à l application principale et ensuite à l utilisateur. Koener Hervé 57

58 Lier une ressource à une autre Ici, l utilisateur souhaite lier un service et un groupe d autoscaling. Celui-ci envoie une requête http «PUT» à l application principale. Le traitement de la requête se fait de la même manière que pour créer une ressource. Un message create envoyé à l objet de classe «Link_Controler» (où Link correspond au type de lien par exemple, «Group_Controler»). Ce dernier vérifie la validité de la requête et appelle la méthode create du manager correspondant au lien à créer. Le manager crée alors le lien en l ajoutant dans la base de données. Finalement, l objet de classe «Link_Controler» (où Link correspond au type de lien par exemple, «Group_Controler»), appelle la méthode show du manager. Les données envoyées par le manager servent à construire la réponse destinée à l utilisateur. Celle-ci est retournée à l application principale qui se charge de l envoyer à l utilisateur. La figure 26 illustre le diagramme de séquence UML de ce cas d utilisation. Figure 26: Diagramme de séquence: Lier une ressource à une autre Koener Hervé 58

59 Lier une ou plusieurs ressources à un mixin Une autre fonctionnalité importante est l association d une ressource (ou un lien) à un mixin. Pour ce faire, l utilisateur envoie une requête http «POST» transportant dans son corps la liste des ressources à associer à ce mixin. Un message «add» est ensuite envoyé au Mixin_Controler qui vérifie la validité de la requête et envoie un message «add» au Mixin_Manager. Celui-ci, lie les différentes ressources dans la base de données. La figure 27 illustre le diagramme de séquence UML de ce cas d utilisation. Figure 27: Diagramme de séquence: lier une ou plusieurs ressources à un mixin Koener Hervé 59

60 Exécuter une action sur une ressource L utilisateur envoie une requête http «POST», s il désire exécuter une action sur une ressource. Si l action nécessite un paramètre pour être exécutée, celui-ci doit se trouver dans le corps de la requête (par exemple, l action increase a besoin de connaitre le nombre d instances de vm à rajouter). La requête est reçue par l application principale et celle-ci appelle la méthode «action» du contrôleur de la ressource. Ce dernier vérifie la requête envoyée par l utilisateur et appelle la méthode «action» du Manager de la ressource. Celui-ci exécute l action en manipulant l API d OpenNebula (pour la méthode start par exemple) et en communiquant avec la base de données. La réponse est alors générée par le contrôleur et est envoyée à l utilisateur par l application principale. La figure 28 illustre le diagramme de séquence UML de ce cas d utilisation. Figure 28: Diagramme de séquence: Exécuter une action sur une ressource Koener Hervé 60

61 La base de données Les données internes du Service Manager sont stockées dans une base de données. Celle-ci est conçue sur le modèle OCCI Service Manager. Elle contient les différentes informations sur les services et les groupes d autoscaling composant ceux-ci. La base de données garde en mémoire les adresses des différentes machines virtuelles et permet de savoir à quel groupe d autoscaling elles appartiennent. Le diagramme de base de données simplifié 22 décrivant les liens entre les différentes ressources est illustré par la figure 29. Figure 29: Diagramme de base de données simplifié: description des liens entre les différentes ressources Comme nous pouvons le voir sur la figure 29, la table «group» lie les groupes d autoscaling aux services. La table «dependence», quant à elle, lie les groupes d autoscaling entre eux afin de représenter la dépendance d un groupe vers un autre. Nous pouvons également remarquer que chaque groupe d autoscaling contient zéro ou plusieurs machines virtuelles. Dans le diagramme complet, disponible dans les annexes, nous remarquons que nous ne gardons que les adresses (URL) des machines virtuelles. Celles-ci seront utilisées lors de la communication avec l api OpenNebula. 22 Le diagramme de classe complet est disponible dans les annexes. Koener Hervé 61

62 Comme spécifié dans le modèle OCCI Core, la table catégorie représente le type des actions. Une action peut être associée à un Kind et/ou à un ou plusieurs Mixins. Chaque ressource est liée à zéro ou plusieurs mixins à l aide d une table qui porte le nom de: «nom de la ressource»_extension. Le diagramme de base de données simplifié 23 décrivant les liens entre les ressources les mixins est illustré par la figure 30. Figure 30: Diagramme de base de données simplifié: lien entre les ressources et les mixins Comme nous pouvons le voir sur la figure 30, les mixins sont reliés entre eux à l aide de la table «mixin_relation». Ce lien permet de créer des mixins à partir des templates du modèle OCCI Service Manager. Chaque mixin est associé à un kind qui permet de savoir quel type de ressource peut être lié à un mixin. Une ressource peut être liée à un mixin s ils sont tous deux associés au même kind. 23 Le diagramme de classe complet est disponible dans les annexes. Koener Hervé 62

63 Le diagramme de classe Pour concevoir le Service Manager, j ai utilisé le patron d architecture intitulé «Modèle Vue Contrôleur». Mes classes sont donc divisées en fonction de leur rôle : Modèle : représente et manipule le modèle de données. Vue : génère la réponse envoyée par le Service Manager. Contrôleur : manipule le modèle afin de générer la vue. Le modèle Le modèle du Service Manager est constitué de classes qui manipulent la base de données et de celles qui représentent les données internes du Service Manager. La structure du modèle permet une extensibilité aisée du Service Manager (par exemple : l utilisation d un autre système de gestion de base de données ne nécessite pas la modification de toutes les classes manipulant le modèle. Seules les classes de type Manager devront être modifiées 24 ). Le diagramme de classe représentant le modèle de manière simplifiée 25 est illustré par la figure 31. Figure 31: Diagramme de classe simplifié (vue) 24 Ces classes devront être modifiées car celles-ci exécutent les requêtes SQL permettant de générer le modèle. 25 Le diagramme de classe complet est disponible dans les annexes. Koener Hervé 63

64 La vue La vue consiste en un ensemble de fichiers ERB permettant de générer le corps de la réponse http envoyé au client. Il existe deux types de fichiers : Les fichiers générant la vue lorsque l utilisateur demande une réponse de type «text/plain» Les fichiers générant la vue lorsque l utilisateur demande une réponse de type «text/occi» Afin de faciliter la lecture des réponses du Service Manager lors des tests, le corps de celles-ci est au format html. Le contrôleur Le contrôleur du Service Manager contient les classes ayant les rôles suivants : Vérifier la validité des requêtes envoyées par le client. Manipuler le modèle en fonction des requêtes du client. Générer la vue en fonction du modèle. Le diagramme de classe représentant le contrôleur de manière simplifiée 26 est illustré par la figure 32. Figure 32: Diagramme de classe simplifié (contrôleur) 26 Le diagramme de classe complet est disponible dans les annexes. Koener Hervé 64

65 Les classes internes Le groupe classes internes est composé des classes qui représentent les exceptions envoyées par le Service Manager. Il est également composé de la classe principale (App), de la classe qui gère la connexion avec la base de données, celle qui permet l exécution de scripts sur les machines virtuelles et de celle qui permet de vérifier les données envoyées par le client. Les exceptions du Service Manager sont divisées en quatre groupes : Les erreurs causées par une erreur interne (par exemple un problème de connexion à la base de données). Les erreurs envoyées lorsque l utilisateur oublie un paramètre lors de l envoi d une requête. Les erreurs envoyées lorsque l utilisateur tente d exécuter une action qui est interdite. Les erreurs envoyées lorsque l utilisateur tente d accéder à une donnée qui est inconnue par le Service Manager. Le diagramme de classe représentant les classes internes de manière simplifiée 27 est illustré par la figure 33. Figure 33: Diagramme de classe simplifié des classes internes Conclusion Ce chapitre nous permet de connaître les fonctionnalités, la structure et les rôles de chaque classe composant le Service Manager. Je décris également la structure de la base de données afin de savoir quel type d information elle contient. Le prochain chapitre se focalise sur l implémentation du Service Manager. 27 Le diagramme de classe complet est disponible dans les annexes. Koener Hervé 65

66 CHAPITRE V Implémentation du Service Manager Koener Hervé 66

67 Table des matières Introduction Technologies utilisées Prérequis Arborescence du Service Manager Manipulation du Service Manager Instanciation et manipulation du service exemple Instanciation du load balancer Instanciation du SGBD Instanciation des Serveurs Webs Instanciation du service Exécution d action Manipulation de l API d OpenNebula Représentation des ressources Authentification de l utilisateur Manipulation des ressources Modification de l état d une ressource Exécution des scripts sur les machines virtuelles Sécurité Conclusion Koener Hervé 67

68 Introduction Dans ce chapitre, je parle de la conception du Service Manager et des technologies utilisées. Ensuite, je décris l arborescence de l application et j explique la manière de manipuler le Service Manager afin d instancier le service exemple et d appliquer des actions sur ses ressources. Les dernières parties de ce chapitre concernent la manipulation de l API OCCI d OpenNebula ainsi que le mécanisme utilisé pour exécuter des scripts sur les machines virtuelles (par exemple pour installer Apache 2 sur les serveurs web). Technologies utilisées Les principales technologies utilisées pour concevoir le Service Manager sont : Ruby, Sinatra, Mysql, erb et git. La principale raison pour laquelle, j ai décidé d implémenter le Service Manager en Ruby à l aide du Framework Sinatra 28 est qu OpenNebula est lui-même codé en ruby et que son API OCCI utilise le Framework Sinatra. De plus Sinatra étant un Framework minimaliste (contrairement à Ruby on Rails), il permet de créer très facilement des applications web. Concernant la base de données, mon application utilise Mysql. J ai choisi cette base de données car elle fournit un bon compromis entre complexité et performance (La complexité du Service Manager ne nécessite pas une base de données Oracle). Erb est utilisé afin de générer la vue du Service Manager qui sera envoyé à l utilisateur. Git est un logiciel de gestion des versions open source. J ai utilisé ce programme avec GitHub afin de pouvoir avoir accès au code du Service Manager à partir d internet. Prérequis Pour fonctionner, le Service Manager nécessite qu OpenNebula soit installé 29. Une image de machine virtuelle est fournie avec l application. L utilisateur peut utiliser sa propre image contextualisée 30 à condition de créer un mixin utilisateur et de le lier au mixin OS template. Le Service Manager nécessite également que Mysql soit installé sur la machine hôte (afin de pouvoir créer la base de données du Service Manager) ainsi que la commande curl (afin de pouvoir communiquer avec l API OCCI d OpenNebula). L application requièrt également les gems suivantes pour pouvoir fonctionner : curb nokogiri Afin de faciliter l installation et l utilisation du service Manager, un fichier README et un script bash d installation sont disponibles dans la racine du projet. 28 Plus d information sur ce Framework sur 29 Un document expliquant la marche à suivre pour installer OpenNebula est disponible dans les annexes. 30 Un document expliquant comment créer sa propre image de machine virtuelle est disponible dans les annexes Koener Hervé 68

69 Arborescence du Service Manager Le tableau 9 décrit l arborescence simplifiée 31 des dossiers du Service Manager. Tableau 9: Arborescence du Service Manager Dossiers/Fichiers Description / Racine du Service Manager config.ru Fichier de configuration du Service Manager INSTALL Fichier d installation du Service Manager readme Fichier expliquant comment installer et démarrer le Service Manager RUN Fichier de démarrage du Service Manager service_manager.sql Fichier SQL contenant les tables de la base de données controlers Dossiers contenant les fichiers permettant de générer la vue du Service Manager images Dossier contenant les images des systèmes d exploitation pouvant être installés sur les vms context Dossier contenant les scripts permettant l exécution de commandes sur les vms lib Dossier contenant les fichiers de librairie du Service Manager exceptions Dossier contenant les exceptions models Dossier contenant les fichiers représentant le modèle de l application mysql Dossier contenant les classes permettant la communication avec la base de données mysql OpenNebula Dossier contenant les classes permettant la communication avec OpenNebula Comme vous pouvez le voir sur le tableau 9, des fonctionnalités peuvent être facilement rajoutées. Par exemple, pour utiliser un autre type de base de données, il suffit de créer un nouveau dossier contenant les fichiers permettant la communication avec la base de données, le placer dans le dossier models et ensuite modifier le fichier de configuration (config.ru) afin que l application utilise ce nouveau type de base de données 32. Pour que le Service Manager communique avec une autre API, il faut créer un dossier contenant les fichiers permettant la communication avec l API, le mettre dans le dossier models et modifier le fichier de configuration 33 (config.ru). D autres fonctionnalités peuvent également être rajoutées en modifiant à la fois les fichiers contenus dans le dossier «controlers» et le fichier app.rb qui se trouve dans le dossier lib. 31 L Arborescence complète est disponible dans les annexes 32 Modifier la ligne «SGBD» 33 Modifier la ligne «Infrastructure_Manager» Koener Hervé 69

70 Manipulation du Service Manager Quand le Service Manager est démarré, celui-ci peut être manipulé à l aide de la commande curl ou d un navigateur web. Pour cela, l utilisateur lui envoie des requêtes http. En fonction du verbe http et de l url de celle-ci, une fonctionnalité spécifique sera exécutée. Par exemple, l envoi d une requête contenant le verbe GET sur l url /service/ listera les différents services alors que l utilisation du verbe DELETE sur cette même adresse supprimera tous les services. Il existe quatre types d url supportés par l API : /-/ : permet de manipuler l interface de requêtes /[type de ressource]/ : permet de manipuler des ressources/liens d un certain type /[type de ressource]/[id de le ressource] : permet de manipuler une ressource/lien spécifique /[type du mixin]/[nom du mixin] : permet de manipuler un ensemble de ressources/liens liés à un certain mixin. (les ressources/liens liés à un mixin, doivent être de même type que le type du mixin) En fonction des verbes http utilisés, les ressources pourront être listées, modifiées, supprimées ou créées. Des actions pourront également être exécutées sur les ressources ou les ensembles de ressources à l aide de la variable get action (exemple : /service/1?action=start) Instanciation et manipulation du service exemple Nous allons instancier dans le Service Manager notre service exemple, composé d un ensemble de serveurs webs (apache + php) reliés à un SGBD (MySQL) et un load balancer (nginx). Si la topologie du service est comme suit : Load balancer Serveurs web SGBD Figure 34 : Description du service exemple Koener Hervé 70

71 Instanciation du load balancer Lors de l instanciation des ressources, nous allons directement les associer à leur mixin respectif 34. Pour instancier le load balancer, exécutons la commande de la figure 35. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: ubuntu; scheme=" class="mixin"; Category: small; scheme=" class="mixin"; Category: nginx; scheme=" class="mixin"; X-OCCI-Attribute: occi.core.title = "Loadbalancer" X-OCCI-Attribute: occi.core.summary = "" X-OCCI-Attribute: occi.autoscalinggroup.size = 1 X-OCCI-Attribute: occi.autoscalinggroup.min = 1 X-OCCI-Attribute: occi.autoscalinggroup.max = 1' Figure 35: Instanciation du loadbalancer Instanciation du SGBD Pour instancier le SGBD, exécutons la commande de la figure 36. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: ubuntu; scheme=" class="mixin"; Category: small; scheme=" class="mixin"; Category: mysql; scheme=" class="mixin"; X-OCCI-Attribute: occi.core.title = "SGBD" X-OCCI-Attribute: occi.core.summary = "" X-OCCI-Attribute: occi.autoscalinggroup.size = 1 X-OCCI-Attribute: occi.autoscalinggroup.min = 1 X-OCCI-Attribute: occi.autoscalinggroup.max = 1' Figure 36: Instanciation du Système de gestion de base de données 34 L association des ressources au mixin pourrait être fait par après à l aide de la commande suivante : curl -d "X-OCCI-Location: Koener Hervé 71

72 Instanciation des Serveurs Webs Lors de l instanciation de l autoscaling group «serveur web», nous allons associer ce groupe aux deux autres (load balancer, SGBD), cela aura pour effet de créer deux liens de type Dependence. Ces liens auront pour but de permettre la récupération d informations sur les autres groupes (par exemple, l ip du load balancer pour pouvoir inscrire les serveurs web à celui-ci). Pour instancier le groupe contenant les serveurs web, exécutons la commande de la figure 37. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: ubuntu; scheme=" class="mixin"; Category: small; scheme=" class="mixin"; Category: apachelb; scheme=" class="mixin"; Link: </autoscalinggroup/1>; rel=" category=" Link: </autoscalinggroup/2>; rel=" category=" X-OCCI-Attribute: occi.core.title = "Serveur Web" X-OCCI-Attribute: occi.core.summary = "" X-OCCI-Attribute: occi.autoscalinggroup.size = 1 X-OCCI-Attribute: occi.autoscalinggroup.min = 1 X-OCCI-Attribute: occi.autoscalinggroup.max = 3' Figure 37: Instanciation des serveurs web Koener Hervé 72

73 Instanciation du service Comme pour le groupe contenant les serveurs web, nous allons lier le service aux différents groupes lors de l instanciation de celui-ci. Les liens ne seront plus de type Dependence mais de type Group. Pour instancier le service, exécutons la commande de la figure 38. $ curl -X POST -d 'Category: service; scheme=" class="kind"; Link: </autoscalinggroup/1>; rel=" category=" Link: </autoscalinggroup/2>; rel=" category=" Link: </autoscalinggroup/3>; rel=" category=" X-OCCI-Attribute: occi.core.title = "Service 1" X-OCCI-Attribute: occi.core.summary = "Service exemple"' Figure 38: Instanciation du service Exécution d action Pour démarrer le service, il nous suffit d exécuter la commande de la figure 39. Celle-ci démarre les différentes machines virtuelles du service et exécute les scripts spécifiés à l aide des mixins. $ curl -X POST Figure 39: Démarrage du service La figure 40 montre comment arrêter le service. Cette commande a pour effet d exécuter les scripts d arrêt (decommission) et d arrêter les vms. $ curl -X POST Figure 40: Arrêt du service Des actions peuvent également être exécutées sur des ressources de type autoscalinggroup. Par exemple, nous pouvons augmenter et diminuer le nombre de machines virtuelles dans le groupe. La figure 41 montre comment augmenter le nombre de machines virtuelles dans un groupe d autoscaling. $ curl -X POST -d 'X-OCCI-Attribute: size = 1' Figure 41: Agrandissement du groupe d'autoscaling Koener Hervé 73

74 La figure 42 montre comment diminuer le nombre de machines virtuelles dans un groupe d autoscaling. $ curl -X POST -d 'X-OCCI-Attribute: size = 1' Figure 42: Réduction du groupe d'autoscaling Manipulation de l API d OpenNebula L API OCCI d OpenNebula permet à un client OCCI de manipuler les différentes ressources (Storage, Compute, Network). L API peut être manipulée de deux manières différentes : En utilisant les commandes fournies par OCCI-Server ; En envoyant des requêtes http ; Le Service Manager manipule l API OCCI d OpenNebula à l aide de requêtes http. Je n expliquerai donc dans ce document que la manipulation utilisant les requêtes http 35. Représentation des ressources Dans OpenNebula, les ressources sont représentées sous le format XML. La figure 43 illustre la représentation d une ressource de type Compute. <COMPUTE href=' <ID>1</ID> <CPU>0.5</CPU> <MEMORY>512</MEMORY> <NAME>VM1</NAME> <STATE>ACTIVE</STATE> <DISK id='0'> <STORAGE href=' name='tinylinux'/> <TYPE>DISK</TYPE> <TARGET>hda</TARGET> </DISK> <NIC> <NETWORK href=' name='lan'/> <IP> </IP> <MAC>02:00:c0:a8:02:01</MAC> </NIC> </COMPUTE> Figure 43: Représentation d'une ressource de type Compute Authentification de l utilisateur Lors de l utilisation d une commande ou l envoi d une requête, l utilisateur doit s identifier. Lors de l envoi de requête http, le client doit fournir : son nom d utilisateur ainsi que le hash CHA1 de son mot de passe utilisateur. 35 Un document expliquant en détail toutes les manières de manipuler l API d OpenNebula est disponible dans les annexes. Koener Hervé 74

75 Manipulation des ressources L interface de requête http de l API OCCI d OpenNebula peut être manipulée à l aide des verbes http. Les requêtes peuvent être envoyées vers une adresse représentant, un ou plusieurs types d instance de vm, un ou plusieurs utilisateurs, un ensemble de ressources ou une ressource particulière. L affichage des différentes collections peut être demandé à l aide du verbe http «GET» sur l url «/». La manipulation d un ou plusieurs types d instance de vm et d un ou plusieurs utilisateurs peut être réalisée à l aide du verbe http «GET». Si celui-ci est appliqué à un ensemble d éléments, l API renverra la liste des éléments de cet ensemble. Si «GET» est appliqué à un seul élément, l API renverra la représentation de l élément demandé. $ curl --user "oneadmin:7bc8559a8fe509e680562b85c337f956fcb06" <USER_COLLECTION> <USER href=" name="oneadmin"/> <USER href=" name="serveradmin"/> </USER_COLLECTION> Figure 44: Envoi d une requête GET sur l ensemble des utilisateurs La manipulation d un ensemble de ressources peut être réalisée à l aide des verbes http suivants : GET : permet de lister toutes les ressources d un même type. POST : permet de créer une nouvelle ressource. Il faut alors fournir la représentation de la ressource en format XML. La figure 45 montre l envoi d une requête GET sur l ensemble de ressources de type Compute. $ curl --user "oneadmin:7bc8559a8fe509e680562b85c337f170956fcb06" <COMPUTE_COLLECTION> <COMPUTE href=" name="vm1"/> </COMPUTE_COLLECTION> Figure 45: Envoi d une requête GET sur l ensemble de ressources de type Compute La manipulation d une ressource particulière peut être réalisée à l aide des verbes http suivants : GET : permet de récupérer la représentation d une ressource. PUT : permet de mettre à jour une ressource. Il faut alors fournir la représentation de la ressource en format XML. DELETE : permet de supprimer une ressource. Koener Hervé 75

76 La figure 46 montre l envoi d une requête DELETE sur une des ressources de type Compute. $ curl X DELETE --user "oneadmin:7bc8559a8fe509e680562b85c337f170956fcb06" Figure 46: Envoi d une requête DELETE sur une de ressource de type Compute Modification de l état d une ressource La modification de l état d une ressource de type Compute, se fait à l aide du mécanisme de mise à jour des ressources («occi-compute update» pour l interface de commande et l utilisation du verbe POST pour l interface de requêtes http). Pour modifier l état d une ressource de type Compute on peut lui appliquer les actions suivantes : done, shutdown, cancel, resume, suspended, stopped et reboot. La figure 47 illustre le passage d un état à un autre en fonction de l action appliquée à la vm. INIT Reboot Shutdown Cancel Done DONE PENDING ACTIVE Resume Suspended SUSPENDED Stopped HOLD Resume STOPPED Figure 47: Etats d'une ressource de type Compute La figure 48 montre la modification de l état d une ressource de type compute à l aide de l interface http de l API OCCI d OpenNebula. $ curl T "<COMPUTE href=' COMPUTE>" --user "oneadmin:7bc8559a8fe509e680562b85c337f170956fcb06" Figure 48: Modification de l'état d'une ressource Koener Hervé 76

77 Exécution des scripts sur les machines virtuelles L exécution des scripts sur les machines virtuelles se fait à l aide d un script écrit en Ruby permettant d écouter des requêtes TCP sur le port 3333 de la machine. Les commandes contenues dans la requête sont alors exécutées sur la machine. Le script Ruby étant exécuté lors du processus de contextualisation de la machine virtuelle, toutes les commandes envoyées au service sont exécutées avec les privilèges «root». Sécurité Afin de vérifier les données envoyées par l utilisateur, j utilise différentes expressions régulières. Celles-ci augmentent également la robustesse du Service Manager en permettant à l utilisateur d ajouter ou non différents caractères d espacement entre les données nécessaires à l exécution d une fonctionnalité. Pour éviter les injections SQL, le Service Manager utilise des requêtes SQL paramétrées. Ainsi, c est le SGBD qui se charge d échapper les caractères en fonction du type de paramètre de la requête. L utilisation de requêtes SQL paramétrées, permet également d améliorer les performances lors de l envoi d une série de requêtes similaire au SGBD. J ai réalisé différents tests 36 afin de vérifier la robustesse du Service Manager. Ces tests montrent que seules les données valides et utiles au Service Manager sont prises en compte. Les erreurs provoquées par les requêtes invalides sont enregistrées dans un fichier de log se trouvant à la racine du projet. Conclusion A travers ce chapitre, je vous explique comment manipuler le Service Manager. Je fournis également des explications sur la communication entre l application et OpenNebula. Cette application montre comment OCCI Service Manager peut être implémentée. Celle-ci peut facilement être modifiée afin de manipuler d autres API tel que celle fournie par EC2 (il faudrait juste modifier le fichier «vm_manager.rb»). 36 Un document décrivant en détail les tests effectués est disponible dans les annexes Koener Hervé 77

78 CONCLUSION Koener Hervé 78

79 En parcourant cet ouvrage, vous avez pu découvrir la démarche réalisée afin de proposer une solution afin de résoudre le problème d enfermement propriétaire (Vendor Lock-in) pour les Services Manager. J ai également expliqué la conception et l implémentation d un Service Manager développé à partir du modèle OCCI Service Manager. Je l ai finalement testé à l aide d un exemple de service. Je vais maintenant vous parler des principaux problèmes rencontrés mais aussi comment les résoudres. Je décrirai ensuite les différentes évolutions possibles de l application et je conclurai par l appréciation du projet. Problèmes rencontrés Je décris ci-après les principaux problèmes rencontrés lors de la réalisation de ce projet. Lorsque j ai commencé le projet, je n avais aucune connaissance dans le domaine du cloud computing. J ai alors décidé de me documenter sur les sujets se rapportant à ce domaine. Cela m a permis d acquérir une base théorique afin de mieux appréhender le problème d enfermement propriétaire. J ai ensuite été confronté au fait que je n avais pas de connaissance en Ruby. Je me suis alors entrainé à développer de petits programmes tout en lisant la documentation disponible sur internet. J ai également eu différents problèmes lors de la manipulation d OpenNebula. En effet, la documentation disponible sur le site internet d OpenNebula 37 ne correspondait pas à la version téléchargeable via l APT 38 de Linux. De plus, la version que j utilisais ne disposait pas de toutes les fonctionnalités requises afin de faire fonctionner mon Service Manager. J ai résolu ce problème en téléchargeant directement les sources sur le site internet d OpenNebula et en l installant manuellement. J ai également perdu du temps lorsque j ai voulu enregistrer une image de machine virtuelle à l aide de l API d OpenNebula. Celle-ci nécessitait de mettre la description de l image dans une variable POST nommé «occixml» et d envoyer le fichier contenant l image dans une variable portant le nom de «file». J ai découvert cette solution en recherchant dans les listes de diffusion d OpenNebula et en regardant dans le code source d OpenNebula. Lorsque j ai commencé à démarrer des machines virtuelles en manipulant l API d OpenNebula, j utilisais une image disponible sur leur site : «ttinylinux.img». Cependant, lorsque j ai voulu permettre l exécution de script sur les vms, la taille disponible sur l image (41 Mb) était trop petite pour installer un programme tel qu Apache2. J ai résolu ce problème en créant mes propres images 39 à partir d un fichier iso téléchargé sur internet. J ai cependant eu un problème pour contextualiser ces VMs : une fois démarrées, celles-ci n étaient pas joignables 40. En recherchant sur internet, j ai découvert que le problème était causé par l attribution automatique de l adresse IP à partir de l adresse MAC. Pour résoudre ce problème, j ai supprimé les fichiers permettant cette attribution Advanced Packaging Tool 39 J ai utilisé des images d ubuntu server La commande ping ne fonctionnait pas. Koener Hervé 79

80 Evolution possible du Service Manager Le Service Manager pourrait être étendu afin d être compatible avec d autres gestionnaires d infrastructure tels qu AWS EC2. Cela pourrait être réalisé en créant un dossier contenant les fichiers permettant la communication avec la nouvelle API, le mettre dans le dossier models et modifier le fichier de configuration 41 (config.ru). Jusqu à présent, le Service Manager ne permet toujours pas d instancier des services auto extensibles. Cette fonctionnalité pourrait être rajoutée en ajoutant le mixin Rule template tel que défini dans le modèle OCCI Service Manager. Il faut également créer un script communiquant avec une application permettant la surveillance de système tel que Nagios. Ce script pourrait envoyer des requêtes au Service Manager lorsque, par exemple, la charge CPU d une vm serait trop élevée. Il faudrait également modifier la classe «autoscalinggroup_manager» afin d activer cette fonctionnalité au démarrage du groupe d autoscaling. Une autre fonctionnalité pouvant être rajoutée, est celle permettant le filtrage des données envoyées par le serveur notamment lorsque l utilisateur désire lister les ressources d un certain type. On pourrait également développer une interface graphique permettant de manipuler plus aisément le Service Manager. Je n ai pas jugé utile d implémenter une telle interface car celle-ci n est pas nécessaire pour valider le modèle OCCI Service Manager. Appréciation du projet La réalisation des différentes fonctionnalités a exigé de la détermination, du courage et de la persévérance. Pour faciliter la réalisation du projet, j ai établi un planning 42. Celui-ci m a permis de gérer mon temps afin de finir le projet avant la date de remise du mémoire. Durant les mois de février à avril, j ai accumulé une semaine de retard sur le planning. J ai cependant résorbé ce retard, en rédigeant le mémoire pendant la réalisation du projet. Ce mémoire m a donc énormément appris sur la gestion de projet de longue haleine. J ai notamment appris comment aménager mon temps de travail afin de réaliser au mieux le projet. Ce projet m a appris beaucoup de choses dans le domaine du cloud computing. J ai appris notamment, comment créer et manipuler des machines virtuelles. J ai également appris le fonctionnement des principaux Service Managers tel qu AWS CloudFormation et RightScale. Pour réaliser ce projet, j ai aussi appris à me servir d un nouveau langage de programmation : «ruby». Celui-ci m a été très utile pour implémenter le Service Manager, même s il manque certains mécanismes orientés objets tels que les classes abstraites et les interfaces. Le projet m a aussi permis de mettre en pratique tous les principes appris durant mes études. Une des choses les plus importantes que j ai apprises est la gestion du stress, car les différentes dead lines établies dans le planning doivent être impérativement respectées afin de terminer le projet à temps. Au final, j'ai appris beaucoup de choses aussi bien au niveau technique que personnel. Finalement, cette expérience a été très enrichissante pour moi. 41 Modifier la ligne «Infrastructure_Manager» 42 Le diagramme de Gant du projet est disponible en annexe. Koener Hervé 80

81 Bibliographie Koener Hervé 81

82 Etat de l art Amazon Elastic Compute Cloud (Amazon EC2). [en ligne]. [Consulté le 20/01/2012] disponible sur: Amazon Machine Images (AMIs) [en ligne]. [Consulté le 17/02/2012] disponible sur: Architectural Styles and the Design of Network-based Software Architectures. [en ligne]. Fielding, Roy Thomas (2000), (chapitre 5: Representational State Transfer (REST)), Doctoral dissertation, University of California, Irvine. [Consulté le 08/02/2012] disponible sur: AWS User Guide. [en ligne]. [Consulté le 12/12/2011] disponible sur: Cloud computing Une technologie futuriste mais si actuelle![en ligne]. [Consulté le 17/10/2011] disponible sur: Cloud Management by RightScale. [en ligne]. [Consulté le 25/01/2012] disponible sur: Journal du net L'architecture REST [en ligne]. [Consulté le 08/02/2012] disponible sur: Morfeo Claudia - Features [en ligne]. [Consulté le21/12/2011] disponible sur: REST, un style d'architecture universel. [en ligne]. [Consulté le 08/02/2012] disponible sur: RightScale - Configuration Framework. [en ligne]. [Consulté le 16/11/2011] disponible sur: SAN ou NAS Quelle est la différence? [en ligne]. [Consulté le 26/01/2012] disponible sur: What is cloud computing? [en ligne]. [Consulté le 17/10/2011] disponible sur: What is Claudia? [en ligne]. [Consulté le21/12/2011] disponible sur: What is hybrid cloud? [en ligne]. [Consulté le 15/10/2011] disponible sur: What is Infrastructure as a service? [en ligne]. [Consulté le 15/10/2011] disponible sur: Koener Hervé 82

83 What is Platform as a service? [en ligne]. [Consulté le 15/10/2011] disponible sur: What is public cloud? [en ligne]. [Consulté le 15/10/2011] disponible sur: What is private cloud? [en ligne]. [Consulté le 15/10/2011] disponible sur: What is Software as a service? [en ligne]. [Consulté le 16/10/2011] disponible sur: Wikipedia Amazon Elastic Compute Cloud [en ligne]. [Consulté le 20/01/2012] disponible sur: Wikipedia - Cloud computing [en ligne]. [Consulté le 15/10/2011] disponible sur: Wikipedia - Cloud computing version Anglaise [en ligne]. [Consulté le 17/10/2011] disponible sur: Wikipedia - Infrastructure as a service [en ligne]. [Consulté le 15/10/2011] disponible sur: Wikipedia Machine virtuelle [en ligne]. [Consulté le 26/01/2012] disponible sur: Wikipedia - Platform as a service [en ligne]. [Consulté le 15/10/2011] disponible sur: Wikipedia Répartition de charge [en ligne]. [Consulté le 26/01/2012] disponible sur: Wikipedia Representational State Transfer [en ligne]. [Consulté le 08/02/2012] disponible sur: Wikipedia Réseau de stockage SAN [en ligne]. [Consulté le 26/01/2012] disponible sur: Wikipedia RightScale [en ligne]. [Consulté le 17/11/2011] disponible sur: Wikipedia Sauvegarde [en ligne]. [Consulté le 26/01/2012] disponible sur: Koener Hervé 83

84 Problématique How to Avoid Cloud Vendor Lock-in [en ligne]. [Consulté le 17/10/2011] disponible sur: OCCI - Core [pdf]. Open Grid Forum. [Consulté le 24/10/2011] disponible sur: OCCI - Infrastructure [pdf]. Open Grid Forum. [Consulté le26/10/2011] disponible sur: OCCI - RESTful HTTP Rendering [pdf]. Open Grid Forum. [Consulté le 02/11/2011] disponible sur: OVF Open Virtualization Format (OVF).[en ligne]. [Consulté le 16/03/2012] disponible sur: SNIA Cloud Data Management Interface (CDMI).[en ligne]. [Consulté le 13/03/2012] disponible sur: What to Do About Cloud Lock-In? [en ligne]. [Consulté le 17/10/2011] disponible sur: Wikipedia Open Cloud Computing Interface [en ligne]. [Consulté le 19/11/2011] disponible sur: Wikipedia Cloud Data Management Interface [en ligne]. [Consulté le 23/03/2012] disponible sur: Wikipedia Open Virtual Machine Format [en ligne]. [Consulté le 15/03/2012] disponible sur: Koener Hervé 84

85 Conception duservice Manager ROQUES Pascal, UML2 par la pratique Études de cas et exercices corrigés, Paris, Édition Eyrolles, 2006, 5ed, 357p. [Consulté le 11/03/2012] Implémentation du Service Manager A Beginner s Sinatra Tutorial [en ligne]. [Consulté le 15/03/2012] disponible sur: Apprenez Ruby [en ligne]. [Consulté le 17/03/2012] disponible sur: Curb - Libcurl bindings for Ruby [en ligne]. [Consulté le 20/03/2012] disponible sur: Curl::Easy [en ligne]. [Consulté le 22/03/2012] disponible sur: Getting started with DataMapper [en ligne]. [Consulté le 25/05/2012] disponible sur: Git - Installation [en ligne]. [Consulté le 08/05/2012] disponible sur: Git - Les Soumissions [en ligne]. [Consulté le 21/05/2012] disponible sur: Install OpenNebula on Ubuntu Enterprise Server [en ligne]. [Consulté le 11/05/2012] disponible sur: MySQL-Ruby Tutorial and Code Samples [en ligne]. [Consulté le 17/04/2012] disponible sur: OpenNebula [en ligne]. [Consulté le 06/05/2012] disponible sur: OpenNebula [en ligne]. [Consulté le 02/05/2012] disponible sur: OpenNebula contextualization and secure context [en ligne]. [Consulté le 16/05/2012] disponible sur: cure_context OpenNebula - Creating Virtual Machines 3.4 [en ligne]. [Consulté le 10/05/2012] disponible sur: OpenNebula - Installing the Software 3.4 [en ligne]. [Consulté le 17/05/2012] disponible sur: Koener Hervé 85

86 OpenNebula - Managing Virtual Machines 3.4 [en ligne]. [Consulté le 23/05/2012] disponible sur: OpenNebula - Managing Virtual Machine Images 3.4 [en ligne]. [Consulté le 24/05/2012] disponible sur: OpenNebula - Managing Virtual Networks 3.4 [en ligne]. [Consulté le 25/05/2012] disponible sur: OpenNebula - OCCI Service Configuration 3.4 [en ligne]. [Consulté le 19/05/2012] disponible sur: OpenNebula - OpenNebula OCCI Specification 3.4 [en ligne]. [Consulté le 28/04/2012] disponible sur: OpenNebula - OpenNebula OCCI User Guide 3.4 [en ligne]. [Consulté le 25/04/2012] disponible sur: OpenNebula Installation and configuration guide [en ligne]. [Consulté le 23/05/2012] disponible sur: OpenNebula 2.0 Tutorial [en ligne]. [Consulté le 22/05/2012] disponible sur: Parse XML using Ruby [en ligne]. [Consulté le 24/05/2012] disponible sur: Rack::Request [en ligne]. [Consulté le 28/05/2012] disponible sur: Ruby doc - Array [en ligne]. [Consulté le 05/05/2012] disponible sur: Ruby doc Regexp [en ligne]. [Consulté le 08/05/2012] disponible sur: Ruby doc - StandardError [en ligne]. [Consulté le 11/05/2012] disponible sur: Ruby doc - String [en ligne]. [Consulté le 17/05/2012] disponible sur: Ruby Techniques Revealed: Autoload [en ligne]. [Consulté le 12/04/2012] disponible sur: Sinatra [en ligne]. [Consulté le 05/04/2012] disponible sur: Koener Hervé 86

87 Sinatra::ResponseHelpers [en ligne]. [Consulté le 17/10/2012] disponible sur: Singing with Sinatra [en ligne]. [Consulté le 17/10/2012] disponible sur: Ubuntu JeOS and vmbuilder [en ligne]. [Consulté le 28/03/2012] disponible sur: Ubuntu - libvirt [en ligne]. [Consulté le 27/03/2012] disponible sur: 5 ways to run commands from Ruby [en ligne]. [Consulté le 29/03/2012] disponible sur: Koener Hervé 87

88 ANNEXES Koener Hervé 88

89 Table des matières ANNEXE 1 Diagramme de classe du modèle de données d AWS CloudFormation...2 ANNEXE 2 Diagramme de classe du modèle de données de RightScale...4 ANNEXE 3 Liste des types de ressource AWS...6 ANNEXE 4 servicemanager.template...8 ANNEXE 5 Structure d un template AWS ANNEXE 6 Exemples d utilisation des formats OCCI ANNEXE 7 Exemple complet ANNEXE 8 Cas d utilisation ANNEXE 9 Diagramme complet de la base de données ANNEXE 10 Diagramme de classe complet ANNEXE 11 Planning ANNEXE 12 Arborescence complète du Service Manager ANNEXE 13 Création d une machine virtuelle contextualisée ANNEXE 14 Installation d Opennebula ANNEXE 15 Manipulation de l API OCCI d OpenNebula ANNEXE 16 Informations complémentaires sur le Service Manager ANNEXE 17 Liste des tests... 57

90 ANNEXE 1 Diagramme de classe du mode le de donne es d AWS CloudFormation Koener Hervé 2

91 Koener Hervé 3

92 ANNEXE 2 Diagramme de classe du mode le de donne es de RightScale Koener Hervé 4

93 Koener Hervé 5

94 ANNEXE 3 Liste des types de ressource AWS Koener Hervé 6

95 Liste des types de ressource AWS Ci-dessous se trouve la liste des ressources disponible sous Amazon Web Services. Ressource AWS Auto Scaling AutoScalingGroup Auto Scaling LaunchConfiguration Auto Scaling Policy Auto Scaling Trigger Amazon CloudFormation Init Amazon CloudFormation Stack Amazon CloudFormation WaitCondition Amazon CloudFormation WaitConditionHandle Amazon CloudFront Distribution Amazon CloudWatch Amazon EBS Volume Amazon EBS Volume Attachment Amazon EC2 Elastic IP Address Amazon EC2 Elastic IP Address Association Amazon EC2 Instance Amazon EC2 Security Group Amazon EC2 Security Group Egress Amazon EC2 Security Group Ingress Amazon ElastiCache Cache Cluster Amazon ElastiCache Parameter Group Amazon ElastiCache Security Group Amazon ElastiCache Security Group Ingress AWS Elastic Beanstalk Application AWS Elastic Beanstalk Environment Elastic Load Balancing LoadBalancer IAM Access Key IAM Group IAM Policy IAM Add User to Group IAM User Amazon RDS DBInstance Amazon RDS DBSecurityGroup Amazon RDS Security Group Ingress Amazon RDS DB Subnet Group Amazon Route 53 Resource Record Set Amazon Route 53 Resource Record Set Group Amazon S3 Bucket Amazon S3 Bucket Policy Amazon SimpleDB Domain SNS Topic Policy Amazon SNS Subscription Amazon SNS Topic Amazon SQS Queue Policy Amazon SQS Queue Identifiant AWS::AutoScaling::AutoScalingGroup AWS::AutoScaling::LaunchConfiguration AWS::AutoScaling::ScalingPolicy AWS::AutoScaling::Trigger AWS::CloudFormation::Init AWS::CloudFormation::Stack AWS::CloudFormation::WaitCondition AWS::CloudFormation::WaitConditionHandle AWS::CloudFront::Distribution AWS::CloudWatch::Alarm AWS::EC2::Volume AWS::EC2::VolumeAttachment AWS::EC2::EIP AWS::EC2::EIPAssociation AWS::EC2::Instance AWS::EC2::SecurityGroup AWS::EC2::SecurityGroupEgress AWS::EC2::SecurityGroupIngress AWS::ElastiCache::CacheCluster AWS::ElastiCache::ParameterGroup AWS::ElastiCache::SecurityGroup AWS::ElastiCache::SecurityGroupIngress AWS::ElasticBeanstalk::Application AWS::ElasticBeanstalk::Environment AWS::ElasticLoadBalancing::LoadBalancer AWS::IAM::AccessKey AWS::IAM::Group AWS::IAM::Policy AWS::IAM::UserToGroupAddition AWS::IAM::User AWS::RDS::DBInstance AWS::RDS::DBSecurityGroup AWS::RDS::SecurityGroupIngress AWS::RDS::DBSubnetGroup AWS::Route53::RecordSet AWS::Route53::RecordSetGroup AWS::S3::Bucket AWS::S3::BucketPolicy AWS::SDB::Domain AWS::SNS::TopicPolicy AWS::SNS::Subscription AWS::SNS::Topic AWS::SQS::QueuePolicy AWS::SQS::Queue Koener Hervé 7

96 ANNEXE 4 servicemanager.template Koener Hervé 8

97 servicemanager.template Le contenu du fichier servicemanager.template est disponible sur le CD. J ai décidé de ne pas le mettre sur les annexes papiers car son contenu est trop long pour être imprimable. Koener Hervé 9

98 ANNEXE 5 Structure d un template AWS Koener Hervé 10

99 Structure d un template AWS Dans AWS Cloudformation, un template est un fichier décrivant la structure d un service et de ses composants. Il est composé de six sections : - AWSTemplateFormatVersion - Description - Parameters - Mappings - Ressources - Output AWSTemplateFormatVersion Cette section est optionnelle. Elle indique la version du format ( ). Description Cette section est optionnelle. Elle décrit le contenu du template. Parameters Cette section est optionnelle, mais si elle apparait, elle doit être composée d au moins un paramètre. Cette section permet de passer des informations au template lors de la création d une stack (un service). A l intérieur du template, ces paramètres peuvent être utilisés dans la définition des ressources à l aide de la fonction «ref». Chaque paramètre peut avoir un certain nombre de propriété : - Type : String, Number, commadelimitedlist (obligatoire) - Default : Valeur par défaut - NoEcho : true = la valeur du paramètre est masqué par des astérisques. - AllowedValues : liste contenant les valeurs autorisées - AllowedPattern : expression régulière permettant de valider le paramètre. - MaxLength: nombre de caractère maximum - MinLength: nombre de caractère minimum - MaxValue: valeur maximale pour le paramètre. - MinValue: valeur minimale pour le paramètre. - Description: description du paramètre. - ConstraintDescription: explicatif textuel des contraintes. Il existe des pseudos paramètres qui sont prédéfinit par AWS CloudFormation : AWS::Region : nom de la région dans laquelle une ressource a été créée. AWS::StackName : nom du service spécifié lors de sa création. Koener Hervé 11

100 Mappings La section mappings permet de faire correspondre une clé à un ensemble de paires nom-valeur par exemple pour spécifier une valeur en fonction d une région géographique. Ces valeur peuvent être récupérées dans d autres endroits du template à l aide de la fonction intrinsèque Fn::FindInMap. Ressources Cette section décrit les différentes ressources du service. Les ressources doivent absolument appartenir à un type. Ce type est formé de la manière suivante : AWS::NomDuProduit::NomDuTypeDeDonnée Si une ressource nécessite des propriétés, celles-ci sont spécifiées dans un bloc «propriety» dans lequel chaque propriété se voit attribuée une valeur ("NomPropriété" : Valeur). Afin de récupérer des valeurs complexent non accessible avant l exécution, on peut utiliser des fonctions intrinsèques. Il en existe 6 : Fn::Base64 : encode une valeur en base 64 ; Fn::FindInMap : renvoie la valeur d une clé d un mapping ; Fn::GetAtt : renvoie la valeur d un attribut d une ressource (exemple, l adresse DNS d un Loadbalancer) ; Fn::GetAZs : renvoie la liste de toutes les Availability Zones d une région ; Fn::Join : concatène un ensemble de valeur ; Ref : renvoie la valeur d un paramètre ou la référence d une ressource ; Output Cette section est optionnelle, mais si elle apparait, elle doit être composée d au moins une sortie. Chaque sortie spécifie une valeur et la description de la sortie (optionnelle). Les sorties sont des valeurs retournée à un utilisateur (par exemple l url d un site web). Koener Hervé 12

101 ANNEXE 6 Exemples d utilisation des formats OCCI Koener Hervé 13

102 Exemples d utilisation des formats OCCI Cette annexe décrit trois exemples utilisant les formats décrits pour l interface http d OCCI. Format text/plain Requête envoyée GET /myserv/serv01 HTTP/1.1 Accept: text/plain [ ] Requête reçue HTTP/ OK [ ] Category: service; scheme= ; class= kind ; Category: custom_serv; scheme= ; class= mixin ; X-OCCI-Attribute: occi.service.state=active Link: [ ] Format text/occi Requête envoyée GET /myserv/serv01 HTTP/1.1 Accept: text/occi [ ] Requête reçue HTTP/ OK Category: service; scheme= ; class= kind ; custom_serv; scheme= ; class= mixin ; X-OCCI-Attribute: occi.service.state=active Link: [ ] [ ] OK Format text/uri-list Requête envoyée GET /myserv/ HTTP/1.1 Accept: text/uri-list [ ] Koener Hervé 14

103 Requête reçue HTTP/ OK Content-type: text/uri-list [ ] Koener Hervé 15

104 ANNEXE 7 Exemple complet Koener Hervé 16

105 Exemple complet Vous trouverez ci-dessous un exemple complet d un service composé d un ensemble de serveurs webs (apache + php) reliés à un SGBD (MySQL) et un load balancer (nginx). Voici la topologie de notre service : Load balancer Serveurs web SGBD La figure 50 illustre la structure du service. Figure 49: Description du service exemple state = active Serv1 : Service g1 : Group g2 : Group g3 : Group loadbalancer : AutoScalingGroup state = active size = 1 min = 1 max = 1 webserver : AutoScalingGroup state = active size = 3 min = 1 max = 3 state = active size = 1 min = 1 max = 1 sgbd : AutoScalingGroup d1 : Dependece d2 : Dependece Figure 50: Structure du service exemple Koener Hervé 17

106 La figure 51 illustre la configuration à appliquer sur les différents groupes d autoscaling. Ceci est réalisé par l ajout d instance de Mixin. os_tpl : Mixin term = os_tpl scheme = related ubuntu : Mixin term = Ubuntu-9.10 scheme = ressource_tpl : Mixin term = ressource_tpl scheme = related smallinstance : Mixin term = small scheme = script_tpl : Mixin term = script_tpl scheme = related loadbalancer : AutoScalingGroup arch = x86 cores = 2 speed = 2.4 memory = 1.0 script = "" url = type = boot nginx : Mixin term = nginx scheme = apachelb : Mixin term = apachelb scheme = webserver : AutoScalingGroup arch = x86 cores = 2 speed = 2.4 memory = 1.0 script = "" url = type = boot iplb = Mx[ address] loadbalancer : AutoScalingGroup arch = x86 cores = 2 speed = 2.4 memory = 1.0 script = "" url = type = boot mysql : Mixin term = mysql scheme = Figure 51: Configuration des groupes d'autoscaling pour le service exemple Koener Hervé 18

107 ANNEXE 8 Cas d utilisation Koener Hervé 19

108 Cas d utilisation Lister les fonctionnalités Acteurs : Utilisateur Objectifs : Lister les fonctionnalités Aperçu : L utilisateur démarre le logiciel et demande l affichage des fonctionnalités. Le logiciel vérifie la validité de la requête. Si la requête est valide, le logiciel envoie la liste des fonctionnalités, sinon il envoie une erreur. L utilisateur ferme le logiciel. Lister les ressources d un certain type Acteurs : Utilisateur Objectifs : Lister les ressources d un certain type Aperçu : L utilisateur démarre le logiciel et demande l affichage des ressources d un certain type. Le logiciel vérifie la validité de la requête. Si la requête est valide, le logiciel envoie la liste des ressources de ce type, sinon il envoie une erreur. L utilisateur ferme le logiciel. Créer une ressource Acteurs : Utilisateur Objectifs : Créer une ressource Aperçu : L utilisateur démarre le logiciel et demande la création d une ressource. Le logiciel vérifie la validité de la requête et de la représentation de la ressource envoyée par l utilisateur. Si la requête et la représentation de ressource sont valides, le logiciel crée la ressource et envoie le détail de celle-ci, sinon il envoie une erreur. L utilisateur ferme le logiciel. Détailler une ressource Acteurs : Utilisateur Objectifs : Détailler une ressource Aperçu : L utilisateur démarre le logiciel et demande le détail d une ressource. Le logiciel vérifie la validité de la requête et l existence de cette ressource. Si la requête est valide et que la ressource existe, le logiciel envoie le détail de la ressource, sinon il envoie une erreur. L utilisateur ferme le logiciel. Koener Hervé 20

109 Supprimer une ressource Acteurs : Utilisateur Objectifs : Supprimer une ressource Aperçu : L utilisateur démarre le logiciel et demande la suppression d une ressource. Le logiciel vérifie la validité de la requête et l existence de cette ressource. Si la requête est valide et que la ressource existe, le logiciel supprime la ressource, sinon il envoie une erreur. L utilisateur ferme le logiciel. Mise à jour partielle d une ressource Acteurs : Utilisateur Objectifs : Mise à jour partielle d une ressource Aperçu : L utilisateur démarre le logiciel et demande la mise à jour partielle d une ressource. Le logiciel vérifie la validité de la requête et l existence de cette ressource. Si la requête est valide et que la ressource existe, le logiciel met à jour la ressource, sinon il envoie une erreur. L utilisateur ferme le logiciel. Mise à jour complète d une ressource Acteurs : Utilisateur Objectifs : Mise à jour complète d une ressource Aperçu : L utilisateur démarre le logiciel et demande la mise à jour complète d une ressource. Le logiciel vérifie la validité de la requête, l existence de cette ressource et si l utilisateur fournit bien la représentation complète de la ressource. Si la requête est valide, que la ressource existe et que l utilisateur fournit bien la représentation complète de la ressource, le logiciel met à jour la ressource, sinon il envoie une erreur. L utilisateur ferme le logiciel. Exécuter une action sur une ressource Acteurs : Utilisateur Objectifs : Exécuter une action sur une ressource Aperçu : L utilisateur démarre le logiciel et demande l exécution d une action sur une ressource. Le logiciel vérifie la validité de la requête, l existence de cette ressource et si l action peut être exécutée sur celle-ci. Si la requête est valide, que la ressource existe et que l action peut être exécutée sur celle-ci, le logiciel exécute l action sur la ressource, sinon il envoie une erreur. L utilisateur ferme le logiciel. Koener Hervé 21

110 Lier une ressource à une autre Acteurs : Utilisateur Objectifs : Lier une ressource à une autre Aperçu : L utilisateur démarre le logiciel et demande la liaison d une ressource à une autre. Le logiciel vérifie la validité de la requête et si les ressources peuvent être liées. Si la requête est valide et que les ressources peuvent être liées, le logiciel lie les ressources, sinon il envoie une erreur. L utilisateur ferme le logiciel. Supprimer toute les ressources d un certain type Acteurs : Utilisateur Objectifs : Supprimer toute les ressources d un certain type Aperçu : L utilisateur démarre le logiciel et demande la suppression de toute des ressources d un certain type. Le logiciel vérifie la validité de la requête et s il existe des ressources de ce type. Si la requête est valide et qu il existe des ressources de ce type, le logiciel supprime les ressources. L utilisateur ferme le logiciel. Supprimer une ou plusieurs ressources d un certain type Acteurs : Utilisateur Objectifs : Supprimer une ou plusieurs ressources d un certain type Aperçu : L utilisateur démarre le logiciel et demande la suppression d une ou plusieurs ressources d un certain type. Le logiciel vérifie la validité de la requête et si les ressources spécifiées existent. Si la requête est valide et que les ressources existent, le logiciel supprime les ressources. L utilisateur ferme le logiciel. Mise à jour complète d une ou plusieurs ressources d un certain type Acteurs : Utilisateur Objectifs : Mise à jour complète d une ou plusieurs ressources d un certain type Aperçu : L utilisateur démarre le logiciel et demande la mise à jour complète d une ou plusieurs ressources d un certain type. Le logiciel vérifie la validité de la requête, l existence des ressources et si l utilisateur fournit bien la représentation complète de toutes les ressources. Si la requête est valide, que les ressources existent et que l utilisateur fournit bien la représentation complète de toutes les ressources, le logiciel met à jour les ressources, sinon il envoie une erreur. L utilisateur ferme le logiciel. Koener Hervé 22

111 Exécuter une action sur une ou plusieurs ressources d un certain type Acteurs : Utilisateur Objectifs : Exécuter une action sur une ou plusieurs ressources d un certain type Aperçu : L utilisateur démarre le logiciel et demande l exécution d une action sur une ou plusieurs ressources d un certain type. Le logiciel vérifie la validité de la requête, l existence des ressources et si l action peut être exécutée sur celles-ci. Si la requête est valide, que les ressources existent et que l action peut être exécutée sur celles-ci, le logiciel exécute l action sur les ressources, sinon il envoie une erreur. L utilisateur ferme le logiciel. Créer un ou plusieurs mixins utilisateur Acteurs : Utilisateur Objectifs : Créer un ou plusieurs mixins utilisateur Aperçu : L utilisateur démarre le logiciel et demande la création d un ou plusieurs mixins utilisateur. Le logiciel vérifie la validité de la requête et de la représentation des mixins envoyés par l utilisateur. Si la requête et la représentation des mixins sont valides, le logiciel crée les mixins, sinon il envoie une erreur. L utilisateur ferme le logiciel. Supprimer un ou plusieurs mixins utilisateur Acteurs : Utilisateur Objectifs : Supprimer un ou plusieurs mixins utilisateur Aperçu : L utilisateur démarre le logiciel et demande la suppression d un ou plusieurs mixins utilisateur. Le logiciel vérifie la validité de la requête et l existence de ces mixins. Si la requête est valide et que les mixins existent, le logiciel délie les ressources liées à ces mixins et supprime les mixins, sinon il envoie une erreur. L utilisateur ferme le logiciel. Supprimer tous les mixins utilisateur Acteurs : Utilisateur Objectifs : Supprimer tous les mixins utilisateur Aperçu : L utilisateur démarre le logiciel et demande la suppression de tous les mixins utilisateur. Le logiciel vérifie la validité de la requête et s il existe des mixins utilisateur. Si la requête est valide et que les mixins existent, le logiciel délie les ressources liées à ces mixins et supprime tous les mixins, sinon il envoie une erreur. L utilisateur ferme le logiciel. Koener Hervé 23

112 Lier une ou plusieurs ressources à un mixin Acteurs : Utilisateur Objectifs : Lier une ou plusieurs ressources à un mixin Aperçu : L utilisateur démarre le logiciel et demande la liaison d une ou plusieurs ressources à un mixin. Le logiciel vérifie la validité de la requête, si les ressources spécifiées existent et si les ressources peuvent être liées au mixin. Si la requête est valide, que les ressources existent et que celles-ci peuvent être liées au mixin, le logiciel lie les ressources au mixin, sinon il envoie une erreur. L utilisateur ferme le logiciel. Lister les ressources liées à un mixin Acteurs : Utilisateur Objectifs : Lister les ressources liées à un mixin Aperçu : L utilisateur démarre le logiciel et demande l affichage des ressources liées à un certain mixin. Le logiciel vérifie la validité de la requête. Si la requête est valide, le logiciel envoie la liste des ressources liées à ce mixin, sinon il envoie une erreur. L utilisateur ferme le logiciel. Délier une ou plusieurs ressources d un mixin Acteurs : Utilisateur Objectifs : Délier une ou plusieurs ressources d un mixin Aperçu : L utilisateur démarre le logiciel et demande de délier une ou plusieurs ressources d un mixin. Le logiciel vérifie la validité de la requête, si les ressources spécifiées existent et qu elles sont liées au mixin. Si la requête est valide, que les ressources existent et que celles-ci sont liées au mixin, le logiciel délie les ressources du mixin, sinon il envoie une erreur. L utilisateur ferme le logiciel. Mise à jour complète d une ou plusieurs ressources liées à un mixin Acteurs : Utilisateur Objectifs : Mise à jour complète d une ou plusieurs ressources liées à un mixin Aperçu : L utilisateur démarre le logiciel et demande la mise à jour complète d une ou plusieurs ressources liées à un certain mixin. Le logiciel vérifie la validité de la requête, l existence des ressources, si l utilisateur fournit bien la représentation complète de toutes les ressources et si les ressources sont bien liées au mixin. Si la requête est valide, que les ressources existent, que l utilisateur fournit bien la représentation complète de toutes les ressources et que les ressources sont bien liées au mixin, le logiciel met à jour les ressources, sinon il envoie une erreur. L utilisateur ferme le logiciel. Koener Hervé 24

113 Exécuter une action sur une ou plusieurs ressources liées à un mixin Acteurs : Utilisateur Objectifs : Exécuter une action sur une ou plusieurs ressources liées à un mixin Aperçu : L utilisateur démarre le logiciel et demande l exécution d une action sur une ou plusieurs ressources liées à un certain mixin. Le logiciel vérifie la validité de la requête, l existence des ressources, si l action peut être exécutée sur celles-ci et si les ressources sont bien liées au mixin. Si la requête est valide, que les ressources existent, que l action peut être exécutée sur celles-ci et si les ressources sont bien liées au mixin, le logiciel exécute l action sur les ressources, sinon il envoie une erreur. L utilisateur ferme le logiciel. Koener Hervé 25

114 Diagramme UML Les cas d utilisations ci-dessous concernent la manipulation de ressources. Koener Hervé 26

115 Les cas d utilisations ci-dessous concernent la manipulation de ressources à l aide de leur type. Koener Hervé 27

116 Les cas d utilisations ci-dessous concernent la manipulation de mixins et de ressources liées à un mixin. Koener Hervé 28

117 ANNEXE 9 Diagramme complet de la base de donne es Koener Hervé 29

118 Diagramme complet de la base de données Représentation des liens entre les ressources. Koener Hervé 30

119 Représentation des liens entre les ressources et les mixins. Koener Hervé 31

120 ANNEXE 10 Diagramme de classe complet Koener Hervé 32

121 Diagramme de classe complet Diagramme de classe des classes composant la vue. Koener Hervé 33

122 Koener Hervé 34

123 Diagramme de classe des contrôleurs. Koener Hervé 35

124 Diagramme de classe des classes internes. Koener Hervé 36

125 ANNEXE 11 Planning Koener Hervé 37

126 Planning Le diagramme de Gant du projet a été réalisé à l aide du logiciel Microsoft Project. Celui-ci étant trop grand pour être imprimé, j ai décidé de vous donner un aperçu, reprenant les principales dead lines du projet. Quant au diagramme complet, il est disponible dans les annexes numériques de l ouvrage. Koener Hervé 38

127 ANNEXE 12 Arborescence comple te du Service Manager Koener Hervé 39

128 Arborescence complète du Service Manager Dossiers/Fichiers Description / Racine du Service Manager config.ru Fichier de configuration du Service Manager INSTALL Fichier d installation du Service Manager readme Fichier expliquant comment installer et démarrer le Service Manager RUN Fichier de démarrage du Service Manager service_manager.sql Fichier SQL contenant les tables de la base de données controlers Dossiers contenant les fichiers permettant de générer la vue du Service Manager autoscalinggroup Dossier contenant le contrôleur des groupes d autoscaling views Dossier contenant les vues des groupes d autoscaling dependence Dossier contenant le contrôleur des dépendances views Dossier contenant les vues des dépendances entity Dossier contenant le contrôleur des ressources de type «Entity» views Dossier contenant les vues des ressources de type «Entity» group Dossier contenant le contrôleur des groupes views Dossier contenant les vues des groupes kind Dossier contenant le contrôleur des types de ressources views Dossier contenant les vues des types de ressources mixin Dossier contenant le contrôleur des mixins views Dossier contenant les vues des mixins requestinterface Dossier contenant le contrôleur de l interface de requête views Dossier contenant les vues de l interface de requête sandbox Dossier contenant le contrôleur de la sandbox views Dossier contenant les vues de la sandbox service Dossier contenant le contrôleur des services views Dossier contenant les vues des services images Dossier contenant les images des systèmes d exploitation pouvant être installés sur les vms context Dossier contenant les scripts permettant l exécution de commandes sur les vms lib Dossier contenant les fichiers de librairie du Service Manager exceptions Dossier contenant les exceptions models Dossier contenant les fichiers représentant le modèle de l application mysql Dossier contenant les classes permettant la communication avec la base de données mysql opennebula Dossier contenant les classes permettant la communication avec OpenNebula Koener Hervé 40

129 ANNEXE 13 Cre ation d une machine virtuelle contextualise e Koener Hervé 41

130 Création d une machine virtuelle contextualisée Nous allons créer une machine virtuelle Ubuntu Server contextualisée. Création de la machine virtuelle Tout d abord, il faut télécharger le cd d installation d Ubuntu Server. Pour ce faire, exécutons la commande suivante : $ wget Nous allons maintenant créer une image vide de la taille d un gigabit. $ qemu-img create ubuntu.img -f raw 1G Ensuite, il faut installer Ubuntu Server sur cette image en utilisant le cd d installation. $ kvm -m 512 -cdrom /chemin/ubuntu server-amd64.iso -boot d ubuntu.img Nous avons maintenant une machine virtuelle générique. Contextualisation de la machine virtuelle Nous allons maintenant contextualisé la machine virtuelle afin de pouvoir la configurer lors de la création du template de vm d Opennebula. Tout d abord, il faut lancer la machine virtuelle : $ kvm -no-acpi -m 512 ubuntu.img La première chose à faire, est de supprimer les fichiers générant l'adresse ip à partir de la mac lors du démarrage de la machine (Sinon, nous ne pourrons pas y avoir accès lors du démarrage de celle-ci). Pour ce faire, exécutons la commande suivante : $ sudo rm /etc/udev/rules.d/*-net* Koener Hervé 42

131 La dernière étape consiste à activer la contextualisation. Il s agit de monter puis d exécuter les fichiers qui configureront la machine virtuelle (Par exemple : ceux-ci lui assigneront une adresse ip). $ sudo nano /etc/rc.local mount -t iso9660 /dev/sr0 /mnt if [ -f /mnt/context.sh ]; then. /mnt/init.sh fi umount /mnt exit 0 NB : Le fichier context.sh est créé automatiquement par Opennebula lorsque le template de la machine virtuelle contient la section «context». La machine virtuelle verra alors un cd (sr0) contenant les différents fichiers de contextualisation. Nous pouvons maintenant éteindre la machine virtuelle : $ sudo halt Koener Hervé 43

132 ANNEXE 14 Installation d Opennebula Koener Hervé 44

133 Installation d Opennebula Avant de pouvoir commencer l installation, il faut télécharger la dernière version d opennebula. Pour ce faire, il faut exécuter la commande suivante : $ wget L utilisateur oneadmin Il faut ensuite créer l utilisateur et le groupe oneadmin. Celui-ci sera utilisé par opennebula pour gérer les vm sur les différents hôtes. $ sudo addgroup --gid 1001 oneadmin $ sudo adduser --ingroup oneadmin --uid home /var/lib/one oneadmin Il faut également ajouter l'utilisateur oneadmin au groupe libvirt pour qu'il ait l autorisation de manipuler libvirt lors du lancement des machines virtuelles. $ adduser oneadmin libvirt Installation et configuration d Opennebula Pour installer Opennebula exécutons la commande suivante : $ sudo dpkg -i Debian opennebula_ _amd64.deb Il est recommandé d installer les différentes les gems afin de pouvoir utiliser toutes les fonctionnalités d Opennebula. $ sudo ruby /usr/share/one/install_gems Pour ne pas devoir indiquer le pont à utiliser à chaque création de réseau virtuel. Nous pouvons définir un pont par défaut dans le template du réseau. $ sudo nano /etc/one/occi_templates/network.erb... <% end %> BRIDGE = br0 #PHYDEV = NAME_OF_PHYSICAL_DEVICE... Koener Hervé 45

134 Nous pouvons maintenant nous connecter en tant que oneadmin. $ su -l oneadmin Nous allons maintenant modifier le mot de passe d'opennebula. (Il faut mettre le même que celui de l'utilisateur oneadmin). $ oneuser passwd 0 oneadmin $ echo "oneadmin:oneadmin" > /var/lib/one/.one/one_auth $ echo "oneadmin:oneadmin" >> /var/lib/one/.one/occi_auth $ echo "oneadmin:oneadmin" >> /var/lib/one/.one/sunstone_auth Ensuite, nous allons permettre à Opennebula de se connecter en ssh sans devoir fournir de mot de passe pour l utilisateur oneadmin. Pour ce faire, exécutons les commandes suivantes : $ cat /var/lib/one/.ssh/id_rsa.pub >> /var/lib/one/.ssh/authorized_keys $ nano /var/lib/one/.ssh/config Host * StrictHostKeyChecking no Finalement nous allons redémarrer Opennebula afin de valider qu il prenne en compte la nouvelle configuration. $ one stop $ one start Nous pouvons maintenant exécuter des commandes d Opennebula comme par exemple celle permettant de créer un nouvel hôte où les machines virtuelles seront lancées. $ onehost create nomhote -i im_kvm -v vmm_kvm -n dummy Koener Hervé 46

135 ANNEXE 15 Manipulation de l API OCCI d OpenNebula Koener Hervé 47

136 Manipulation de l API OCCI d OpenNebula L API OCCI d OpenNebula permet à un client OCCI de manipuler les différentes ressources (Storage, Compute, Network). L API peut être manipulée de deux manières différentes : En utilisant les commandes fournies par OCCI-Server ; En envoyant des requêtes http ; Représentation des ressources Dans OpenNebula, les ressources sont représentées sous le format XML. La figure ci-dessous illustre la représentation d une ressource de type Compute. <COMPUTE href=' <ID>1</ID> <CPU>0.5</CPU> <MEMORY>512</MEMORY> <NAME>VM1</NAME> <STATE>ACTIVE</STATE> <DISK id='0'> <STORAGE href=' name='tinylinux'/> <TYPE>DISK</TYPE> <TARGET>hda</TARGET> </DISK> <NIC> <NETWORK href=' name='lan'/> <IP> </IP> <MAC>02:00:c0:a8:02:01</MAC> </NIC> </COMPUTE> Figure 52: Représentation d'une ressource de type Compute Authentification de l utilisateur Lors de l utilisation d une commande ou l envoi d une requête, l utilisateur doit s identifier. Lors de l utilisation d une commande, le client OCCI doit fournir son login et son mot de passe en clair. Alors que pour l envoi de requête http, le client doit fournir, comme mot de passe, le hash CHA1 de son mot de passe utilisateur. Manipulation des ressources Commandes OCCI-server L API OCCI d OpenNebula fournit une commande pour chaque ressource : occi-storage : permet de manipuler des ressources de type Storage ; occi-compute : permet de manipuler des ressources de type Compute ; occi-network : permet de manipuler des ressources de type Network ; Chacune de ces commandes peuvent être appelée avec quatre options différentes : list : cette option permet de lister les ressources d un même type. create : cette option permet de créer une nouvelle ressource. Il faut alors fournir un fichier XML contenant la représentation de la ressource à créer. Koener Hervé 48

137 update : cette option permet de mettre à jour une ressource. Il faut alors fournir un fichier XML contenant la représentation entière de la ressource. (Seul un attribut à la fois peut être mis à jour) show : cette option permet de récupérer la représentation d une ressource. Il faut fournir l id de la ressource. delete : cette option permet de supprimer une ressource. Il faut fournir l id de la ressource. La figure ci-dessous montre l utilisation de la commande occi-storage avec l option list. $ occi-storage --url --username oneadmin --password oneadmin list <STORAGE_COLLECTION> <STORAGE name='tinylinux' href=' </STORAGE_COLLECTION> Figure 53: Utilisation de la commande occi-storage avec l option list L API OCCI d OpenNebula fournit également une commande permettant de manipuler les types d instance de vm : occi-instance-type. Celle-ci peut être appelée avec deux options : list : cette option permet de lister les différents types d instance de vm show : cette option permet de récupérer les détails d une instance de vm. Il faut fournir le nom du type d instance de vm. Les différents types d instance de vm disponibles sont : small : l instance dispose d un CPU et de 1024Mo de mémoire. medium : l instance dispose de 4 CPU et de 4096Mo de mémoire. large : l instance dispose de 8 CPU et de 8192Mo de mémoire. Requêtes http L interface de requête http de l API OCCI d OpenNebula peut être manipulée à l aide des verbes http. Les requêtes peuvent être envoyées vers une adresse représentant, un ou plusieurs types d instance de vm, un ou plusieurs utilisateurs, un ensemble de ressources ou une ressource particulière. L affichage des différentes collections peut être demandé à l aide du verbe http «GET» sur l url «/». La manipulation d un ou plusieurs types d instance de vm et d un ou plusieurs utilisateurs peut être réalisée à l aide du verbe http «GET». Si celui-ci est appliqué à un ensemble d éléments, l API renverra la liste des éléments de cet ensemble. Si «GET» est appliqué à un seul élément, l API renverra la représentation de l élément demandé. Koener Hervé 49

138 $ curl --user "oneadmin:7bc8559a8fe509e680562b85c337f956fcb06" <USER_COLLECTION> <USER href=" name="oneadmin"/> <USER href=" name="serveradmin"/> </USER_COLLECTION> Figure 54: Envoi d une requête GET sur l ensemble des utilisateurs La manipulation d un ensemble de ressources peut être réalisée à l aide des verbes http suivants : GET : permet de lister toutes les ressources d un même type. POST : permet de créer une nouvelle ressource. Il faut alors fournir la représentation de la ressource en format XML. La figure ci-dessous montre l envoi d une requête GET sur l ensemble de ressources de type Compute. $ curl --user "oneadmin:7bc8559a8fe509e680562b85c337f170956fcb06" <COMPUTE_COLLECTION> <COMPUTE href=" name="vm1"/> </COMPUTE_COLLECTION> Figure 55: Envoi d une requête GET sur l ensemble de ressources de type Compute La manipulation d une ressource particulière peut être réalisée à l aide des verbes http suivants : GET : permet de récupérer la représentation d une ressource. PUT : permet de mettre à jour une ressource. Il faut alors fournir la représentation de la ressource en format XML. DELETE : permet de supprimer une ressource. La figure ci-dessous montre l envoi d une requête DELETE sur une des ressources de type Compute. $ curl X DELETE --user "oneadmin:7bc8559a8fe509e680562b85c337f170956fcb06" Figure 56: Envoi d une requête DELETE sur une de ressource de type Compute Modification de l état d une ressource La modification de l état d une ressource de type Compute, se fait à l aide du mécanisme de mise à jour des ressources («occi-compute update» pour l interface de commande et l utilisation du verbe POST pour l interface de requêtes http). Pour modifier l état d une ressource de type Compute on peut lui appliquer les actions suivantes : done, shutdown, cancel, resume, suspended, stopped et reboot. Koener Hervé 50

139 La figure ci-dessus illustre le passage d un état à un autre en fonction de l action appliquée à la vm. INIT Reboot Shutdown Cancel Done DONE PENDING ACTIVE Resume Suspended SUSPENDED Stopped HOLD Resume STOPPED Figure 57: Etats d'une ressource de type Compute La figure ci-dessous montre la modification de l état d une ressource de type compute à l aide de l interface http de l API OCCI d OpenNebula. $ curl T "<COMPUTE href=' COMPUTE>" --user "oneadmin:7bc8559a8fe509e680562b85c337f170956fcb06" Figure 58: Modification de l'état d'une ressource Koener Hervé 51

140 ANNEXE 16 Informations comple mentaires sur le Service Manager Koener Hervé 52

141 Informations complémentaires sur le Service Manager Caractéristique du Service Manager Le Service Manager a été développé en Ruby. Il utilise le Framework Synatra afin d'analyser les requêtes http envoyées par l'utilisateur. Le nombre de lignes de code nécessaires au développement du Service Manager est de ~5700. Il possède 46 classes réparties dans 79 fichiers. Le nombre de méthode implémentée est de 150. L'application manipule une base de données composée de 14 tables. Celles-ci représentent le modèle de données définit par OCCI Service Manager. Le Service Manager est disponible à l adresse suivante : Fonctionnalités du Service Manager Les données envoyées par le Service Manager peuvent être représentées sous deux formats différents: text/plain ou text/occi. Le format par défaut est «text/plain». Le service manager peut être manipulé de la manière suivante: Interface de requête Méthode URL Description Réponse GET /-/ Liste les fonctionnalités du Service Manager 200 OK : La liste des fonctionnalités du Service Manager POST /-/ Ajoute un mixin utilisateur 200 OK DELETE /-/ Supprime un mixin utilisateur 200 OK Service Méthode URL Description Réponse GET /service/ Liste les différents 200 OK : La liste des services services POST /service/ Crée un nouveau service 200 OK : La représentation du service créé POST /service/?action=<action> Exécute l action 200 OK <action> sur tous les services PUT /service/ Crée un nouveau service 200 OK : La représentation du service créé DELETE /service/ Supprime un 200 OK ensemble de services GET /service/<id> Affiche la représentation du 200 OK : La représentation du service identifié par <id> service identifié par <id> POST /service/<id> Met à jour un service 200 OK : La représentation du service mis à jour Koener Hervé 53

142 POST /service/<id>?action=<action> Exécute l action <action> sur un service PUT /service/<id> Met à jour complètement un service 200 OK DELETE /service/<id> Supprime un service 200 OK 200 OK : La représentation du service mis à jour Autoscalinggroup Méthode URL Description Réponse GET /autoscalinggroup/ Liste les différents autoscalinggroups 200 OK : La liste des autoscalinggroups POST /autoscalinggroup/ Crée un nouveau autoscalinggroup 200 OK : La représentation de l autoscalinggroup créé POST /autoscalinggroup/?action=<action> Exécute l action <action> sur tous les autoscalinggroups 200 OK PUT /autoscalinggroup/ Crée un nouveau autoscalinggroup DELETE /autoscalinggroup/ Supprime un ensemble d autoscalinggroups GET /autoscalinggroup /<id> Affiche la représentation de l autoscalinggroup identifié par <id> POST /autoscalinggroup/<id> Met à jour un autoscalinggroup POST /autoscalinggroup/<id>?action=<action> Exécute l action <action> sur un autoscalinggroup PUT /autoscalinggroup/<id> Met à jour complètement un autoscalinggroup DELETE /autoscalinggroup/<id> Supprime un autoscalinggroup 200 OK : La représentation de l autoscalinggroup créé 200 OK 200 OK : La représentation de l autoscalinggroup identifié par <id> 200 OK : La représentation de l autoscalinggroup mis à jour 200 OK 200 OK : La représentation de l autoscalinggroup mis à jour 200 OK Koener Hervé 54

143 Group Méthode URL Description Réponse GET /group/ Liste les différents 200 OK : La liste des groupes groupes POST /group/ Crée un nouveau groupe 200 OK : La représentation du groupe créé POST /group/?action=<action> Exécute l action 200 OK <action> sur tous les groupes PUT /group/ Crée un nouveau groupe 200 OK : La représentation du groupe créé DELETE /group/ Supprime un 200 OK ensemble de groupes GET /group/<id> Affiche la représentation du 200 OK : La représentation du groupe identifié par <id> groupe identifié par <id> POST /group/<id> Met à jour un groupe 200 OK : La représentation du groupe mis à jour POST /group/<id>?action=<action> Exécute l action <action> sur un groupe 200 OK PUT /group/<id> Met à jour complètement un groupe DELETE /group/<id> Supprime un groupe 200 OK 200 OK : La représentation du groupe mis à jour Dependence Méthode URL Description Réponse GET /dependence/ Liste les différentes dépendances 200 OK : La liste des dépendances POST /dependence/ Crée une nouvelle dépendance 200 OK : La représentation de la dépendance créée POST /dependence/?action=<action> Exécute l action 200 OK <action> sur toutes les dépendances PUT /dependence/ Crée une nouvelle dépendance 200 OK : La représentation de la dépendance créée DELETE /dependence/ Supprime un 200 OK ensemble de dépendances GET /dependence/<id> Affiche la représentation de la dépendance identifiée par <id> 200 OK : La représentation de la dépendance identifiée par <id> POST /dependence/<id> Met à jour une dépendance 200 OK : La représentation de la dépendance mis à jour Koener Hervé 55

144 POST /dependence/<id>?action=<action> Exécute l action <action> sur une dépendance PUT /dependence/<id> Met à jour complètement une dépendance DELETE /dependence/<id> Supprime une dépendance 200 OK 200 OK : La représentation de la dépendance mis à jour 200 OK L'état d'un service et d'un groupe d'autoscaling peut être modifié de cette manière: restart Active start stop Inactive On peut également modifier le nombre de vm contenue dans un groupe d'autoscaling à l'aide des actions «increase» et «decrease». Increase Autoscalinggroup Autoscalinggroup vm1 vm2 vm1 vm2 vm3 Decrease Autoscalinggroup Autoscalinggroup vm1 vm2 vm1 vm2 vm3 Koener Hervé 56

145 ANNEXE 17 Liste des tests Koener Hervé 57

146 Liste des tests Envoyer une requête à une URL inexistante ou invalide. $ curl Interface de requête Lister les fonctionnalités du Service Manager. $ curl Lister les fonctionnalités du Service Manager sous le format text/occi. $ curl --header "Content-Type: text/occi" Création d'un mixin utilisateur. $ curl -X POST -d 'Category: monmixin; scheme=" class="mixin"; title="mixin de test"; attributes="";' Création d'un mixin utilisateur lié à un mixin. $ curl -X POST -d 'Category: monmixin2; scheme=" class="mixin"; title="mixin de test 2"; attributes=""; rel=" ' Création de plusieurs mixin utilisateurs. $ curl -X POST -d 'Category: monmixin4; scheme=" class="mixin"; title="mixin de test 4"; attributes=""; rel=" Category: monmixin5; scheme=" class="mixin"; title="mixin de test5"; attributes="";' Création de plusieurs mixin utilisateurs lié À différents mixins. $ curl -X POST -d 'Category: monmixin3; scheme=" class="mixin"; title="mixin de test 3"; attributes=""; rel=" ost:9292/templates/autoscalinggroup#apachelb";' Koener Hervé 58

147 Suppression d'un mixin utilisateur. $ curl -X DELETE -d 'Category: monmixin2; scheme=" class="mixin"; title="mixin de test 2"; attributes=""; rel=" ' Suppression de tous les mixins utilisateurs. $ curl -X DELETE Tests de robustesse Lister les fonctionnalités du Service Manager sous un format inexistant. $ curl --header "Content-Type: text/error" Création d'un mixin utilisateur (doublon). $ curl -X POST -d 'Category: monmixin; scheme=" class="mixin"; title="mixin de test"; attributes=""; ' Création d'un mixin utilisateur lié à un mixin inexistant. $ curl -X POST -d 'Category: monmixin2; scheme=" class="mixin"; title="mixin de test 2"; attributes=""; rel=" ' Création d'un mixin utilisateur contenant des informations incomplètes. $ curl -X POST -d 'Category: monmixin; class="mixin"; title="mixin de test"; attributes=""; ' Création d'un mixin utilisateur contenant des informations superflues. $ curl -X POST -d 'Category: monmixin; scheme=" class="mixin"; title="mixin de test"; attributes=""; error="yes"; ' Création de plusieurs mixin utilisateurs avec des parasites entre les mixins. $ curl -X POST -d 'Category: monmixin4; scheme=" class="mixin"; title="mixin de test 4"; attributes=""; rel=" ERROR&@cfz2Category: monmixin5; scheme=" class="mixin"; title="mixin de test5"; attributes=""; ' Koener Hervé 59

148 Création de plusieurs mixin utilisateurs mélangés l'un dans l'autre. $ curl -X POST -d 'Category: monmixin6; scheme=" title="mixin de test 6"; attributes=""; rel=" Category: class="mixin"; monmixin7; scheme=" class="mixin"; title="mixin de test7"; attributes=""; ' Suppression d'un mixin utilisateur inexistant. $ curl -X DELETE -d 'Category: monmixinerror; scheme=" class="mixin"; title="mixin de test 2"; attributes=""; rel=" ' Suppression d'un mixin utilisateur contenant des informations incomplètes. $ curl -X DELETE -d 'Category: monmixin; class="mixin"; title="mixin de test"; attributes=""; ' Suppression de plusieurs mixin utilisateurs mélangés l'un dans l'autre. $ curl -X DELETE -d 'Category: monmixin6; scheme=" title="mixin de test 6"; attributes=""; rel=" Category: class="mixin"; monmixin7; scheme=" class="mixin"; title="mixin de test7"; attributes=""; ' Suppression de plusieurs mixin utilisateurs avec des parasites entre les mixins. $ curl -X DELETE -d 'Category: monmixin4; scheme=" class="mixin"; title="mixin de test 4"; attributes=""; rel=" ERROR&@cfz2Category: monmixin5; scheme=" class="mixin"; title="mixin de test5"; attributes=""; ' Suppression d'un mixin utilisateur contenant des informations superflues. $ curl -X DELETE -d 'Category: monmixin; scheme=" class="mixin"; title="mixin de test"; attributes=""; error="yes"; ' Koener Hervé 60

149 Kind Lister les ressources d'un certain type. $ curl Créer une ressource. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; X-OCCI-Attribute: occi.core.title = "ressource 1"X-OCCI- Attribute: occi.core.summary = ""' Créer une ressource liée à un mixin. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: ubuntu; scheme=" X-OCCI- Attribute: occi.core.title = "ressource 2"X-OCCI-Attribute: occi.core.summary = ""' Créer une ressource liée à une autre ressource. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Link: </autoscalinggroup/1>; rel=" category=" X-OCCI- Attribute: occi.core.title = "ressource 3"X-OCCI-Attribute: occi.core.summary = ""' Créer une ressource lié à une autre ressource et lié à un mixin. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: ubuntu; scheme=" Link: </autoscalinggroup/1>; rel=" category=" X-OCCI- Attribute: occi.core.title = "ressource 4"X-OCCI-Attribute: occi.core.summary = ""' Créer un lien. $ curl -X POST -d 'Category: dependence; scheme=" class="kind"; X-OCCI-Attribute: occi.core.title = "SGBD link"x-occi- Attribute: occi.core.source = " occi.core.target = " Koener Hervé 61

150 Mise à jour complète d'une ressource. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; X-OCCI-Attribute: occi.core.title = "ressource 12"X-OCCI- Attribute: occi.core.summary = ""' Supprimer des ressources. $ curl -X DELETE -d 'X-OCCI-Location: Supprimer toutes les ressources. $ curl -X DELETE Exécuter une action sur un ensemble de ressources. $ curl -X POST Tests de robustesse Lister les ressources d'un type qui n'existe pas. $ curl Créer une ressource liée à un mixin inexistant. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: error; scheme=" X-OCCI- Attribute: occi.core.title = "ressource 2"X-OCCI-Attribute: occi.core.summary = ""' Créer une ressource liée à une ressource inexistante. $ curl -X POST -d 'Category: autoscalinggroup; scheme=" class="kind"; Link: </autoscalinggroup/105>; rel=" category=" X-OCCI- Attribute: occi.core.title = "ressource 3"X-OCCI-Attribute: occi.core.summary = ""' Créer une ressource contenant des informations incomplètes. $ curl -X POST -d 'Category: autoscalinggroup; X-OCCI-Attribute: occi.core.title = "ressource 1"X-OCCI-Attribute: occi.core.summary = ""' Koener Hervé 62

151 Créer un lien entre deux ressources inexistantes. $ curl -X POST -d 'Category: dependence; scheme=" class="kind"; X-OCCI-Attribute: occi.core.title = "SGBD link"x-occi- Attribute: occi.core.source = " occi.core.target = " Créer un lien entre une ressource existante et une ressource inexistante. $ curl -X POST -d 'Category: dependence; scheme=" class="kind"; X-OCCI-Attribute: occi.core.title = "SGBD link"x-occi- Attribute: occi.core.source = " occi.core.target = " Exécuter une action inexistante. $ curl -X POST Exécuter une action sans les paramètres requis. $ curl -X POST Exécuter une action avec des valeurs invalide pour certains paramètres. $ curl -X POST -d 'X-OCCI-Attribute: size = -100' Exécuter une action avec des paramètres superflus. $ curl -X POST -d 'X-OCCI-Attribute: size = 1X-OCCI-Attribute: type = error' Supprimer des ressources inexistantes. $ curl -X DELETE -d 'X-OCCI-Location: Koener Hervé 63

152 Ressources et Liens Afficher la représentation complète d'une ressource. $ curl Exécuter une action sur une ressource. $ curl -X POST Mettre à jour une ressource. $ curl -X POST -d 'X-OCCI-Attribute: occi.core.title = "ressource maj"' Mettre à jour complétement une ressource. $ curl -X PUT -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: ubuntu; scheme=" X-OCCI- Attribute: occi.core.title = "ressource MAJ 2"X-OCCI-Attribute: occi.core.summary = "MAJ"' Supprimer une ressource. $ curl -X DELETE Tests de robustesse Mettre à jour un attribut inexistant d'une ressource. $ curl -X POST -d 'X-OCCI-Attribute: occi.core.title = "ressource maj"' Mettre à jour complétement une ressource avec des informations manquantes. $ curl -X PUT -d 'Category: autoscalinggroup; class="kind"; Category: ubuntu; scheme=" X- OCCI-Attribute: occi.core.summary = "MAJ"' Mettre à jour complétement une ressource avec des informations superflues. $ curl -X PUT -d 'Category: autoscalinggroup; scheme=" class="kind"; Category: ubuntu; scheme=" X-OCCI- Attribute: occi.core.title = "ressource MAJ 2"X-OCCI-Attribute: occi.core.summary = "MAJ"X-OCCI-Attribute: occi.core.status = "ERROR"' Exécuter une action sur une ressource inexistante. $ curl -X POST Koener Hervé 64