Un environnement de déploiement automatique pour les applications à base de composants

Transcription

1 ICSSEA 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 Grenoble Cedex 9 France Vincent.Lestideau@imag.fr 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.

2 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

3 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). Configurer Packager Transférer Installer Désinstaller Mettre à jour Adapter Activer Désactiver 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 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

4 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 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 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 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

5 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 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 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

6 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 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 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

7 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 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 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

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 , Dept. of Computer Science, University of Colorado, April [2] Web site InstallShield Developer [3] Web site Microsoft's Windows Installer [4] Web site Java Web Start [5] J. Mischkinsky - CORBA 3.0 New Components Chapters - CCMFTFDraft ptc/ OMG TC Document ptc/ October 29, 1999 [6] A. van Hoff, I. Hadi Partovi, T. Thai - The Open Software Description Format (OSD) Site Web : [7] Web site.net Framework [8] Rick Anderson - The End of DLL Hell- Microsoft Corporation January [9] Jacky Estublier and Anh-Tuyet LE. Design and development of Software Federation ICSSEA Paris, France. 4-6 December [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 January [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 October /8