Deploy automatic in the cloud

MEMOIRE DE MASTER
Spécialité : Ingénierie des Systèmes Complexes et Multimédia
Discipline : Informatique
DÉPLOIEMENT AUTOMATIQUE DES
APPLICATIONS SUR LE CLOUD
COMPUTING
présenté et soutenu
par
KADDOUR GUETTAOUI Abdelhalim
Juin 2016
JURY
Président : Mme HADI Nadia
Encadreurs : DEBA El Abbassia Université d’Oran 1
AOUAT Asmaa Université d’Oran 1
Examinateurs : HADJ TAYEB Lylia Université d’Oran 1
Département 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 ﬁgures 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éﬁnition 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éﬁnition 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 Workﬂow . . . . . . . . . . . . . . . . . . . . . . . . . . 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

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

• Chapitre 4 : discute les aspects d’implémentation du déploiement automa-
tique d’applications.
Enﬁn, 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

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

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

• 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

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

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éﬁnition 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 proﬁt 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

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

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

ê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

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

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 conﬁdentialité 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

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

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éﬁnitivement pas les performances des applications.
• La ﬁabilité 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

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

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

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

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 conﬁg-
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 conﬁgurer 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

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

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

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

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

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

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

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

• 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

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

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

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

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

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

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

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

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

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 diﬀé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

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 ﬁn 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 simpliﬁer la livraison d’une application en fournissant
des services qui sont prêts pour une utilisation immédiate et aussi des capacités
45

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 «conﬁguration», 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

Figure 4.4: Plate-forme Heroku
Heroku est une plate-forme d’application cloud polyglottes qui oﬀre une grande
ﬂexibilité 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

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

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

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

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 ﬁgure 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 ﬁgure
4.10).
51

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

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

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

Deploy automatic in the cloud

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Deploy automatic in the cloud

Similaire à Deploy automatic in the cloud (20)

Deploy automatic in the cloud