L'outil wsadmin permet de configurer et d'administrer les serveurs d'applications, le déploiement des applications et les opérations d'exécution des serveurs.
Pourquoi et quand exécuter cette tâche
L'outil wsadmin permet d'automatiser des tâches de configuration pour votre environnement via l'exécution de scripts. Cependant, les limitations suivantes s'appliquent à l'utilisation de l'outil wsadmin :
- L'outil wsadmin prend uniquement en charge les langages de script Jython et Jacl.
La version 6.1 de WebSphere
Application Server représentait le début du processus d'obsolescence pour la syntaxe Jacl qui est associée à l'outil wsadmin. La syntaxe Jacl pour l'outil wsadmin reste dans le produit et est prise en charge pour au moins deux éditions principales du produit. Ensuite, la prise en charge du langage Jacl est susceptible d'être retirée de l'outil wsadmin. La syntaxe Jython pour l'outil wsadmin est la direction stratégique de l'automatisation d'administration WebSphere Application Server. Le serveur d'applications contient des fonctions et des outils d'administration très avancés qui prennent en charge l'automatisation du produit et l'utilisation de la syntaxe Jython.
Fonction obsolète: Jacl est obsolète ;
Jython est le langage de script par défaut.
depfeat
Eviter les incidents: Toutes les classes de composant
WebSphere
Application Server ne sont
pas rassemblées dans le même fichier
.jar. Si vous envisagez d'utiliser
l'outil wsadmin pour l'exécution des scripts Jython, incluez la propriété système
jython.package.path à votre commande wsadmin afin de vous assurer que tous les
fichiers JAR requis ont le chemin de package jython au démarrage de wsadmin.
./wsadmin.sh -lang jython -javaoption
"-Djython.package.path=/usr/WebSphere70/AppServer/plugins/com.ibm.ws.wlm.jar"
Si vous souhaitez appeler les
fonctions WebSphere
Application Server à partir de différentes classes
WebSphere
Application Server rassemblées dans des fichiers .jar autres que runtime.jar et admin.jar, vous pouvez inclure plusieurs fichiers JAR dans le chemin
spécifié pour la propriété système jython.package.path en les séparant par un point-virgule (;).
./wsadmin.sh -lang jython -javaoption
"-Djython.package.path=/usr/WebSphere70/AppServer/plugins/com.ibm.ws.wlm.jar;com.ibm.ws.wccm.jar"
Si vous souhaitez appeler les fonctions WebSphere
Application Server dans un script jython à l'aide de ws_ant, vous pouvez créer un fichier texte .prop et inclure la ligne suivante à ce fichier :
jython.package.path=/usr/WebSphere70/AppServer/plugins/com.ibm.ws.wlm.jar
Incluez ensuite le fichier de propriétés au fichier XML de script ant. Par exemple :
<taskdef name="wsadmin" classname="com.ibm.websphere.ant.tasks.WsAdmin"/>
<target name="main">
<wsadmin conntype="NONE" lang="jython" failonerror="true" properties="/tmp/jython.prop"
script="/home/fsgapp/MSTWasBuild/project/scripts/socr/socr/jython/configure.py">
</wsadmin>
</target>
gotcha
- L'outil wsadmin permet de gérer les opérations d'installation, de configuration, de déploiement et d'exécution pour des serveurs d'applications, des gestionnaires de déploiement, des agents d'administration et des gestionnaires de travaux qui exécutent la même version ou une version supérieure du produit. L'outil wsadmin ne peut pas se connecter à un serveur d'applications, un gestionnaire de déploiement, un agent d'administration ou un gestionnaire de travaux qui exécute une version de produit antérieure à la version de l'outil wsadmin. Par exemple, un client wsadmin version 7.x ne peut pas se connecter à un serveur d'applications version 6.x. Cependant, un client wsadmin version 6.x peut se connecter à un serveur d'applications version 7.x. Cette limitation existe car de nouvelles fonctionnalités sont ajoutées à l'outil wsadmin dans chaque édition de produit. Vous ne pouvez pas utiliser de nouvelles fonctionnalités de commande sur des serveurs d'applications exécutant des versions antérieures du produit.
- L'outil wsadmin fonctionne au niveau du noeud du gestionnaire de déploiement dans un environnement avec des cellules mixtes. Afin de garantir la disponibilité de toutes les fonctionnalités de commande, n'exécutez pas wsadmin
au niveau du noeud du serveur d'applications.
Le programme de lancement wsadmin prend en charge plusieurs objets de scriptage, notamment les objets AdminConfig, AdminControl, AdminApp, AdminTask et Help. Les scripts utilisent ces objets pour la gestion des applications, la configuration, le contrôle des opérations et la communication avec les MBeans exécutés dans les processus du produit. Pour effectuer une tâche en utilisant le scriptage, vous devez au préalable démarrer le client de scriptage.
Avant de lancer l'outil wsadmin avec la sécurité activée, reportez-vous aux rubriques Remarques sur SSL (Secure Sockets Layer) à l'intention des administrateurs WebSphere Application Server et Définition de la sécurité SSL pour les clients et les serveurs.
Dans un environnement de gestion souple, vous pouvez connecter l'outil à un processus du serveur d'applications de base, du gestionnaire de déploiement, de l'agent d'administration ou du gestionnaire de travaux. Sans indication du port du serveur d'applications de base ou du nom du profil attribué au gestionnaire de travaux, l'outil wsadmin se connecte automatiquement à l'agent d'administration.
Eviter les incidents: La conception de la gestion des applications ne permet pas d'installer un module ou un fichier EAR de niveau spécification EE situé à un niveau supérieur au client. Le code client exécuté dans wsadmin lit le fichier EAR et utilise l'introspection du contenu pour générer les options de configuration de déploiement qui sont applicables à cette application. Le code côté client ne peut pas traiter un niveau de spécification supérieur à celui pris en charge par le client.
gotcha
Résultats
L'outil wsadmin retourne la sortie suivante lorsqu'une connexion est établie vers le processus du serveur :
Exemple de sortie
Jython :
Applications currently installed:
DefaultApplication
ivtApp
requête
WASX70311 : Pour obtenir de l'aide, entrez : "print Help.help()"
wsadmin>
Exemple de sortie Jacl :
Applications actuellement installées :
DefaultApplication
ivtApp
requête
WASX70311: Pour obtenir l'aide, entrez : "$Help help"
wsadmin>
![[z/OS]](../images/ngzos.gif)
Si le message suivant apparaît :
[ Impossible d'allouer un segment Java avec une taille initiale de 268435456 octets. ]
[ **Mémoire insuffisante, abandon** ]
[ *** panic: JVMST016: Impossible d'allouer de la mémoire au segment Java initial ]
CEE5207E Le signal SIGABRT a été reçu.
Le client de scriptage wsadmin n'a pas pu démarrer car la taille de région sur votre page de connexion n'est pas suffisante pour allouer la taille de segment minimale (-Xms) indiquée sur la JVM qui est créée lors du démarrage de wsadmin. La valeur par défaut pour l'option -Xms, comme indiquée dans l'instruction de fichier wsadmin.sh PERF_JVM_OPTIONS="-Xms256m -Xmx256m, est 256 Mo. Pour résoudre cet incident, déconnectez-vous de TSO, puis lorsque vous vous connectez de nouveau, essayez d'augmenter la valeur du paramètre
Size sur votre écran de connexion. Si vous ne pouvez pas augmenter cette valeur, vérifiez s'il existe des IEFUSI qui pourraient vous empêcher d'effectuer cette opération.
Si vous vous connectez par telnet à OMVS, la valeur utilisée pour déterminer la taille d'espace adresse reçue par votre connexion est indiquée dans le membre BPXPRMxx parmlib. BPXPRMxx contrôle l'environnement complet de z/OS UNIX. Par conséquent, la valeur définie pour le paramètre MAXASSIZE détermine la taille de l'espace adresse. Toutefois, si vous utilisez RACF, la taille d'adresse peut également être définie pour un utilisateur individuel dans le segment RACF OMVS concerné. Dans ce cas, la valeur fournie pour le paramètre ASSIZEMAX indique la limite de taille d'espace adresse, en octets, pour cet utilisateur. Par exemple, ASSIZEMAX=0268435456 indique que l'espace adresse alloué à cet utilisateur est 256 Mo.