Documentation déploiement Auteur: Ratefiarivony Herimamy Date: 23/10/08

Transcription

1 Objet: Documentation déploiement Auteur: Ratefiarivony Herimamy Date: 23/10/08 Présentation de l'architecture matérielle du SIENS/Cachan: Spider3 (Linux) via adaptor (web) Poste client (PC/Mac) Accés WO 4.51 (Citrix) via direct connect java-client Filemon (Linux) rouge indigo vert blanc orange (OSX srv (OSX srv WO 5.3) WO 5.3) (Win2K srv (Win2K srv WO 5.2.4) WO 5.2.4) (Win2k WO 4.51) jaune (Linux) (GEST, GEST2005, PRES, PRESTEST)

2 L'architecture que nous utilisons est composée de plusieurs types de serveurs utilisés selon les applications. Les serveurs principaux sont les machines "rouge" et "indigo". Ces machines sont de type "MacOS 10.4 Server" incluant un serveur "WebObjects 5.3". Ces serveurs hébergent les applications de "Production" et de "Test". Le serveur vert est de type "Windows 200 Server" incluant un serveur "WebObjects 5.2.4". Ce serveur héberge les services centraux utilisés par toutes les applications (SIX, Servaut, GEDFS) il nous permet également d'assurer la compatibilité avec les applications Le serveur vert est de type "Windows 200 Server" incluant un serveur "WebObjects 5.2.4". Ce serveur héberge les applications destinées au PRES. Le serveur jaune est le serveur de base de données. C'est un serveur de type Linux sur lequel tourne un serveur de base de données Oracle 9i. Ce serveur héberge les différentes instances de notre base: GEST (production), GEST2005 (test), PRES (production), PRESTEST (test). Le serveur orange est de type "Windows 200 Server" incluant un serveur "WebObjects 4.51". Celui-ci donne accès aux applications WO 4.51(Annuaire.app,Scolarix...) qui sont accessibles aux clients via un service Citrix. Le serveur filemon est une machine de type Linux, celui-ci permet aux postes clients d'accéder aux applications (WO 5) via un répertoire partagé sur le réseau. Celui-ci héberge également les binaires des applications WO 5 (pré travaillés) destinés à être déployés sur les autres serveurs. Le serveur Spider3 est une machine de type Linux incluant un serveur Apache. Il héberge le service "Adaptor" (module Apache) par lequel transitent les requêtes de certaines applications WO 5 (applications web essentiellement). Il héberge aussi les "ressources" de ces applications (ex:carambole) Ainsi les accés aux applications java client WO 5 se font via le répertoire partagé sur filemon, les accés aux applications web se font via un navigateur tandis que les accès aux applications WO 4.51 se font via une connexion Citrix. Dans cette architecture nous dupliquons les serveurs (rouge et indigo) afin d'obtenir une meilleure résistance aux pannes. En effet chacun de ces serveur doit pouvoir assurer les services de l'autre. C'est également pour cette raison que nous avons isolés les services centraux (Six, Servaut, Gedfs) qui doivent être lancés en premier. Ainsi il serait possible plus facilement de remplacer un serveur (hébergeant les applications WO 5) en utilisant cette architecture ainsi que la procédure de déploiement que nous avons élaborée.

3 Procédure de déploiement sur l'ens Cachan: Filemon (Linux) Makefile rouge indigo vert blanc (OSX srv (OSX srv WO 5.3) WO 5.3) (Win2K srv (Win2K srv WO 5.2.4) WO 5.2.4) Afin d'assurer le déploiement avec le moins de risque possible nous procédons par étapes déterminées.

4 Voici donc les principales étapes: - Il faut en premier lieu arrêter le service en instance de mise à jour depuis le monitor (disponible sur chaque serveur WO 5): Ex: NB: Assurez-vous que l'application concernée n'est plus utilisée (colonne "Active Sessions" à 0) Nb: Pensez à désactiver les options de "Scheduled/Auto-Recover" qui relancent les services en cas d'arrêt accidentel. - Téléchargez les archives depuis le forum déploiement, et déposez-les (via winscp, Cyberduck ou scp) sur le serveur filemon.ens-cachan.fr dans le répertoire: /home/unites/cri/cri/woapplications/apps(année) par exemple pour 2008: /home/unites/cri/cri/woapplications/apps Connectez-vous sur le serveur filemon via SSH (winssh, putty, Terminal): ssh administrateur@filemon.ens-cachan.fr puis cd /home/unites/cri/cri/woapplications/apps2008 Ce répertoire contient également un fichier "Makefile" qui permet de faire l'installation de l'application (binaire uniquement) sur le serveur choisi.

