Un environnement de déploiement automatique pour les

ICSSEA 2002-7 Lestideau
Un environnement de déploiement automatique
pour les applications à base de composants
Vincent Lestideau
Adele Team Bat C
LSR-IMAG , 220 rue de la chimie
Domaine Universitaire, BP 53
38041 Grenoble Cedex 9 France
E-mail: [email protected]
Résumé : Avec le développement des réseaux et de l’Internet, la problématique du déploiement automatisé du
logiciel à grande échelle est devenue de plus en plus cruciale. Le déploiement est un procédé logiciel complexe
couvrant plusieurs activités allant de la configuration jusqu’à la désinstallation du logiciel. Une approche
prometteuse est d’utiliser la technologie des fédérations d’outils. Ainsi dans la conceptualisation, nous avons
considéré un système de déploiement comme une fédération d’outils coopératifs en distinguant les rôles de
chaque outil Cet article présente un « framework qui permet de décrire de manière unifiée les outils. L’article
développe cette approche et étudie plus particulièrement son application et expérimentation sur les phases de
configuration et d’installation
Mots clés : Environnement de déploiement, processus de déploiement, outils de déploiement, configuration,
installation.
Abstract : With the development of the networks and the Internet, the software deployment topic is becoming
more and more critical. Deployment is in fact a complex software process with activities from the configuration
to the software de-installation. Each step uses an appropriate tool. A promising approach is to use federation
technology. During conceptualization, we consider deployment as a system federating cooperative tools by
distinguishing the role of each tool. The paper presents our approach and focuses particularly on its application
and experimentation to the configuration and installation steps.
Keywords : Deployment, environment, process, tools, configuration, installation.
1. Introduction
Le déploiement du logiciel est actuellement un des thèmes majeurs en génie logiciel. Ceci est dû en particulier à
l'avènement des nouvelles technologies liées à l'Internet. Un des objectifs recherchés concerne l'automatisation
d'un processus de déploiement couvrant toutes les étapes du cycle de vie d'un logiciel telles que la configuration,
l'installation, la mise à jour et la désinstallation. Ce domaine fait l’objet d’un développement actif
particulièrement de la part d’industriels comme en témoigne le nombre de produits disponibles sur le marché.
Nous avons tout d'abord spécifié notre processus de déploiement en terme d'activités et de relations. Notre
objectif est de créer un environnement de déploiement permettant d'automatiser ce processus. Pour cela, nous
avons commencé par une étude des outils existants. Nous nous sommes rendu compte qu'il n'existe pour l'instant
aucun outil couvrant tout le cycle de vie d'une application. Les outils ayant été conçu de manière ad hoc et
partielle en privilégiant seulement un ou plusieurs aspects du déploiement. Par contre, ils sont souvent très
performants dans leur domaine spécifique d'utilisation.
Notre travail concerne plus particulièrement le déploiement d'applications à base de composants. Nous avons
remarqué que les nouveaux modèles à composants tiennent de plus en plus compte des problèmes de
déploiement. Pour résumer, elles proposent des moyens de résoudre, en amont, des problèmes de déploiement
comme le versionnement lors de l'installation.
Afin de réaliser notre environnement de déploiement, nous avons choisi de proposer une approche utilisant
certaines des fonctionnalités offertes par les outils existants. Ainsi nous bénéficions à la fois des avantages des
outils de déploiement et de la programmation à base de composants. Nous avons comme objectif de couvrir tout
le cycle de vie d'un logiciel.
Notre article se présente de la manière suivante. Nous présentons d'abord notre processus de déploiement.
Ensuite nous avons réalisé une synthèse (du point de vue déploiement) des outils et des modèles à composant.
Puis nous décrivons notre environnement en spécifiant les différentes entités de notre architecture et notre
processus de déploiement. Afin de valider notre approche, nous présentons l'implémentation de notre
environnement de déploiement.
2. Processus de déploiement logiciel
Selon la définition de Carzaniga [1], le processus de déploiement fait référence à toutes les activités et leurs
interactions lors du cycle de vie d’une application (figure 1). Ces activités concernent le versionnement,
l’installation, la désinstallation, la mise à jour, l’adaptation, l’activation et la désactivation d’une application.
Dans ce papier, nous nous intéressons aux activités de versionnement et d’installation, dans le cas d’applications
basées sur des modèles à composants. Les autres activités sont présentées plus brièvement.
Activation et désactivation. Ces activités correspondent aux étapes de démarrage (ou d’arrêt) des composants
nécessaires lors du démarrage (ou de l’arrêt) d’une application. Sans l’activation de ces composants,
l’application ne peut pas fonctionner correctement.
Mise à jour. Il s’agit d’un cas particulier de l’activité d’installation. Elle consiste à installer une autre version
d’une application déjà installée. Du fait que certains de ses composants sont déjà installés, elle est moins
complexe que l’activité d’installation.
Adaptation. Cette activité permet de modifier une application déjà installée. Cependant, à l’inverse de l’activité
de mise à jour, on garde la même version de l’application, en se contentant de modifier sa configuration.
Désinstallation. Cela consiste à désinstaller une application, en s’assurant que les autres applications installées
fonctionneront toujours correctement. Pour cela, il faut tenir compte des composants partagés et de la mise à jour
des registres.
Dans notre processus, nous avons décomposé l’activité de versionnement en 3 sous activités. En particulier, nous
avons ajouté l’activité de configuration, qui permet de créer les différents packages correspondants aux versions.
Configuration. Un aspect intéressant des applications à base de composants est la possibilité de réutiliser des
composants existants pour créer de nouvelles applications. Généralement, les composants sont stockés dans des
2/8
bases de développement et ils sont implémentés sous plusieurs versions. Nous avons développé un processus de
sélection permettant d’annoter et de sélectionner les versions des composants correspondant à une configuration
souhaitée.
Packaging. Cela consiste à récupérer les composants issus de l’activité de configuration, ainsi que leurs
annotations. Un package contient aussi la liste des dépendances logicielles de l’application, des informations
liées au déploiement (identifiant du package, date de création…) et une description de l’application packagée
(une sorte de manifeste). Cette description sera utilis ée pour déterminer si un package peut être installé sur une
machine donnée, en respectant les contraintes liées à sa configuration.
Transfert. Cette activité traite du transport d’un package d’un producteur vers un site consommateur. Dans le
cas des réseaux, il faut tenir compte en particulier de la présence éventuelle de firewalls et de l’utilisation des
bandes passantes.
Installation. Cette activité réalise le « dé-packaging » des packages reçus, l’installation des différents
composants, la modification des registres, la résolution des dépendances. Toutes ces opérations ayant été préparé
lors des activités précédentes (configuration et packaging).
Packager
Configurer
Transférer
Installer
Désinstaller
Mettre à jour
Adapter
Désactiver
Activer
Figure 1 : Processus de déploiement
Depuis peu, le déploiement est devenu une étape importante dans l’ingénierie logicielle et de nombreux outils
ont été créer pour essayer de couvrir tout le processus de déploiement. En parallèle, les nouvelles spécifications
de modèles à composant, comme « Component Corba Model » ou « Microsoft .NET » ont pris en compte les
problèmes de déploiement. Dans le paragraphe suivant, nous présentons certains de ces outils de déploiement
ainsi que les deux modèles à composants, cités auparavant.
3. Les outils et travaux existants
Dans cette partie, nous nous intéressons à deux outils liés au déploiement, ainsi qu’à deux spécifications de
modèles à composants.
3-1 Les outils de déploiement
3-1-1 InstallShield Developer
Actuellement, le logiciel d’installation le plus connu se nomme InstallShield Developer [2] (ID). Son processus
d’installation est composé de trois activités : la création, la distribution et la maintenance des applications. C’est
un outil spécialisé dans les applications basées sur la plate forme Windows, ce qui lui permet d’utiliser les
fonctionnalités offertes par le service Microsoft’s Windows Installer [3]. Ce service offre des moyens
3/8
automatiques pour réparer les fichiers corrompus d’une application. Il permet d’installer et de désinstaller
correctement les applications sans altérer les applications déjà installées. Et enfin il offre un service de retour en
arrière permettant un retour à l’état initial en cas de problèmes lors de l’installation. Afin d’utiliser ce service, ID
crée un fichier MSI (selon le format Windows Installer) contenant des informations sur le package (version, date,
nom du vendeur…), une base de données relationnelle et les fichiers de l’application (ou leur localisation, s’ils
ne sont pas contenus dans le package).
L’activité de création spécifie les fichiers de l’application et résout les dépendances. A la fin, un package est
créé. L’activité de distribution fait référence au transfert du package. Pour cela, différents moyens sont
proposés : via le Web, via un intranet, ou en utilisant un CD d’installation. Une fois le package transféré, il est lu
et exécuté par le service Windows Installer. L’activité de maintenance consiste à mettre à jour et à assurer la
cohérence de l’application installée.
En terme de déploiement, ID propose une solution efficace pour les applications Windows en réalisant les
activités d’installation et en assurant la cohérence des applications installées.
3-1-2 Java Web Start
Java Web Start [4] (JWS) est une solution pour le déploiement d’applications sur le web. Il déploie des
applications basées sur la technologie Java, soit à partir du web ou soit à partir d’un gestionnaire (le Java
Application Manager). Les applications sont lancées par un simple clic sur une page Web ou dans le
gestionnaire. Si l’application n’est pas déjà présente sur la machine de l’utilisateur (l’application sera donc
installée pour la première fois), JWS lance le téléchargement de l’application. Les fichiers de l’application sont
ensuite stockés et mis en mémoire. Ainsi l’application pourra être exécutée autant de fois que l’on souhaite sans
devoir l’installer à chaque fois. Avant chaque exécution, JWS vérifie qu’il s’agit de la version la plus récente,
sinon il lance automatiquement la mise à jour et ceci de façon transparente pour l’utilisateur. De cette façon,
seules les versions les plus récentes sont exécutées.
En terme de déploiement, JWS propose une solution permettant d’exécuter toujours les versions les plus récentes
de chaque application. Ce système permet de résoudre les problèmes de mise à jour et de cohérence du système,
mais ceci implique d’être régulièrement connecté au serveur d’applications.
3-1-3 Synthèse
Il existe un grand nombre d’outils proposant des solutions partielles pour les problèmes de déploiement. Dans
certains cas, ils sont très efficaces, mais ne couvrent pas tout le processus de déploiement. Certains (comme Java
Web Start) couvrent une large partie du spectre mais ils imposent des contraintes assez restrictives (applications
java, serveur web…).
3-2 Les modèles à composants.
Récemment, de nouvelles spécifications ont essayé de traiter explicitement les problèmes dus au déploiement en
en tenant compte dès la phase de conception. Dans ce paragraphe, nous décrivons deux de ces modèles en
insistant plus particulièrement sur la partie liée au déploiement.
3-2-1 Le modèle à composant Corba (CCM)
CCM est une spécification développée par l’OMG [5]. Elle spécifie explicitement un scénario de déploiement
pour les composants. Dans CCM, les composants sont packagés dans des packages auto-descriptifs pouvant être
assemblés entre eux. On forme ainsi un assemblage, qui correspond à l’unité de déploiement de CCM. Pour
réaliser le déploiement d’applications CCM, il est nécessaire de définir la liste des composants constituant
l’application, leur localisation logique et leurs connections. Pour chaque composant, il est nécessaire de spécifier
ses éléments (interfaces, implémentations), de décrire ses contraintes système (OS, ORB…) et sa configuration
initiale. Toutes ces informations sont nécessaires pour installer et exécuter une application. Afin d’utiliser ces
informations, CCM spécifie plusieurs descripteurs, décrivant les packages, les composants et les assemblages.
Ces différents descripteurs sont basés sur le langage OSD [6]. CCM propose un scénario de déploiement, basé
sur ces packages et leurs descripteurs, assurant l’installation cohérente des applications CCM.
4/8
Dans ce modèle, le déploiement est réalisé par un ORB et par des outils de déploiement. Ces outils utilisent les
services de l’ORB pour réaliser le transfert, l’installation, l’assemblage, l’instantiation et la configuration des
applications sur les machines des clients.
3-2-2 Microsoft .NET
Il s’agit du Framework [7] proposé par Microsoft pour résoudre ses problèmes de versionnement et de
déploiement, dus essentiellement aux DLLs. Connu sous le nom d’ « enfer des DLLs » [8], le problème de
versionnement apparaît, par exemple, lorsqu’on installe une nouvelle application et qu’elle comporte des
composants déjà présent sur la machine, mais sous une autre version. Pour résoudre ce genre de problèmes,
Microsoft utilise un nouveau concept appelé assemblage ; il est constituée par le code des composants, leurs
ressources et un manifeste. Ce manifeste comporte des informations sur le composant telles que la liste des
fichiers, les dépendances et d’autres informations utilisées pour exécuter le code. Pour concevoir des
applications .NET, on doit respecter les contraintes suivantes :
•
•
•
•
Les assemblages doivent être descriptifs, ainsi il n’y a pas d’impact sur les registres lors des
installations. Ceci permet de simplifier les activités d’installation et de désinstallation.
Les assemblages doivent respecter une politique de numérotation des versions.
Le Framework doit supporter les composants « side by side » permettant à plusieurs versions d’un
composant de s’exécuter sur la même machine.
L’application doit être isolée le plus possible : un assemblage ne doit être accessible que par une seule
application. Les assemblages peuvent être partagés mais ils doivent alors respecter des contraintes plus
fortes comme avoir un nom global et unique.
Dans .NET, le problème de versionnement durant l’activité d’installation semble être résolu, mais pour cela, il
faut respecter des contraintes fortes comme le non partage (entre différentes applications) des assemblages. En
terme de déploiement, .NET améliore la qualité des installations en diminuant le risque de modifier
irrémédiablement une application déjà installée.
3-2-3 Synthèse
En spécifiant explicitement les contraintes à respecter pour le déploiement, ces spécifications améliorent les
activités de déploiement (en terme de dépendance, de localisation physique des composants…). Ainsi certains
problèmes de déploiement sont pris en compte dès la phase de développement de l’application et non lors de
l’installation elle-même. Un autre avantage est l’effort de standardisation des descriptions.
3-3 Conclusion
Il apparaît que les problèmes de déploiement sont de plus en plus pris en compte par des outils et par des
spécifications de modèles à composants. Les outils essayent de résoudre et d’automatiser plus particulièrement
les problèmes d’installation et de maintenance, alors que les spécifications essayent d’aider ces outils en
résolvant en amont une partie du travail (descriptions…).
4. Notre approche
Comme nous l’avons précédemment expliqué, les outils existants ne couvrent pas tout le processus de
déploiement, mais ils supportent des sous parties de ce processus. Notre approche consiste à utiliser ces outils
pour constituer un environnement de déploiement. Une caractéristique importante au sujet de ces outils est qu’ils
n’ont pas été conçus pour fonctionner ensemble et qu’ils ne sont pas modifiables (il s’agit pour la plupart de
produits du commerce). C’est pourquoi nous avons décidé d’utiliser la technologie des fédérations développée
par notre équipe.
4-1 La technologie des fédérations
Cette technologie [9] permet de créer des applications en fédérant des outils existants. Ces outils ont été conçus
pour un usage autonome, ils ne peuvent pas être modifiés et ils peuvent interagir directement avec leur
environnement. Nous n’expliquerons pas dans cet article, les moyens utilisés pour fédérer les outils ensemble.
De cette façon, tout le processus de déploiement peut être automatisé et guidé par la fédération (à l’aide d’un
moteur de processus nommé APEL [10]). Une fédération est décrite en termes de rôles, qui sont les seules entités
manipulées par la fédération. Il s’agit d’une abstraction d’un ensemble de fonctionnalités. Les outils (jouant des
5/8
rôles) ne sont pas considérés explicitement par la fédération. Cette technique nous permet d’être indépendant des
outils que nous pouvons remplacer sans problèmes.
Cette technologie offre aussi les avantages suivants : une infrastructure de communication permettant de
transférer des données à travers des firewalls et la possibilité d’exécuter des applications à distance sur une
machine distante sans intervention ou autorisation de son utilisateur.
4-2 Notre fédération de dépl oiement
Actuellement, nous avons développé les parties de notre environnement de déploiement concernant l’installation
et la configuration. Nous nous sommes intéressés aux applications à base de composants. Pour cela nous avons
utilisé un modèle de composants inspiré de CCM ; nous avons ajouté le concept d’externalisation permettant un
composant constitué de plusieurs composants d’être lui-même un composant.
4-2-1 Architecture
En terme d’architecture, nous avons identifié 3 entités (figure 2) dans notre fédération d’installation :
•
•
•
un ensemble de serveurs d’applications,
un serveur de déploiement,
un ensemble de sites physiques.
Serveur d’applications
Serveur de déploiement
Site physique
Figure 2 : Architecture de déploiement
Le serveur d’applications stocke un ensemble d’applications. Ces applications sont disponibles sous la forme
d’un package ; résultat de l’activité de configuration (recherche des composants composant l’application…) puis
d’ un outil de packaging (comme InstallShield). Chaque package comporte une description de l’application.
Un site physique peut correspondre soit à la machine d’un utilisateur final, soit à une simple machine comme un
distributeur de billets. Afin de gérer automatiquement le déploiement, chaque site est décrit par un modèle de
site, qui donne une description physique (mémoire, processeur, capacité de stockage…) et logicielle (liste des
applications installées..) du site. On peut aussi associer à un site, un ensemble de contraintes ou de règles à
respecter lors d’une installation.
Le serveur de déploiement est l’élément central de notre architecture. Toutes les communications et échanges
entre les différentes entités passent par son intermédiaire. Lui seul, à la connaissance, à un instant donné, des
différentes entités connectées à la fédération, ce qui procure une grande souplesse. Il gère toutes les
communications entre les autres éléments.
4-2-2 Les rôles
La première étape d’identification, nous a permis d’identifier les rôles de notre scénario : configuration,
installation et analyse.
6/8
La configuration a pour rôle de créer une application à partir d’une configuration (par exemple, on peut imposer
un langage de programmation) et en respectant des contraintes comme le système d’exploitation.
L’installation a pour objectif de récupérer les composants d’une application, de lister les dépendances, de
packager l’application.
L’analyse permet à partir d’une configuration (description des fonctionnalités, choix de l’utilisateur…) de
vérifier qu’un package (par l’intermédiaire de sa description) répond à la recherche effectuée et que son
installation ne sera pas dommageable pour les applications déjà installées sur la cible.
4-2-3 La configuration
L’objectif de cette activité consiste à concevoir une application correspondant à une configuration donnée. Il
s’agit de trouver le bon assemblage de composants réalisant les fonctionnalités recherchées. Pour cela, nous
utilisons un système d’annotations et de règles. Les annotations permettent de décrire chaque composant ainsi
que ses différentes implémentations. Les règles assurent la cohérence de ces annotations. Dans notre modèle,
chaque composant possède une interface et chaque interface est implémentée par des implémentations natives
(code) ou composites (un ensemble de composants). Afin de disposer d’un large choix de versions pour chaque
composant, nous nous sommes intéressés à la phase de développement des composants, ainsi nous disposons
d’une base hiérarchisée de composants où les composants peuvent êtres terminés ou dans état de transition.
L’objectif de ce papier, n’étant pas de décrire ce système [11], il suffit de savoir que l’on peut sélectionner
automatiquement (en utilisant un algorithme de parcours) les composants, formant une application, en assurant la
cohérence de l’ensemble.
4-2-4 L’installation
Dans notre scénario, nous distinguons deux types possibles de déploiement ; en mode « push » (installation sans
aucune demande ou intervention de l’utilisateur de la machine cible) ou en mode « pull » (à la demande explicite
de la machine cible).
La stratégie en mode « push » :
Dans ce cas, la décision d’installer une application n’est pas prise au niveau des sites physiques mais au niveau
du serveur de déploiement. C’est le cas, par exemple, lors de la mise à jour d’une application donnée sur un
ensemble de sites physiques. Dans notre scénario, nous avons ajouté un rôle de superviseur, qui a pour objectif
de trouver pour chaque cible, la bonne configuration de l’application à installer. Pour cela, il récupère d’abord la
configuration souhaitée (à l’aide du modèle de site de la cible), puis il interroge le serveur de déploiement pour
récupérer la liste des serveurs d’applications disponibles. Ensuite, il recherche les packages contenant
l’application voulue et pour chacun il vérifie (à l’aide de l’outil d’analyse) s’ils sont compatibles. Dans le cas
positif, il demande à la fédération de transférer le package. Une fonctionnalité importante de cette stratégie, c’est
qu’elle permet d’effectuer des transfert d’un point à un autre de la fédération et ceci malgré la présence
éventuelle de firewalls. Une fois le package transféré, on lance automatiquement sur la machine cible, un outil
d’installation, qui réalise l’installation proprement dite. Dans le cas où aucun package ne correspondrait, on peut
utiliser un outil de configuration pour le créer.
La stratégie en mode « pull » :
La différence avec la stratégie précédente, c’est que la décision d’installer une application est prise par le site
physique. Dans ce cas, il peut participer au choix de la configuration souhaitée. Ensuite, le serveur de fédération
prend le contrôle des opérations (recherche du package, analyse, installation…). Ceci est dû au fait que l’on ne
veut pas que la machine cible puisse communiquer directement avec les serveurs d’application (problèmes de
sécurité, contrôle des installations…).
Dans les deux cas, on doit mettre à jour le modèle de site à chaque installation. Nous avons implémenté ces
scénarios en utilisant un moteur de processus, qui permet l’automatisation. Chaque scénario est modélisé sous la
forme d’un processus où chaque activité est jouée par un rôle. Ainsi nous avons créé une infrastructure de
déploiement (réalisant les activités de configuration et d’installation) à l’aide de laquelle nous pouvons modéliser
différents scénarios en terme de rôle tout en étant indépendant d’un scénario particulier.
7/8
Nous avons crée une fédération de déploiement couvrant les activités de configuration et d’installation de notre
processus de déploiement. Nous avons donc le noyau autour duquel nous allons greffer de façon quasi
transparente les rôles et processus des autres activités du cycle de vie du déploiement d’un logiciel.
5. Conclusion et perspectives
Le but de notre étude est de fournir un environnement de déploiement générique tendant vers le zéro
administration. Une des principales contributions de notre étude consiste en une définition d’un « framework »
pour le déploiement. A partir de ce « framework », nous pouvons appliquer de nombreuses stratégies, pour
adapter notre environnement. Des expérimentations ont été réalisées en laboratoire. Nous sommes à la phase
d’expérimentation en vraie grandeur avec nos partenaires industriels.
Bibliographie
[1] Carzaniga, A. Fuggetta, R.S. Hall, A. van der Hoek, D. Heimbigner, A.L. Wolf. A Characterization Framework for
Software Deployment Technologies. Technical Report CU-CS-857-98, Dept. of Computer Science, University of
Colorado, April 1998.
[2] Web site InstallShield Developer
http://www.installshield.com/isd/
[3] Web site Microsoft's Windows Installer
http://www.microsoft.com/
[4] Web site Java Web Start
http://java.sun.com/products/javawebstart/
[5] J. Mischkinsky - CORBA 3.0 New Components Chapters - CCMFTFDraft ptc/99-10-04 -- OMG TC Document ptc/9910-04 October 29, 1999
[6] A. van Hoff, I. Hadi Partovi, T. Thai - The Open Software Description Format (OSD) –
Site Web : http://www.w3.org/TR/NOTE-OSD
[7] Web site .NET Framework
http://msdn.microsoft.com/library/
[8] Rick Anderson - The End of DLL Hell- Microsoft Corporation – January 2000
http://msdn.microsoft.com/library/
[9] Jacky Estublier and Anh-Tuyet LE. Design and development of Software Federation ICSSEA 2001. Paris, France.
4-6 December 2001.
http://www-adele.imag.fr/Les.Publications/intConferences/ICSSEA2001Est.pdf
[10] S. Dami, J. Estublier and M. Amiour. APEL: A Graphical yet Executable Formalism for Process Modeling.
Kluwer Academic Publishers, Boston. Process Technology. Edited by E. Di Nitto and A. Fuggetta..Pages 61
- 97. January 1998.
[11] N.Belkhatir, P.Y. Cunin, V. Lestideau and H. Sali.- An OO framework for configuration of deployable
large component based Software Products-OOPSLA 2001 Workshop on Engineering Complex O.O.
systems for Evolution. Tempa, Florida, USA. 14-18 October 2001
8/8