SlideShare une entreprise Scribd logo
MEMOIRE DE MASTER
Sp´ecialit´e : Ing´enierie des Syst`emes Complexes et Multim´edia
Discipline : Informatique
D´EPLOIEMENT AUTOMATIQUE DES
APPLICATIONS SUR LE CLOUD
COMPUTING
pr´esent´e et soutenu
par
KADDOUR GUETTAOUI Abdelhalim
Juin 2016
JURY
Pr´esident : Mme HADI Nadia
Encadreurs : DEBA El Abbassia Universit´e d’Oran 1
AOUAT Asmaa Universit´e d’Oran 1
Examinateurs : HADJ TAYEB Lylia Universit´e d’Oran 1
D´epartement d’Informatique
Remerciements
Grâce à «Allah» le tout puissant, ce travail s’est accompli.. Je tiens à remercier
tout particulièrement mes encadreurs
DEBA El Abbassia
AOUAT Asmaa
De m’avoir fait l’honneur d’assurer le suivi de mon travail
Jusqu’à son achèvement.
Je désire exprimer mes profondes gratitudes et remerciements A Mmes les
membres du jury
Mme HADI Nadia
Mme HADJ TAYEB Lylia
Qui m’ont honoré et ont bien accepté d’examiner mon travail
Et
À tous les enseignants qui ont contribué à ma formation. Je tiens à remercier
également tous mes amis, qui étaient à Mes côtés aux lieux fraternels et amicaux
qui ont germé dans Mes esprits ... .
I
Je dédie ce travail,
A mes chères parents
A mes frères et sœurs
II
Résume :
Le cloud computing est une tendance actuelle majeure pour répartir les traite-
ments et les données de façon virtuelle sur des environnements d’exécution
paramétrables. Le déploiement automatique d’applications sur le cloud propose
un nouveau challenge scientifique en termes d’expression et de prise en compte de
la variabilité. Dans ce mémoire, nous présentons une solution basée sur les scripts
pour déployer automatiquement les applications dans le cloud. Pour évaluer notre
solution, nous avons mené une expérience de deux personnes qui ont déployé
une application manuellement dans le cloud et ils ont utilisé notre solution de
déploiement automatique. Les résultats ont montré que notre solution a présenté
un impact positif en termes de charge de travail et le temps consommé.
Mots Clés : Cloud Computing, Script, Déploiement automatique, Plateforme
cloud
Abstract :
Cloud computing is a major trend to allocate treatments and data on virtually
parameterized execution environments. Automatic deployment of applications on
the cloud offers a new scientific challenge in terms of expression and consideration
of variability. In this paper, we present a solution based on scripts to automati-
cally deploy applications in the cloud. To evaluate our solution, we conducted an
experiment of two people who have made an application manually in the cloud
and they used our automatic deployment solution. The results showed that our
solution has presented a positive impact in terms of workload and time consumed.
Key Words: Cloud Computing, Script, Automatic deployment, PaaS
III
Table des matières
Liste des figures VII
Acronymes VIII
Introduction générale 1
Chapitre 1 Cloud Computing : état de l’art 4
1.1 Les fondements du cloud . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 L’informatique utilitaire de John McCarthy . . . . . . . . . 5
1.1.2 Les services bureau . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 Les applications service providers . . . . . . . . . . . . . . . 5
1.1.4 La virtualisation . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 L’évolution de Cloud computing . . . . . . . . . . . . . . . . . . . . 6
1.3 Cloud Computing : Définition et Concepts . . . . . . . . . . . . . . 7
1.4 Cloud vs Grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Les caractéristiques essentielles de cloud computing . . . . . . . . . 10
1.5.1 Self-service à la demande . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Elasticité et rapidité . . . . . . . . . . . . . . . . . . . . . . 10
1.5.3 Accès aux ressources . . . . . . . . . . . . . . . . . . . . . . 10
1.5.4 Allocation des ressources . . . . . . . . . . . . . . . . . . . . 11
1.5.5 Mesure du service . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Taxonomie du cloud computing . . . . . . . . . . . . . . . . . . . . 11
1.6.1 Modèle de délivrance . . . . . . . . . . . . . . . . . . . . . . 11
1.6.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . 14
IV
Table des matières
1.6.3 Le modèle business . . . . . . . . . . . . . . . . . . . . . . . 16
1.7 Avantages et inconvénients du Cloud Computing . . . . . . . . . . . 16
1.7.1 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7.2 Inconvenients . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.8 Les plateformes cloud computing . . . . . . . . . . . . . . . . . . . 17
1.8.1 Amazon Web Services (AWS) . . . . . . . . . . . . . . . . . 18
1.8.1.1 Elastic Computing Cloud (EC2) . . . . . . . . . . 18
1.8.2 Service de Stockage Simple(S3) . . . . . . . . . . . . . . . . 19
1.8.3 Google AppEngine . . . . . . . . . . . . . . . . . . . . . . . 19
1.8.4 Windows Azure . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapitre 2 Déploiement d’applications : tour d’horizon 22
2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Le déploiement automatique des logiciels dans le cloud computing . 24
2.3 Définition du déploiement automatique . . . . . . . . . . . . . . . . 25
2.4 Les approches de déploiement . . . . . . . . . . . . . . . . . . . . . 25
2.4.1 Les scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.2 Langage de programmation . . . . . . . . . . . . . . . . . . 26
2.4.3 Les approches semi-automatiques . . . . . . . . . . . . . . . 26
2.4.4 Les Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.5 Approche basée sur les modèles . . . . . . . . . . . . . . . . 26
2.5 Les outils et les Frameworks de déploiement . . . . . . . . . . . . . 27
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Chapitre 3 Conception du processus de déploiement 30
3.1 Choix de l’approche Script . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 CLI de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Architecture de déploiement . . . . . . . . . . . . . . . . . 32
V
Table des matières
3.3.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . 33
3.3.3 Diagramme d’Activité . . . . . . . . . . . . . . . . . . . . . 34
3.3.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . 36
3.3.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . 40
3.3.6 Description de diagramme de classes . . . . . . . . . . . . . 41
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Chapitre 4 Mise en oeuvre du déploiement 43
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Langage et outils de développement . . . . . . . . . . . . . . . . . . 43
4.2.1 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Plate-forme IBM-Bluemix . . . . . . . . . . . . . . . . . . . 45
4.2.3 Plate-forme Heroku . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Description du fonctionnement de notre logiciel . . . . . . . . . . . 47
4.3.1 Lancement de l’application . . . . . . . . . . . . . . . . . . . 48
4.3.2 Menu principal . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.3 Déploiement avec Heroku . . . . . . . . . . . . . . . . . . . 49
4.3.4 Le déploiement avec IBM bluemix . . . . . . . . . . . . . . . 50
4.4 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Conclusion générale 55
Bibliographie 57
VI
Liste des figures
1.1 Evolution du cloud computing . . . . . . . . . . . . . . . . . . . . . 7
1.2 Utilisation du Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Différents modèles de délivrance du Cloud . . . . . . . . . . . . . . 12
1.4 Modèles de déploiement du Cloud . . . . . . . . . . . . . . . . . . . 15
1.5 Les acteurs principaux du cloud computing . . . . . . . . . . . . . . 18
3.1 Architecture de déploiement . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Diagramme de cas d’utilisation de notre système . . . . . . . . . . . 34
3.3 Diagramme d’Activité . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Diagramme de séquence pour le déploiement . . . . . . . . . . . . . 37
3.5 Diagramme de séquence pour "installation et configuration" . . . . 39
3.6 Diagramme de Classes . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Logo de Script shell . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Logo de Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Plate-forme Bluemix . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Plate-forme Heroku . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 Appel de notre application . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Menu principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7 déployer au niveau de la machine local . . . . . . . . . . . . . . . . 50
4.8 déployer au niveau du service web d’hébergement GitHub . . . . . . 50
4.9 Déploiement au niveau de la machine locale . . . . . . . . . . . . . 51
4.10 déployer au niveau du service web d’hébergement GitHub . . . . . . 52
4.11 La métrique temps consommé sans/ avec l?aide de notre solution
«déploiement automatique» . . . . . . . . . . . . . . . . . . . . . . 53
4.12 La métrique effort fourni sans/ avec l?aide de notre solution
«déploiement automatique» . . . . . . . . . . . . . . . . . . . . . . 54
VII
Acronymes
AMI : Amazon Machine Image
AWS : Amazon Web Services
CLI : Command Line Interface
EC2 : Elastic Computing Cloud
IaaS : Infrastructure as a Service
IDL : Interface Definition Language
OMG : Object Management Group
OSGi : Open Services Gateway initiative
PaaS : Platform as a service
PIM : Platform-Independent Model
PSM : Platform-Specific Mapping
SaaS : Software as a Service
SH : Script Shell
VM : Virtuel Machine
XML : Extensible Markup Languageï¿1
2
UML : Unified Modeling Language
VIII
Acronymes
API : Application Programming Interface
S3 : Service de Stockage Simple
IX
Introduction générale
Au cours de ces dernières années, avec le développement rapide des technologies
de l’information, de nombreuses organisations et entreprises cherchent la meilleure
façon de réduire les coûts de fonctionnement, d’assurer la mise à l’échelle de leurs
systèmes informatiques, de fournir la bonne performance à leurs applications tout
en optimisant l’utilisation des ressources. Cette problématique trouve une réponse
dans l’utilisation du concept de Cloud Computing où les techniques de concep-
tion et moyens de déploiement, de gestion des applications des utilisateurs et la
fourniture de ressources informatiques pour faciliter et garantir la performance
souhaitable sont devenus de véritables défis.
Le Cloud computing est très attractive pour les entreprises/utilisateurs
pour plusieurs raisons économiques : il nécessite un investissement faible pour
l’infrastructure et des coûts de fonctionnement bas qui sont fondés sur la notion
de payez uniquement ce que vous consommez". Cependant, dans le marché de
Cloud computing, il n’existe pas un seul nuage homogène mais plusieurs nuages dis-
parates. Ainsi, le Cloud computing a émergé ces dernières années pour compléter
les technologies des systèmes distribués et ajouter de nouvelles caractéristiques à
l’approvisionnement des ressources pour les applications.
Dans le contexte de l’adoption du Cloud computing par les développeurs de
logiciels, le déploiement d’applications a pris de l’importance.
Ainsi, le déploiement est l’étape qui arrive en <fin> du cycle de vie du logiciel
est une étape complexe qui permet non seulement d’installer le logiciel, mais de
le gérer jusqu à la fin de sa vie. Plusieurs activités entrent alors en jeu ; comme
la mise à jour ou la désinstallation.il s’agit alors de prendre en charge le logiciel
depuis son installation, jusqu à sa désinstallation , en passant par touts les phases
1
Introduction générale
de maintenance (évolutive ou corrective). Cette étape a pris de l’importance ces
dernières années. En effet, avec le développement d’internet, il est maintenant pos-
sible de déployer un produit directement depuis son producteur vers une machine
cible définie.
Pour exécuter un logiciel correctement dans une architecture de Cloud, il est
nécessaire de déployer non seulement le logiciel lui-même, mais aussi ses dépen-
dances (c-à-d d’autres services dont le logiciel dépend au cours de son exécution).
Pour satisfaire à cette exigence, chaque développeur, qui a besoin de déployer
une application dans le nuage doit acquérir une clé d’accès au fournisseur de
Cloud, sélectionnez une instance de machine dans le fournisseur qui prend en
charge l’application ainsi que configurer et installer la machine virtuelle. Après
cela, le développeur doit déployer l’application et ses dépendances (dans un ordre
approprié) dans la machine virtuelle sélectionnée.
Cependant, le moyen le plus efficace pour déployer le logiciel dans
l’environnement de nuage est grâce à l’automatisation de ce processus, étant donné
que les détails de configuration peuvent être extraites à un niveau supérieur en
diminuant ainsi les efforts humains pour l’exécuter.
L’objectif de notre projet est de proposer de prendre en charge ce processus
d’automatisation du déploiement d’applications dans le Cloud en faisant le choix
d’expérimenter le processus de déploiement sur deux plateformes de Cloud dif-
férentes en premier lieu afin de pouvoir le généraliser par la suite à d’autres Clouds.
Ce présent document est organisé comme suit :
• Chapitre 1 : présente un état de l’art sur le cloud computing en mettant
l’accent sur la définition du concept cloud, ses modèles ainsi que les outils et
platformes utilisés.
• Chapitre 2 : présente le concept de déploiement d’applications et discute
les travaux de déploiement automatique existants dans le contexte du cloud
computing.
• Chapitre 3 : explicite la démarche conceptuelle de la solution adoptée du
déploiement automatique dans le cadre de notre projet de fin d’études.
2
Introduction générale
• Chapitre 4 : discute les aspects d’implémentation du déploiement automa-
tique d’applications.
Enfin, nous concluons ce travail par des perspectives pour améliorer le produit
réalisé.
3
Chapitre 1
Cloud Computing : état de l’art
Introduction
Indéniablement, la technologie de l’internet se développe de manière exponentielle
depuis sa création. Actuellement, une nouvelle "tendance" a fait son apparition
dans le monde des Technologies de l’information et de la communication (IT). Il
s’agit du cloud computing. Cette technologie, s’appuyant sur le WEB 2.0, offre
des occasions aux sociétés de réduire les coûts d’exploitation des logiciels par leurs
utilisations directement en ligne. Divers fournisseurs comme Google, Amazon,
IBM offrent une vaste gamme de services de Cloud Computing. Cette technologie
vient juste d’éclore où elle est au début de son exploitation mais déjà plusieurs
acteurs majeurs cités précédemment adoptent leurs propres stratégies de pionnier
qui déterminera l’utilisation du cloud computing des entreprises souhaitant investir
ce domaine.
1.1 Les fondements du cloud
Le «Cloud Computing» est l’évolution de concepts informatiques étudiés et
développés depuis les années septante. Ces concepts ont évolué avec la technolo-
gie, les besoins des utilisateurs et un besoin constant de réduire les coûts liés à
l’informatique. Afin de définir les fondements du cloud computing, nous intro-
duisons les concepts liés.
4
Chapitre 1. Cloud Computing : état de l’art
1.1.1 L’informatique utilitaire de John McCarthy
Ce concept se base sur la notion de consommation et a été proposé en 1961,
lors d’une conférence au MIT (Massachusetts Institute of Technology), par John
McCarthy aussi connu comme l’un des pionniers de l’intelligence artificielle (dont il
proposa le nom en 1955) et pour avoir inventé du LISP en 1958. Lors de ce discours,
John McCarthy suggéra que la technologie informatique partagée «time-sharing»
pouvait construire un bel avenir dans lequel la puissance de calcul et même les
applications spécifiques pouvaient être vendues comme un service public. Cette
idée, très populaire dans les années 60, disparu au milieu des années 70 : à l’époque,
les technologies matérielles, logicielles et réseaux n’étaient tout simplement pas
prêtes. Le Cloud Computing met en oeuvre l’idée d’informatique utilitaire du
type service public, proposée par John McCarthy.
1.1.2 Les services bureau
C’est dans cette philosophie, que depuis les années 70, on inventa la notion de
«service bureau» pour qualifier une entreprise louant des lignes téléphoniques,
répondeurs, services informatiques etc. Généralement, les clients des «services
bureau» n’ont ni l’ampleur ni l’expertise pour intégrer en interne ces services,
c’est pourquoi ils passent par un prestataire. La combinaison de technologies,
processus et expertise dans le domaine des entreprises est la valeur ajoutée des
«services bureau», comme modèle économique basé sur leur capacité à produire
des services et à les déployer en volume.
1.1.3 Les applications service providers
Les ASP, «Application Service Provider» ont aussi leur part dans l’historique du
Cloud Computing. Une ASP désigne une application fournie comme un service,
c’est ce que l’on nomme maintenant SaaS pour «Software as a Service» dans la
terminologie actuelle du Cloud Computing. Plutôt que d’installer le logiciel sur
le poste client en ayant à assurer les phases d’installation et de maintenance sur
chaque poste, les applications ASP sont hébergées et centralisées sur un serveur
unique et accessible par les clients au travers de protocole standard. C’est par
exemple le cas avec des applications Web accessibles par http : il n’y a alors plus de
5
Chapitre 1. Cloud Computing : état de l’art
déploiement ou de maintenance à effectuer sur le poste utilisateur, celui-ci n’a alors
besoin que d’un simple navigateur Internet. Le déploiement, la configuration, la
maintenance, la sauvegarde, etc. sont désormais de la responsabilité du fournisseur
du service, le client est alors consommateur.
1.1.4 La virtualisation
Comme nous le verrons dans la suite, la virtualisation a été la première pierre
vers le Cloud Computing. En effet, cette notion permet une gestion optimisée
des ressources matérielles dans le but de pouvoir y exécuter plusieurs systèmes
«virtuels» sur une seule ressource physique et fournir une couche supplémentaire
d’abstraction du matériel. Les premiers travaux peuvent être attribués à IBM,
qui dans les années 60, travaillait déjà sur les mécanismes de virtualisation en
développant dans les centres de recherche de Cambridge et de Grenoble, CMS
(Conversation Monitor System), le tout premier hyperviseur. C’est donc depuis
presque 50 ans que l’idée d’une informatique à la demande est présente dans les
esprits même si les technologies n’étaient jusqu’alors pas au rendez-vous pour pou-
voir concrétiser cette idée.
1.2 L’évolution de Cloud computing
Le Cloud computing est le fruit d’une évolution pouvant être présentée en 5 phases :
• Elle débute avec les Fournisseurs d’Accès Internet (FAI 1.0). Ils ont pour
but de mettre en place des moyens de télécommunication pour assurer le
raccordement des personnes ou entreprises au réseau internet.
• La seconde phase est l’orientation des FAI vers l’hébergement de pages
web (FAI 2.0). Cette phase marque un grand bond dans le développement
d’internet.
• La troisième phase (FAI 3.0) est la possibilité qu’offrent les FAI à héberger
des applications métiers des entreprises.
• Une connaissance des besoins applicatifs des entreprises permettent aux FAI
de faire évoluer leur domaine d’intervention. Ils mettent en place des plate-
6
Chapitre 1. Cloud Computing : état de l’art
formes de génération d’applications à la demande. Il s’agit des ASP (Appli-
cation Service Provider) dont les "Software as a Service" sont des dérives :
c’est le FAI 4.0.
• La généralisation des pratiques précédentes, la prise en compte de nouvelles
pratiques et l’intégration des principes que nous présentons dans les sections
suivantes donnent naissance au cloud computing [Fos98].
Figure 1.1: Evolution du cloud computing
1.3 Cloud Computing : Définition et Concepts
Le terme «Cloud Computing» possède plusieurs définitions. Nous présentons ci-
dessous quelques-unes de ces définitions.
1. Microsoft : L’ensemble des disciplines, technologies et modèles commer-
ciaux utilisés pour délivrer des capacités informatiques (logiciels, plates-
formes, matériels), comme un service à la demande.
• Le service à la demande (vous ne payez que ce que vous utilisez).
• Le service est accessible n’importe où.
7
Chapitre 1. Cloud Computing : état de l’art
• Le service est mesuré, ce qui permet de préserver les ressources.
• La quantité est modulable à la location (élasticité infinie).
• La quantité est modulable à la location (élasticité infinie).
• Les ressources sont mises en commun, ce qui réduit les coûts.
2. Cisco : Les ressources informatiques et les services sont abstraits par
rapport à l’infrastructure sous-jacente et sont fournis à la demande.
3. NIST, National Institute of Standards Technology : Le Cloud Com-
puting est un modèle d’accès à des ressources informatiques partagées et
configurables, depuis un accès réseau, à la demande,de manière simple, à
partir de n?importe quel type d?appareil et depuis n’importe quel endroit.
Ces ressources sont disponibles rapidement et opérationnelles avec un mini-
mums efforts et d’interactions avec le fournisseur de services.
4. EMC, Fournisseur de solutions d’archivage et de stockage : Le Cloud
Computing permet aux utilisateurs d’accéder aux pools de ressources quand
ils le souhaitent et bénéficient ainsi de l’éfficacité partagée et de souplesse.
5. Open Group : Le Cloud Computing est représenté comme un cube de
quatre dimensions :
• La localisation physique des données (interne ou externe) par rapport
à l’entreprise.
• La propriété (propriétaire ou ouvert) : il s’agit non seulement de savoir
si vous êtes propriétaire de la technologie, mais aussi de se poser des
questions en termes d’interopérabilité,de facilité quant au transfert des
données et à votre degré de dépendance par rapport à votre fournisseur.
• Les frontières de sécurité (périmètre ou hors périmètre).
• L’externalisation : le service est-il fourni par le client ou par un four-
nisseur externe.
8
Chapitre 1. Cloud Computing : état de l’art
Figure 1.2: Utilisation du Cloud
1.4 Cloud vs Grilles
Introduites pour la première fois dans les années 90, les grilles de calcul situent
la mutualisation au coeur de leur technologie. De même, la mutualisation est au
coeur de la technologie du Cloud computing. La question que se pose : "A quel
niveau se situe la différence entre le Cloud et les grilles (si elle existe)?". Autrement
dit, le terme "Cloud Computing" n’est-il pas une autre appellation de "Grid Com-
puting"?
Dans la littérature, nous ne trouvons qu’une étude sérieuse consacrée entièrement
à cette comparaison [FZRL08]. D’un point de vue technologique, il n’y a pas de
réelle différence entre les plateformes de grille et de Cloud. Cependant, l’ouverture
du Cloud aux utilisateurs de différents niveaux (pas toujours des informaticiens
comme dans les grilles) et éventuellement son caractère commercial sont les poten-
tielles différences. De plus, dans les environnements de grilles, les applications (ap-
pelées le plus souvent job) s’exécutent généralement sur une durée limitée (même
si celle-ci peut être illimitée comme dans le Cloud). Ces différences rendent la ges-
9
Chapitre 1. Cloud Computing : état de l’art
tion et l’utilisation des plate-formes de Cloud plus complexes que dans les grilles.
En résumé, nous considérons que la technologie de Cloud computing utilise la
technologie de grille à laquelle elle associe les principes d’ouverture au public de
facturation, et d’hébergement durable [FZRL08].
1.5 Les caractéristiques essentielles de cloud com-
puting
La définition du National Institute of Standards and Technology américain est
souvent considéré comme étant une des références en la matière et elle présente les
cinq caractéristiques essentielles du «Cloud Computing» [MG11] qu’on va présen-
ter dans ce qui suit.
1.5.1 Self-service à la demande
L’utilisateur d’un service de «Cloud Computing» a la capacité («self-
provisioning») d’approvisionner lui-même de nouvelles ressources telles que de
l’espace disque, des serveurs virtuels, du temps CPU, des nouvelles boîtes aux
lettres.
1.5.2 Elasticité et rapidité
Les ressources peuvent être allouées ou désallouées rapidement. C’est une des
caractéristiques essentielles du Cloud computing; la capacité d’augmenter et de
réduire le volume des ressources utilisées en fonction des besoins, de même que
libérer les ressources qui ne sont plus nécessaires, au profit d’autres utilisations,
ces opérations peuvent se faire par demande ou de façon automatique, par pro-
grammation ou triggers.
1.5.3 Accès aux ressources
Les ressources sont disponibles via le réseau Internet, ou via l’Intranet dans le
cas d’un Cloud privé. Les ressources sont accessibles via des protocoles standards
(TCP/IP, SSL, HTTP). L’accès aux ressources peut se faire à partir d’un grand
10
Chapitre 1. Cloud Computing : état de l’art
nombre de périphériques clients (ordinateurs, clients légers, portables, téléphones
mobiles, smartphones) et depuis n’importe quelle plate-forme (Windows, Unix,
MacOs, Linux, systèmes propriétaires,...).
1.5.4 Allocation des ressources
Les ressources mises à disposition par les providers de «Cloud Computing» sont
mutualisées pour répondre aux besoins de plusieurs clients dans une architecture
multi-tenant. Une architecture «multi-tenant» ou «multi-locataire» fait qu’une
seule instance d’une application est adaptée aux besoins de tous les utilisateurs et
offre malgré tout un certain niveau de customisation pour s’adapter de manière
individualisée aux différents clients.
1.5.5 Mesure du service
Les systèmes contrôlent et optimisent automatiquement l’utilisation des ressources
par rapport à une moyenne estimée de consommation du service.
1.6 Taxonomie du cloud computing
Différents types des modèles de cloud existent dans la littérature, afin de les
représentés nous devons constater les principaux critères de classification :
• Le niveau de service c’est le type de service que peut être délivré par le
cloud aux clients.
• L’accessibilité Les services de cloud diffèrent également dans la façon dont
l’accessibilité de leurs déploiements.
• La raison de développement C’est la raison qui justifie le déploiement de
la plateforme de cloud.
1.6.1 Modèle de délivrance
Le cloud computing est la livraison des ressources informatiques comme un service
plutôt qu’un produit, selon laquelle les ressources informatiques sont fournies aux
11
Chapitre 1. Cloud Computing : état de l’art
clients suivant trois services majeurs : Infrastructure en tant que service (IaaS),
Plateforme en tant que service (PaaS) et Logiciel en tant que service (SaaS).
Souvent l’ensemble de ces catégories de service est représenté sous la forme d’une
pile, afin d’illustrer les différentes étapes potentiellement existantes au sein de la
chaîne de production de services via le cloud. Cette pile est représentée sur la
Figure 1.3, son niveau inférieur, représente les ressources matérielles et réseaux
informatiques primaires, puis les trois niveaux intermédiaires représentent les trois
types de services du modèle de délivrance, et enfin le niveau supérieur représente
les interactions entre les utilisateurs finaux des services proposés et le cloud.
Figure 1.3: Différents modèles de délivrance du Cloud
Infrastructure en tant que service
L’infrastructure en tant que service est plus connue sous le nom d’IaaS pour
«Infrastructure as a Service». Ce type de service permet aux développeurs et aux
ingénieurs système d’administrer et d’exploiter un «data center». L’infrastructure
en tant que service ou l’IaaS permet aux utilisateurs de disposer d’une infrastruc-
ture à la demande, peut héberger et exécuter des applications et des services, ou
12
Chapitre 1. Cloud Computing : état de l’art
être utiliser de façon générique en tant que ressource informatiques au lieu virtuel,
tel que le stockage de données et le calcul haut de performance.
L’utilisateur n’a aucun contrôle sur l’infrastructure sous-jacente du provider de
Cloud mais il a le contrôle sur le système d?exploitation, les applications déployées,
les données stockées et un contrôle limité sur les composants réseaux sur le serveur
virtuel. On retrouve dans cette catégorie les plateformes comme Amazon Elastic
Compute Cloud (EC2) ainsi que d?autre ElasticHosts, GoGrid, Rackspace Cloud,
RightScale, Skytap et Orange Business.
Plateforme en tant que service
La Plateforme en tant que service (PaaS) fournit une couche d’abstraction plus
élevé que l’IaaS dans lequel le cloud fournit une plateforme d’exécution, de dé-
ploiement et de développement des applications autrement-dit une plateforme ap-
plicative de programmation . Les services offerts par ce niveau facilitent la pro-
grammation et le déploiement des applications dans le cloud aux utilisateurs sans
faire attention à l’infrastructure sous-jacente «achat de logiciels et l’installation
supplémentaires. L’utilisateur n’a aucun information sur l’infrastructure sous-
jacente du provider de Cloud tel que serveurs virtuel, les composants réseaux,
l’emplacement de stockage et le système d’exploitation mais il a le contrôle sur les
applications programmées et l’environnement d’hébergement tel que le paramé-
trage des services Web, structure des bases de données, nombre de serveurs.
On peut distinguer deux types principaux de plateformes en tant que services :
• Les plateformes qui offrent des services accessibles en ligne présentées via
des API, l’utilisateur interagit avec cette plateforme via une API pour le dé-
ploiement de service, c’est le cas de Windows Azure de Microsoft, AppEngine
de Google, Force.com de Salesforce.
• Les plateformes qui offrent des services de type middleware à installer, le but
derrière ce type de plateforme est de permettre aux utilisateurs d’ajouter
des fonctions personnalisées aux services classiques, c’est le cas de Appistry,
AppScale, VMware vSphere.
Logiciel en tant que service
Logiciel en tant que service (SaaS) offre des applications complètes fournies à
la demande. Ce type de service fournit différents types d’applications telle que
13
Chapitre 1. Cloud Computing : état de l’art
webmail, suite de bureautique en ligne, CRM, ERP ainsi que les réseaux sociaux
et les jeux. Ces applications s’exécutent sur les infrastructures du provider. Elles
sont hébergées sur le cloud et accessibles via un navigateur Internet. L’utilisation
des services SaaS est plus simple que les autres services où la facturation s’adapte
dynamiquement avec la consommation et la paramétrisation des services offerts
sont limités. L’utilisateur n’a aucun souci sur l’installation des logiciels ou de
leur mise à jour et il n’a aucun contrôle sur l’infrastructure du Cloud tel que
serveurs virtuel, les composants réseaux, l’emplacement de stockage, la version de
l’application et les fonctions d’application disponibles [TBB03]. On peut distinguer
deux types principaux de logiciels ou applications en tant que services :
• Des applications sont disponibles au publique général totalement gratuit,
par exemple Services Gmail et Facebook, où les e-mails, pièces jointes dé-
mail, photos, vidéos et musiques. Généralement ce type d’application est
indirectement financé par la publicité, ou par des produits dérivés de l’analyse
statistique à grande échelle.
• Des applications sont disponibles pour répondre aux attentes des entreprises
payantes selon la consommation. Ces applications sont conçues pour fournir
des logiciels faciles à utiliser.
1.6.2 Modèles de déploiement
La mission principale de providers de cloud computing est de rendre le cloud
disponible pour tous les consommateurs. Le cloud peut être accessible pour tous
les consommateurs et donc on est dans le cloud public. Il peut être aussi accessible
seulement pour des consommateurs particuliers et on se retrouve dans le cas de
cloud privé. On peut distinguer trois types de cloud selon le modèle de déploiement
: le cloud public, le cloud privé et le cloud communautaire. La figure 1.4 montre
l’utilisation du cloud public et le cloud privé.
14
Chapitre 1. Cloud Computing : état de l’art
Figure 1.4: Modèles de déploiement du Cloud
• Le cloud public : Le cloud public est accessible publiquement à tous les
particuliers et les groupe industriels. Son propriétaire est un fournisseur de
service IaaS, PaaS ou SaaS. Les consommateurs ne sont facturés que pour les
applications, les services ou les données qu’ils utilisent. Les ressources sont
illimitées et il n’y a donc aucun investissement initial. Les «Clouds» publics
sont généralement exploités par des les fournisseurs de cloud commerciaux
comme Amazon, Google, Microsoft, GoGrid.
• Le cloud privé : Un cloud privé est une infrastructure de cloud n’est
utilisé que par une seule organisation. Le cloud privé peut être gérée par
l’organisation elle-même ou par un prestataire de service qui peut être située
dans les locaux de l’organisation ou à l’externe chez le prestataire de services.
L’avantage supplémentaire du cloud privé c’est contrôle total des données
par l’organisation, d’autre façon il permet la confidentialité et la sécurité des
données grâce aux ressources qui ne peuvent pas être partagées par d’autre
organisations [CC12].
• Le cloud hybride : Le cloud hybride est une composition de deux ou
plusieurs infrastructures de Cloud publics et privés. Généralement les don-
nées sensibles sont gérées au niveau interne par l’organisation ou chez le
15
Chapitre 1. Cloud Computing : état de l’art
prestataire de cloud prive et l’autre type de données sont gérées par le cloud
public.
1.6.3 Le modèle business
L’utilisation du cloud computing ne se limite pas uniquement aux entreprises à
caractère commercial. Il existe d’autre raisons pour le déploiement de cloud com-
puting, nous présentons par la suite deux types d’architecture de cloud computing
:
• Cloud d’Entreprises : Dans cette catégorie, nous retrouvons des en-
treprises de petites et de moyennes tailles disposant chacune de peu de
ressources et de moyens de maintenance de leurs infrastructures. Elles se re-
groupent donc autour d’un projet de cloud afin de mutualiser leurs capacités.
La plate-forme qui en découle est privée, c’est-a-dire accessible uniquement
par les entités des différentes entreprises. Cette plate-forme à l’avantage
d’être de petite taille et d’accès restreint à des utilisateurs connus.
• Cloud Gouvernemental et Recherche Scientifique : Pour des raisons
de recherche et de développement, des instituts de recherche mettent sur pied
des environnements de cloud. Leur développement est encouragé et financé
par des gouvernements. L’accès est exclusivement réservé aux personnes
exerçant dans le même domaine de recherche, ou appartenant aux instituts de
recherche associées, ou ayant une dérogation précise. Ces plate-formes sont
pour la plupart orientées projets. Seules les avancées scientifiques obtenues
par les groupes de recherche qui l’utilisent permettent de valoriser la plate-
forme.
1.7 Avantages et inconvénients du Cloud Comput-
ing
Dans cette section, nous discuterons les avantages et les inconvénients du cloud
computing.
16
Chapitre 1. Cloud Computing : état de l’art
1.7.1 Avantages
• Un démarrage rapide : Le Cloud computing permet de tester le business
plan rapidement, à coûts réduits et avec facilité.
• L’agilité pour l’entreprise : Résolution des problèmes de gestion informatique
simplement sans avoir à vous engager à long terme.
• Un développement plus rapide des produits où le temps de recherche est
réduit pour les développeurs sur le paramétrage des applications.
• Pas de dépenses de capital : Plus besoin des locaux pour élargir les infras-
tructures informatiques
1.7.2 Inconvenients
• La bande passante peut faire exploser le budget d’un utilisateur.
• Les performances des applications peuvent être amoindries : Un Cloud public
n’améliorera définitivement pas les performances des applications.
• La fiabilité du Cloud : un grand risque lorsqu’on met une application qui
donne des avantages compétitifs ou qui contient des informations clients dans
le Cloud
• Taille de l’entreprise : Si l’entreprise est grande alors les ressources sont
grandes, ce qui inclut une grande consommation du Cloud. Dans ce cas là,
il peut-être plus intéressant de mettre au point un Cloud privé plutôt que
d’en utiliser un externalisé. Les gains sont bien plus importants quand on
passe d’une petite consommation de ressources à une consommation plus
importante.
1.8 Les plateformes cloud computing
Grâce aux caractéristiques de cloud, plusieurs compagnies se sont intéressées à ce
paradigme et ont développé un certain nombre de solutions dont certaines sont
commercialisées. Dans chaque modèle de Cloud Computing, nous trouvons des
17
Chapitre 1. Cloud Computing : état de l’art
acteurs principaux, tels qu’Amazon, Microsoft, Google, Salesforce.com et Euca-
lyptus.
Figure 1.5: Les acteurs principaux du cloud computing
1.8.1 Amazon Web Services (AWS)
Au début de 2006, Amazon a commencé à fournir l’environnement AWS, qui est
un outil facile à utiliser, fiable et économique, qui offre une plateforme de Cloud
Computing à travers des services web. La clé du succès de cette plate-forme (plus
de 60 000 clients individuels) est dûe au fait qu’elle offre un service immédiat, ne
contenant pas de contrats et utilisant le principe «pay as you go» pour le paiement
des services utilisés. Amazon Web Services (AWS) est une collection de services
informatiques distants (aussi appelés services Web).
1.8.1.1 Elastic Computing Cloud (EC2)
EC2 est un ensemble d’infrastructures physiques localisées sur une très large échelle
et notamment en Europe et aux Etats-Unis. Il est utilisé par Amazon pour fournir
18
Chapitre 1. Cloud Computing : état de l’art
des environnements de type IaaS (Infrastructure as a Service). EC2 fournit une
grande partie des caractéristiques du Cloud Computing, dont les plus importantes
sont :
• Scalabilité : Amazon fournit une interface pour définir des règles lorsque
l’application doit supporter un facteur d’échelle.
• Localité transparence : Le client/l’utilisateur final n’a pas besoin de savoir
où les applications se trouvent sur le cloud. Amazon offre des adresses IP
élastiques " Elastic IP Addresses" qui lient une adresse IP à un compte
utilisateur.
• Equilibrage de charge : C’est un service gratuit qui, automatiquement
et de manière transparente, distribue le trafic (charge) entre les instances
disponibles d’une infrastructure.
D’un point de vue technique, lorsqu’une image de l’infrastructure
(AMI)(Amazon Machine Image) est démarrée quelque part dans le cloud et que le
client reçoit un chemin pour l’utiliser, celui-ci peut ainsi utiliser Amazon le service
à travers EC2Web pour configurer la sécurité, l’accès au réseau et choisir le type
d’instance, arrêter et surveiller les instances de l’utilisateur AMI utilisant les API
de service Web. EC2 prévoit deux types différents d’instance : un type standard
qui est conçu pour répondre aux besoins de la plupart des clients et des instances
spécifiques qui sont destinées à des applications de calcul intensif.
1.8.2 Service de Stockage Simple(S3)
Le S3 (ou Service de stockage simple) est un IaaS mis en place pour le stockage
séparé, comme une ressource pour les applications web. Du point de vue PaaS,
il fournit une interface de service Web (sous forme de SOAP / WSDL / XML ou
REST) qui est utilisée pour récupérer et stocker des données de toute taille à tout
moment.
1.8.3 Google AppEngine
Google AppEngine est une plate-forme as a servise (PaaS) qui permet aux util-
isateurs de construire des applications Web qui fonctionnent sur l’infrastructure
19
Chapitre 1. Cloud Computing : état de l’art
de Google dans un environnement Java ou Python. L’environnement Java et les
environnements d’exécution Python sont conçus pour assurer une exécution rapide
des applications, en toute sécurité, et sans interférence de la part d’autres appli-
cations. L’AppEngine de google a beaucoup de services sous-jacents fournis par
AWS, comme IaaS sous la forme de DataStore, qui offre les mêmes fonctions que
SimpleDB AWS et sur JDO qui permet le stockage comme S3. Bien qu’il existe
un grand nombre de quotas sur le disque dur, le service est gratuit et il est pos-
sible d’utiliser des espaces hors de disque dur moyennant un paiement. Il offre
également d’autres fonctions comme Memcache, qui fournit une mémoire cache
partagée distribuée pour les applications et urlfetch, qui permet l’extraction des
ressources et la communication avec d’autres hôtes utilisant le protocole HTTP
en toute sécurité via HTTPS. Il fournit également un service de messagerie avec
l’API Mail. Avec AppEngine, on ne paye que ce que l’on utilise. Il n’y a pas
de frais d’installation et pas de frais récurrents. Les ressources utilisées par une
application, comme le stockage et la bande passante, sont mesurées par gigaoctets
et facturées à des tarifs compétitifs. AppEngine ne coûte rien pour commencer.
Toutes les applications peuvent utiliser jusqu’à 500 Mo de stockage, une puissance
de calcul et une bande passante suffisante pour soutenir une application efficace
au service d’environ 5 millions de pages vues par mois, tout à fait gratuitement.
Lorsqu’un utilisateur active la facturation de son application, des limites libres
sont soulevées et il ne paye que pour les ressources qu’il a utilisées au delà du
niveau libre.
1.8.4 Windows Azure
Windows Azure est une fondation pour exécuter des applications et stocker des
données dans un cloud. Elle fournit les logiciels que les clients de Microsoft peu-
vent installer et exécuter eux-mêmes sur leur propre ordinateur. Windows Azure
est aujourd’hui un service, que les clients utilisent pour exécuter des applications
et stocker des données sur des machines accessibles par Internet appartenant à
Microsoft. Ces applications peuvent fournir des services aux entreprises, aux con-
sommateurs ou les deux. Windows Azure a été conçue en partie au soutien de Mi-
crosoft applications SaaS, si les éditeurs de logiciels peuvent aussi l’utiliser comme
une base pour une variété de logiciels de clouds à vocation commerciale.
20
Chapitre 1. Cloud Computing : état de l’art
1.9 Conclusion
Le cloud computing repose bien souvent sur des techniques qui existent depuis
parfois de nombreuse années. C’est à la fois son point fiable et son point fort.
Se baser sur l ’existant donne confiance aux utilisateurs potentiels et assure une
certaine stabilité et une expertise dans le domaine. Malheureusement, c’est égale-
ment en essayant de faire du neuf avec du vieux qu’on se retrouve parfois dans des
situation alambiquées ou des techniques récentes reposent sur des concepts trop
anciens.
Néanmoins, la plus grande force du cloud computing est son utilisation à des fins
commerciales : payer uniquement ce qui est consommé.
21
Chapitre 2
Déploiement d’applications : tour
d’horizon
Introduction
Le Cloud Computing, est un nouveau modèle informatique qui consiste à pro-
poser les services informatiques sous forme de services à la demande, accessi-
bles de n’importe où, n’importe quand et par n’importe qui. Très utilisé dans
l’informatique répartie qui permet d’accéder à des ressources virtuelles config-
urables (e.g., serveurs, espace de stockage, bande passante) sous forme de services.
Pour être accessible en tant que service (Software-as-a-Service, SaaS) sur le
Cloud, une application peut être déployée soit sur l’infrastructure (Infrastructure-
as-a-Service, IaaS) du fournisseur de Cloud, soit sur la plateforme qui va l’exécuter
(Platform-as-a-Service, PaaS). Dans les deux cas, il faut configurer et dimen-
sionner l’environnement d’exécution selon l’application pour prendre en compte
l’hétérogénéité et l’élasticité inhérentes au paradigme du Cloud Computing.
Notamment, il existe un grand nombre de provider ayant des niveaux de
fonctionnalité et des possibilités de dimensionnement hétérogènes parmi les dif-
férentes solutions de cloud disponibles (Amazon EC2, Rackspace cloud , Win-
dowsAzure). Lors d’un déploiement d’application sur un PaaS, il faut choisir un
serveur d’application, la fréquence CPU nécessaire à l’exécution, la base de don-
22
Chapitre 2. Déploiement d’applications : tour d’horizon
nées à utiliser, sa capacité en terme espace mémoire, etc. Cette variabilité en
termes de configuration et de dimensionnement offre une multitude de possibil-
ités de configurations qui sont généralement effectuées de manière ad hoc et sont
sources d’erreurs lorsqu’elles sont configurées à la main [QD12].
La structure du chapitre est la suivante, la section 2 est dédiée à l’élaboration du
problème de déploiement. La section 3 décrit les concepts de base de déploiement
automatique. Afin de faciliter la compréhension du problème de déploiement, nous
montrons dans la 4 section les principales approches ou techniques utilisées. Dans
la section 5, nous discutons les travaux connexes et enfin nous terminons notre
chapitre par une conclusion.
2.1 Motivation
Le déploiement d’une application dans le Cloud offre à son propriétaire de nom-
breux avantages : réduction des coûts, passage à l’échelle, haute disponibilité,
etc.
Cependant, la migration d’une application ou le développement d’un nouveau
service dans le Cloud est un défi sérieux. En effet, il existe différent choix au mo-
ment de sélectionner le fournisseur de Cloud capable à fournir l’environnement pour
héberger l’application en tant que service. Ainsi, certains utilisateurs préfèrent dé-
ployer leur application vers une solution de Cloud qu’ils ont déjà utilisée mais qui
ne correspond pas complètement aux exigences de l’application à déployer (e.g.,
changer le type de base de données) plutôt que de se risquer à configurer un nou-
veau cloud computing malgré qu’il est plus adapté à leurs exigences [QD12].
L’émergence vers le cloud computing exige aux développeurs de reconstruire ou
reconcevoir sensiblement les applications existantes pour répondre aux nouvelles
exigences.
Le Cloud offre de nombreux choix de configuration et de dimensionnement tant
au niveau de l’application à déployer que des environnements d’exécution IaaS
ou PaaS paramétrables. Il est donc très difficile de prendre les bonnes décisions
23
Chapitre 2. Déploiement d’applications : tour d’horizon
face aux questions suivantes : Quel niveau de déploiement PaaS? ou IaaS? Quel
fournisseur choisir? Comment être sûr qu’il représente une bonne solution pour les
types d’applications et de déploiements souhaités? Il était possible aux logiciels
existants de bénéficieer d’un nouveau environnement exécution.
2.2 Le déploiement automatique des logiciels dans
le cloud computing
Pour exécuter correctement un logiciel dans une architecture de cloud, il est néces-
saire de déployer non seulement le logiciel lui-même, mais aussi ses dépendances
(e.g., les autres services qui ont une dépendance avec le logiciel du moment où il
est en cours d’exécution). Pour satisfaire cette exigence, chaque développeur, qui
a besoin de déployer une application dans le cloud :
• doit acquérir un accès clé au fournisseur de cloud,
• sélectionner une instance de machine dans le fournisseur qui prend en charge
l’application,
• configurer et installer la machine virtuelle.
Après cela, le développeur a besoin pour déployer l’application et ses dépendances
(dans un ordre approprié) dans la machine virtuelle sélectionnée.
Un moyen plus efficace pour déployer le logiciel dans l’environnement de cloud est
par l’automatisation de ce processus, étant donné que les détails de configuration
peuvent être extraits à un plus haut niveau diminuant ainsi les efforts humains
pour l’exécuter. Un autre avantage du déploiement automatique des logiciels dans
le cloud est l’élimination des tâches manuelles qui sont sujettes à l’erreur, tels
que : le logiciel de configuration de la pile, l’authentification entre les machines
virtuelles, spécification des dépendances entre les composants de service et entre
les services, la définition des temporelle et dépendances spatiales et, enfin, l’analyse
des ressources dans l’environnement cloud afin de remplir les exigences minimales
du service [RJdRSM16].
24
Chapitre 2. Déploiement d’applications : tour d’horizon
2.3 Définition du déploiement automatique
Le déploiement de logiciel est défini dans comme le processus, constitué d’un en-
semble d’activités liées, entre l’acquisition et l’exécution du logiciel. Ce processus
a pour objectif de rendre opérationnel une application, qui peut ainsi être utilisée
par les utilisateurs. Une fois l’application déployée, le processus de déploiement
continue par les mécanismes d’adaptation du logiciel afin de chercher à atteindre
une qualité de service. En effet, les infrastructures modernes sur lesquelles on
déploie des applications sont caractérisées par de fréquentes variations de leur en-
vironnement.
Automatisant un déploiement comprend la planification d’une séquence d’actions
de bas niveau comme ; la création et la suppression de composants, le port de liai-
son et dé-liaison, et les changements d’état interne, qui atteint une configuration
avec au moins un composant dans un état interne de cible spécifique [Fay15].
2.4 Les approches de déploiement
Après une étude bibliographique sur les états de l’art sur les principales approches
du déploiement automatique des logiciels sur le cloud, nous avons sélectionné
quelques-unes d’entre ellex pour une description et une analyse.
Cette section explique les architectures et les solutions adoptées existantes pour le
déploiement automatique des logiciels sur le cloud.
2.4.1 Les scripts
Pour faire face au déploiement automatique, différents outils et solutions utilisent
la codification manuelle par le biais de scripts, ce qui nécessite plus de temps pour
déployer le logiciel. Ce type d’approche réduit le risque d’erreur humaine lors du
processus de déploiement manuelle, et pour le cas de développeur, il s’occupe de
développement d’application au lieu la configuration du cloud.
Le seul inconvénient de ces approches de déploiement, c’est qu’il augmente les
coûts associés à la codification, le temps et les efforts humains [RJdRSM16].
25
Chapitre 2. Déploiement d’applications : tour d’horizon
2.4.2 Langage de programmation
Nous avons également noté d’autre solutions utilisant le déploiement automatisé
de services dans le cloud à l’aide de langage de programmation. En comparaison
avec les approches présentées à l’aide des scripts, ces approches sont plus avan-
tageuses en fonction de l’effort humain et le temps appréciée dans le processus de
déploiement.
2.4.3 Les approches semi-automatiques
En outre, les modèles virtuels proposés par Disnix ont présenté des mécanismes
semi-automatisés pour le déploiement. En d’autres termes, ces approches nécessi-
tent encore que certaines étapes sont effectuées manuellement pendant le processus
de déploiement. La solution proposée par Ardagna et. Al. a présenté une approche
partiellement orientée et semi-automatisée pour le déploiement de logiciel. Elle ex-
ige un certain niveau de la compréhension de l’utilisateur final sur les détails de
la structure des clouds et une charge lourde de l’information dans les modèles de
déploiement demandé à l’utilisateur [RJdRSM16].
2.4.4 Les Workflow
Cette solution propose que les développeurs aient les services à déployer pour
créer les modèles UML du déploiement de logiciels. Ces modèles définissent tous
les informations requises pour le déploiement (machines virtuelles, services, ap-
plications, dépendances, systèmes d’exploitation des machines virtuelles, services
référentiels et des machines virtuelles, des bases de données, fournisseur de ser-
vices et les clés d’accès) en tant que paramètres sans la nécessité du codage de la
configuration d’une machine virtuelle. Ces modèles sont transformés pour générer
le code de déploiement à l’aide d’outils spécialisés.
2.4.5 Approche basée sur les modèles
L’objectif est de déployer le logiciel à un niveau plus élevé d’abstraction pour
réduire les efforts humains et le temps passé à effectuer la tâche de déploiement, car
l’approche basée sur un modèle est une meilleure façon d’augmenter la productivité
26
Chapitre 2. Déploiement d’applications : tour d’horizon
de développeur. Cette approche est la proposition de l’OMG qui est en cours de
standardisation.
La spécification de l’OMG, elle a pour objectif de fournir un modèle de données et
d’exécution permettant de gérer le développement, le packaging, le déploiement et
la configuration d’applications à base de composants. La spécification est décrite à
travers une entité appelée "Platform-Independent Model" (PIM), composée d’un
ensemble de modèles UML et de règles sémantiques associées. Le PIM est indépen-
dant de tout modèle de composant particulier. Pour utiliser cette spécification avec
un modèle particulier de composant, il faut créer une entité appelée "Platform-
Specific Mapping" (PSM). Le PSM est un ensemble de règles qui transforme les
modèles UML du PIM en données et modèles d’exécution, dans un format ap-
proprié pour le déploiement du modèle de composant cible. La spécification n’a
pour l’instant standardiser que le PSM pour le modèle de composant Corba, dans
lequel les modèles de données et d’exécution sont transformés en deux formats :
XML schema pour le stockage sur disque et l’échange entre outils, et IDL (In-
terface Definition Language) pour la représentation du modèle d’exécution et des
communications entre les entités du déploiement.
2.5 Les outils et les Frameworks de déploiement
D’après une étude bibliographique sur les travaux qui s’articulent sur le dé-
ploiement automatique des logiciels sur le cloud computing, nous avons sélectionné
les principaux outils et frameworks de déploiement afin de les décrire :
1. L’outil SALOON est un outil de configuration et de déploiement. Basé
sur des ontologies , SALOON permet de spécifier une configuration tech-
nique pour l’application à déployer et de dimensionner cette configuration
[QRD16].
2. OSGi fournit un environnement d’exécution, basé sur la technologie Java. Le
processus de déploiement inclut les activités suivantes : l’installation, la mise
à jour et la désinstallation. Il fournit un cadre qui permet le déploiement
d’applications Java, extensibles et téléchargeables (appelées "bundle"). Un
"bundle" est constitué de classes Java et d’autres ressources (librairies,
27
Chapitre 2. Déploiement d’applications : tour d’horizon
fichiers, etc.), l’ensemble pouvant fournir un ou plusieurs services aux util-
isateurs. Ils sont déployés sous la forme d’archives JAR (Java ARchive). Les
"bundles" sont les seules entités utilisées pour le déploiement d’applications.
Les appareils OSGi compatibles peuvent télécharger, installer, supprimer les
"bundles". L’installation et la mise à jour se font de manière dynamique, en
gérant les dépendances entre les "bundles" et les services. Les limitations de
ce modèle sont liées au fait qu’il est spécifique à l’environnement Java et à
des applications non distribuées.
3. ACTRESS est un cadre basé sur l’ingénierie des modèles et qui fournit des
outils pour concevoir et intégrer des mécanismes d’adaptation dans une ap-
plication, sous la forme de boucle de contrôle.
4. EUREMA (ExecUtable RuntimE MegAmodels) est aussi une approche basée
sur l’ingénierie des modèles. EUREMA propose un langage de modélisa-
tion et un environnement permettant la spécification et l’exécution de mé-
canismes d’adaptation constitues d’une ou de plusieurs boucles de contrôle.
L’approche repose sur une architecture en couches, dans laquelle le système
auto-adaptatif est séparé logiquement en deux parties: la couche métier qui
fournit les fonctionnalités, et au dessus, la couche qui gère le mécanisme
d’adaptation (de la couche métier), sous la forme de boucles de contrôle
[VG14].
5. Li et al. [LSTE12] ont proposé une encapsulation de services dans des ma-
chines virtuelles et le déploiement de services dans une gamme de cloud
scénarios, tels que le cloud privé, cloud public, cloud fédéré et le multi cloud.
Ils ont conclu que le temps de déploiement dépend du scénario de cloud.
6. Ardagna et al. [ADNC+
12] ont présenté une approche pilotée par les mod-
èles pour la conception et l’exécution des applications sur plusieurs nuages
appelés MODAClouds où ils ont proposé une architecture divisée en deux
points de vue, la conception et temps d’exécution de déploiement de logi-
ciels.
7. Pour découpler une machine virtuelle à partir du logiciel, Zhang et al.
[ADNC+
12] ont élaboré un framework pour le déploiement des applications
28
Chapitre 2. Déploiement d’applications : tour d’horizon
dans le cloud, qui vise à réduire le temps et les coûts liés au déploiement. La
proposition diffère des autres approches présentées jusqu’ici, car le logiciel
ne serait pas préinstallé sur l’image VM. Le framework proposé par Zhang
offre un ensemble de fonctionnalités divisées en trois étapes :(i) la première
étape c’est la préparation de logiciels, le client stock le logiciel dans un dépôt
; (ii) la deuxième étape c’est l’étape de sélection, le client peut sélectionner
un logiciel à partir du référentiel. Le logiciel est installé dans une machine
virtuelle et cette VM est envoyée et installée sur le machine local du client
; (iii) et enfin la dernière partie c’est le déploiement de logiciel, au lieu de
stocker l’application dans une image VM, elle fonctionne sur la machine lo-
cale sur le côté client sans l’installer.
2.6 Conclusion
Dans ce chapitre, nous avons présenté les solutions très récentes qui permettent
de déployer des applications sur le cloud, afin de faciliter le choix de la solution
possible qui répond aux exigences techniques de la configuration et au dimension-
nement de ces exigences.
Vus l’absence d’un consensus entre les comités de standardisation sur les approches
de déploiement automatique des applications sur le cloud et le manque de détails
techniques sur ces approches, il était préférable d’étudier les solutions décrites au
paravant «les outils et framework» d’un point de vu technique en faisant abstrac-
tion des détails théoriques.
L’étude des outils et frameworks, nous a permis de nous orienter vers les scripts.
L’architecture de la solution qui va être présenté dans le chapitre suivant a été
réalisée en respectant les exigences techniques tel que le choix des providers gra-
tuits.
29
Chapitre 3
Conception du processus de
déploiement
Introduction
Nous avons présenté dans le chapitre précédent les principales contributions sur le
déploiement automatique des applications sur le cloud. Parmi les approches citées
(chapitre 2, section 4), on s’intéresse beaucoup plus à l’approche scripts sur lequel
on a appliqué notre travail.
Nous allons, dans la suite de ce chapitre, présenter les deux providers sur
lesquelles on a travaillé. Ensuite nous présenterons l’architecture générale pro-
posée.
3.1 Choix de l’approche Script
Nous avons étudié dans le chapitre 2, les différentes approches de déploiement
automatique des applications sur le cloud qui existent dans la littérature. Notre
choix a convergé vers les scripts. Les scripts que nous avons choisis pour le dé-
ploiement automatique sont des fichiers SH (script shell). Un script shell permet
d’automatiser une série d’opérations. Il se présente sous la forme d’un fichier con-
tenant un ou plusieurs commandes qui seront exécutées de manière séquentielle.
Le script de déploiement contenant le code exécutable pour le déploiement d’une
application vers le cloud computing, et vous pouvez aussi utiliser vos scripts de
30
Chapitre 3. Conception du processus de déploiement
déploiement pour exécuter le package d’installation pour le fournisseur que vous
avez utilisé. Nous avons choisis les scripts de déploiement car ce type d’approche
réduit le risque d’erreur humaine lors du processus de déploiement manuelle, et
pour le cas de développeur, il s’occupe de développement d’application tout le
temps.
3.2 Environnement de travail
Dans notre projet, nous nous sommes basé sur l’idée de déploiement avec
les lignes de commandes pour les lier avec des programme script Shell dans
le but d’automatiser le déploiement et la configuration des applications et
aussi l’installation des interface de ligne de commandes (CLI) du fournisseur.
L’architecture que nous proposons se base essentiellement sur la définition d’un
ensemble de commandes à utiliser avec une interface de ligne de commande (CLI).
Chaque commande spécifie une action à effectuer dans un système.
3.2.1 CLI
Une interface de ligne de commande (CLI) est une interface utilisateur pour le sys-
tème d’exploitation d’un ordinateur ou d’une application dans laquelle l’utilisateur
répond à une invite visuelle en tapant une commande sur une ligne spécifiée, reçoit
une réponse du système, puis saisit une autre commande [LF05]. CLI est une an-
cienne méthode pour interagir avec les applications et les systèmes d’exploitation
et est utilisé pour effectuer des tâches spécifiques requises par les utilisateurs.
Elle est complètement textuelle, contrairement à l’interface graphique qui utilise
des options graphiques qui permettent à l’utilisateur d’interagir avec le système
d’exploitation et des applications.
CLI permet à un utilisateur d’effectuer des tâches par la saisie des commandes.
Son mécanisme de travail est très facile, Les utilisateurs saisissent la commande
spécifique, appuient sur "Enter", puis attendent une réponse. Après réception de
la commande, la CLI traite en conséquence et envoie la sortie/résultat sur le même
écran; l’interpréteur de ligne de commande est utilisée à cette fin [LF05].
31
Chapitre 3. Conception du processus de déploiement
CLI a été introduite avec la machine de téléscripteur. Ce système est basé sur
un traitement par lots. Les ordinateurs modernes supportent CLI, le traitement
par lots et l’interface graphique dans une seule interface.
Afin de mieux faire usage de CLI, un utilisateur doit être en mesure d’entrer
dans un paquet de commandes (un par un) rapidement. Il existe de nombreuses
applications (systèmes mono-traitement) qui utilisent encore des CLI pour leurs
opérateurs. En outre, certains langages de programmation, comme Forth, Python
et BASIC, offrent des CLI. l’interpréteur de ligne de commande est utilisé pour
implémenter l’interface à base de texte.
3.2.2 CLI de Linux
Une invite de commande, également appelé l’invite du Shell ou invite, est un
message texte court, généré automatiquement au début de la ligne de commande
qui sert à informer l’utilisateur que le système est prêt pour la commande suivante.
,élément de données ou autre entrée et aider le plan d’utilisateur et d’exécuter les
opérations suivantes. Lorsque le Shell bash est utilisé, qui est le shell par défaut
sur Linux, l’invite de commande par défaut contient le nom de l’utilisateur, le nom
de l’ordinateur et le nom du répertoire courant (à savoir, le répertoire dans lequel
l’utilisateur travaille actuellement).
3.3 Conception
Dans cette partie nous présenterons la démarche conceptuelle de la solution adop-
tée pour le déploiement des applications sur le cloud. La conception de la solution
se base sur l’utilisation du formalisme UML à travers quelques diagrammes UML.
3.3.1 Architecture de déploiement
Cette section présente l’architecture de déploiement qui permet à la fois le dé-
ploiement des applications à l’aide des fichiers scripts qui sont livrés et déployés
vers le cloud final.
La solution comprend des fonctions telle que :
32
Chapitre 3. Conception du processus de déploiement
• le déploiement pourrait être exécuté à partir de la machine local du
développeur ou service web d’hébergement.
• l’utilisateur «le développeur dans notre cas» spécifie la préférence du
provider cloud.
• La possibilité de vérifier la configuration et l’installation des différents outils
avant d’entamer une nouvelle installation et configuration.
• prendre en compte l’inscription sur au moins un fournisseur cloud avant de
procéder vers le déploiement.
Figure 3.1: Architecture de déploiement
3.3.2 Diagramme de cas d’utilisation
Un diagramme de cas d’utilisation capture le comportement d’un système, d’un
sous système,d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit.
Il scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation,
ayant un sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le
besoin des utilisateurs d’un système, ils sont donc une vision orientée utilisateur
de ce besoin au contraire d’une vision informatique [Aud07].
Le rôle des diagrammes de cas d’utilisation est de permettre de recueillir, d’analyser
et d’organiser les besoins, et de recenser les grandes fonctionnalités d’un système.
Il s’agit donc de la première étape UML d’analyse d’un système [Aud07].
Acteur
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus
ou une chose qui interagit avec un système [Aud07].
Cas d’utilisation
Un cas d’utilisation est une unité cohérente représentant une fonctionnalité visible
de l’extérieur.Il réalise un service de bout en bout, avec un déclenchement, un
33
Chapitre 3. Conception du processus de déploiement
déroulement et une fin, pour l’acteur qui l’initie [Aud07]. Notre cas d’utilisation
contient un seul acteur qui va interagir avec le système, c’est le développeur (Figure
3.3.2).
Le développeur c’est la personne qui s’en charge de développer des applications et
des logiciels avec n’importe quel langage de programmation.
Le développeur c’est le seul collaborateur au sein du système de déploiement
automatique. Ci-après ses actions possibles :
• Déployer des applications vers le cloud
• Vérifier l’installation des CLI
• Installer et configurer les CLI
Figure 3.2: Diagramme de cas d’utilisation de notre système
3.3.3 Diagramme d’Activité
Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils
sont donc particulièrement adaptés à la modélisation du cheminement de flots de
34
Chapitre 3. Conception du processus de déploiement
contrôle et de flots de données. Ils permettent ainsi de représenter graphiquement
le comportement d’une méthode ou le déroulement d’un cas d’utilisation [Aud07].
Les diagrammes d’activités sont particulièrement adaptés à la description des cas
d’utilisation. Plus précisément, ils viennent illustrer et consolider la description
textuelle des cas d’utilisation.
Action
Une action est le plus petit traitement qui puisse être exprimé en UML. Une action
a une incidence sur l’état du système ou en extrait une information. Les actions
sont des étapes discrètes à partir desquelles se construisent les comportements
[Aud07].
Transition
Le passage d’une activité vers une autre est matérialisé par une transition.
Graphiquement les transitions sont représentées par des flèches en traits pleins
qui connectent les activités entre elles. Dans la figure 3.3.3 est représenté notre
diagramme d’activité.
35
Chapitre 3. Conception du processus de déploiement
Figure 3.3: Diagramme d’Activité
3.3.4 Diagramme de séquence
Les diagrammes de séquences mettent en valeur les échanges de messages (déclen-
chant des événements) entre acteurs et objets (ou entre objets et objets) de manière
chronologique où l’évolution du temps se lit de haut en bas. Chaque colonne cor-
respond à un objet (décrit dans le diagramme des classes), ou éventuellement à un
acteur, introduit dans le diagramme des cas. La ligne de vie de l’objet représente
la durée de son interaction avec les autres objets du diagramme.
36
Chapitre 3. Conception du processus de déploiement
Un diagramme de séquences est un moyen semi-formel de capturer le com-
portement de tous les objets et acteurs impliqués dans un cas d’utilisation. On
peut indiquer un type de message particulier : les retours de fonction qui, bien
entendu, ne concernent aucun message mais signifient la fin de l’appel de l’objet
appelé. Ils permettent d’indiquer la libération de l’objet appelant (ou de l’acteur).
Un emploi abusif de retours de fonction peut alourdir considérablement le
diagramme, aussi un usage parcimonieux est-il conseillé. On peut faire apparaître
de nombreuses informations de contrôle le long de la ligne de vie d’un objet [Sig05] .
Dans notre modèle, le développeur représente l’utilisateur de notre applica-
tion. Il accède à l’interface utilisateur de système pour lancer l’application de
déploiement qui permettra de d’offrir le choix du fournisseur qui propose un scé-
nario spécifique de déploiement. La figure 3.4 présente le processus de déploiement
de ce projet.
Figure 3.4: Diagramme de séquence pour le déploiement
37
Chapitre 3. Conception du processus de déploiement
1:Lancé
Au début de processus, le développeur exécute l’interface de ligne de commande.
3:Lancer interface déploiement
avec interface de ligne de commande, le développeur lance (4 : Appelé Interface
de déploiement) à partir quelques commandes sur Interface utilisateur .
4:Appelé
Dans cette action, interface utilisateur exécute quelque commande pour afficher
l’interface de déploiement.
6:déployer avec GitHub
Dans cette étape, le développeur a le choix de déployer avec GitHub ou avec path
sur GitHub. Il va utiliser URL de l’application sur GitHub et interface utilisateur
va (8 : Clone application) et ceci se fera automatiquement.
8: Clone application
on clone l’application sur un service d’hébergement .
10:déployer avec path
Le développeur utilise un chemin de l’application sur le disque et l’application est
déployée avec (11:Script 2) automatiquement .
Diagramme de sequence installation et configuration
Dans ce diagramme nous allons présenter l’installation et la configuration des
fournisseurs utilisés.
38
Chapitre 3. Conception du processus de déploiement
Figure 3.5: Diagramme de séquence pour "installation et configuration"
1 : installer
Si le développeur n’a jamais utilisé IBM-BlUEMIX, il faut passer par instal-
lation et configuration à travers l’interface IBM-BlUEMIX et tout se fera
de manière automatique mais si le développeur a déjà installé la CLI de IBM-
BlUEMIX , le processus interface utilisateur va afficher la version de l’installation .
2 : script3
pour installer la CLI de provider bluemix, le script3 est exécuté.
3 : Afficher la version
si le provider est déjà installé, on affiche la version de l’installation
4 :installer et configurer
le terminal commence l’installation puis la configuration du provider.
39
Chapitre 3. Conception du processus de déploiement
6 : installer
Pour la plate-forme heroku,appliquer le même mécanisme de IBM-BlUEMIX.
3.3.5 Diagramme de classes
Le diagramme de classes est le point central dans un développement orienté objet.
En analyse, il a pour objectif de décrire la structure des entité manipulées par les
utilisateurs. En conception, le diagramme de classes représente la structure d’un
code orienté objet ou à un niveau de détail plus important, les modules du langage
de développement [Roq09].
Comment le représenter
Le diagramme de classes met en oeuvre des classes, contenant des attributs et des
opérations, et reliées par des relations (associations, généralisation, ...) [Roq09].
Figure 3.6: Diagramme de Classes
40
Chapitre 3. Conception du processus de déploiement
3.3.6 Description de diagramme de classes
la classe terminal : Cette classe que nous avons créée présente comment
le développeur d’application va lancer l’application de déploiement et permet
d’afficher les résultats de déploiement et de l’installation. Cette classe a comme
méthode :
• Commande () : cette méthode permet de lancer l’application à travers le
développeur .
La classe module d’accès : Cette classe permet la création de la connexion aux
différentes plate-formes.
La classe Platform-IBM : cette classe représente le provider Bluemix qui nous
avons utilisé pour déployer les applications vers le cloud IBM. Cette classe a comme
méthode :
• configuré() : cette méthode permet de configurer les plate-forme (installer
quelques plugins à utiliser pour les plate-formes)
La classe Platform-heroku : cette classe représente le provider Heroku qui nous
avons utilisé pour déployer les applications vers le cloud Heroku. Cette classe a
comme méthode :
• configuré() : cette méthode permet de configurer les plate-forme (installer
quelques plugins utilisés pour les plate-formes)
La classe Application : la classe application représente l’application qui le
développeur va déployer. Cette classe a comme méthode :
• afficher(): pour affichage de notre application soit dans le local host soit dans
le provider qui nous avons choisi.
La classe CLI : notre architecture est basée sur cette classes pour pour exé-
cuter les commandes de déploiement de différents providers .Cette classe a comme
méthode :
• installer(): cette méthode permet d’installer la CLI de provider utilisé.
41
Chapitre 3. Conception du processus de déploiement
3.4 Conclusion
Nous avons présenté dans ce chapitre, la démarche conceptuelle du déploiement
automatique vers le cloud computing .
Nous avons utilisé des diagrammes UML pour modéliser notre système ce qui
nous a permis d’exploiter son fonctionnement en faisant ressortir ses principales
caractéristiques ainsi que les interactions entre ses différents composants.
42
Chapitre 4
Mise en oeuvre du déploiement
4.1 Introduction
Afin de concrétiser, valider et évaluer la stratégie utilisée pour le déploiement
automatique des applications sur le cloud, nous avons conçu un outil reflètant
notre architecture proposée dans le chapitre 3.
Aussi nous avons effectué une série d’expérimentations dont les résultats et les
interprétations font l’objet du présent chapitre. Nous commencerons d’abord, par
décrire l’environnement dans lequel nous avons réalisé notre logiciel, puis nous
discuterons et analyserons les résultats que nous avons obtenus.
4.2 Langage et outils de développement
Nous avons développé notre application sur deux providers cloud qui sont IBM-
Bluemix et Heroku. L’application a été développée en utilisant le langage de
programmation Python.
4.2.1 Langages
Pour les besoins d’implémentation de notre application, nous avons utilisé un lan-
gage de commandes et un langage de programmation de haut niveau qu’est Python.
Ces deux langages sont présentés dans ce qui suit.
43
Chapitre 4. Mise en oeuvre du déploiement
Script shell
Un shell (sh)(Figure 4.1) est un interpréteur de langage de commandes dont le Csh
est une évolution du shell sh utilisant une syntaxe plus proche du langage C. Le C
shell est un interpréteur de commandes qui s’exécute généralement dans une fenêtre
en mode texte, ce qui permet à l’utilisateur de taper des commandes. Le C shell
peut également lire les commandes depuis un fichier, appelé alors script. Comme
tous les shells Unix, il prend en charge les caractères spéciaux de remplacement de
nom de fichier, les pipes, le mode multi-ligne, la substitution de commande, des
variables et des structures de contrôle pour les tests de conditions et d’itérations
[Joy80].
Figure 4.1: Logo de Script shell
Python
Python est un langage objet interprété de haut niveau, créé au début des
années quatre-vingt-dix par Guido Van Rossum au Centrum voor Wiskunde
à Informatica, Amsterdam. En 1995, Rossum poursuivit le développement de
Python à la Corporation for National Research Initiatives de Reston (Virginie)
[Dup10].
Le langage Python est modulaire. La définition du langage est très succincte et
autour de ce noyau concis, de nombreuses librairies ou modules ont été développées.
Python est assez intuitif, être à l’aise avec ce langage revient à connaître tout
autant sa syntaxe que les nombreux modules disponibles, eux-mêmes écrits en
Python [Dup10].
44
Chapitre 4. Mise en oeuvre du déploiement
Le langage Python est à syntaxe positionnelle en ce sens que l’indentation
fait partie du langage. Le point virgule permet de séparer les instructions en
langage C, l’accolade permet de commencer un bloc d’instruction. En Python,
seule l’indentation permet de marquer le début et la fin d’un tel bloc. Ce procédé
consiste à décaler les lignes vers la droite pour montrer qu’elles appartiennent au
même bloc d’instructions [Dup10].
Figure 4.2: Logo de Python
4.2.2 Plate-forme IBM-Bluemix
Bluemix est un PaaS (Platform as a Service). C’est une plate-forme cloud IBM
qui fournit aux développeurs d’accéder à des logiciels IBM pour l’intégration, la
sécurité, transaction et d’autres fonctions clés,ainsi que les logiciels de partenaires
commerciaux [Liu11].
Construit sur la technologie open source Cloud Foundry, Bluemix rend le
développement des applications plus facile avec la plate-forme en tant que ser-
vice (PaaS). Le but est de simplifier la livraison d’une application en fournissant
des services qui sont prêts pour une utilisation immédiate et aussi des capacités
45
Chapitre 4. Mise en oeuvre du déploiement
d’hébergement pour permettre le développement à l’échelle interne [Raf15].
Figure 4.3: Plate-forme Bluemix
4.2.3 Plate-forme Heroku
Heroku, prononcé hey-oh-koo, est l’un des principaux fournisseurs de PaaS dans
le secteur des logiciels de cloud. Il se révèle être la solution leader PaaS pour
les petites et grandes entreprises. Avec une amélioration constante et la philoso-
phie de commodité sur la «configuration», Heroku est devenu la principale plate-
forme de développement d’applications de cloud pour les développeurs. Il a été
utilisé par plus de de 40000 sites. La Philosophie Heroku est de permettre aux
développeurs de se concentrer uniquement sur l’écriture de l’application Web et
oublier les serveurs. Heroku prend en charge à la demande de la construction,
le déploiement, l’exécution, et la mise à l’échelle de l’application réalisée par le
développeur [Han14].
46
Chapitre 4. Mise en oeuvre du déploiement
Figure 4.4: Plate-forme Heroku
Heroku est une plate-forme d’application cloud polyglottes qui offre une grande
flexibilité dans le choix d’un langage de programmation approprié pour développer
des applications Web (Figure 4.4). Heroku fournit un support de plate-forme pour
Ruby on rails, Java, Node.js, Clojure, Scala, python, PHP [Han14].
4.3 Description du fonctionnement de notre logi-
ciel
Dans cette partie, nous somme intéressé à la démonstration de notre application
à travers un exemple en faisant référence à quelques interfaces graphiques.
47
Chapitre 4. Mise en oeuvre du déploiement
4.3.1 Lancement de l’application
Pour lancer notre application, on doit utiliser un terminal pour exécuter une com-
mande avec l’interpréteur SHELL . Ceci est illustré dans la figure 4.5.
Figure 4.5: Appel de notre application
4.3.2 Menu principal
Après l?exécution de lappel de notre application, une interface s’affiche. Elle
représente le menu principal (voir la figure 4.6).
Le menu principal contient deux sous-menu : File et Aide. Chacun d’eux est
composé d’un ensemble d’items qui vont être expliqués dans les sections suivantes.
Le choix de la plate-forme cloud s’apparaît sous forme de boutons sur le menu prin-
cipal. Deux plate-formes en choix sont possibles devant l’utilisateur (développeur
de notre cas) : la plate-forme Heroku ou la plate-forme IBM bluemix.
48
Chapitre 4. Mise en oeuvre du déploiement
Figure 4.6: Menu principal
4.3.3 Déploiement avec Heroku
Afin de réaliser le déploiement avec Heroku, la première chose à effectuer est de
cliquer sur le bouton Heroku. Ensuite vérifier l’installation et la configuration des
CLI, configurer et installer les CLI dans le cas contraire. Enfin sélectionner le
type de stockage de l’application à déployer. L’application à déployer peut être
sauvegardée soit au niveau de la machine locale, soit au niveau du service Web
d’hébergement GitHub.
Machine locale
Dans le cas où l’application se trouve au niveau de la machine locale, l’accès à
l’application à déployer se fait en sélectionnant le chemin à partir de l’interface.
(voir la figure 4.7)
49
Chapitre 4. Mise en oeuvre du déploiement
Figure 4.7: déployer au niveau de la machine local
Service web d’hébergement GitHub
Maintenant si l’application se trouve au niveau du service web d’hébergement
GitHub. Il faut cloner l’application à partir de l’interface.(voir la figure 4.8)
Figure 4.8: déployer au niveau du service web d’hébergement GitHub
4.3.4 Le déploiement avec IBM bluemix
Afin de réaliser le déploiement avec IBM bluemix, la première chose à effectuer
est de cliquer sur le bouton IBM bluemix. Ensuite vérifier l’installation et la
configuration des CLI, configurer et installer les CLI dans le cas contraire. En fin
sélectionner l’endroit où l’application se trouve. L’application à déployer est déposé
soit au niveau de la machine local, soit au niveau du service web d’hébergement
GitHub.
50
Chapitre 4. Mise en oeuvre du déploiement
Machine local
Dans le cas où l’application se trouve au niveau de la machine local, sélectionner
le chemin à partir de l’interface. (voir la figure 4.9)
Figure 4.9: Déploiement au niveau de la machine locale
Service web d’hébergement GitHub
Si l’application se trouve au niveau du service Web d’hébergement GitHub, l’accès
se fait à l’aide d’un clonage de l’application à partir de l’interface (voir la figure
4.10).
51
Chapitre 4. Mise en oeuvre du déploiement
Figure 4.10: déployer au niveau du service web d’hébergement GitHub
4.4 Expérimentation
Dans cette expérimentation, nous avons défini des mesures d’évaluation objectives,
pour l’évaluation du notre logiciel. Cette enquête a été entamée afin de montrer
l’utilité et les avantages de notre logiciel. Parmi les mesures d’évaluation de notre
logiciel, nous avons sélectionné pour cette étude: (i) l’effort fourni et (i) le temps
consommé.
Pour la métrique l’effort fourni, elle est subdivise en réalité sur trois sous
métriques : L’effort fourni dans la première utilisation de la plate-forme cloud,
l’effort fourni dans le deuxième déploiement et les déploiements postérieurs et
l’effort fourni pour la maintenabilité.
La même chose pour la métrique ; le temps consommé, elle est subdivise en
réalité sur trois sous métriques : le temps consommé fourni dans la première util-
isation de la plateforme cloud, le temps consommé dans le deuxième déploiement
et les déploiements postérieurs et le temps consommé pour la maintenabilité.
Notre enquête a été réalisée par moi-même et par mon co-encadreur. Dans
52
Chapitre 4. Mise en oeuvre du déploiement
mon cas a fin d’effectuer un déploiement manuellement pour la première fois à
pris une journée ou plus, selon la plateforme cloud utilisée. Pour le cas de mon
co-encadreur le temps estimé pour faire un premier déploiement manuellement
réussi a pris une à trois jours, selon la plateforme cloud utilisée. Le temps
consommé afin de réaliser un deuxième déploiement manuelle ma pris entre 15
et 30 minutes. Pour le cas de mon-encadreur, le déploiement a pris entre un 3
4
trois-cardeur heur jusqu’à deux heurs.
Après avoir effectué l’expérience, nous avons recueilli et analysé les données.
Pour la mesure temps consommé, on a obtenu les valeurs indiquées sur la figure
10. La figure 10 montre que le temps consommé est diminué lorsqu’on utilise notre
logiciel du déploiement automatique. Cela veut dire qu’il y a eu un impact positif
avec l’utilisation de la solution proposée par notre logiciel. La figure 11 présente
la mesure effort fourni. Elle montre un graphique qui contient le pourcentage de
l’effort fourni. Le pourcentage est calculé en fonction des facteurs d’effort pondéré
sur les coefficients. Les facteurs d’effort sont : la documentation, les tentatives
d’installation et de configuration et l’inscription sur les plate-formes cloud.
Figure 4.11: La métrique temps consommé sans/ avec l?aide de notre solution
«déploiement automatique»
53
Chapitre 4. Mise en oeuvre du déploiement
Figure 4.12: La métrique effort fourni sans/ avec l?aide de notre solution
«déploiement automatique»
4.5 Conclusion
Dans ce chapitre, nous avons présenté l’implémentation de notre logiciel ainsi les
résultats obtenues. Aussi nous avons réalisé plusieurs séries d’expérimentations
dans le but de comparer notre solution avec la solution classique «manuel» tout
en variant différents paramètre comme : le temps consommé et l’effort fourni.
Les résultats de comparaison ont montré que notre stratégie de déploiement
automatique donne des bons résultats par rapport au déploiement manuels
qui peuvent être fastidieux et peut prendre beaucoup de temps et d’effort, en
particulier lorsque la plateforme cloud est utilisée pour la premier fois.
Dans le cas où un problème critique est découvert avec une application après le
déploiement, l’effort manuel et le temps fourni peut également être perdu et coûte
des efforts de restauration ou de rapiéçage.
54
Conclusion générale
Ce travail s’inscrit dans le contexte de déploiement automatique des applications
dans le cloud où il nous a immergé complètement dans le monde du cloud, ces
plate-formes et providers. En effet nous avons découvert les multiples façons et
techniques d’exploiter ce domaine.
Ce projet a adopté une solution de scripts pour automatiser le déploiement des
applications dans le cloud. Notre principal objectif était de réduire la charge de
travail des développeurs et les chercheurs qui ont besoin d’utiliser les ressources de
cloud. Pour évaluer notre solution, nous avons mené une expérience impliquant
une utilisation manuelle du cloud et une autre automatique. L’expérimentation a
révélé que l’automatisation de déploiement avait réduit les risques impliqués dans le
déploiement, la charge de travail et temps perdu. Ce qui permet aux développeurs
de déployer le cloud plus fréquemment et de manière fiable.
La mise en oeuvre d’une solution de déploiement automatisé en réalité n’est
pas automatique à cent pour cent, mais les avantages de risque réduit, une fiabilité
accrue et la transparence par rapport aux déploiements manuels montrent que
cette manière de faire est un investissement très convaincant.
La limite du temps et le manque de financement ont constitué une barrière à
l?amélioration de notre logiciel. L?applicatif réalisé répond au cahier de charge.
Reste à préciser que la conception effectuée et l?architecture technique permet
d?ajouter d?autres services pour répondre aux futurs besoins éventuels.
Les travaux menés au cours de ce travail ouvrent un certain nombre de perspec-
tives à la fois liées à l’automatisation du déploiement et aux plate-formes cloud.
55
Conclusion générale
Nous pourrons proposer quelques pistes de développement pour le futur :
• Afin de réaliser un déploiement automatique, on est obligé de passer par la
création des fichiers de configuration pour chaque application. Ces fichiers de
configuration sont de type YML et WAR et POCFILE. La création automa-
tique des fichiers de configuration peut être considérée comme une perspec-
tive d’évolution de l’automatisation de déploiement puisque notre solution
édite les fichiers de configuration d’une façon manuelle.
• Notre expérimentation a été appliquée sur deux exemples d’application. Mais
elle pourrait être effectuée sur d’autre applications contenant une multitude
de service tel que : le service SGBD, le service mobile etc.
• Finalement, l’exécution de notre solution a été effectuée sur deux plateformes
cloud gratuites Heroku et IBMbluemix. On peut dire que notre solution
pourrait être exécutée sur la majorité des plate-formes cloud. Vu le manque
des cartes crédits normalement financées par l’université d’Oran 1 et l’accès
à la plupart des plate-formes cloud est payant, nous avons limité le nombre
de plate-formes cloud à deux.
Il est important de noter que la recherche des plate-formes cloud gratuites était
une tâche très difficile et fastidieuse à la fois.
56
Bibliographie
[ADNC+
12] Danilo Ardagna, Elisabetta Di Nitto, Giuliano Casale, Dana Petcu,
Parastoo Mohagheghi, Sébastien Mosser, Peter Matthews, Anke
Gericke, Cyril Ballagny, Francesco D’Andria, et al. Modaclouds:
A model-driven approach for the design and execution of applica-
tions on multiple clouds. In Proceedings of the 4th International
Workshop on Modeling in Software Engineering, pages 50–56. IEEE
Press, 2012.
[Aud07] Laurent Audibert. UML2. Interfaces, 3:10, 2007.
[CC12] Gerard Conway and Edward Curry. Managing Cloud Computing-A
Life Cycle Approach. In CLOSER, pages 198–207, 2012.
[Dup10] Xavier Dupré. Langage Python, 2010. http ://www.xavierdupre.fr/.
[Fay15] Maurice-Djibril Faye. Déploiement auto-adaptatif d’intergiciel sur
plate-forme élastique. PhD thesis, Ecole normale supérieure de lyon-
ENS LYON, 2015.
[Fos98] I Foster. The grid, blueprintfor a new computing infrastructure,
1998.
[FZRL08] Ian Foster, Yong Zhao, Ioan Raicu, and Shiyong Lu. Cloud comput-
ing and grid computing 360-degree compared. In Grid Computing
Environments Workshop, 2008. GCE’08, pages 1–10. Ieee, 2008.
[Han14] Anubhav Hanjura. Heroku Cloud Application Development. Packt
Publishing Ltd, 2014.
[Joy80] William Joy. An Introduction to the C shell. University of California,
Berkeley, 1980.
[LF05] M.J. Little and S. Froyd. Command line interface abstraction engine,
june 2005. US Patent 6,907,572.
57
Bibliographie
[Liu11] Haoyun Liu. Introduction to IOT, 2011.
[LSTE12] Wubin Li, Petter Svard, Johan Tordsson, and Erik Elmroth. A gen-
eral approach to service deployment in cloud environments. In Cloud
and Green Computing (CGC), 2012 Second International Confer-
ence on, pages 17–24. IEEE, 2012.
[MG11] Peter Mell and Tim Grance. The NIST definition of cloud comput-
ing, 2011.
[QD12] Clément Quinton and Laurence Duchien. Vers un Outil de Configu-
ration et de Déploiement pour les Nuages. In JLdP-Journée Lignes
de Produits, pages 83–94, 2012.
[QRD16] Clément Quinton, Daniel Romero, and Laurence Duchien. SA-
LOON: a platform for selecting and configuring cloud environments.
Software: Practice and Experience, 46(1):55–78, 2016.
[Raf15] Stifani Raffaele. IBM Bluemix: The Digital Innovation Platform.
Copyright International Business Machines Corporation 2015, July
2015.
[RJdRSM16] Franklin Magalhães Ribeiro Jr, Tarcísio da Rocha, Joanna CS San-
tos, and Edward David Moreno. A Model-Driven Solution for Auto-
matic Software Deployment in the Cloud. In Information Technol-
ogy: New Generations, pages 591–601. Springer, 2016.
[Roq09] Pascal Roques. UML 2 par la pratique. Editions Eyrolles, 2009.
[Sig05] Olivier Sigaud. Introduction à la modélisation orientée objets avec
UML. Laboratoire d’Informatique de Paris VI (LIP6), France, 2005.
[TBB03] Mark Turner, David Budgen, and Pearl Brereton. Turning software
into a service. Computer., 36(10):38–44, 2003.
[VG14] Thomas Vogel and Holger Giese. Model-driven engineering of self-
adaptive software with eurema. ACM Transactions on Autonomous
and Adaptive Systems (TAAS), 8(4):18, 2014.
58

Contenu connexe

Tendances

Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborativeMémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Messaoud Hatri
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
Mohamed Boubaya
 
Le Développement d’une Application Web
Le Développement d’une Application WebLe Développement d’une Application Web
Le Développement d’une Application Web
Malick Mbaye
 
PROJET JAVA BD MySQL
PROJET JAVA BD MySQLPROJET JAVA BD MySQL
PROJET JAVA BD MySQL
Wilfried Tiani
 
Template _rapport_pfe - new
Template  _rapport_pfe - newTemplate  _rapport_pfe - new
Template _rapport_pfe - new
karousn
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
ALALSYSE
 
Object detection and recognition in digital images
Object detection and recognition in digital imagesObject detection and recognition in digital images
Object detection and recognition in digital images
Sakher BELOUADAH
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Nawres Farhat
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Benjamin Vidal
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
Glei Hadji
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
Hicham Ben
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
Oussama Ben Sghaier
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
ichrafkhalfaoui
 
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Benjamin Vidal
 
Conception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2CConception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2C
Nassim Bahri
 
Envoi SMS JAVA
Envoi SMS JAVAEnvoi SMS JAVA
Envoi SMS JAVA
Eric Maxime
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Yosra ADDALI
 

Tendances (20)

Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborativeMémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Le Développement d’une Application Web
Le Développement d’une Application WebLe Développement d’une Application Web
Le Développement d’une Application Web
 
PROJET JAVA BD MySQL
PROJET JAVA BD MySQLPROJET JAVA BD MySQL
PROJET JAVA BD MySQL
 
Template _rapport_pfe - new
Template  _rapport_pfe - newTemplate  _rapport_pfe - new
Template _rapport_pfe - new
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
 
Object detection and recognition in digital images
Object detection and recognition in digital imagesObject detection and recognition in digital images
Object detection and recognition in digital images
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Rapport pfev7
Rapport pfev7Rapport pfev7
Rapport pfev7
 
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013Le logiciel libre dans le secteur public, un état des lieux en juin 2013
Le logiciel libre dans le secteur public, un état des lieux en juin 2013
 
Conception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2CConception et développement d&rsquo;une place de marché B2C
Conception et développement d&rsquo;une place de marché B2C
 
Envoi SMS JAVA
Envoi SMS JAVAEnvoi SMS JAVA
Envoi SMS JAVA
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 

Similaire à Deploy automatic in the cloud

Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
Adem Amen Allah Thabti
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
Slimane Akaliâ , سليمان أقليع
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
Ben Ahmed Zohra
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
Ilef Ben Slima
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Sofien Benrhouma
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
Taieb Kristou
 
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard RoulleauRapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Nicolas Roulleau
 
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Hadjer BENHADJ DJILALI
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
younes elmorabit
 
Android VoIP/SIP Softphone
Android VoIP/SIP SoftphoneAndroid VoIP/SIP Softphone
Android VoIP/SIP Softphone
Hamza Lazaar
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
Khadidja BOUKREDIMI
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
Université de Rennes 1
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 

Similaire à Deploy automatic in the cloud (20)

Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard RoulleauRapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
 
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
 
Android VoIP/SIP Softphone
Android VoIP/SIP SoftphoneAndroid VoIP/SIP Softphone
Android VoIP/SIP Softphone
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
 
siem.pdf
siem.pdfsiem.pdf
siem.pdf
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
ns.pdf
ns.pdfns.pdf
ns.pdf
 

Deploy automatic in the cloud

  • 1. MEMOIRE DE MASTER Sp´ecialit´e : Ing´enierie des Syst`emes Complexes et Multim´edia Discipline : Informatique D´EPLOIEMENT AUTOMATIQUE DES APPLICATIONS SUR LE CLOUD COMPUTING pr´esent´e et soutenu par KADDOUR GUETTAOUI Abdelhalim Juin 2016 JURY Pr´esident : Mme HADI Nadia Encadreurs : DEBA El Abbassia Universit´e d’Oran 1 AOUAT Asmaa Universit´e d’Oran 1 Examinateurs : HADJ TAYEB Lylia Universit´e d’Oran 1 D´epartement d’Informatique
  • 2. Remerciements Grâce à «Allah» le tout puissant, ce travail s’est accompli.. Je tiens à remercier tout particulièrement mes encadreurs DEBA El Abbassia AOUAT Asmaa De m’avoir fait l’honneur d’assurer le suivi de mon travail Jusqu’à son achèvement. Je désire exprimer mes profondes gratitudes et remerciements A Mmes les membres du jury Mme HADI Nadia Mme HADJ TAYEB Lylia Qui m’ont honoré et ont bien accepté d’examiner mon travail Et À tous les enseignants qui ont contribué à ma formation. Je tiens à remercier également tous mes amis, qui étaient à Mes côtés aux lieux fraternels et amicaux qui ont germé dans Mes esprits ... . I
  • 3. Je dédie ce travail, A mes chères parents A mes frères et sœurs II
  • 4. Résume : Le cloud computing est une tendance actuelle majeure pour répartir les traite- ments et les données de façon virtuelle sur des environnements d’exécution paramétrables. Le déploiement automatique d’applications sur le cloud propose un nouveau challenge scientifique en termes d’expression et de prise en compte de la variabilité. Dans ce mémoire, nous présentons une solution basée sur les scripts pour déployer automatiquement les applications dans le cloud. Pour évaluer notre solution, nous avons mené une expérience de deux personnes qui ont déployé une application manuellement dans le cloud et ils ont utilisé notre solution de déploiement automatique. Les résultats ont montré que notre solution a présenté un impact positif en termes de charge de travail et le temps consommé. Mots Clés : Cloud Computing, Script, Déploiement automatique, Plateforme cloud Abstract : Cloud computing is a major trend to allocate treatments and data on virtually parameterized execution environments. Automatic deployment of applications on the cloud offers a new scientific challenge in terms of expression and consideration of variability. In this paper, we present a solution based on scripts to automati- cally deploy applications in the cloud. To evaluate our solution, we conducted an experiment of two people who have made an application manually in the cloud and they used our automatic deployment solution. The results showed that our solution has presented a positive impact in terms of workload and time consumed. Key Words: Cloud Computing, Script, Automatic deployment, PaaS III
  • 5. Table des matières Liste des figures VII Acronymes VIII Introduction générale 1 Chapitre 1 Cloud Computing : état de l’art 4 1.1 Les fondements du cloud . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 L’informatique utilitaire de John McCarthy . . . . . . . . . 5 1.1.2 Les services bureau . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.3 Les applications service providers . . . . . . . . . . . . . . . 5 1.1.4 La virtualisation . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 L’évolution de Cloud computing . . . . . . . . . . . . . . . . . . . . 6 1.3 Cloud Computing : Définition et Concepts . . . . . . . . . . . . . . 7 1.4 Cloud vs Grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Les caractéristiques essentielles de cloud computing . . . . . . . . . 10 1.5.1 Self-service à la demande . . . . . . . . . . . . . . . . . . . . 10 1.5.2 Elasticité et rapidité . . . . . . . . . . . . . . . . . . . . . . 10 1.5.3 Accès aux ressources . . . . . . . . . . . . . . . . . . . . . . 10 1.5.4 Allocation des ressources . . . . . . . . . . . . . . . . . . . . 11 1.5.5 Mesure du service . . . . . . . . . . . . . . . . . . . . . . . . 11 1.6 Taxonomie du cloud computing . . . . . . . . . . . . . . . . . . . . 11 1.6.1 Modèle de délivrance . . . . . . . . . . . . . . . . . . . . . . 11 1.6.2 Modèles de déploiement . . . . . . . . . . . . . . . . . . . . 14 IV
  • 6. Table des matières 1.6.3 Le modèle business . . . . . . . . . . . . . . . . . . . . . . . 16 1.7 Avantages et inconvénients du Cloud Computing . . . . . . . . . . . 16 1.7.1 Avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.7.2 Inconvenients . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.8 Les plateformes cloud computing . . . . . . . . . . . . . . . . . . . 17 1.8.1 Amazon Web Services (AWS) . . . . . . . . . . . . . . . . . 18 1.8.1.1 Elastic Computing Cloud (EC2) . . . . . . . . . . 18 1.8.2 Service de Stockage Simple(S3) . . . . . . . . . . . . . . . . 19 1.8.3 Google AppEngine . . . . . . . . . . . . . . . . . . . . . . . 19 1.8.4 Windows Azure . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Chapitre 2 Déploiement d’applications : tour d’horizon 22 2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2 Le déploiement automatique des logiciels dans le cloud computing . 24 2.3 Définition du déploiement automatique . . . . . . . . . . . . . . . . 25 2.4 Les approches de déploiement . . . . . . . . . . . . . . . . . . . . . 25 2.4.1 Les scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.2 Langage de programmation . . . . . . . . . . . . . . . . . . 26 2.4.3 Les approches semi-automatiques . . . . . . . . . . . . . . . 26 2.4.4 Les Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4.5 Approche basée sur les modèles . . . . . . . . . . . . . . . . 26 2.5 Les outils et les Frameworks de déploiement . . . . . . . . . . . . . 27 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Chapitre 3 Conception du processus de déploiement 30 3.1 Choix de l’approche Script . . . . . . . . . . . . . . . . . . . . . . . 30 3.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.1 CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.2 CLI de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.1 Architecture de déploiement . . . . . . . . . . . . . . . . . 32 V
  • 7. Table des matières 3.3.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . 33 3.3.3 Diagramme d’Activité . . . . . . . . . . . . . . . . . . . . . 34 3.3.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . 36 3.3.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . 40 3.3.6 Description de diagramme de classes . . . . . . . . . . . . . 41 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Chapitre 4 Mise en oeuvre du déploiement 43 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 Langage et outils de développement . . . . . . . . . . . . . . . . . . 43 4.2.1 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.2 Plate-forme IBM-Bluemix . . . . . . . . . . . . . . . . . . . 45 4.2.3 Plate-forme Heroku . . . . . . . . . . . . . . . . . . . . . . . 46 4.3 Description du fonctionnement de notre logiciel . . . . . . . . . . . 47 4.3.1 Lancement de l’application . . . . . . . . . . . . . . . . . . . 48 4.3.2 Menu principal . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3.3 Déploiement avec Heroku . . . . . . . . . . . . . . . . . . . 49 4.3.4 Le déploiement avec IBM bluemix . . . . . . . . . . . . . . . 50 4.4 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Conclusion générale 55 Bibliographie 57 VI
  • 8. Liste des figures 1.1 Evolution du cloud computing . . . . . . . . . . . . . . . . . . . . . 7 1.2 Utilisation du Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Différents modèles de délivrance du Cloud . . . . . . . . . . . . . . 12 1.4 Modèles de déploiement du Cloud . . . . . . . . . . . . . . . . . . . 15 1.5 Les acteurs principaux du cloud computing . . . . . . . . . . . . . . 18 3.1 Architecture de déploiement . . . . . . . . . . . . . . . . . . . . . . 33 3.2 Diagramme de cas d’utilisation de notre système . . . . . . . . . . . 34 3.3 Diagramme d’Activité . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4 Diagramme de séquence pour le déploiement . . . . . . . . . . . . . 37 3.5 Diagramme de séquence pour "installation et configuration" . . . . 39 3.6 Diagramme de Classes . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1 Logo de Script shell . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2 Logo de Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3 Plate-forme Bluemix . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4 Plate-forme Heroku . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.5 Appel de notre application . . . . . . . . . . . . . . . . . . . . . . 48 4.6 Menu principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.7 déployer au niveau de la machine local . . . . . . . . . . . . . . . . 50 4.8 déployer au niveau du service web d’hébergement GitHub . . . . . . 50 4.9 Déploiement au niveau de la machine locale . . . . . . . . . . . . . 51 4.10 déployer au niveau du service web d’hébergement GitHub . . . . . . 52 4.11 La métrique temps consommé sans/ avec l?aide de notre solution «déploiement automatique» . . . . . . . . . . . . . . . . . . . . . . 53 4.12 La métrique effort fourni sans/ avec l?aide de notre solution «déploiement automatique» . . . . . . . . . . . . . . . . . . . . . . 54 VII
  • 9. Acronymes AMI : Amazon Machine Image AWS : Amazon Web Services CLI : Command Line Interface EC2 : Elastic Computing Cloud IaaS : Infrastructure as a Service IDL : Interface Definition Language OMG : Object Management Group OSGi : Open Services Gateway initiative PaaS : Platform as a service PIM : Platform-Independent Model PSM : Platform-Specific Mapping SaaS : Software as a Service SH : Script Shell VM : Virtuel Machine XML : Extensible Markup Languageï¿1 2 UML : Unified Modeling Language VIII
  • 10. Acronymes API : Application Programming Interface S3 : Service de Stockage Simple IX
  • 11. Introduction générale Au cours de ces dernières années, avec le développement rapide des technologies de l’information, de nombreuses organisations et entreprises cherchent la meilleure façon de réduire les coûts de fonctionnement, d’assurer la mise à l’échelle de leurs systèmes informatiques, de fournir la bonne performance à leurs applications tout en optimisant l’utilisation des ressources. Cette problématique trouve une réponse dans l’utilisation du concept de Cloud Computing où les techniques de concep- tion et moyens de déploiement, de gestion des applications des utilisateurs et la fourniture de ressources informatiques pour faciliter et garantir la performance souhaitable sont devenus de véritables défis. Le Cloud computing est très attractive pour les entreprises/utilisateurs pour plusieurs raisons économiques : il nécessite un investissement faible pour l’infrastructure et des coûts de fonctionnement bas qui sont fondés sur la notion de payez uniquement ce que vous consommez". Cependant, dans le marché de Cloud computing, il n’existe pas un seul nuage homogène mais plusieurs nuages dis- parates. Ainsi, le Cloud computing a émergé ces dernières années pour compléter les technologies des systèmes distribués et ajouter de nouvelles caractéristiques à l’approvisionnement des ressources pour les applications. Dans le contexte de l’adoption du Cloud computing par les développeurs de logiciels, le déploiement d’applications a pris de l’importance. Ainsi, le déploiement est l’étape qui arrive en <fin> du cycle de vie du logiciel est une étape complexe qui permet non seulement d’installer le logiciel, mais de le gérer jusqu à la fin de sa vie. Plusieurs activités entrent alors en jeu ; comme la mise à jour ou la désinstallation.il s’agit alors de prendre en charge le logiciel depuis son installation, jusqu à sa désinstallation , en passant par touts les phases 1
  • 12. Introduction générale de maintenance (évolutive ou corrective). Cette étape a pris de l’importance ces dernières années. En effet, avec le développement d’internet, il est maintenant pos- sible de déployer un produit directement depuis son producteur vers une machine cible définie. Pour exécuter un logiciel correctement dans une architecture de Cloud, il est nécessaire de déployer non seulement le logiciel lui-même, mais aussi ses dépen- dances (c-à-d d’autres services dont le logiciel dépend au cours de son exécution). Pour satisfaire à cette exigence, chaque développeur, qui a besoin de déployer une application dans le nuage doit acquérir une clé d’accès au fournisseur de Cloud, sélectionnez une instance de machine dans le fournisseur qui prend en charge l’application ainsi que configurer et installer la machine virtuelle. Après cela, le développeur doit déployer l’application et ses dépendances (dans un ordre approprié) dans la machine virtuelle sélectionnée. Cependant, le moyen le plus efficace pour déployer le logiciel dans l’environnement de nuage est grâce à l’automatisation de ce processus, étant donné que les détails de configuration peuvent être extraites à un niveau supérieur en diminuant ainsi les efforts humains pour l’exécuter. L’objectif de notre projet est de proposer de prendre en charge ce processus d’automatisation du déploiement d’applications dans le Cloud en faisant le choix d’expérimenter le processus de déploiement sur deux plateformes de Cloud dif- férentes en premier lieu afin de pouvoir le généraliser par la suite à d’autres Clouds. Ce présent document est organisé comme suit : • Chapitre 1 : présente un état de l’art sur le cloud computing en mettant l’accent sur la définition du concept cloud, ses modèles ainsi que les outils et platformes utilisés. • Chapitre 2 : présente le concept de déploiement d’applications et discute les travaux de déploiement automatique existants dans le contexte du cloud computing. • Chapitre 3 : explicite la démarche conceptuelle de la solution adoptée du déploiement automatique dans le cadre de notre projet de fin d’études. 2
  • 13. Introduction générale • Chapitre 4 : discute les aspects d’implémentation du déploiement automa- tique d’applications. Enfin, nous concluons ce travail par des perspectives pour améliorer le produit réalisé. 3
  • 14. Chapitre 1 Cloud Computing : état de l’art Introduction Indéniablement, la technologie de l’internet se développe de manière exponentielle depuis sa création. Actuellement, une nouvelle "tendance" a fait son apparition dans le monde des Technologies de l’information et de la communication (IT). Il s’agit du cloud computing. Cette technologie, s’appuyant sur le WEB 2.0, offre des occasions aux sociétés de réduire les coûts d’exploitation des logiciels par leurs utilisations directement en ligne. Divers fournisseurs comme Google, Amazon, IBM offrent une vaste gamme de services de Cloud Computing. Cette technologie vient juste d’éclore où elle est au début de son exploitation mais déjà plusieurs acteurs majeurs cités précédemment adoptent leurs propres stratégies de pionnier qui déterminera l’utilisation du cloud computing des entreprises souhaitant investir ce domaine. 1.1 Les fondements du cloud Le «Cloud Computing» est l’évolution de concepts informatiques étudiés et développés depuis les années septante. Ces concepts ont évolué avec la technolo- gie, les besoins des utilisateurs et un besoin constant de réduire les coûts liés à l’informatique. Afin de définir les fondements du cloud computing, nous intro- duisons les concepts liés. 4
  • 15. Chapitre 1. Cloud Computing : état de l’art 1.1.1 L’informatique utilitaire de John McCarthy Ce concept se base sur la notion de consommation et a été proposé en 1961, lors d’une conférence au MIT (Massachusetts Institute of Technology), par John McCarthy aussi connu comme l’un des pionniers de l’intelligence artificielle (dont il proposa le nom en 1955) et pour avoir inventé du LISP en 1958. Lors de ce discours, John McCarthy suggéra que la technologie informatique partagée «time-sharing» pouvait construire un bel avenir dans lequel la puissance de calcul et même les applications spécifiques pouvaient être vendues comme un service public. Cette idée, très populaire dans les années 60, disparu au milieu des années 70 : à l’époque, les technologies matérielles, logicielles et réseaux n’étaient tout simplement pas prêtes. Le Cloud Computing met en oeuvre l’idée d’informatique utilitaire du type service public, proposée par John McCarthy. 1.1.2 Les services bureau C’est dans cette philosophie, que depuis les années 70, on inventa la notion de «service bureau» pour qualifier une entreprise louant des lignes téléphoniques, répondeurs, services informatiques etc. Généralement, les clients des «services bureau» n’ont ni l’ampleur ni l’expertise pour intégrer en interne ces services, c’est pourquoi ils passent par un prestataire. La combinaison de technologies, processus et expertise dans le domaine des entreprises est la valeur ajoutée des «services bureau», comme modèle économique basé sur leur capacité à produire des services et à les déployer en volume. 1.1.3 Les applications service providers Les ASP, «Application Service Provider» ont aussi leur part dans l’historique du Cloud Computing. Une ASP désigne une application fournie comme un service, c’est ce que l’on nomme maintenant SaaS pour «Software as a Service» dans la terminologie actuelle du Cloud Computing. Plutôt que d’installer le logiciel sur le poste client en ayant à assurer les phases d’installation et de maintenance sur chaque poste, les applications ASP sont hébergées et centralisées sur un serveur unique et accessible par les clients au travers de protocole standard. C’est par exemple le cas avec des applications Web accessibles par http : il n’y a alors plus de 5
  • 16. Chapitre 1. Cloud Computing : état de l’art déploiement ou de maintenance à effectuer sur le poste utilisateur, celui-ci n’a alors besoin que d’un simple navigateur Internet. Le déploiement, la configuration, la maintenance, la sauvegarde, etc. sont désormais de la responsabilité du fournisseur du service, le client est alors consommateur. 1.1.4 La virtualisation Comme nous le verrons dans la suite, la virtualisation a été la première pierre vers le Cloud Computing. En effet, cette notion permet une gestion optimisée des ressources matérielles dans le but de pouvoir y exécuter plusieurs systèmes «virtuels» sur une seule ressource physique et fournir une couche supplémentaire d’abstraction du matériel. Les premiers travaux peuvent être attribués à IBM, qui dans les années 60, travaillait déjà sur les mécanismes de virtualisation en développant dans les centres de recherche de Cambridge et de Grenoble, CMS (Conversation Monitor System), le tout premier hyperviseur. C’est donc depuis presque 50 ans que l’idée d’une informatique à la demande est présente dans les esprits même si les technologies n’étaient jusqu’alors pas au rendez-vous pour pou- voir concrétiser cette idée. 1.2 L’évolution de Cloud computing Le Cloud computing est le fruit d’une évolution pouvant être présentée en 5 phases : • Elle débute avec les Fournisseurs d’Accès Internet (FAI 1.0). Ils ont pour but de mettre en place des moyens de télécommunication pour assurer le raccordement des personnes ou entreprises au réseau internet. • La seconde phase est l’orientation des FAI vers l’hébergement de pages web (FAI 2.0). Cette phase marque un grand bond dans le développement d’internet. • La troisième phase (FAI 3.0) est la possibilité qu’offrent les FAI à héberger des applications métiers des entreprises. • Une connaissance des besoins applicatifs des entreprises permettent aux FAI de faire évoluer leur domaine d’intervention. Ils mettent en place des plate- 6
  • 17. Chapitre 1. Cloud Computing : état de l’art formes de génération d’applications à la demande. Il s’agit des ASP (Appli- cation Service Provider) dont les "Software as a Service" sont des dérives : c’est le FAI 4.0. • La généralisation des pratiques précédentes, la prise en compte de nouvelles pratiques et l’intégration des principes que nous présentons dans les sections suivantes donnent naissance au cloud computing [Fos98]. Figure 1.1: Evolution du cloud computing 1.3 Cloud Computing : Définition et Concepts Le terme «Cloud Computing» possède plusieurs définitions. Nous présentons ci- dessous quelques-unes de ces définitions. 1. Microsoft : L’ensemble des disciplines, technologies et modèles commer- ciaux utilisés pour délivrer des capacités informatiques (logiciels, plates- formes, matériels), comme un service à la demande. • Le service à la demande (vous ne payez que ce que vous utilisez). • Le service est accessible n’importe où. 7
  • 18. Chapitre 1. Cloud Computing : état de l’art • Le service est mesuré, ce qui permet de préserver les ressources. • La quantité est modulable à la location (élasticité infinie). • La quantité est modulable à la location (élasticité infinie). • Les ressources sont mises en commun, ce qui réduit les coûts. 2. Cisco : Les ressources informatiques et les services sont abstraits par rapport à l’infrastructure sous-jacente et sont fournis à la demande. 3. NIST, National Institute of Standards Technology : Le Cloud Com- puting est un modèle d’accès à des ressources informatiques partagées et configurables, depuis un accès réseau, à la demande,de manière simple, à partir de n?importe quel type d?appareil et depuis n’importe quel endroit. Ces ressources sont disponibles rapidement et opérationnelles avec un mini- mums efforts et d’interactions avec le fournisseur de services. 4. EMC, Fournisseur de solutions d’archivage et de stockage : Le Cloud Computing permet aux utilisateurs d’accéder aux pools de ressources quand ils le souhaitent et bénéficient ainsi de l’éfficacité partagée et de souplesse. 5. Open Group : Le Cloud Computing est représenté comme un cube de quatre dimensions : • La localisation physique des données (interne ou externe) par rapport à l’entreprise. • La propriété (propriétaire ou ouvert) : il s’agit non seulement de savoir si vous êtes propriétaire de la technologie, mais aussi de se poser des questions en termes d’interopérabilité,de facilité quant au transfert des données et à votre degré de dépendance par rapport à votre fournisseur. • Les frontières de sécurité (périmètre ou hors périmètre). • L’externalisation : le service est-il fourni par le client ou par un four- nisseur externe. 8
  • 19. Chapitre 1. Cloud Computing : état de l’art Figure 1.2: Utilisation du Cloud 1.4 Cloud vs Grilles Introduites pour la première fois dans les années 90, les grilles de calcul situent la mutualisation au coeur de leur technologie. De même, la mutualisation est au coeur de la technologie du Cloud computing. La question que se pose : "A quel niveau se situe la différence entre le Cloud et les grilles (si elle existe)?". Autrement dit, le terme "Cloud Computing" n’est-il pas une autre appellation de "Grid Com- puting"? Dans la littérature, nous ne trouvons qu’une étude sérieuse consacrée entièrement à cette comparaison [FZRL08]. D’un point de vue technologique, il n’y a pas de réelle différence entre les plateformes de grille et de Cloud. Cependant, l’ouverture du Cloud aux utilisateurs de différents niveaux (pas toujours des informaticiens comme dans les grilles) et éventuellement son caractère commercial sont les poten- tielles différences. De plus, dans les environnements de grilles, les applications (ap- pelées le plus souvent job) s’exécutent généralement sur une durée limitée (même si celle-ci peut être illimitée comme dans le Cloud). Ces différences rendent la ges- 9
  • 20. Chapitre 1. Cloud Computing : état de l’art tion et l’utilisation des plate-formes de Cloud plus complexes que dans les grilles. En résumé, nous considérons que la technologie de Cloud computing utilise la technologie de grille à laquelle elle associe les principes d’ouverture au public de facturation, et d’hébergement durable [FZRL08]. 1.5 Les caractéristiques essentielles de cloud com- puting La définition du National Institute of Standards and Technology américain est souvent considéré comme étant une des références en la matière et elle présente les cinq caractéristiques essentielles du «Cloud Computing» [MG11] qu’on va présen- ter dans ce qui suit. 1.5.1 Self-service à la demande L’utilisateur d’un service de «Cloud Computing» a la capacité («self- provisioning») d’approvisionner lui-même de nouvelles ressources telles que de l’espace disque, des serveurs virtuels, du temps CPU, des nouvelles boîtes aux lettres. 1.5.2 Elasticité et rapidité Les ressources peuvent être allouées ou désallouées rapidement. C’est une des caractéristiques essentielles du Cloud computing; la capacité d’augmenter et de réduire le volume des ressources utilisées en fonction des besoins, de même que libérer les ressources qui ne sont plus nécessaires, au profit d’autres utilisations, ces opérations peuvent se faire par demande ou de façon automatique, par pro- grammation ou triggers. 1.5.3 Accès aux ressources Les ressources sont disponibles via le réseau Internet, ou via l’Intranet dans le cas d’un Cloud privé. Les ressources sont accessibles via des protocoles standards (TCP/IP, SSL, HTTP). L’accès aux ressources peut se faire à partir d’un grand 10
  • 21. Chapitre 1. Cloud Computing : état de l’art nombre de périphériques clients (ordinateurs, clients légers, portables, téléphones mobiles, smartphones) et depuis n’importe quelle plate-forme (Windows, Unix, MacOs, Linux, systèmes propriétaires,...). 1.5.4 Allocation des ressources Les ressources mises à disposition par les providers de «Cloud Computing» sont mutualisées pour répondre aux besoins de plusieurs clients dans une architecture multi-tenant. Une architecture «multi-tenant» ou «multi-locataire» fait qu’une seule instance d’une application est adaptée aux besoins de tous les utilisateurs et offre malgré tout un certain niveau de customisation pour s’adapter de manière individualisée aux différents clients. 1.5.5 Mesure du service Les systèmes contrôlent et optimisent automatiquement l’utilisation des ressources par rapport à une moyenne estimée de consommation du service. 1.6 Taxonomie du cloud computing Différents types des modèles de cloud existent dans la littérature, afin de les représentés nous devons constater les principaux critères de classification : • Le niveau de service c’est le type de service que peut être délivré par le cloud aux clients. • L’accessibilité Les services de cloud diffèrent également dans la façon dont l’accessibilité de leurs déploiements. • La raison de développement C’est la raison qui justifie le déploiement de la plateforme de cloud. 1.6.1 Modèle de délivrance Le cloud computing est la livraison des ressources informatiques comme un service plutôt qu’un produit, selon laquelle les ressources informatiques sont fournies aux 11
  • 22. Chapitre 1. Cloud Computing : état de l’art clients suivant trois services majeurs : Infrastructure en tant que service (IaaS), Plateforme en tant que service (PaaS) et Logiciel en tant que service (SaaS). Souvent l’ensemble de ces catégories de service est représenté sous la forme d’une pile, afin d’illustrer les différentes étapes potentiellement existantes au sein de la chaîne de production de services via le cloud. Cette pile est représentée sur la Figure 1.3, son niveau inférieur, représente les ressources matérielles et réseaux informatiques primaires, puis les trois niveaux intermédiaires représentent les trois types de services du modèle de délivrance, et enfin le niveau supérieur représente les interactions entre les utilisateurs finaux des services proposés et le cloud. Figure 1.3: Différents modèles de délivrance du Cloud Infrastructure en tant que service L’infrastructure en tant que service est plus connue sous le nom d’IaaS pour «Infrastructure as a Service». Ce type de service permet aux développeurs et aux ingénieurs système d’administrer et d’exploiter un «data center». L’infrastructure en tant que service ou l’IaaS permet aux utilisateurs de disposer d’une infrastruc- ture à la demande, peut héberger et exécuter des applications et des services, ou 12
  • 23. Chapitre 1. Cloud Computing : état de l’art être utiliser de façon générique en tant que ressource informatiques au lieu virtuel, tel que le stockage de données et le calcul haut de performance. L’utilisateur n’a aucun contrôle sur l’infrastructure sous-jacente du provider de Cloud mais il a le contrôle sur le système d?exploitation, les applications déployées, les données stockées et un contrôle limité sur les composants réseaux sur le serveur virtuel. On retrouve dans cette catégorie les plateformes comme Amazon Elastic Compute Cloud (EC2) ainsi que d?autre ElasticHosts, GoGrid, Rackspace Cloud, RightScale, Skytap et Orange Business. Plateforme en tant que service La Plateforme en tant que service (PaaS) fournit une couche d’abstraction plus élevé que l’IaaS dans lequel le cloud fournit une plateforme d’exécution, de dé- ploiement et de développement des applications autrement-dit une plateforme ap- plicative de programmation . Les services offerts par ce niveau facilitent la pro- grammation et le déploiement des applications dans le cloud aux utilisateurs sans faire attention à l’infrastructure sous-jacente «achat de logiciels et l’installation supplémentaires. L’utilisateur n’a aucun information sur l’infrastructure sous- jacente du provider de Cloud tel que serveurs virtuel, les composants réseaux, l’emplacement de stockage et le système d’exploitation mais il a le contrôle sur les applications programmées et l’environnement d’hébergement tel que le paramé- trage des services Web, structure des bases de données, nombre de serveurs. On peut distinguer deux types principaux de plateformes en tant que services : • Les plateformes qui offrent des services accessibles en ligne présentées via des API, l’utilisateur interagit avec cette plateforme via une API pour le dé- ploiement de service, c’est le cas de Windows Azure de Microsoft, AppEngine de Google, Force.com de Salesforce. • Les plateformes qui offrent des services de type middleware à installer, le but derrière ce type de plateforme est de permettre aux utilisateurs d’ajouter des fonctions personnalisées aux services classiques, c’est le cas de Appistry, AppScale, VMware vSphere. Logiciel en tant que service Logiciel en tant que service (SaaS) offre des applications complètes fournies à la demande. Ce type de service fournit différents types d’applications telle que 13
  • 24. Chapitre 1. Cloud Computing : état de l’art webmail, suite de bureautique en ligne, CRM, ERP ainsi que les réseaux sociaux et les jeux. Ces applications s’exécutent sur les infrastructures du provider. Elles sont hébergées sur le cloud et accessibles via un navigateur Internet. L’utilisation des services SaaS est plus simple que les autres services où la facturation s’adapte dynamiquement avec la consommation et la paramétrisation des services offerts sont limités. L’utilisateur n’a aucun souci sur l’installation des logiciels ou de leur mise à jour et il n’a aucun contrôle sur l’infrastructure du Cloud tel que serveurs virtuel, les composants réseaux, l’emplacement de stockage, la version de l’application et les fonctions d’application disponibles [TBB03]. On peut distinguer deux types principaux de logiciels ou applications en tant que services : • Des applications sont disponibles au publique général totalement gratuit, par exemple Services Gmail et Facebook, où les e-mails, pièces jointes dé- mail, photos, vidéos et musiques. Généralement ce type d’application est indirectement financé par la publicité, ou par des produits dérivés de l’analyse statistique à grande échelle. • Des applications sont disponibles pour répondre aux attentes des entreprises payantes selon la consommation. Ces applications sont conçues pour fournir des logiciels faciles à utiliser. 1.6.2 Modèles de déploiement La mission principale de providers de cloud computing est de rendre le cloud disponible pour tous les consommateurs. Le cloud peut être accessible pour tous les consommateurs et donc on est dans le cloud public. Il peut être aussi accessible seulement pour des consommateurs particuliers et on se retrouve dans le cas de cloud privé. On peut distinguer trois types de cloud selon le modèle de déploiement : le cloud public, le cloud privé et le cloud communautaire. La figure 1.4 montre l’utilisation du cloud public et le cloud privé. 14
  • 25. Chapitre 1. Cloud Computing : état de l’art Figure 1.4: Modèles de déploiement du Cloud • Le cloud public : Le cloud public est accessible publiquement à tous les particuliers et les groupe industriels. Son propriétaire est un fournisseur de service IaaS, PaaS ou SaaS. Les consommateurs ne sont facturés que pour les applications, les services ou les données qu’ils utilisent. Les ressources sont illimitées et il n’y a donc aucun investissement initial. Les «Clouds» publics sont généralement exploités par des les fournisseurs de cloud commerciaux comme Amazon, Google, Microsoft, GoGrid. • Le cloud privé : Un cloud privé est une infrastructure de cloud n’est utilisé que par une seule organisation. Le cloud privé peut être gérée par l’organisation elle-même ou par un prestataire de service qui peut être située dans les locaux de l’organisation ou à l’externe chez le prestataire de services. L’avantage supplémentaire du cloud privé c’est contrôle total des données par l’organisation, d’autre façon il permet la confidentialité et la sécurité des données grâce aux ressources qui ne peuvent pas être partagées par d’autre organisations [CC12]. • Le cloud hybride : Le cloud hybride est une composition de deux ou plusieurs infrastructures de Cloud publics et privés. Généralement les don- nées sensibles sont gérées au niveau interne par l’organisation ou chez le 15
  • 26. Chapitre 1. Cloud Computing : état de l’art prestataire de cloud prive et l’autre type de données sont gérées par le cloud public. 1.6.3 Le modèle business L’utilisation du cloud computing ne se limite pas uniquement aux entreprises à caractère commercial. Il existe d’autre raisons pour le déploiement de cloud com- puting, nous présentons par la suite deux types d’architecture de cloud computing : • Cloud d’Entreprises : Dans cette catégorie, nous retrouvons des en- treprises de petites et de moyennes tailles disposant chacune de peu de ressources et de moyens de maintenance de leurs infrastructures. Elles se re- groupent donc autour d’un projet de cloud afin de mutualiser leurs capacités. La plate-forme qui en découle est privée, c’est-a-dire accessible uniquement par les entités des différentes entreprises. Cette plate-forme à l’avantage d’être de petite taille et d’accès restreint à des utilisateurs connus. • Cloud Gouvernemental et Recherche Scientifique : Pour des raisons de recherche et de développement, des instituts de recherche mettent sur pied des environnements de cloud. Leur développement est encouragé et financé par des gouvernements. L’accès est exclusivement réservé aux personnes exerçant dans le même domaine de recherche, ou appartenant aux instituts de recherche associées, ou ayant une dérogation précise. Ces plate-formes sont pour la plupart orientées projets. Seules les avancées scientifiques obtenues par les groupes de recherche qui l’utilisent permettent de valoriser la plate- forme. 1.7 Avantages et inconvénients du Cloud Comput- ing Dans cette section, nous discuterons les avantages et les inconvénients du cloud computing. 16
  • 27. Chapitre 1. Cloud Computing : état de l’art 1.7.1 Avantages • Un démarrage rapide : Le Cloud computing permet de tester le business plan rapidement, à coûts réduits et avec facilité. • L’agilité pour l’entreprise : Résolution des problèmes de gestion informatique simplement sans avoir à vous engager à long terme. • Un développement plus rapide des produits où le temps de recherche est réduit pour les développeurs sur le paramétrage des applications. • Pas de dépenses de capital : Plus besoin des locaux pour élargir les infras- tructures informatiques 1.7.2 Inconvenients • La bande passante peut faire exploser le budget d’un utilisateur. • Les performances des applications peuvent être amoindries : Un Cloud public n’améliorera définitivement pas les performances des applications. • La fiabilité du Cloud : un grand risque lorsqu’on met une application qui donne des avantages compétitifs ou qui contient des informations clients dans le Cloud • Taille de l’entreprise : Si l’entreprise est grande alors les ressources sont grandes, ce qui inclut une grande consommation du Cloud. Dans ce cas là, il peut-être plus intéressant de mettre au point un Cloud privé plutôt que d’en utiliser un externalisé. Les gains sont bien plus importants quand on passe d’une petite consommation de ressources à une consommation plus importante. 1.8 Les plateformes cloud computing Grâce aux caractéristiques de cloud, plusieurs compagnies se sont intéressées à ce paradigme et ont développé un certain nombre de solutions dont certaines sont commercialisées. Dans chaque modèle de Cloud Computing, nous trouvons des 17
  • 28. Chapitre 1. Cloud Computing : état de l’art acteurs principaux, tels qu’Amazon, Microsoft, Google, Salesforce.com et Euca- lyptus. Figure 1.5: Les acteurs principaux du cloud computing 1.8.1 Amazon Web Services (AWS) Au début de 2006, Amazon a commencé à fournir l’environnement AWS, qui est un outil facile à utiliser, fiable et économique, qui offre une plateforme de Cloud Computing à travers des services web. La clé du succès de cette plate-forme (plus de 60 000 clients individuels) est dûe au fait qu’elle offre un service immédiat, ne contenant pas de contrats et utilisant le principe «pay as you go» pour le paiement des services utilisés. Amazon Web Services (AWS) est une collection de services informatiques distants (aussi appelés services Web). 1.8.1.1 Elastic Computing Cloud (EC2) EC2 est un ensemble d’infrastructures physiques localisées sur une très large échelle et notamment en Europe et aux Etats-Unis. Il est utilisé par Amazon pour fournir 18
  • 29. Chapitre 1. Cloud Computing : état de l’art des environnements de type IaaS (Infrastructure as a Service). EC2 fournit une grande partie des caractéristiques du Cloud Computing, dont les plus importantes sont : • Scalabilité : Amazon fournit une interface pour définir des règles lorsque l’application doit supporter un facteur d’échelle. • Localité transparence : Le client/l’utilisateur final n’a pas besoin de savoir où les applications se trouvent sur le cloud. Amazon offre des adresses IP élastiques " Elastic IP Addresses" qui lient une adresse IP à un compte utilisateur. • Equilibrage de charge : C’est un service gratuit qui, automatiquement et de manière transparente, distribue le trafic (charge) entre les instances disponibles d’une infrastructure. D’un point de vue technique, lorsqu’une image de l’infrastructure (AMI)(Amazon Machine Image) est démarrée quelque part dans le cloud et que le client reçoit un chemin pour l’utiliser, celui-ci peut ainsi utiliser Amazon le service à travers EC2Web pour configurer la sécurité, l’accès au réseau et choisir le type d’instance, arrêter et surveiller les instances de l’utilisateur AMI utilisant les API de service Web. EC2 prévoit deux types différents d’instance : un type standard qui est conçu pour répondre aux besoins de la plupart des clients et des instances spécifiques qui sont destinées à des applications de calcul intensif. 1.8.2 Service de Stockage Simple(S3) Le S3 (ou Service de stockage simple) est un IaaS mis en place pour le stockage séparé, comme une ressource pour les applications web. Du point de vue PaaS, il fournit une interface de service Web (sous forme de SOAP / WSDL / XML ou REST) qui est utilisée pour récupérer et stocker des données de toute taille à tout moment. 1.8.3 Google AppEngine Google AppEngine est une plate-forme as a servise (PaaS) qui permet aux util- isateurs de construire des applications Web qui fonctionnent sur l’infrastructure 19
  • 30. Chapitre 1. Cloud Computing : état de l’art de Google dans un environnement Java ou Python. L’environnement Java et les environnements d’exécution Python sont conçus pour assurer une exécution rapide des applications, en toute sécurité, et sans interférence de la part d’autres appli- cations. L’AppEngine de google a beaucoup de services sous-jacents fournis par AWS, comme IaaS sous la forme de DataStore, qui offre les mêmes fonctions que SimpleDB AWS et sur JDO qui permet le stockage comme S3. Bien qu’il existe un grand nombre de quotas sur le disque dur, le service est gratuit et il est pos- sible d’utiliser des espaces hors de disque dur moyennant un paiement. Il offre également d’autres fonctions comme Memcache, qui fournit une mémoire cache partagée distribuée pour les applications et urlfetch, qui permet l’extraction des ressources et la communication avec d’autres hôtes utilisant le protocole HTTP en toute sécurité via HTTPS. Il fournit également un service de messagerie avec l’API Mail. Avec AppEngine, on ne paye que ce que l’on utilise. Il n’y a pas de frais d’installation et pas de frais récurrents. Les ressources utilisées par une application, comme le stockage et la bande passante, sont mesurées par gigaoctets et facturées à des tarifs compétitifs. AppEngine ne coûte rien pour commencer. Toutes les applications peuvent utiliser jusqu’à 500 Mo de stockage, une puissance de calcul et une bande passante suffisante pour soutenir une application efficace au service d’environ 5 millions de pages vues par mois, tout à fait gratuitement. Lorsqu’un utilisateur active la facturation de son application, des limites libres sont soulevées et il ne paye que pour les ressources qu’il a utilisées au delà du niveau libre. 1.8.4 Windows Azure Windows Azure est une fondation pour exécuter des applications et stocker des données dans un cloud. Elle fournit les logiciels que les clients de Microsoft peu- vent installer et exécuter eux-mêmes sur leur propre ordinateur. Windows Azure est aujourd’hui un service, que les clients utilisent pour exécuter des applications et stocker des données sur des machines accessibles par Internet appartenant à Microsoft. Ces applications peuvent fournir des services aux entreprises, aux con- sommateurs ou les deux. Windows Azure a été conçue en partie au soutien de Mi- crosoft applications SaaS, si les éditeurs de logiciels peuvent aussi l’utiliser comme une base pour une variété de logiciels de clouds à vocation commerciale. 20
  • 31. Chapitre 1. Cloud Computing : état de l’art 1.9 Conclusion Le cloud computing repose bien souvent sur des techniques qui existent depuis parfois de nombreuse années. C’est à la fois son point fiable et son point fort. Se baser sur l ’existant donne confiance aux utilisateurs potentiels et assure une certaine stabilité et une expertise dans le domaine. Malheureusement, c’est égale- ment en essayant de faire du neuf avec du vieux qu’on se retrouve parfois dans des situation alambiquées ou des techniques récentes reposent sur des concepts trop anciens. Néanmoins, la plus grande force du cloud computing est son utilisation à des fins commerciales : payer uniquement ce qui est consommé. 21
  • 32. Chapitre 2 Déploiement d’applications : tour d’horizon Introduction Le Cloud Computing, est un nouveau modèle informatique qui consiste à pro- poser les services informatiques sous forme de services à la demande, accessi- bles de n’importe où, n’importe quand et par n’importe qui. Très utilisé dans l’informatique répartie qui permet d’accéder à des ressources virtuelles config- urables (e.g., serveurs, espace de stockage, bande passante) sous forme de services. Pour être accessible en tant que service (Software-as-a-Service, SaaS) sur le Cloud, une application peut être déployée soit sur l’infrastructure (Infrastructure- as-a-Service, IaaS) du fournisseur de Cloud, soit sur la plateforme qui va l’exécuter (Platform-as-a-Service, PaaS). Dans les deux cas, il faut configurer et dimen- sionner l’environnement d’exécution selon l’application pour prendre en compte l’hétérogénéité et l’élasticité inhérentes au paradigme du Cloud Computing. Notamment, il existe un grand nombre de provider ayant des niveaux de fonctionnalité et des possibilités de dimensionnement hétérogènes parmi les dif- férentes solutions de cloud disponibles (Amazon EC2, Rackspace cloud , Win- dowsAzure). Lors d’un déploiement d’application sur un PaaS, il faut choisir un serveur d’application, la fréquence CPU nécessaire à l’exécution, la base de don- 22
  • 33. Chapitre 2. Déploiement d’applications : tour d’horizon nées à utiliser, sa capacité en terme espace mémoire, etc. Cette variabilité en termes de configuration et de dimensionnement offre une multitude de possibil- ités de configurations qui sont généralement effectuées de manière ad hoc et sont sources d’erreurs lorsqu’elles sont configurées à la main [QD12]. La structure du chapitre est la suivante, la section 2 est dédiée à l’élaboration du problème de déploiement. La section 3 décrit les concepts de base de déploiement automatique. Afin de faciliter la compréhension du problème de déploiement, nous montrons dans la 4 section les principales approches ou techniques utilisées. Dans la section 5, nous discutons les travaux connexes et enfin nous terminons notre chapitre par une conclusion. 2.1 Motivation Le déploiement d’une application dans le Cloud offre à son propriétaire de nom- breux avantages : réduction des coûts, passage à l’échelle, haute disponibilité, etc. Cependant, la migration d’une application ou le développement d’un nouveau service dans le Cloud est un défi sérieux. En effet, il existe différent choix au mo- ment de sélectionner le fournisseur de Cloud capable à fournir l’environnement pour héberger l’application en tant que service. Ainsi, certains utilisateurs préfèrent dé- ployer leur application vers une solution de Cloud qu’ils ont déjà utilisée mais qui ne correspond pas complètement aux exigences de l’application à déployer (e.g., changer le type de base de données) plutôt que de se risquer à configurer un nou- veau cloud computing malgré qu’il est plus adapté à leurs exigences [QD12]. L’émergence vers le cloud computing exige aux développeurs de reconstruire ou reconcevoir sensiblement les applications existantes pour répondre aux nouvelles exigences. Le Cloud offre de nombreux choix de configuration et de dimensionnement tant au niveau de l’application à déployer que des environnements d’exécution IaaS ou PaaS paramétrables. Il est donc très difficile de prendre les bonnes décisions 23
  • 34. Chapitre 2. Déploiement d’applications : tour d’horizon face aux questions suivantes : Quel niveau de déploiement PaaS? ou IaaS? Quel fournisseur choisir? Comment être sûr qu’il représente une bonne solution pour les types d’applications et de déploiements souhaités? Il était possible aux logiciels existants de bénéficieer d’un nouveau environnement exécution. 2.2 Le déploiement automatique des logiciels dans le cloud computing Pour exécuter correctement un logiciel dans une architecture de cloud, il est néces- saire de déployer non seulement le logiciel lui-même, mais aussi ses dépendances (e.g., les autres services qui ont une dépendance avec le logiciel du moment où il est en cours d’exécution). Pour satisfaire cette exigence, chaque développeur, qui a besoin de déployer une application dans le cloud : • doit acquérir un accès clé au fournisseur de cloud, • sélectionner une instance de machine dans le fournisseur qui prend en charge l’application, • configurer et installer la machine virtuelle. Après cela, le développeur a besoin pour déployer l’application et ses dépendances (dans un ordre approprié) dans la machine virtuelle sélectionnée. Un moyen plus efficace pour déployer le logiciel dans l’environnement de cloud est par l’automatisation de ce processus, étant donné que les détails de configuration peuvent être extraits à un plus haut niveau diminuant ainsi les efforts humains pour l’exécuter. Un autre avantage du déploiement automatique des logiciels dans le cloud est l’élimination des tâches manuelles qui sont sujettes à l’erreur, tels que : le logiciel de configuration de la pile, l’authentification entre les machines virtuelles, spécification des dépendances entre les composants de service et entre les services, la définition des temporelle et dépendances spatiales et, enfin, l’analyse des ressources dans l’environnement cloud afin de remplir les exigences minimales du service [RJdRSM16]. 24
  • 35. Chapitre 2. Déploiement d’applications : tour d’horizon 2.3 Définition du déploiement automatique Le déploiement de logiciel est défini dans comme le processus, constitué d’un en- semble d’activités liées, entre l’acquisition et l’exécution du logiciel. Ce processus a pour objectif de rendre opérationnel une application, qui peut ainsi être utilisée par les utilisateurs. Une fois l’application déployée, le processus de déploiement continue par les mécanismes d’adaptation du logiciel afin de chercher à atteindre une qualité de service. En effet, les infrastructures modernes sur lesquelles on déploie des applications sont caractérisées par de fréquentes variations de leur en- vironnement. Automatisant un déploiement comprend la planification d’une séquence d’actions de bas niveau comme ; la création et la suppression de composants, le port de liai- son et dé-liaison, et les changements d’état interne, qui atteint une configuration avec au moins un composant dans un état interne de cible spécifique [Fay15]. 2.4 Les approches de déploiement Après une étude bibliographique sur les états de l’art sur les principales approches du déploiement automatique des logiciels sur le cloud, nous avons sélectionné quelques-unes d’entre ellex pour une description et une analyse. Cette section explique les architectures et les solutions adoptées existantes pour le déploiement automatique des logiciels sur le cloud. 2.4.1 Les scripts Pour faire face au déploiement automatique, différents outils et solutions utilisent la codification manuelle par le biais de scripts, ce qui nécessite plus de temps pour déployer le logiciel. Ce type d’approche réduit le risque d’erreur humaine lors du processus de déploiement manuelle, et pour le cas de développeur, il s’occupe de développement d’application au lieu la configuration du cloud. Le seul inconvénient de ces approches de déploiement, c’est qu’il augmente les coûts associés à la codification, le temps et les efforts humains [RJdRSM16]. 25
  • 36. Chapitre 2. Déploiement d’applications : tour d’horizon 2.4.2 Langage de programmation Nous avons également noté d’autre solutions utilisant le déploiement automatisé de services dans le cloud à l’aide de langage de programmation. En comparaison avec les approches présentées à l’aide des scripts, ces approches sont plus avan- tageuses en fonction de l’effort humain et le temps appréciée dans le processus de déploiement. 2.4.3 Les approches semi-automatiques En outre, les modèles virtuels proposés par Disnix ont présenté des mécanismes semi-automatisés pour le déploiement. En d’autres termes, ces approches nécessi- tent encore que certaines étapes sont effectuées manuellement pendant le processus de déploiement. La solution proposée par Ardagna et. Al. a présenté une approche partiellement orientée et semi-automatisée pour le déploiement de logiciel. Elle ex- ige un certain niveau de la compréhension de l’utilisateur final sur les détails de la structure des clouds et une charge lourde de l’information dans les modèles de déploiement demandé à l’utilisateur [RJdRSM16]. 2.4.4 Les Workflow Cette solution propose que les développeurs aient les services à déployer pour créer les modèles UML du déploiement de logiciels. Ces modèles définissent tous les informations requises pour le déploiement (machines virtuelles, services, ap- plications, dépendances, systèmes d’exploitation des machines virtuelles, services référentiels et des machines virtuelles, des bases de données, fournisseur de ser- vices et les clés d’accès) en tant que paramètres sans la nécessité du codage de la configuration d’une machine virtuelle. Ces modèles sont transformés pour générer le code de déploiement à l’aide d’outils spécialisés. 2.4.5 Approche basée sur les modèles L’objectif est de déployer le logiciel à un niveau plus élevé d’abstraction pour réduire les efforts humains et le temps passé à effectuer la tâche de déploiement, car l’approche basée sur un modèle est une meilleure façon d’augmenter la productivité 26
  • 37. Chapitre 2. Déploiement d’applications : tour d’horizon de développeur. Cette approche est la proposition de l’OMG qui est en cours de standardisation. La spécification de l’OMG, elle a pour objectif de fournir un modèle de données et d’exécution permettant de gérer le développement, le packaging, le déploiement et la configuration d’applications à base de composants. La spécification est décrite à travers une entité appelée "Platform-Independent Model" (PIM), composée d’un ensemble de modèles UML et de règles sémantiques associées. Le PIM est indépen- dant de tout modèle de composant particulier. Pour utiliser cette spécification avec un modèle particulier de composant, il faut créer une entité appelée "Platform- Specific Mapping" (PSM). Le PSM est un ensemble de règles qui transforme les modèles UML du PIM en données et modèles d’exécution, dans un format ap- proprié pour le déploiement du modèle de composant cible. La spécification n’a pour l’instant standardiser que le PSM pour le modèle de composant Corba, dans lequel les modèles de données et d’exécution sont transformés en deux formats : XML schema pour le stockage sur disque et l’échange entre outils, et IDL (In- terface Definition Language) pour la représentation du modèle d’exécution et des communications entre les entités du déploiement. 2.5 Les outils et les Frameworks de déploiement D’après une étude bibliographique sur les travaux qui s’articulent sur le dé- ploiement automatique des logiciels sur le cloud computing, nous avons sélectionné les principaux outils et frameworks de déploiement afin de les décrire : 1. L’outil SALOON est un outil de configuration et de déploiement. Basé sur des ontologies , SALOON permet de spécifier une configuration tech- nique pour l’application à déployer et de dimensionner cette configuration [QRD16]. 2. OSGi fournit un environnement d’exécution, basé sur la technologie Java. Le processus de déploiement inclut les activités suivantes : l’installation, la mise à jour et la désinstallation. Il fournit un cadre qui permet le déploiement d’applications Java, extensibles et téléchargeables (appelées "bundle"). Un "bundle" est constitué de classes Java et d’autres ressources (librairies, 27
  • 38. Chapitre 2. Déploiement d’applications : tour d’horizon fichiers, etc.), l’ensemble pouvant fournir un ou plusieurs services aux util- isateurs. Ils sont déployés sous la forme d’archives JAR (Java ARchive). Les "bundles" sont les seules entités utilisées pour le déploiement d’applications. Les appareils OSGi compatibles peuvent télécharger, installer, supprimer les "bundles". L’installation et la mise à jour se font de manière dynamique, en gérant les dépendances entre les "bundles" et les services. Les limitations de ce modèle sont liées au fait qu’il est spécifique à l’environnement Java et à des applications non distribuées. 3. ACTRESS est un cadre basé sur l’ingénierie des modèles et qui fournit des outils pour concevoir et intégrer des mécanismes d’adaptation dans une ap- plication, sous la forme de boucle de contrôle. 4. EUREMA (ExecUtable RuntimE MegAmodels) est aussi une approche basée sur l’ingénierie des modèles. EUREMA propose un langage de modélisa- tion et un environnement permettant la spécification et l’exécution de mé- canismes d’adaptation constitues d’une ou de plusieurs boucles de contrôle. L’approche repose sur une architecture en couches, dans laquelle le système auto-adaptatif est séparé logiquement en deux parties: la couche métier qui fournit les fonctionnalités, et au dessus, la couche qui gère le mécanisme d’adaptation (de la couche métier), sous la forme de boucles de contrôle [VG14]. 5. Li et al. [LSTE12] ont proposé une encapsulation de services dans des ma- chines virtuelles et le déploiement de services dans une gamme de cloud scénarios, tels que le cloud privé, cloud public, cloud fédéré et le multi cloud. Ils ont conclu que le temps de déploiement dépend du scénario de cloud. 6. Ardagna et al. [ADNC+ 12] ont présenté une approche pilotée par les mod- èles pour la conception et l’exécution des applications sur plusieurs nuages appelés MODAClouds où ils ont proposé une architecture divisée en deux points de vue, la conception et temps d’exécution de déploiement de logi- ciels. 7. Pour découpler une machine virtuelle à partir du logiciel, Zhang et al. [ADNC+ 12] ont élaboré un framework pour le déploiement des applications 28
  • 39. Chapitre 2. Déploiement d’applications : tour d’horizon dans le cloud, qui vise à réduire le temps et les coûts liés au déploiement. La proposition diffère des autres approches présentées jusqu’ici, car le logiciel ne serait pas préinstallé sur l’image VM. Le framework proposé par Zhang offre un ensemble de fonctionnalités divisées en trois étapes :(i) la première étape c’est la préparation de logiciels, le client stock le logiciel dans un dépôt ; (ii) la deuxième étape c’est l’étape de sélection, le client peut sélectionner un logiciel à partir du référentiel. Le logiciel est installé dans une machine virtuelle et cette VM est envoyée et installée sur le machine local du client ; (iii) et enfin la dernière partie c’est le déploiement de logiciel, au lieu de stocker l’application dans une image VM, elle fonctionne sur la machine lo- cale sur le côté client sans l’installer. 2.6 Conclusion Dans ce chapitre, nous avons présenté les solutions très récentes qui permettent de déployer des applications sur le cloud, afin de faciliter le choix de la solution possible qui répond aux exigences techniques de la configuration et au dimension- nement de ces exigences. Vus l’absence d’un consensus entre les comités de standardisation sur les approches de déploiement automatique des applications sur le cloud et le manque de détails techniques sur ces approches, il était préférable d’étudier les solutions décrites au paravant «les outils et framework» d’un point de vu technique en faisant abstrac- tion des détails théoriques. L’étude des outils et frameworks, nous a permis de nous orienter vers les scripts. L’architecture de la solution qui va être présenté dans le chapitre suivant a été réalisée en respectant les exigences techniques tel que le choix des providers gra- tuits. 29
  • 40. Chapitre 3 Conception du processus de déploiement Introduction Nous avons présenté dans le chapitre précédent les principales contributions sur le déploiement automatique des applications sur le cloud. Parmi les approches citées (chapitre 2, section 4), on s’intéresse beaucoup plus à l’approche scripts sur lequel on a appliqué notre travail. Nous allons, dans la suite de ce chapitre, présenter les deux providers sur lesquelles on a travaillé. Ensuite nous présenterons l’architecture générale pro- posée. 3.1 Choix de l’approche Script Nous avons étudié dans le chapitre 2, les différentes approches de déploiement automatique des applications sur le cloud qui existent dans la littérature. Notre choix a convergé vers les scripts. Les scripts que nous avons choisis pour le dé- ploiement automatique sont des fichiers SH (script shell). Un script shell permet d’automatiser une série d’opérations. Il se présente sous la forme d’un fichier con- tenant un ou plusieurs commandes qui seront exécutées de manière séquentielle. Le script de déploiement contenant le code exécutable pour le déploiement d’une application vers le cloud computing, et vous pouvez aussi utiliser vos scripts de 30
  • 41. Chapitre 3. Conception du processus de déploiement déploiement pour exécuter le package d’installation pour le fournisseur que vous avez utilisé. Nous avons choisis les scripts de déploiement car ce type d’approche réduit le risque d’erreur humaine lors du processus de déploiement manuelle, et pour le cas de développeur, il s’occupe de développement d’application tout le temps. 3.2 Environnement de travail Dans notre projet, nous nous sommes basé sur l’idée de déploiement avec les lignes de commandes pour les lier avec des programme script Shell dans le but d’automatiser le déploiement et la configuration des applications et aussi l’installation des interface de ligne de commandes (CLI) du fournisseur. L’architecture que nous proposons se base essentiellement sur la définition d’un ensemble de commandes à utiliser avec une interface de ligne de commande (CLI). Chaque commande spécifie une action à effectuer dans un système. 3.2.1 CLI Une interface de ligne de commande (CLI) est une interface utilisateur pour le sys- tème d’exploitation d’un ordinateur ou d’une application dans laquelle l’utilisateur répond à une invite visuelle en tapant une commande sur une ligne spécifiée, reçoit une réponse du système, puis saisit une autre commande [LF05]. CLI est une an- cienne méthode pour interagir avec les applications et les systèmes d’exploitation et est utilisé pour effectuer des tâches spécifiques requises par les utilisateurs. Elle est complètement textuelle, contrairement à l’interface graphique qui utilise des options graphiques qui permettent à l’utilisateur d’interagir avec le système d’exploitation et des applications. CLI permet à un utilisateur d’effectuer des tâches par la saisie des commandes. Son mécanisme de travail est très facile, Les utilisateurs saisissent la commande spécifique, appuient sur "Enter", puis attendent une réponse. Après réception de la commande, la CLI traite en conséquence et envoie la sortie/résultat sur le même écran; l’interpréteur de ligne de commande est utilisée à cette fin [LF05]. 31
  • 42. Chapitre 3. Conception du processus de déploiement CLI a été introduite avec la machine de téléscripteur. Ce système est basé sur un traitement par lots. Les ordinateurs modernes supportent CLI, le traitement par lots et l’interface graphique dans une seule interface. Afin de mieux faire usage de CLI, un utilisateur doit être en mesure d’entrer dans un paquet de commandes (un par un) rapidement. Il existe de nombreuses applications (systèmes mono-traitement) qui utilisent encore des CLI pour leurs opérateurs. En outre, certains langages de programmation, comme Forth, Python et BASIC, offrent des CLI. l’interpréteur de ligne de commande est utilisé pour implémenter l’interface à base de texte. 3.2.2 CLI de Linux Une invite de commande, également appelé l’invite du Shell ou invite, est un message texte court, généré automatiquement au début de la ligne de commande qui sert à informer l’utilisateur que le système est prêt pour la commande suivante. ,élément de données ou autre entrée et aider le plan d’utilisateur et d’exécuter les opérations suivantes. Lorsque le Shell bash est utilisé, qui est le shell par défaut sur Linux, l’invite de commande par défaut contient le nom de l’utilisateur, le nom de l’ordinateur et le nom du répertoire courant (à savoir, le répertoire dans lequel l’utilisateur travaille actuellement). 3.3 Conception Dans cette partie nous présenterons la démarche conceptuelle de la solution adop- tée pour le déploiement des applications sur le cloud. La conception de la solution se base sur l’utilisation du formalisme UML à travers quelques diagrammes UML. 3.3.1 Architecture de déploiement Cette section présente l’architecture de déploiement qui permet à la fois le dé- ploiement des applications à l’aide des fichiers scripts qui sont livrés et déployés vers le cloud final. La solution comprend des fonctions telle que : 32
  • 43. Chapitre 3. Conception du processus de déploiement • le déploiement pourrait être exécuté à partir de la machine local du développeur ou service web d’hébergement. • l’utilisateur «le développeur dans notre cas» spécifie la préférence du provider cloud. • La possibilité de vérifier la configuration et l’installation des différents outils avant d’entamer une nouvelle installation et configuration. • prendre en compte l’inscription sur au moins un fournisseur cloud avant de procéder vers le déploiement. Figure 3.1: Architecture de déploiement 3.3.2 Diagramme de cas d’utilisation Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous système,d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant un sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, ils sont donc une vision orientée utilisateur de ce besoin au contraire d’une vision informatique [Aud07]. Le rôle des diagrammes de cas d’utilisation est de permettre de recueillir, d’analyser et d’organiser les besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la première étape UML d’analyse d’un système [Aud07]. Acteur Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système [Aud07]. Cas d’utilisation Un cas d’utilisation est une unité cohérente représentant une fonctionnalité visible de l’extérieur.Il réalise un service de bout en bout, avec un déclenchement, un 33
  • 44. Chapitre 3. Conception du processus de déploiement déroulement et une fin, pour l’acteur qui l’initie [Aud07]. Notre cas d’utilisation contient un seul acteur qui va interagir avec le système, c’est le développeur (Figure 3.3.2). Le développeur c’est la personne qui s’en charge de développer des applications et des logiciels avec n’importe quel langage de programmation. Le développeur c’est le seul collaborateur au sein du système de déploiement automatique. Ci-après ses actions possibles : • Déployer des applications vers le cloud • Vérifier l’installation des CLI • Installer et configurer les CLI Figure 3.2: Diagramme de cas d’utilisation de notre système 3.3.3 Diagramme d’Activité Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots de 34
  • 45. Chapitre 3. Conception du processus de déploiement contrôle et de flots de données. Ils permettent ainsi de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation [Aud07]. Les diagrammes d’activités sont particulièrement adaptés à la description des cas d’utilisation. Plus précisément, ils viennent illustrer et consolider la description textuelle des cas d’utilisation. Action Une action est le plus petit traitement qui puisse être exprimé en UML. Une action a une incidence sur l’état du système ou en extrait une information. Les actions sont des étapes discrètes à partir desquelles se construisent les comportements [Aud07]. Transition Le passage d’une activité vers une autre est matérialisé par une transition. Graphiquement les transitions sont représentées par des flèches en traits pleins qui connectent les activités entre elles. Dans la figure 3.3.3 est représenté notre diagramme d’activité. 35
  • 46. Chapitre 3. Conception du processus de déploiement Figure 3.3: Diagramme d’Activité 3.3.4 Diagramme de séquence Les diagrammes de séquences mettent en valeur les échanges de messages (déclen- chant des événements) entre acteurs et objets (ou entre objets et objets) de manière chronologique où l’évolution du temps se lit de haut en bas. Chaque colonne cor- respond à un objet (décrit dans le diagramme des classes), ou éventuellement à un acteur, introduit dans le diagramme des cas. La ligne de vie de l’objet représente la durée de son interaction avec les autres objets du diagramme. 36
  • 47. Chapitre 3. Conception du processus de déploiement Un diagramme de séquences est un moyen semi-formel de capturer le com- portement de tous les objets et acteurs impliqués dans un cas d’utilisation. On peut indiquer un type de message particulier : les retours de fonction qui, bien entendu, ne concernent aucun message mais signifient la fin de l’appel de l’objet appelé. Ils permettent d’indiquer la libération de l’objet appelant (ou de l’acteur). Un emploi abusif de retours de fonction peut alourdir considérablement le diagramme, aussi un usage parcimonieux est-il conseillé. On peut faire apparaître de nombreuses informations de contrôle le long de la ligne de vie d’un objet [Sig05] . Dans notre modèle, le développeur représente l’utilisateur de notre applica- tion. Il accède à l’interface utilisateur de système pour lancer l’application de déploiement qui permettra de d’offrir le choix du fournisseur qui propose un scé- nario spécifique de déploiement. La figure 3.4 présente le processus de déploiement de ce projet. Figure 3.4: Diagramme de séquence pour le déploiement 37
  • 48. Chapitre 3. Conception du processus de déploiement 1:Lancé Au début de processus, le développeur exécute l’interface de ligne de commande. 3:Lancer interface déploiement avec interface de ligne de commande, le développeur lance (4 : Appelé Interface de déploiement) à partir quelques commandes sur Interface utilisateur . 4:Appelé Dans cette action, interface utilisateur exécute quelque commande pour afficher l’interface de déploiement. 6:déployer avec GitHub Dans cette étape, le développeur a le choix de déployer avec GitHub ou avec path sur GitHub. Il va utiliser URL de l’application sur GitHub et interface utilisateur va (8 : Clone application) et ceci se fera automatiquement. 8: Clone application on clone l’application sur un service d’hébergement . 10:déployer avec path Le développeur utilise un chemin de l’application sur le disque et l’application est déployée avec (11:Script 2) automatiquement . Diagramme de sequence installation et configuration Dans ce diagramme nous allons présenter l’installation et la configuration des fournisseurs utilisés. 38
  • 49. Chapitre 3. Conception du processus de déploiement Figure 3.5: Diagramme de séquence pour "installation et configuration" 1 : installer Si le développeur n’a jamais utilisé IBM-BlUEMIX, il faut passer par instal- lation et configuration à travers l’interface IBM-BlUEMIX et tout se fera de manière automatique mais si le développeur a déjà installé la CLI de IBM- BlUEMIX , le processus interface utilisateur va afficher la version de l’installation . 2 : script3 pour installer la CLI de provider bluemix, le script3 est exécuté. 3 : Afficher la version si le provider est déjà installé, on affiche la version de l’installation 4 :installer et configurer le terminal commence l’installation puis la configuration du provider. 39
  • 50. Chapitre 3. Conception du processus de déploiement 6 : installer Pour la plate-forme heroku,appliquer le même mécanisme de IBM-BlUEMIX. 3.3.5 Diagramme de classes Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il a pour objectif de décrire la structure des entité manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d’un code orienté objet ou à un niveau de détail plus important, les modules du langage de développement [Roq09]. Comment le représenter Le diagramme de classes met en oeuvre des classes, contenant des attributs et des opérations, et reliées par des relations (associations, généralisation, ...) [Roq09]. Figure 3.6: Diagramme de Classes 40
  • 51. Chapitre 3. Conception du processus de déploiement 3.3.6 Description de diagramme de classes la classe terminal : Cette classe que nous avons créée présente comment le développeur d’application va lancer l’application de déploiement et permet d’afficher les résultats de déploiement et de l’installation. Cette classe a comme méthode : • Commande () : cette méthode permet de lancer l’application à travers le développeur . La classe module d’accès : Cette classe permet la création de la connexion aux différentes plate-formes. La classe Platform-IBM : cette classe représente le provider Bluemix qui nous avons utilisé pour déployer les applications vers le cloud IBM. Cette classe a comme méthode : • configuré() : cette méthode permet de configurer les plate-forme (installer quelques plugins à utiliser pour les plate-formes) La classe Platform-heroku : cette classe représente le provider Heroku qui nous avons utilisé pour déployer les applications vers le cloud Heroku. Cette classe a comme méthode : • configuré() : cette méthode permet de configurer les plate-forme (installer quelques plugins utilisés pour les plate-formes) La classe Application : la classe application représente l’application qui le développeur va déployer. Cette classe a comme méthode : • afficher(): pour affichage de notre application soit dans le local host soit dans le provider qui nous avons choisi. La classe CLI : notre architecture est basée sur cette classes pour pour exé- cuter les commandes de déploiement de différents providers .Cette classe a comme méthode : • installer(): cette méthode permet d’installer la CLI de provider utilisé. 41
  • 52. Chapitre 3. Conception du processus de déploiement 3.4 Conclusion Nous avons présenté dans ce chapitre, la démarche conceptuelle du déploiement automatique vers le cloud computing . Nous avons utilisé des diagrammes UML pour modéliser notre système ce qui nous a permis d’exploiter son fonctionnement en faisant ressortir ses principales caractéristiques ainsi que les interactions entre ses différents composants. 42
  • 53. Chapitre 4 Mise en oeuvre du déploiement 4.1 Introduction Afin de concrétiser, valider et évaluer la stratégie utilisée pour le déploiement automatique des applications sur le cloud, nous avons conçu un outil reflètant notre architecture proposée dans le chapitre 3. Aussi nous avons effectué une série d’expérimentations dont les résultats et les interprétations font l’objet du présent chapitre. Nous commencerons d’abord, par décrire l’environnement dans lequel nous avons réalisé notre logiciel, puis nous discuterons et analyserons les résultats que nous avons obtenus. 4.2 Langage et outils de développement Nous avons développé notre application sur deux providers cloud qui sont IBM- Bluemix et Heroku. L’application a été développée en utilisant le langage de programmation Python. 4.2.1 Langages Pour les besoins d’implémentation de notre application, nous avons utilisé un lan- gage de commandes et un langage de programmation de haut niveau qu’est Python. Ces deux langages sont présentés dans ce qui suit. 43
  • 54. Chapitre 4. Mise en oeuvre du déploiement Script shell Un shell (sh)(Figure 4.1) est un interpréteur de langage de commandes dont le Csh est une évolution du shell sh utilisant une syntaxe plus proche du langage C. Le C shell est un interpréteur de commandes qui s’exécute généralement dans une fenêtre en mode texte, ce qui permet à l’utilisateur de taper des commandes. Le C shell peut également lire les commandes depuis un fichier, appelé alors script. Comme tous les shells Unix, il prend en charge les caractères spéciaux de remplacement de nom de fichier, les pipes, le mode multi-ligne, la substitution de commande, des variables et des structures de contrôle pour les tests de conditions et d’itérations [Joy80]. Figure 4.1: Logo de Script shell Python Python est un langage objet interprété de haut niveau, créé au début des années quatre-vingt-dix par Guido Van Rossum au Centrum voor Wiskunde à Informatica, Amsterdam. En 1995, Rossum poursuivit le développement de Python à la Corporation for National Research Initiatives de Reston (Virginie) [Dup10]. Le langage Python est modulaire. La définition du langage est très succincte et autour de ce noyau concis, de nombreuses librairies ou modules ont été développées. Python est assez intuitif, être à l’aise avec ce langage revient à connaître tout autant sa syntaxe que les nombreux modules disponibles, eux-mêmes écrits en Python [Dup10]. 44
  • 55. Chapitre 4. Mise en oeuvre du déploiement Le langage Python est à syntaxe positionnelle en ce sens que l’indentation fait partie du langage. Le point virgule permet de séparer les instructions en langage C, l’accolade permet de commencer un bloc d’instruction. En Python, seule l’indentation permet de marquer le début et la fin d’un tel bloc. Ce procédé consiste à décaler les lignes vers la droite pour montrer qu’elles appartiennent au même bloc d’instructions [Dup10]. Figure 4.2: Logo de Python 4.2.2 Plate-forme IBM-Bluemix Bluemix est un PaaS (Platform as a Service). C’est une plate-forme cloud IBM qui fournit aux développeurs d’accéder à des logiciels IBM pour l’intégration, la sécurité, transaction et d’autres fonctions clés,ainsi que les logiciels de partenaires commerciaux [Liu11]. Construit sur la technologie open source Cloud Foundry, Bluemix rend le développement des applications plus facile avec la plate-forme en tant que ser- vice (PaaS). Le but est de simplifier la livraison d’une application en fournissant des services qui sont prêts pour une utilisation immédiate et aussi des capacités 45
  • 56. Chapitre 4. Mise en oeuvre du déploiement d’hébergement pour permettre le développement à l’échelle interne [Raf15]. Figure 4.3: Plate-forme Bluemix 4.2.3 Plate-forme Heroku Heroku, prononcé hey-oh-koo, est l’un des principaux fournisseurs de PaaS dans le secteur des logiciels de cloud. Il se révèle être la solution leader PaaS pour les petites et grandes entreprises. Avec une amélioration constante et la philoso- phie de commodité sur la «configuration», Heroku est devenu la principale plate- forme de développement d’applications de cloud pour les développeurs. Il a été utilisé par plus de de 40000 sites. La Philosophie Heroku est de permettre aux développeurs de se concentrer uniquement sur l’écriture de l’application Web et oublier les serveurs. Heroku prend en charge à la demande de la construction, le déploiement, l’exécution, et la mise à l’échelle de l’application réalisée par le développeur [Han14]. 46
  • 57. Chapitre 4. Mise en oeuvre du déploiement Figure 4.4: Plate-forme Heroku Heroku est une plate-forme d’application cloud polyglottes qui offre une grande flexibilité dans le choix d’un langage de programmation approprié pour développer des applications Web (Figure 4.4). Heroku fournit un support de plate-forme pour Ruby on rails, Java, Node.js, Clojure, Scala, python, PHP [Han14]. 4.3 Description du fonctionnement de notre logi- ciel Dans cette partie, nous somme intéressé à la démonstration de notre application à travers un exemple en faisant référence à quelques interfaces graphiques. 47
  • 58. Chapitre 4. Mise en oeuvre du déploiement 4.3.1 Lancement de l’application Pour lancer notre application, on doit utiliser un terminal pour exécuter une com- mande avec l’interpréteur SHELL . Ceci est illustré dans la figure 4.5. Figure 4.5: Appel de notre application 4.3.2 Menu principal Après l?exécution de lappel de notre application, une interface s’affiche. Elle représente le menu principal (voir la figure 4.6). Le menu principal contient deux sous-menu : File et Aide. Chacun d’eux est composé d’un ensemble d’items qui vont être expliqués dans les sections suivantes. Le choix de la plate-forme cloud s’apparaît sous forme de boutons sur le menu prin- cipal. Deux plate-formes en choix sont possibles devant l’utilisateur (développeur de notre cas) : la plate-forme Heroku ou la plate-forme IBM bluemix. 48
  • 59. Chapitre 4. Mise en oeuvre du déploiement Figure 4.6: Menu principal 4.3.3 Déploiement avec Heroku Afin de réaliser le déploiement avec Heroku, la première chose à effectuer est de cliquer sur le bouton Heroku. Ensuite vérifier l’installation et la configuration des CLI, configurer et installer les CLI dans le cas contraire. Enfin sélectionner le type de stockage de l’application à déployer. L’application à déployer peut être sauvegardée soit au niveau de la machine locale, soit au niveau du service Web d’hébergement GitHub. Machine locale Dans le cas où l’application se trouve au niveau de la machine locale, l’accès à l’application à déployer se fait en sélectionnant le chemin à partir de l’interface. (voir la figure 4.7) 49
  • 60. Chapitre 4. Mise en oeuvre du déploiement Figure 4.7: déployer au niveau de la machine local Service web d’hébergement GitHub Maintenant si l’application se trouve au niveau du service web d’hébergement GitHub. Il faut cloner l’application à partir de l’interface.(voir la figure 4.8) Figure 4.8: déployer au niveau du service web d’hébergement GitHub 4.3.4 Le déploiement avec IBM bluemix Afin de réaliser le déploiement avec IBM bluemix, la première chose à effectuer est de cliquer sur le bouton IBM bluemix. Ensuite vérifier l’installation et la configuration des CLI, configurer et installer les CLI dans le cas contraire. En fin sélectionner l’endroit où l’application se trouve. L’application à déployer est déposé soit au niveau de la machine local, soit au niveau du service web d’hébergement GitHub. 50
  • 61. Chapitre 4. Mise en oeuvre du déploiement Machine local Dans le cas où l’application se trouve au niveau de la machine local, sélectionner le chemin à partir de l’interface. (voir la figure 4.9) Figure 4.9: Déploiement au niveau de la machine locale Service web d’hébergement GitHub Si l’application se trouve au niveau du service Web d’hébergement GitHub, l’accès se fait à l’aide d’un clonage de l’application à partir de l’interface (voir la figure 4.10). 51
  • 62. Chapitre 4. Mise en oeuvre du déploiement Figure 4.10: déployer au niveau du service web d’hébergement GitHub 4.4 Expérimentation Dans cette expérimentation, nous avons défini des mesures d’évaluation objectives, pour l’évaluation du notre logiciel. Cette enquête a été entamée afin de montrer l’utilité et les avantages de notre logiciel. Parmi les mesures d’évaluation de notre logiciel, nous avons sélectionné pour cette étude: (i) l’effort fourni et (i) le temps consommé. Pour la métrique l’effort fourni, elle est subdivise en réalité sur trois sous métriques : L’effort fourni dans la première utilisation de la plate-forme cloud, l’effort fourni dans le deuxième déploiement et les déploiements postérieurs et l’effort fourni pour la maintenabilité. La même chose pour la métrique ; le temps consommé, elle est subdivise en réalité sur trois sous métriques : le temps consommé fourni dans la première util- isation de la plateforme cloud, le temps consommé dans le deuxième déploiement et les déploiements postérieurs et le temps consommé pour la maintenabilité. Notre enquête a été réalisée par moi-même et par mon co-encadreur. Dans 52
  • 63. Chapitre 4. Mise en oeuvre du déploiement mon cas a fin d’effectuer un déploiement manuellement pour la première fois à pris une journée ou plus, selon la plateforme cloud utilisée. Pour le cas de mon co-encadreur le temps estimé pour faire un premier déploiement manuellement réussi a pris une à trois jours, selon la plateforme cloud utilisée. Le temps consommé afin de réaliser un deuxième déploiement manuelle ma pris entre 15 et 30 minutes. Pour le cas de mon-encadreur, le déploiement a pris entre un 3 4 trois-cardeur heur jusqu’à deux heurs. Après avoir effectué l’expérience, nous avons recueilli et analysé les données. Pour la mesure temps consommé, on a obtenu les valeurs indiquées sur la figure 10. La figure 10 montre que le temps consommé est diminué lorsqu’on utilise notre logiciel du déploiement automatique. Cela veut dire qu’il y a eu un impact positif avec l’utilisation de la solution proposée par notre logiciel. La figure 11 présente la mesure effort fourni. Elle montre un graphique qui contient le pourcentage de l’effort fourni. Le pourcentage est calculé en fonction des facteurs d’effort pondéré sur les coefficients. Les facteurs d’effort sont : la documentation, les tentatives d’installation et de configuration et l’inscription sur les plate-formes cloud. Figure 4.11: La métrique temps consommé sans/ avec l?aide de notre solution «déploiement automatique» 53
  • 64. Chapitre 4. Mise en oeuvre du déploiement Figure 4.12: La métrique effort fourni sans/ avec l?aide de notre solution «déploiement automatique» 4.5 Conclusion Dans ce chapitre, nous avons présenté l’implémentation de notre logiciel ainsi les résultats obtenues. Aussi nous avons réalisé plusieurs séries d’expérimentations dans le but de comparer notre solution avec la solution classique «manuel» tout en variant différents paramètre comme : le temps consommé et l’effort fourni. Les résultats de comparaison ont montré que notre stratégie de déploiement automatique donne des bons résultats par rapport au déploiement manuels qui peuvent être fastidieux et peut prendre beaucoup de temps et d’effort, en particulier lorsque la plateforme cloud est utilisée pour la premier fois. Dans le cas où un problème critique est découvert avec une application après le déploiement, l’effort manuel et le temps fourni peut également être perdu et coûte des efforts de restauration ou de rapiéçage. 54
  • 65. Conclusion générale Ce travail s’inscrit dans le contexte de déploiement automatique des applications dans le cloud où il nous a immergé complètement dans le monde du cloud, ces plate-formes et providers. En effet nous avons découvert les multiples façons et techniques d’exploiter ce domaine. Ce projet a adopté une solution de scripts pour automatiser le déploiement des applications dans le cloud. Notre principal objectif était de réduire la charge de travail des développeurs et les chercheurs qui ont besoin d’utiliser les ressources de cloud. Pour évaluer notre solution, nous avons mené une expérience impliquant une utilisation manuelle du cloud et une autre automatique. L’expérimentation a révélé que l’automatisation de déploiement avait réduit les risques impliqués dans le déploiement, la charge de travail et temps perdu. Ce qui permet aux développeurs de déployer le cloud plus fréquemment et de manière fiable. La mise en oeuvre d’une solution de déploiement automatisé en réalité n’est pas automatique à cent pour cent, mais les avantages de risque réduit, une fiabilité accrue et la transparence par rapport aux déploiements manuels montrent que cette manière de faire est un investissement très convaincant. La limite du temps et le manque de financement ont constitué une barrière à l?amélioration de notre logiciel. L?applicatif réalisé répond au cahier de charge. Reste à préciser que la conception effectuée et l?architecture technique permet d?ajouter d?autres services pour répondre aux futurs besoins éventuels. Les travaux menés au cours de ce travail ouvrent un certain nombre de perspec- tives à la fois liées à l’automatisation du déploiement et aux plate-formes cloud. 55
  • 66. Conclusion générale Nous pourrons proposer quelques pistes de développement pour le futur : • Afin de réaliser un déploiement automatique, on est obligé de passer par la création des fichiers de configuration pour chaque application. Ces fichiers de configuration sont de type YML et WAR et POCFILE. La création automa- tique des fichiers de configuration peut être considérée comme une perspec- tive d’évolution de l’automatisation de déploiement puisque notre solution édite les fichiers de configuration d’une façon manuelle. • Notre expérimentation a été appliquée sur deux exemples d’application. Mais elle pourrait être effectuée sur d’autre applications contenant une multitude de service tel que : le service SGBD, le service mobile etc. • Finalement, l’exécution de notre solution a été effectuée sur deux plateformes cloud gratuites Heroku et IBMbluemix. On peut dire que notre solution pourrait être exécutée sur la majorité des plate-formes cloud. Vu le manque des cartes crédits normalement financées par l’université d’Oran 1 et l’accès à la plupart des plate-formes cloud est payant, nous avons limité le nombre de plate-formes cloud à deux. Il est important de noter que la recherche des plate-formes cloud gratuites était une tâche très difficile et fastidieuse à la fois. 56
  • 67. Bibliographie [ADNC+ 12] Danilo Ardagna, Elisabetta Di Nitto, Giuliano Casale, Dana Petcu, Parastoo Mohagheghi, Sébastien Mosser, Peter Matthews, Anke Gericke, Cyril Ballagny, Francesco D’Andria, et al. Modaclouds: A model-driven approach for the design and execution of applica- tions on multiple clouds. In Proceedings of the 4th International Workshop on Modeling in Software Engineering, pages 50–56. IEEE Press, 2012. [Aud07] Laurent Audibert. UML2. Interfaces, 3:10, 2007. [CC12] Gerard Conway and Edward Curry. Managing Cloud Computing-A Life Cycle Approach. In CLOSER, pages 198–207, 2012. [Dup10] Xavier Dupré. Langage Python, 2010. http ://www.xavierdupre.fr/. [Fay15] Maurice-Djibril Faye. Déploiement auto-adaptatif d’intergiciel sur plate-forme élastique. PhD thesis, Ecole normale supérieure de lyon- ENS LYON, 2015. [Fos98] I Foster. The grid, blueprintfor a new computing infrastructure, 1998. [FZRL08] Ian Foster, Yong Zhao, Ioan Raicu, and Shiyong Lu. Cloud comput- ing and grid computing 360-degree compared. In Grid Computing Environments Workshop, 2008. GCE’08, pages 1–10. Ieee, 2008. [Han14] Anubhav Hanjura. Heroku Cloud Application Development. Packt Publishing Ltd, 2014. [Joy80] William Joy. An Introduction to the C shell. University of California, Berkeley, 1980. [LF05] M.J. Little and S. Froyd. Command line interface abstraction engine, june 2005. US Patent 6,907,572. 57
  • 68. Bibliographie [Liu11] Haoyun Liu. Introduction to IOT, 2011. [LSTE12] Wubin Li, Petter Svard, Johan Tordsson, and Erik Elmroth. A gen- eral approach to service deployment in cloud environments. In Cloud and Green Computing (CGC), 2012 Second International Confer- ence on, pages 17–24. IEEE, 2012. [MG11] Peter Mell and Tim Grance. The NIST definition of cloud comput- ing, 2011. [QD12] Clément Quinton and Laurence Duchien. Vers un Outil de Configu- ration et de Déploiement pour les Nuages. In JLdP-Journée Lignes de Produits, pages 83–94, 2012. [QRD16] Clément Quinton, Daniel Romero, and Laurence Duchien. SA- LOON: a platform for selecting and configuring cloud environments. Software: Practice and Experience, 46(1):55–78, 2016. [Raf15] Stifani Raffaele. IBM Bluemix: The Digital Innovation Platform. Copyright International Business Machines Corporation 2015, July 2015. [RJdRSM16] Franklin Magalhães Ribeiro Jr, Tarcísio da Rocha, Joanna CS San- tos, and Edward David Moreno. A Model-Driven Solution for Auto- matic Software Deployment in the Cloud. In Information Technol- ogy: New Generations, pages 591–601. Springer, 2016. [Roq09] Pascal Roques. UML 2 par la pratique. Editions Eyrolles, 2009. [Sig05] Olivier Sigaud. Introduction à la modélisation orientée objets avec UML. Laboratoire d’Informatique de Paris VI (LIP6), France, 2005. [TBB03] Mark Turner, David Budgen, and Pearl Brereton. Turning software into a service. Computer., 36(10):38–44, 2003. [VG14] Thomas Vogel and Holger Giese. Model-driven engineering of self- adaptive software with eurema. ACM Transactions on Autonomous and Adaptive Systems (TAAS), 8(4):18, 2014. 58