5 par exemple: make rouge-papayetest provoque l'installation de PapayeTEST.woa sur la machine "rouge". Le sytème Makefile permet de gérer des dépendances conditionnant une installation. Actuellement il vérifie la date de l'application à installer, ainsi que les fichiers de configuration (app.config, index.eomodeld, etc) habituellement modifiés. Il y a également des contraintes sur le nom des applications, il faut donc réutiliser les même que ceux déjà en place. Actuellement les installations sont organisées de la façon suivante: - SIENS (Prod/TEST): sur rouge et indigo - PRES (Prod/TEST): sur blanc vert n'est plus utilisé que pour les services de base: SIX, Servaut, GEDFS. Préparation du binaire pour une installation d'une application: Il faut commencer par renommer la version précédente (ex: Papaye.woa en Papaye.woa_2_2_1) Lors d'une installation (binaire), nous modifions les fichiers suivant: -.config (il peut s'appeler autrement: conf.config nom_de_l'appli.config, config.xml) Il se trouve dans le répertoire: par ex: Papaye.woa/Contents/Resources/ Généralement nous copions celui de la version précédente, aprés avoir vérifié qu'il n'y a pas de modifications majeures (diff) Exemple: diff Papaye.woa_2_2_1/Contents/Resources/Papaye.config Papaye.woa/Contents/ Resources/Papaye.config cp -pv Papaye.woa_2_2_1/Contents/Resources/Papaye.config Papaye.woa/ Contents/Papaye.woa.config ( Ce fichier détermine la version (PROD/TEST) utilisée grâce aux champs SAUT_ID_TRANSLATION ) - index.eomodeld (ex: Papaye.woa/Contents/Resources/Papaye.eomodeld/ index.eomodeld)

6 Dans ce fichier est décrit le dictionnaire de connection. Il faut supprimer TOUTES les entrées suivantes: URL="..." username="..." password="..." Ces entrées ne sont pas utilisées chez nous car nous utilisons ServAut qui permet de stocker en base de données les paramètres d'accès base de données. Un mot clé est utilisé par le fichier de config SAUT_ID (cf section précédente). Il permet de récupérer ensuite les identifiant de connexion. Ces derniers sont consultables dans le service en ligne: NB: Les identifiants sont parfois définis par un mot-clé dans un framework, pour ce cas pensez à vérifier que cette valeur est bien défini dans servaut (ex: CRIWebExt2.framework/Resources/UserLogin.eomodeld/index.eomodeld -> modelid=ulogin; ) - Classpath (ex: Papaye.woa/Contents/MacOS/MacOSClassPath.txt) Ce fichier définit les chemins pour accéder aux classes, framework. Il existe une version pour chaque architecture supportées (MacOS, UNIX, Windows). Afin de pouvoir manipuler les applications comme des modules indépendant (moins de risque de panne), nous "embarquons" les frameworks dans le répertoire "Resources" de chaque application: Ex: Papaye.woa/Contents/Resources/PapayeServerFramework.framework Ceci implique donc de recopier les frameworks supplémentaires (indiqués sur les forums en général) dans chaque répertoire "Resources" des applications au moment du déploiement. Il faut également modifier les chemins dans les fichiers "classpath". ces fichiers continnent des lignes avec des variables prédéfinis qu'il faudra remplacer... LOCALROOT/Library/WebObjects/Applications/Frameworks/Papaye... devient APPROOT/Resources/Library/WebObjects/Applications/Frameworks/Papaye... APPROOT désigne le répertoire de l'application (ici Papaye.woa) Cette méthode nous permet aussi d'utiliser indépendamment différentes versions de frameworks et de manipuler (changer de répertoire par ex) les applications plus facilement. Une fois ces changements effectués, il faut effectuer un changement de droit:

