[AIX][Linux][Windows][IBM i][z/OS]

Déploiement à chaud et rechargement dynamique

Vous pouvez apporter diverses modifications aux applications et à leurs modules sans devoir arrêter et redémarrer le serveur. Le fait d'apporter ce type de modifications s'appelle du déploiement à chaud et rechargement dynamique.

Avant de commencer

La remarque suivante s'applique aux références de fichier xmi dans cette rubrique :
Configurations prises en charge Configurations prises en charge: Pour les fichiers de liaison et d'extension IBM®, l'extension de nom de fichier .xmi ou .xml est différente selon que vous utilisiez un module ou une application antérieure à Java EE 5 ou un module ou une application ultérieure à Java™ EE 5. Un fichier de liaison ou d'extension IBM porte le nom ibm-*-ext.xmi ou ibm-*-bnd.xmi où * correspond au fichier d'extension ou de liaison, tel app, application, ejb-jar ou web. Les conditions suivantes s'appliquent :
  • Pour une application ou un module qui utilise une version Java EE antérieure à la version 5, l'extension de fichier doit être .xmi.
  • Pour une application ou un module qui utilise Java EE 5 ou version ultérieure, l'extension de fichier doit être .xml. Si des fichiers .xmi sont inclus dans l'application ou le module, le produit les ignore.

Toutefois, un module Java EE 5 ou version ultérieure peut exister dans une application qui inclut des fichiers antérieurs à Java EE 5 et utilise l'extension de nom de fichier .xmi.

Les fichiers ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et ibm-portlet-ext.xmi continuent d'utiliser les extensions de fichier .xmi.

sptcfg
[Solaris][HP-UX]Restriction : La fonction de déploiement à chaud et de rechargement dynamique n'est pas prise en charge lorsque le produit s'exécute sur ces systèmes d'exploitation. Les fichiers JAR (Java archive) du kit JDK (Java Development Kit) associé sont mappés à la mémoire. Si ces fichiers JAR sont mis à jour par la fonction de déploiement à chaud et de rechargement dynamique lorsqu'ils sont utilisés par la machine virtuelle Java (JVM), les fichiers deviennent incohérents, ce qui entraîne l'arrêt inattendu du serveur d'applications. Lorsque vous apportez des modifications à une application sur ces systèmes d'exploitation, n'utilisez pas la fonction de déploiement à chaud et de rechargement dynamique. Au lieu de cela, redémarrez l'application pour que les modifications soient prises en compte.

Cette rubrique suppose que vos fichiers d'application sont déployés sur un serveur et que vous souhaitez mettre à niveau les fichiers.

Voir Méthodes de mise à jour des fichiers d'application d'entreprise et déterminez si le déploiement à chaud est la mise à jour des fichiers d'application qui convient. D'autres méthodes sont plus simples et le déploiement à chaud ne s'adresse qu'aux utilisateurs confirmés.

N'utilisez pas le déploiement à chaud si vous prévoyez d'exporter votre application, de générer un plug-in à partir de sa configuration ou d'effectuer d'autres tâches de gestion d'application dans le futur. Les modifications par déploiement à chaud, apportées aux fichiers d'application, ne sont reconnues ni par la console d'administration ni par les fonctions de gestion des applications wsadmin. Ces fonctions ne reconnaissent que les fichiers d'application que les programmes d'administration, tels que la console ou wsadmin, présentent lors de l'installation d'application, la mise à jour ou autres fonctions de gestion. Les fonctions de gestion d'application ne reconnaissent pas les fichiers modifiés par déploiement à chaud.

Important : Ne recourez pas au déploiement à chaud pour mettre à jour des composants dans une cellule gérée du gestionnaire de déploiement de production. Le déploiement à chaud est bien adapté au développement et à la mise au point mais fait courir des risques inacceptables aux environnements de production. Une nouvelle synchronisation totale ou partielle peut écraser des composants déployés de façon dynamique. De plus, l'exécution de la commande restoreconfig peut écraser les modifications apportées aux fichiers de l'application développés. De plus, les composants déployés de façon dynamique ne migrent pas entre les versions de WebSphere Application Server. Pour ajouter de nouveaux composants ou modules à une application d'entreprise, réassemblez le fichier EAR de l'application pour prendre en compte ces nouvelles ressources, puis redéployez le fichier EAR.