7 Ex: chmod -R a+rx Papaye.woa Pour finir il faut au besoin (PROD/TEST) changer le nom de l'application. Par convention (attendu par le Makefile!!!!) nous nommons les applications de test avec le suffixe TEST: Ex: mv -v Papaye.woa PapayeTEST.woa Nb: Pensez à vérifier les SAUT_ID et SAUT_ID_TRANSLATION. Une fois ces étapes effectuées il est possible de lancer l'installation. Pour simuler une installation vous pouvez taper: make -n rouge-papayetest Vous apercevrez ainsi les instructions qui seront utilisées. Pour lancer l'installation tapez: make rouge-papayetest Si votre application a déjà été installée la commande répondra: rouge-papayetest est à jour Pour forcer une installation il faut modifier la date du répertoire de l'application Ex: touch PapayeTEST.woa make rouge-papayetest Le fichier Makefile définit des "cibles" d'installation ainsi que des dépendances (conditions à vérifier) pour effectuer une action. Pour prendre en compte de nouvelles actions il faudra l'éditer. Reportez-vous au manuel de make/makefile pour de plus amples détails. Pour avoir la liste des "cibles" vous pouvez parcourir ce fichier. par ex ici la cible est: rouge-papayetest Convention de nommage: nom_de_machine-nom_appli(test si version test). Vérification de validité du binaire installé Vous avez la possibilité de vérifier la validité du binaire avant de le relancer depuis le monitor. Pour cela connectez-vous par ssh à la machine serveur: ssh administrateur@rouge.gadm.ens-cachan.fr

8 puis positionnez-vous dans le répertoire de l'application cd /Library/WebObjects/Applications/APPS2008/PapayeTEST.woa/ Lancez le service en ligne de commande:./papaye L'application affichera alors toutes les informations "côté serveur" (logs) notamment la base utilisée (gest, gest2005). Dans le cas où tout fonctionne normalement, l'application attendra aprés un message du type: Waiting for request... Il se peut qu'il y ait un autre message mais elle ne doît pas "rendre la main". Pour récupérer la main (le prompt): Ctrl-C Dans le cas d'une erreur le lancement se termine et un message apparaîtra. Souvent il s'agit: - mauvais chemin pour un framework = frameworkmanquant ( Class Not Found Exception) - mauvais dictionnaire de connexion base de données (Check connection dictionnary...) vérifiez votre fichier de config et les mots-clés SAUT_URL SAUT_ID SAUT_ID_TRANSLATION - Framework trop vieux. Verifiez qu'un nouveau framework est disponible sur le forum - un paramètre manquant dans le fichier de config. Vérifiez l'original - un bug (JavaNullPointer Exception). Si toutes ces étapes sont validées vous pouvez lancer le service depuis le monitor. Si le "feu passe et reste au vert" le service est à nouveau actif. Nb: Votre service peut "tomber" repasser au rouge lorsque vous avez oublié d'effectuer la commande: chmod -R a+rx votre_application.woa

9 Mise à jour côté base de données (script SQL). Une mise à jour d'une application s'accompagne souvent d'un script SQL. NB: Le service doit-être arrêter AVANT toute mise à jour base de données - Testez les scripts sur la base de TEST (gest2005) avant de le faire en PROD. - Vérifiez en premier lieu les "user" concernés. En général, les "user" sont indiqués dans le script (en commentaires) ou dans le nom du script. Suivant le client base de données (ici Oracle 9i) que vous utilisez vous serez peutêtre amené à modifier le script. - Tout d'abord mettre les "comit" en commentaire de façon à pouvoir annuler (rollback) en cas d'erreur. - Oracle 9 Client supporte mal les caractère & dans les chaînes, remplacez-les par "et" - Oracle 9 Client exige des requêtes ordonnées: SELECT,,. FROM,, WHERE AND AND Nb: les sauts de lignes provoquent aussi des erreurs. L'utilisation de Toad ou SQLdevelopper peut faciliter le passage des scripts. De manière générale si le script est trop long vous pouvez l'exécuter par morceau. - Une fois que les scripts sont passés, pensez à vérifier la validité de vos vues, packages, fonctions, procédures... En cas d'invalidité vous devrez les "compiler" voir corriger. Mise en place d'une base de test: Afin de pouvoir effectuer des tests "réalistes" il est recommandé de mettre en place une instance de test (gest2005 ici). Le mieux est de créer cette instance à partir d'une sauvegarde récente de la base de production. A long terme, nous prévoyons ici trois types d'instance: PROD (gest): la référence CLONE (gestdev?): une image la plus fidèle de la production (synchronisation régulière). TEST (gest2005): une image synchronisée moins souvent (applications en évaluation, développements...).