Pourquoi et quand exécuter cette tâche

Le déploiement à chaud consiste à ajouter de nouveaux composants (tels que des fichiers WAR, des fichiers Jar d'EJB, des beans Java enterprise, des servlets et des fichiers JSP) à un serveur actif sans devoir arrêter et redémarrer le serveur d'applications.

Le rechargement dynamique est la possibilité de modifier un composant existant sans devoir redémarrer le serveur pour que ce changement prenne effet. Le rechargement dynamique implique :

  • Des modifications apportées à l'implémentation du composant d'une application, par exemple la modification de l'implémentation d'un servlet
  • Des changements de paramétrage de l'application, par exemple la modification du descripteur de déploiement pour un module Web

A l'opposé des modifications apportées à une application déployée décrite dans Mise à jour des fichiers d'applications d'entreprise, les modifications apportées à l'aide du déploiement à chaud ou du rechargement dynamique n'utilisent pas la console d'administration ou une commande de script wsadmin. Vous devez manipuler directement les fichiers d'application sur le serveur sur lequel l'application est déployée.

Si l'application que vous mettez à jour est déployée sur un serveur dont la règle de chargeur de classe d'application est associée à la valeur Un seul, il se peut que vous ne puissiez pas recharger dynamiquement votre application. Vous devrez, au minimum, redémarrez le serveur après la mise à jour de votre application.

Procédure

  1. Recherchez les fichiers d'application développés.

    Ces derniers se trouvent dans le répertoire que vous avez indiqué lors de l'installation de l'application ou dans le répertoire cible par défaut, racine_serveur_app/installedApps/nom_cellule. Le fichier EAR, ${APP_INSTALL_ROOT}/nom_cellule/nom_application.ear, désigne le répertoire cible. Le fichier variables.xml du noeud définit ${APP_INSTALL_ROOT}.

    Il est très important de connaître l'emplacement des fichiers d'application développés dans la mesure où, dans le cadre de l'installation des applications, un serveur d'applications WebSphere Application Server décompacte certains éléments du fichier EAR dans le système de fichiers de la machine sur laquelle l'application sera exécutée. Ces fichiers développés sont consultés par le serveur lors de l'exécution de l'application. Si vous ne trouvez pas les fichiers d'applications développés, recherchez l'attribut binariesURL dans le fichier deployment.xml de l'application. Cet attribut indique l'emplacement où le système recherche ces fichiers lors de l'exécution.

    En ce qui concerne le reste des informations relatives au déploiement à chaud et au rechargement dynamique, racine_application représente le répertoire racine des fichiers d'application étendus.

  2. Recherchez les fichiers de métadonnées de l'application. Ces derniers comprennent les descripteurs de déploiement (web.xml, application.xml, ejb-jar.xml et assimilés), les fichiers de liaison (ibm-web-bnd.xmi, ibm-app-bnd.xmi et les fichiers d'extensions (ibm-web-ext.xmi, ibm-app-ext.xmi et assimilés).

    Les fichiers XML de métadonnées d'une application peuvent être chargés à partir d'un ou deux emplacements. Les fichiers de métadonnées peuvent être chargés à partir du même emplacement que les fichiers binaires d'application racine_application/META-INF) ou à partir de l'arborescence de configuration WebSphere, ${CONFIG_ROOT}/cells/nom_cellule/applications /nom_EAR_application/deployments/nom_application/. La valeur de l'option useMetadataFromBinary spécifiée lors de l'installation de l'application détermine l'emplacement utilisé. Lorsque cette valeur est définie, les fichiers de métadonnées sont chargés à partir du même emplacement que les fichiers binaires d'application. Lorsqu'elle n'est pas définie, ces fichiers sont chargés à partir du dossier de déploiement de l'application dans l'arborescence de configuration.

    Important : Vous pouvez configurer useMetadataFromBinaries=true, modifier une copie extraite de votre application en utilisant le déploiement à chaud et faire en sorte que vos modifications soient prises en compte à l'exécution en suivant la procédure décrite dans cette rubrique. Cependant, les modifications que vous apportez aux fichiers de l'application lorsque vous utilisez le déploiement à chaud ne sont pas reconnues par les fonctions de gestion d'application de la console d'administration ou de wsadmin. Ces fonctions reconnaissent seulement les fichiers d'application d'origine, et non ceux qui sont modifiés par le déploiement à chaud. N'utilisez pas le déploiement à chaud si vous prévoyez d'exporter votre application, de générer un plug-in à partir de sa configuration ou d'effectuer d'autres tâches de gestion d'application dans le futur. Le déploiement à chaud est pratique pour modifier rapidement les fichiers d'une application, mais il ne prend pas en charge le cycle complet de gestion de l'application.

    En ce qui concerne le reste des informations, racine_métadonnées représente l'emplacement des fichiers de métadonnées de l'application ou du module indiqué.

  3. Obligatoire : Si vous exécutez WebSphere Application Server sur un groupe de postes utilisant WebSphere Application Server, Network Deployment et que vous modifiez une application sur un noeud particulier, désactivez la synchronisation automatique.
    1. Cliquez sur Administration du système > Agents de noeud > nom_agent_noeud > Service de synchronisation de fichiers dans l'arborescence de navigation de la console.
    2. A la page de service de synchronisation de fichier, décochez la case de synchronisation automatique et cliquez sur OK.

    Lorsque vous exécutez WebSphere Application Server sur un groupe de postes utilisant WebSphere Application Server, Network Deployment et que vous modifiez un fichier sur disque figurant dans le répertoire d'application étendu d'un noeud donné, vous risquez de perdre ces modifications lors de la prochaine synchronisation des noeuds. Dans l'environnement WebSphere Application Server, Network Deployment, la configuration stockée par le gestionnaire de déploiement est la copie principale et toute modification détectée par rapport à celle-ci dans la copie installée sur une machine donnée déclenche le téléchargement de la copie principale sur le noeud.

  4. Facultatif : Examinez les valeurs spécifiées pour les paramètres Recharger des classes lors de la mise à jour des fichiers d'application et Intervalle d'interrogation des fichiers mis à jour sur la page de paramètres du chargeur de classes de l'application.

    Si le rechargement des classes est activé et que l'intervalle d'interrogation est supérieur à zéro (0), les fichiers de l'application sont rechargés une fois celle-ci mise à jour. Pour les fichiers JavaServer Pages (JSP) dans un module Web, un conteneur Web recharge les fichiers JSP uniquement si l'extension IBM jspReloadingEnabled dans les attributs jspAttributes du fichier ibm-web-ext.xmi a la valeur true. Vous pouvez attribuer la valeur true au paramètre jspReloadingEnabled lorsque vous éditez les descripteurs de déploiement étendus de vos modules Web dans l'outil d'assemblage.

  5. Modifiez ou ajoutez comme il convient les composants ou les modules suivants :
  6. Pour que les modifications prennent effet, vous pouvez être amené à démarrer, arrêter ou relancer une application.

    La rubrique Démarrage ou arrêt d'une application d'entreprise fournit des informations sur l'utilisation de la console d'administration pour lancer, arrêter ou relancer une application.

    Les rubriques Démarrage d'applications à l'aide de l'outil de scriptage wsadmin et Arrêt d'applications à l'aide de l'outil de scriptage wsadmin fournissent des informations sur l'utilisation de l'outil de scriptage wsadmin.

  7. Si vous avez désactivé la synchronisation automatique à l'étape 3, activez-la de nouveau :
    1. Retournez à la page de service de synchronisation de fichier.
    2. Sélectionnez Synchronisation automatique.
    3. Cliquez sur OK.

Résultats

Les fichiers de l'application sont mis à jour sur le serveur.

Comme vous avez manipulé les fichiers de l'application directement sur le serveur, il est possible que vous ne puissiez plus travailler dessus en utilisant la console d'administration ou les commandes de scriptage de l'outil wsadmin. Par exemple, si vous essayez d'exporter une application modifiée manuellement via la commande Exporter sur une page de console d'applications d'entreprise, les modifications de l'application dans le répertoire installedApps ne sont pas exportées. Pour exporter ces modifications, vous devez copier et déplacer manuellement les fichiers des applications.


Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=trun_app_hotupgrade
Nom du fichier : trun_app_hotupgrade.html