Menu Close
Guide d'administration et de configuration
À utiliser dans Red Hat JBoss Enterprise Application Platform 6
Résumé
Chapitre 1. Introduction
1.1. Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6)
1.2. Les fonctionnalités de JBoss EAP 6
Tableau 1.1. Fonctionnalités 6.1.0
Fonctionnalité | Description |
---|---|
Certification Java | Implémentation certifiée des spécifications de JBoss Enterprise Application Platform 6 Full Profil et Web Profile. |
Domaine géré |
|
Console de gestion et Management CLI | Il y a de nouvelles interfaces pour gérer le domaine ou serveur autonome. Il n'est nul besoin de modifier les fichiers de configuration XML à la main. Le Management CLI offre également un mode lot, ce qui signifie que vous pourrez scripter et automatiser les tâches de gestion. |
La disposition du répertoire est simplifiée | Le répertoire modules/ contient maintenant les modules du serveur d'application, au lieu d'utiliser les répertoires communs et spécifiques au serveur lib/. Les répertoires domain/ et standalone/ contiennent les artefacts et les fichiers de configuration pour le domaine et pour les déploiements autonomes. |
Mécanisme de chargement de classes modulaire | Les modules sont chargés et déchargés à la demande pour plus de performance et de sécurité et des démarrages et redémarrages plus rapides. |
Gestion de Sources de données simplifiée | Les pilotes de base de données peuvent être déployés comme tout autre service. En plus, les sources de données sont créées et gérées directement dans la Console de gestion ou le Management CLI. |
Temps de démarrage et d'arrêt optimisés | JBoss EAP 6 utilise moins de ressources et est extrêmement efficace au niveau de l'utilisation des ressources. Surtout utile aux développeurs. |
1.3. JBoss EAP 6 Operating Modes
1.4. Les serveurs autonomes
1.5. Les Domaines gérés
domain.sh
ou domain.bat
est exécuté. Contrairement au contrôleur de domaine, les contrôleurs hôtes sont configurés pour lui déléguer des tâches de gestion de domaine. Le contrôleur hôte de chaque hôte interagit avec le contrôleur de domaine pour vérifier le cycle de vie des instances du serveur d'application exécutées sur son hôte et pour aider le contrôleur de domaine à les gérer. Chaque hôte peut contenir plusieurs groupes de serveurs. Un groupe de serveurs est un ensemble d'instances de serveurs sur lequel JBoss EAP 6 est installé et étant configurées comme une seule et même entité. Etant donné que le contrôleur de domaine gère la configuration et les applications déployées sur les groupes de serveurs, chaque serveur de groupe de serveurs partage la même configuration et les mêmes déploiements.

Figure 1.1. Représentation graphique d'un domaine géré
1.6. Contrôleur de domaine
- maintenir la politique centrale de gestion du domaine
- s'assurer que tous les contrôleurs soient mis au courant de leurs contenus actuels
- assister tous les contrôleurs pour que toutes les instances en cours de JBoss EAP 6 soient configurées suivant cette politique
domain/configuration/domain.xml
, dans le fichier d'installation JBoss EAP 6 non compressé, sur le système de fichiers de l'hôte du contrôleur de domaines.
domain/configuration/
du contrôleur hôte qui est destiné à être exécuté comme contrôleur de domaine. Ce fichier n'est pas obligatoire pour les installations sur les contrôleurs hôtes non destinés à être conçus comme contrôleur de domaine. Cependant, la présence d'un fichier domain.xml
sur un tel serveur ne nuit pas. Le fichier domain.xml contient la configuration des divers profils qui peuvent être configurés pour exécuter sur les instances de serveur d'un domaine. Une configuration de profil inclut la configuration détaillée des différents sous-systèmes qui composent un profil. La configuration de domaine inclut également la définition des groupes de sockets et la définition des groupes de serveurs.
1.7. Échecs de Contrôleurs de domaines
1.8. Contrôleur hôte
domain.sh
ou domain.bat script
est exécuté sur un hôte. La responsabilité primaire d'un contrôleur hôte est la gestion de serveur. Il délègue des tâches de gestion de domaine et est responsable de lancer et d'arrêter les processus de serveurs d'applications individuels qui s'exécutent sur son hôte. Il interagit avec le contrôleur de domaines pour gérer la communication entre les serveurs et le contrôleur de domaines. Plusieurs contrôleurs hôte d'un domaine peuvent interagir avec un contrôleur de domaine unique. Par conséquent, tous les contrôleurs hôtes et les instances de serveurs exécutant en mode de domaine unique peuvent avoir un contrôleur de domaine unique et doivent appartenir au même domaine.
domain/configuration/host.xml
situé dans le fichier d'installation de JBoss EAP 6 décompressé sur le système de fichiers de son hôte. Le fichier host.xml
contient les informations de configuration suivantes spécifiques à l'hôte particulier :
- Énumère les noms des instances de JBoss EAP 6 censées être exécutées à partir de l'installation.
- Une des configurations suivantes :
- la façon dont le contrôleur hôte contacte le contrôleur de domaines pour s'enregistrer et pour accéder à la configuration de domaine
- la façon de rechercher et contacter un contrôleur de domaines éloigné
- comment le contrôleur d'hôtes doit se persuader lui-même d'agir en tant que contrôleur de domaines
- Configuration d'éléments spécifiques à l'installation physique locale. Ainsi, les définitions d'interfaces nommées déclarées dans domain.xml peuvent être mappées vers une adresse IP spécifique à une machine dans host.xml. Les noms de chemins d'accès abstraits de domain.xml peuvent être mappés vers les chemins d'accès d'host.xml.
1.9. Les groupes de serveurs
<server-group name="main-server-group" profile="default"> <socket-binding-group ref="standard-sockets"/> <deployments> <deployment name="foo.war_v1" runtime-name="foo.war"/> <deployment name="bar.ear" runtime-name="bar.ear"/> </deployments> </server-group>
- nom : le nom du groupe de serveurs
- profil : le nom du profil du groupe de serveurs
- socket-binding-group : le nom du groupe de liaisons de sockets par défaut à utiliser pour les serveurs dans le groupe. Ce nom peut être remplacé sur la base d'un serveur à la fois dans host.xml. Si le nom socket-binding-group n'est pas fourni dans l'élément server-group, il doit être donné pour chaque serveur dans le fichier host.xml.
- deployments : le contenu de déploiement à déployer sur les serveurs du groupe
- system-properties : les propriétés système à définir sur les serveurs du groupe
- jvm : les paramètres de configuration par défaut de tous les serveurs du groupe. Le contrôleur hôte fait fusionner ces paramètres dans n'importe quelle configuration fournie par host.xml pour établir les paramètres à utiliser dans la JVM du serveur.
1.10. Profils JBoss EAP 6
Chapitre 2. Gestion de serveurs d'applications
2.1. Démarrer et stopper JBoss EAP 6
2.1.1. Démarrer JBoss EAP 6
2.1.2. Démarrez JBoss EAP 6 comme un serveur autonome
Cette rubrique couvre toutes les étapes à couvrir pour démarrer JBoss EAP 6 en tant que serveur autonome.
Procédure 2.1. Démarrer le Service de plate-forme comme serveur autonome.
Dans Red Hat Enterprise Linux.
Exécuter la commande suivante :EAP_HOME/bin/standalone.sh
Dans Microsoft Windows Server
Exécuter la commande suivante :EAP_HOME\bin\standalone.bat
Option : indiquer les paramètres supplémentaires.
Pour imprimer une liste de paramètres supplémentaires à passer aux scripts de démarrage, utiliser le paramètre-h
.
L'instance de serveur autonome JBoss EAP 6 démarre.
2.1.3. Démarrez JBoss EAP 6 comme domaine géré
Le contrôleur de domaines doit être démarré avant qu'un serveur esclave ne démarre dans des groupes de serveurs du domaine. Utiliser cette procédure sur le contrôleur de domaine pour commencer, puis, sur chaque contrôleur d'hôte associé et sur chaque hôte associé.
Procédure 2.2. Démarrer le Service de plate-forme comme serveur géré
Dans Red Hat Enterprise Linux.
Exécutez la commande :EAP_HOME/bin/domain.sh
Dans Microsoft Windows Server
Exécutez la commande :EAP_HOME\bin\domain.bat
En option : passez des paramètres supplémentaires au script de démarrage.
Pour obtenir une liste de paramètres que vous pourrez passer au script de démarrage, utilisez le paramètre-h
.
L'instance de domaine géré de JBoss EAP 6 démarre.
2.1.4. Démarrez JBoss EAP 6 avec une configuration différente
Prérequis
- Avant d'utiliser un fichier de configuration alternatif, préparez-le à l'aide de la configuration par défaut comme modèle. Pour un domaine géré, le fichier de configuration doit être placé dans
EAP_HOME/domain/configuration/
. Pour les serveurs autonomes, le fichier de configuration devra être mis dans le répertoireEAP_HOME/standalone/configuration/
.
Note
EAP_HOME/docs/examples/configs/
. Utiliser ces exemples pour activer des fonctionnalités supplémentaires, comme clustering ou l'API XTS de Transactions.
Procédure 2.3. Démarrage de l'instance par une configuration différente
Serveur autonome
Pour un domaine autonome, fournir le nom du fichier de configuration comme option du paramètre--server-config
. Le fichier de configuration doit se trouver dans le répertoireEAP_HOME/standalone/configuration/
, et vous devez indiquer le chemin d'accès du fichier de ce répertoire.Exemple 2.1. Utiliser un fichier de configuration alternatif pour un Serveur autonome Red Hat Enterprise Linux.
[user@host bin]$
./standalone.sh --server-config=
standalone-alternate.xml
Cet exemple utilise le fichier de configurationEAP_HOME/standalone/configuration/standalone-alternate.xml
.Exemple 2.2. Utiliser un fichier de configuration alternatif pour un Serveur autonome Microsoft Windows.
C:\EAP_HOME\bin>
standalone.bat --server-config=
standalone-alternate.xml
Cet exemple utilise le fichier de configurationEAP_HOME/standalone/configuration/standalone-alternate.xml
.Domaine géré
Pour un domaine géré, fournir le nom du fichier de configuration comme option du paramètre--domain-config
. Le fichier de configuration se trouve dans le répertoireEAP_HOME/domain/configuration/
, et vous devez indiquer le chemin d'accès de ce répertoire.Exemple 2.3. Utilisation d'un fichier de configuration alternatif pour un Domaine géré dans Red Hat Enterprise Linux
[user@host bin]$
./domain.sh --domain-config=
domain-alternate.xml
Cet exemple utilise le fichier de configurationEAP_HOME/domain/configuration/domain-alternate.xml
.Exemple 2.4. Utilisation d'un fichier de configuration alternatif pour un Domaine géré dans un serveur Microsoft Windows
C:\EAP_HOME\bin>
domain.bat --domain-config=
domain-alternate.xml
Cet exemple utilise le fichier de configurationEAP_HOME\domain\configuration\domain-alternate.xml
.
La plateforme JBoss Enterprise Application Platform est maintenant en cours d'exécution, avec votre fichier de configuration alternatif.
2.1.5. Stopper le serveur JBoss EAP 6
Note
Procédure 2.4. Stopper une instance autonome de JBoss EAP 6
Stopper une instance qui a été démarrée de façon interactive à partir d'une invite de commande.
Appuyez surCtrl-C
dans le terminal où JBoss EAP 6 exécute.Stopper une instance qui a démarré en tant que service de système d'exploitation.
Suivant votre système d'exploitation, utiliser une des procédures suivantes :Red Hat Enterprise Linux
Dans Red Hat Enterprise Linux, si vous avez écrit un script de service, utiliser sa fonctionstop
. Cela devra être inscrit dans le script. Ensuite, vous pourrez utiliserservice scriptname stop
, avec scriptname comme nom de script.Microsoft Windows Server
Dans Microsoft Windows, utiliser la commandenet service
, ou bien faites cesser le service à partir de l'applet Services qui se trouve dans le Panneau de contrôle.
Stopper une instance qui exécute en arrière-plan (Red Hat Enterprise Linux)
- Cherchez l'instance dans la liste de processus. Une option consiste à exécuter la commande
ps aux |grep "[j]ava -server"
. Cela renverra un résultat pour chaque instance de JBoss EAP 6 en cours d'exécution sur la machine locale. - Envoyer au processus le signal
TERM
, en exécutantkill process_ID
, avec process_ID comme numéro de deuxième champ de la commandeps aux
ci-dessus.
Chacune de ces solutions ferme la plate-forme JBoss EAP 6 nettement, ce qui fait qu'aucune donnée n'est perdue.
2.1.6. Référence aux variables et arguments à passer à l'exécution du serveur
standalone.xml
, domain.xml
et host.xml
. Cela peut comprendre le démarrage du serveur par un ensemble de liaisons de sockets différent ou une configuration secondaire. Vous pourrez accéder à une liste des paramètres disponibles en passant la variable d'assistance au démarrage.
Exemple 2.5.
-h
ou --help
en plus. Les résultats de cette variable d'assistance sont expliqués dans le tableau ci-dessous.
[localhost bin]$ standalone.sh -h
Tableau 2.1. Tableau des arguments et variables du temps d'exécution
Argument ou Variable | Description |
---|---|
--admin-only | Définir le type d'exécution du serveur à ADMIN_ONLY. Cela le fera ouvrir les interfaces administratives et il pourra ainsi accepter les ordres de gestion, mais il ne pourra pas démarrer d'autres services de runtime ou accepter les demandes de l'utilisateur final. |
-b=<value> | Définir la propriété système jboss.bind.address à la valeur donnée. |
-b <value> | Définir la propriété système jboss.bind.address à la valeur donnée. |
-b<interface>=<value> | Définir la propriété système jboss.bind.address.<interface> à la valeur donnée. |
-c=<config> | Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml . |
-c <config> | Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml . |
--debug [<port>] | Activer le mode de débogage par un argument en option qui indique le port. Ne fonctionne que si le script de lancement le supporte. |
-D<name>[=<value>] | Définir une propriété système. |
-h | Afficher le message d'assistance et sortir. |
--help | Afficher le message d'assistance et sortir. |
--read-only-server-config=<config> | Nom du fichier de configuration du serveur à utiliser. Cela diffère de '--server-config' et '-c' en ce que le fichier d'origine n'est jamais écrasé. |
-P=<url> | Télécharger les propriétés système de l'URL donné. |
-P <url> | Télécharger les propriétés système de l'URL donné. |
--properties=<url> | Télécharger les propriétés système de l'URL donné. |
-S<name>[=<value>] | Définir une propriété de sécurité. |
--server-config=<config> | Nommer le fichier de configuration du serveur à utiliser. La valeur par défaut est standalone.xml . |
-u=<value> | Définir la propriété système jboss.default.multicast.address à la valeur donnée. |
-u <value> | Définir la propriété système jboss.default.multicast.address à la valeur donnée. |
-V | Afficher la version du serveur d'application et sortir. |
-v | Afficher la version du serveur d'application et sortir. |
--version | Afficher la version du serveur d'application et sortir. |
2.2. Démarrer et arrêter les serveurs
2.2.1. Démarrer et arrêter les serveurs par le Management CLI
Vous pouvez démarrer une instance de serveur autonome par les scripts de ligne de commande, et le fermer par le Management CLI par la commande shutdown
. Si vous avez besoin de l'instance par la suite, exécuter le processus de démarrage à nouveau selon les instructions dans Section 2.1.2, « Démarrez JBoss EAP 6 comme un serveur autonome ».
Exemple 2.6. Démarrer et arrêter une instance de serveur autonome par le Management CLI
[standalone@localhost:9999 /] shutdown
Si vous exécutez un Domaine géré, la Console de gestion va vous permettre de démarrer ou de stopper sélectivement des serveurs spécifiques pour ce domaine. Cela inclut les groupes de serveurs dans tout le domaine, ainsi que les instances de serveur spécifiques sur un hôte.
Exemple 2.7. Stopper un Hôte de serveur dans un Domaine géré via un Management CLI
shutdown
est utilisée pour fermer un hôte de Domaine Géré déclaré. Cette exemple stoppe un hôte de serveur nommé master en déclarant le nom d'instance avant d'appeler l'opération de fermeture. Utiliser la touche tab pour aider à la complétion de chaînes et pour exposer des variables visibles comme les valeurs hôtes disponibles.
[domain@localhost:9999 /] /host=master:shutdown
Exemple 2.8. Stopper un Hôte de serveur dans un Domaine géré via un Management CLI
main-server-group
en déclarant le groupe avant les opérations start
et stop
. Utilisez la touche tab pour aider à la complétion de chaînes et pour exposer des variables visibles comme les valeurs de nom de groupe de serveur disponible.
[domain@localhost:9999 /] /server-group=main-server-group:start-servers
[domain@localhost:9999 /] /server-group=main-server-group:stop-servers
Exemple 2.9. Démarrer et stopper une instance de serveur dans un Domaine géré via un Management CLI
server-one
sur l'hôte master
en déclarant la configuration de l'hôte et du serveur avant d'invoquer les opérations start
et stop
. Utilisez la touche tab pour aider à la complétion de chaînes et pour exposer des variables visibles comme les valeurs de configuration de l'hôte et du serveur.
[domain@localhost:9999 /] /host=master/server-config=server-one:start
[domain@localhost:9999 /] /host=master/server-config=server-one:stop
2.2.2. Démarrer un serveur par la Console de gestion
Prérequis
Procédure 2.5. Démarrer le serveur
Naviguer dans Server Instances dans la Console de gestion
- Sélectionner l'onglet Runtime en haut de la console.
Sélectionner un serveur
À partir de la liste Server Instances, sélectionner le serveur que vous souhaitez démarrer. Les serveurs qui sont en cours d'exécution sont indiqués.En plaçant le curseur sur une instance de cette liste, vous verrez vos options en bleu sous Détails du serveur.Cliquer sur le bouton Start
Pour démarrer une instance, cliquer surStart Server
quand vous verrez ce texte. Une boîte de dialogue de confirmation va s'ouvrir. Cliquer sur le bouton Confirm pour démarrer le serveur.
Le serveur sélectionné démarre et exécute.
2.2.3. Stopper un serveur qui utilise une Console de gestion
Prérequis
Procédure 2.6. Stopper un serveur qui utilise une Console de gestion
Naviguez dans Hôtes, groupes et instances de serveur dans la Console de gestion
- Sélectionner l'onglet Runtime en haut de la console. Les instances de serveur disponibles seront affichées sur le tableau général de l'onglet Topologie.
Sélectionner un serveur
À partir de la liste Server Instances, sélectionner le serveur que vous souhaitez stopper. Les serveurs qui sont en cours d'exécution sont indiqués.Cliquer sur le texte Stop Server.
Cliquer sur le texte Stop Server qui apparaît quand vous bougez la souris sur l'entrée serveur. Une boîte de dialogue de confirmation apparaîtra.- Cliquer sur le bouton Confirm pour arrêter le serveur.
Le serveur sélectionné est stoppé.
2.3. Chemins d'accès aux systèmes de fichiers
2.3.1. Chemins d'accès aux systèmes de fichiers
domain.xml
, host.xml
et standalone.xml
incluent tous une section où les chemins d'accès peuvent être déclarés. D'autres sections de la configuration peuvent ensuite référencer ces chemins par leur nom logique, évitant la déclaration du chemin d'accès absolu pour chaque instance. Cela bénéficie aux efforts de configuration et d'administration car cela permet à des configurations hôtes spécifiques de résoudre des noms logiques universels.
jboss.server.log.dir
qui pointe vers le répertoire log
du serveur.
Exemple 2.10. Exemple de chemin d'accès relatif du répertoire de logging
<file relative-to="jboss.server.log.dir" path="server.log"/>
Tableau 2.2. Chemins d'accès standard
Valeur | Description |
---|---|
jboss.home.dir | Le répertoire root de la distribution JBoss EAP 6. |
user.home | Le répertoire d'accueil de l'utilisateur. |
user.dir | Le répertoire de travail actuel de l'utilisateur |
java.home | Le répertoire d'installation de Java |
jboss.server.base.dir | Le répertoire root d'une instance de serveur individuel. |
jboss.server.data.dir | Le répertoire que le serveur va utiliser pour le stockage de fichier de données persistantes. |
jboss.server.config.dir | Le répertoire qui contient la configuration du serveur. |
jboss.server.log.dir | Le répertoire que le serveur va utiliser pour le stockage de fichier de journalisation. |
jboss.server.temp.dir | Le répertoire que le serveur va utiliser pour le stockage de fichier temporaires. |
jboss.controller.temp.dir | Le répertoire que le contrôleur hôte va utiliser pour le stockage de fichier temporaires. |
path
dans leur fichier de configuration. L'exemple suivant indique la nouvelle déclaration de chemin relatif qui se rapporte au répertoire root de l'instance du serveur individuel.
Exemple 2.11. Format d'un chemin relatif
<path name="examplename" path="example/path" relative-to="jboss.server.data.dir"/>
Tableau 2.3. Attributs de chemin d'accès
Attribut | Description |
---|---|
name | Le nom du chemin d'accès. |
path | Le chemin d'accès du système de fichier. Considéré comme chemin absolu, à moins que l'attribut relative-to ne soit spécifié, dans lequel cas, la valeur sera traitée comme étant relative à ce chemin. |
relative-to | Un attribut optionnel qui indique le nom d'un autre nom ancienement nommé, ou bien qui correspond à un chemin standard défini par le système. |
path
(chemin) d'un fichier de configuration domain.xml
ne requiert que le nom de l'attribut. Il n'a pas besoin d'inclure des informations sur le chemin du système de fichiers, comme le montre l'exemple suivant.
Exemple 2.12. Exemple de chemin de domaine
<path name="example"/>
exemple
auquel les autres parties de la configuration du domain.xml
peuvent faire référence. L'emplacement du système de fichiers courant déclaré par l'exemple
est spécifique aux fichiers de configuration host.xml
respectifs des instances de l'hôte qui se joignent aux groupes de domaine. Si cette approche est utilisée, il doit y avoir un élément de chemin dans l'host.xml
de chaque machine, qui indique le chemin du système de fichier.
Exemple 2.13. Exemple de chemin d'hôte
<path name="example" path="path/to/example" />
path
d'un fichier standalone.xml
doit inclure la spécification du chemin d'accès du système de fichier.
2.4. Historique du fichier de configuration
2.4.1. Fichiers de configuration de JBoss EAP 6
Tableau 2.4. Emplacements de Fichiers de configuration
Mode du serveur | Emplacement | But |
---|---|---|
domain.xml | EAP_HOME/domain/configuration/domain.xml | Il s'agit du fichier de configuration principal d'un domaine géré. Seul le master du domaine lit ce fichier. Il peut être supprimé pour les autres membres du domaine. |
host.xml | EAP_HOME/domain/configuration/host.xml | Ce fichier contient les détails de configuration spécifiques à un hôte physique dans un domaine géré, tels que les interfaces réseau, les liaisons de sockets, le nom de l'hôte et d'autres détails spécifiques à l'hôte. Le fichier host.xml contient toutes les fonctionnalités de hôte-master.xml et hôte-slave.xml , qui sont décrits ci-dessous. Ce fichier n'est pas présent pour les serveurs autonomes. |
host-master.xml | EAP_HOME/domain/configuration/host-master.xml | Ce fichier inclut tous les détails de configuration nécessaires pour exécuter un serveur en tant que serveur maître de domaine géré. Ce fichier n'est pas présent dans les serveurs autonomes. |
host-slave.xml | EAP_HOME/domain/configuration/host-slave.xml | Ce fichier inclut tous les détails de configuration nécessaires pour exécuter un serveur en tant que serveur esclave de domaine géré. Ce fichier n'est pas présent dans les serveurs autonomes. |
standalone.xml | EAP_HOME/standalone/configuration/standalone.xml | C'est le fichier de configuration par défaut pour un serveur autonome. Il contient toutes les informations sur le serveur autonome, y compris les sous-systèmes, réseautage, déploiements, les liaisons de sockets et autres détails configurables. Cette configuration est utilisée automatiquement lorsque vous démarrez votre serveur autonome. |
standalone-full.xml | EAP_HOME/standalone/configuration/standalone-full.xml | Il s'agit d'un exemple de configuration pour un serveur autonome. Il prend en charge chaque sous-système possible à l'exception de ceux destinés à la haute disponibilité. Pour l'utiliser, arrêtez votre serveur et redémarrez à l'aide de la commande suivante : EAP_HOME/bin/standalone.sh -c standalone-full.xml |
standalone-ha.xml | EAP_HOME/standalone/configuration/standalone-ha.xml | Cet exemple de fichier de configuration active tous les sous-systèmes par défaut et ajoute les mod_cluster et les sous-systèmes JGroups pour un serveur autonome, afin qu'il puisse participer à un cluster de haute disponibilité ou d'équilibrage de la charge. Ce fichier n'est pas applicable à un domaine géré. Pour utiliser cette configuration, arrêtez votre serveur et redémarrez le à l'aide de la commande suivante : EAP_HOME/bin/standalone.sh -c standalone-ha.xml |
standalone-full-ha.xml | EAP_HOME/standalone/configuration/standalone-full-ha.xml | Il s'agit d'un exemple de configuration pour un serveur autonome. Il prend en charge chaque sous-système possible incluant ceux destinés à la haute disponibilité. Pour l'utiliser, arrêtez votre serveur et redémarrez à l'aide de la commande suivante : EAP_HOME/bin/standalone.sh -c standalone-full-ha.xml |
2.4.2. Historique du fichier de configuration
standalone.xml
, ainsi que les fichiers domain.xml
et host.xml
. Alors que ces fichiers sont modifiables directement, la méthode recommandée consiste à configurer le modèle de serveur d'applications par les opérations de gestion disponibles, y compris Management CLI et la Console de gestion.
2.4.3. Démarrer le serveur par une ancienne configuration
standalone.xml
. Le même concept s'applique à un domaine géré par domain.xml
et host.xml
respectivement.
- Identifier la version de sauvegarde que vous souhaitez démarrer. Cet exemple va rappeler l'instance de modèle de serveur qui précédait la première modification qui a lieu suite à un démarrage réussi.
EAP_HOME/configuration/standalone_xml_history/current/standalone.v1.xml
- Démarrer le serveur par cette configuration du modèle de sauvegarde en passant le nom de fichier relatif sous
jboss.server.config.dir
.EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml
Le serveur d'applications démarre par la configuration sélectionnée.
2.4.4. Sauvegarder un snapshot de configuration par le Management CLI
Les snapshots représentent une copie d'un moment précis d'une configuration de serveur en cours. Ces copies peuvent être sauvegardées et chargées par l'administrateur.
standalone.xml
, mais le même processus s'applique aux fichiers de configuration domain.xml
et host.xml
.
Procédure 2.7. Télécharger un Snapshot de configuration et Sauvegardez-le
Sauvegarde d'un snapshot
Exécuter l'opérationtake-snapshot
pour acquérir une copie de la configuration du serveur.[standalone@localhost:9999 /] :take-snapshot { "outcome" => "success", "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
Un snapshot de la configuration du serveur en cours a été sauvegardé.
2.4.5. Charger un Snapshot de Configuration avec le Management CLI.
standalone.xml
, mais le même processus s'applique aux fichiers domain.xml
et host.xml
.
Procédure 2.8. Télécharger un snapshot de configuration
- Identifier le snapshot à télécharger. Cet exemple va rappeler le fichier suivant du répertoire de snapshots. Le chemin par défaut des fichiers de snapshot est le suivant.
EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml
Les snapshots sont exprimés par leurs chemins relatifs, selon lesquels l'exemple ci-dessus peut être écrit ainsi.jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml
- Démarrer le serveur par le snapshot de configuration sélectionné en passant le nom du fichier.
EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml
Le serveur démarre à nouveau avec la configuration sélectionnée dans le snapshot téléchargé.
2.4.6. Supprimer un snapshot de configuration par le Management CLI
standalone.xml
, mais le même processus s'applique aux fichiers domain.xml
et host.xml
.
Procédure 2.9. Supprimer un snapshot particulier
- Identifier le snapshot à effacer. Cet exemple va effacer le fichier suivant du répertoire de snapshots.
EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-165714239standalone.xml
- Exécuter la commande
:delete-snapshot
pour supprimer un snapshot particulier, en spécifiant le nom du snapshot comme dans l'exemple ci-dessous.[standalone@localhost:9999 /]
:delete-snapshot(name="20110630-165714239standalone.xml")
{"outcome" => "success"}
Le snapshot a été supprimé.
Procédure 2.10. Supprimer tous les snapshots
- Exécuter la commande
:delete-snapshot(name="all")
pour supprimer tous les snapshots comme dans l'exemple ci-dessous.[standalone@localhost:9999 /]
:delete-snapshot(name="all")
{"outcome" => "success"}
Tous les snapshots ont été supprimés.
2.4.7. Lister tous les snapshots de configuration par le Management CLI
standalone.xml
, mais le même processus s'applique aux fichiers domain.xml
et host.xml
.
Procédure 2.11. Lister tous les snapshots de configuration
Lister tous les snapshots
Lister tous les snapshots sauvegardés en exécutant la commande:list-snapshots
.[standalone@localhost:9999 /]
:list-snapshots
{ "outcome" => "success", "result" => { "directory" => "/home/hostname/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot", "names" => [ "20110818-133719699standalone.xml", "20110809-141225039standalone.xml", "20110802-152010683standalone.xml", "20110808-161118457standalone.xml", "20110912-151949212standalone.xml", "20110804-162951670standalone.xml" ] } }
Les snapshots sont listés.
Chapitre 3. Interfaces de gestion
3.1. Gestion du serveur d'applications
3.2. Les API (de l'anglais Application Programming Interfaces) de Gestion
JBoss EAP 6 offre trois approches différentes pour configurer et gérer des serveurs, étant à la fois une interface web, un client de ligne de commande et un ensemble de fichiers de configuration XML. Tandis que les méthodes recommandées pour la modification du fichier de configuration incluent la Console de Gestion et Management CLI, les modifications de configuration de la part des trois sont toujours synchronisées à travers les différentes vues et sont conservées dans les fichiers XML. Notez que les modifications apportées aux fichiers de configuration XML pendant l'exécution d'une instance de serveur seront remplacées par le modèle de serveur.
La Console de gestion est un exemple d'interface web construite avec Google Web Toolkit (GWT). La Console de gestion communique avec le serveur à l'aide de l'interface de gestion HTTP. Le point de terminaison HTTP API est le point d'entrée pour les clients de gestion basés sur le protocole HTTP, pour s'intégrer à la couche de gestion. Il utilise un protocole JSON encodé et un API de style RPC de-typed, pour décrire et exécuter des opérations de gestion en fonction d'un domaine géré ou d'un serveur autonome. L'API HTTP est utilisé par la console web, mais offre aussi des possibilités d'intégration pour un large éventail d'autres clients.
Exemple 3.1. Exemple de fichier de configuration HTTP API
<management-interfaces> [...] <http-interface security-realm="ManagementRealm"> <socket-binding http="management-http"/> </http-interface> </management-interfaces>
Tableau 3.1. Les URL d'accès à la Console de gestion
URL | Description |
---|---|
http://localhost:9990/console | Le Console de gestion accédée par l'hôte local, qui contrôle la configuration du Domaine géré. |
http://hostname:9990/console | La Console de gestion accédée à distance, qui nomme l'hôte et qui contrôle la configuration du Domaine géré. |
http://hostname:9990/management | Le HTTP Management API exécute sur le même port que la Console de gestion, affiche les mêmes valeurs et attributs bruts exposés à l'API. |
Le Management CLI est un exemple d'outil d'API Natif. Cet outil de gestion est disponible à une instance de Serveur autonome ou à un Domaine, permettant ainsi à un utilisateur de se connecter à une instance du Serveur autonome ou au Contrôleur du domaine, et d'exécuter des opérations de gestion rendues disponibles par le modèle de gestion de-types.
Exemple 3.2. Exemple de fichier de configuration d'API natif
<management-interfaces> <native-interface security-realm="ManagementRealm"> <socket-binding native="management-native"/> </native-interface> [...] </management-interfaces>
3.3. Console de gestion et Management CLI
3.4. La console de gestion
3.4.1. Console de gestion
3.4.2. Se conncecter à la console de gestion
Prérequis
- JBoss EAP doit être en cours d'exécution.
Procédure 3.1. Se conncecter à la console de gestion
Naviguer vers la page de démarrage de la console de gestion
Naviguer vers la console de gestion. L'emplacement par défaut est http://localhost:9990/console/, où le port 9990 est prédéfini comme liaison de socket de console de gestion.Se conncecter à la console de gestion
Saisir le nom d'utilisateur et le mot de passe du compte que vous avez déjà créé pour vous connecter à l'écran de connexion de la console de gestion.Figure 3.1. Écran de connexion de la console de gestion
Résultat
- Domaine géré
- Serveur autonome
3.4.3. Changer la Langue de la Console de management
Langues prises en charge
- Allemand (de)
- Chinois simplifié (zn-Hans)
- Portugais brézilien (pt-BR)
- Français (fr)
- Espagnol (es)
- Japonais (ja)
Procédure 3.2. Changer la Langue de la Console de management basée-web
Connectez-vous à la Console de management.
Connectez-vous à la Console de management basée web.Ouvrir le dialogue de configuration.
Dans le coin gauche de l'écran, il y a une étiquette Settings de configuration. Cliquer sur cette étiquette pour ouvrir les paramètres de configuration de la Console de management.Sélectionner la langue désirée.
Sélectionner la langue désirée à partir de la case Locale. Puis sélectionner Save. Une autre case explicative vous demande de charger à nouveau l'application. Cliquer sur Confirm. Réactualiser votre navigateur pour pouvoir utiliser les nouveaux paramètres régionaux (Locale).
3.4.4. Configurer un Serveur par la Console de gestion
Prérequis
Procédure 3.3. Configurer le Serveur
Naviguer dans le panneau Server Configurations qui se trouve dans la Console de gestion
- Sélectionner l'onglet Hosts en haut de la console. Les instances de serveur disponibles s'afficheront sur un tableau.
Modifier la configuration du serveur
- Sélectionner l'instance de serveur à partir du tableau Available Server Configurations.
- Sélectionner le bouton Edit qui se trouve en dessous de la liste de serveurs.
- Procédez avec les changements des attributs de configuration.
- Sélectionnez le bouton Save qui se trouve en dessous de la liste du serveurs.
La configuration du serveur a changé, et prendra effet la prochaine fois que le serveur démarre.
3.4.5. Ajouter un déploiement dans une Console de gestion
Procédure 3.4. Ajouter et vérifier un déploiement
Naviguez dans le panneau Manage Deployments de la Console de gestion.
- Sélectionner l'onglet Runtime en haut de la console.
- Pour un serveur autonome, il vous faudra étendre l'élément de menu Server qui se trouve à gauche de la console et sélectionner Manage Deployments. Pour un domaine géré, étendre l'élément de menu Domain qui se trouve à gauche de la console, et sélectionner Manage Deployments.
Le panneau Manage Deployments apparaît.Ajouter le contenu du déploiement.
Sélectionner le bouton Add dans l'onglet Content Repository. Une boîte de dialogue Create Deployment apparaîtra.Choisissez un fichier à déployer
Dans la boîte de dialogue, sélectionner le bouton Browse. Cherchez le fichier que vous souhaitez déployer, et sélectionnez-le en vue de son chargement. Sélectionner le bouton Next pour continuer une fois que le fichier a été sélectionné.Vérifier les noms de déploiement
Vérifier le nom du déploiement et le nom du runtime qui apparaît dans la boîte de dialogue Create Deployments. Sélectionner le bouton Save pour charger le fichier une fois que les noms auront été vérifiés.
Le contenu sélectionné est téléchargé dans le serveur et est maintenant prêt à être déployé.
3.4.6. Créer un nouveau serveur dans la Console de management
Prérequis
Procédure 3.5. Créer une nouvelle configuration de serveur
Naviguez sur la page Server Configuration qui se trouve dans la Console de management
Sélectionnez l'onglet Server qui se trouve en haut et à droite de la console.Créer une nouvelle configuration
- Sélectionner le bouton Add qui se trouve en haut du panneau Server Configuration.
- Modifier les paramètres de base du serveur dans la boîte de dialogue Create Server Configuration.
- Cliquez sur le bouton Save pour enregistrer la nouvelle configuration de votre serveur.
Le nouveau serveur créé est listé dans Server Configurations.
3.4.7. Modifier les Niveaux de journalisation par défaut en utilisant la Console de gestion
Procédure 3.6. Modifier les niveaux de journalisation
Naviguez dans le panneau Logging de la Console de gestion.
- Si vous travaillez dans un domaine géré, sélectionner l'onglet Profiles en haut de la console, puis, sélectionnez le profil qui convient dans la liste déroulante à gauche de la console.
- Pour une domaine géré ou un serveur autonome, sélectionner Core → Logging à partir du menu qui se trouve à gauche de la console et cliquer sur Logging.
- Cliquer sur l'onglet Log Categories en haut de la console.
Modifier les informations du créateur du journal
Modifer les informations des entrées du tableau Log Categories.- Sélectionner une entrée dans le tableau Log Categories, puis sélectionner le bouton Edit dans la section Details ci-dessous.
- Définir le niveau de journalisation de la catégorie dans la zone déroulante Log Level. Sélectionner le bouton Save quand c'est fait.
Les niveaux de journalisation des catégories qui conviennent sont maintenant mis à jour.
3.4.8. Créer un nouveau groupe de service dans la Console de gestion
Procédure 3.7. Configurer et Ajouter un groupe de serveurs
Rendez-vous dans la vue Server Groups
Sélectionner l'onglet Hosts en haut et à droite.- Sélectionner l'onglet Server Groups dans le menu Server dans la colonne de gauche.
Ajouter un groupe de serveurs
Cliquer sur le bouton Add pour ajouter un nouveau groupe de serveurs.Configurer le groupe de serveurs
- Saisir un nom pour le groupe de serveurs
- Sélectionner le profil dans lequel vous souhaitez ajouter le groupe de serveurs.
- Sélectionner la liaison de socket dans laquelle vous souhaitez ajouter le groupe de serveurs.
- Sélectionner le bouton Save pour sauvegarder le nouveau groupe.
Le nouveau groupe de serveurs est visible dans la Console de gestion.
3.5. L'interface CLI
3.5.1. Gestion par interface en ligne de commande (CLI)
3.5.2. Lancement du Management CLI
Conditions préalables :
Procédure 3.8. Lancement du CLI dans Linux ou Windows
Lancement du CLI dans Linux
Exécutez le fichierEAP_HOME/bin/jboss-cli.sh
en saisissant ce qui suit dans la ligne de commande :$ EAP_HOME/bin/jboss-cli.sh
Lancement du CLI dans Windows
Exécutez le fichierEAP_HOME/bin/jboss-cli.bat
en cliquant deux fois, ou en saisissant ce qui suit dans la ligne de commande :C:\>EAP_HOME\bin\jboss-cli.bat
3.5.3. Quitter le Management CLI
Procédure 3.9. Quitter le Management CLI
Exécutez la commande
quit
Avec le Management CLI, saisir la commandequit
:[domain@localhost:9999 /]
quit
Closed connection to localhost:9999
3.5.4. Se connecter à une instance de serveur géré par le Management CLI
Procédure 3.10. Se connecter à une instance de serveur gérée
Exécutez la commande
connect
Avec Management CLI, saisir la commandeconnect
:[disconnected /]
connect
Connected to domain controller at localhost:9999- Sinon, pour vous connecter à un serveur géré quand on démarre le Management CLI sur le système Linux, utiliser le paramètre
--connect
:$
EAP_HOME/bin/jboss-cli.sh --connect
- Le paramètre
--connect
peut être utilisé pour indiquer l'hôte et le port du serveur. Pour connecter l'adresse192.168.0.1
à la valeur du port9999
ce qui suit s'applique :$
EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999
3.5.5. Comment obtenir de l'aide avec le Management CLI
L'interface de gestion CLI dispose d'une boîte de dialogue d'assistance avec des options générales et des options sensibles au contexte. Les commandes d'assistance dépendant du contexte de l'opération nécessitent une connexion à un contrôleur de domaine ou à un serveur autonome. Ces commandes ne seront pas affichées dans la liste, sauf si la connexion a été établie.
Procédure 3.11. Aide au niveau options Générales et options Sensibles au contexte
Exécuter la commande
help
Avec le Management CLI, saisir la commandehelp
:[standalone@localhost:9999 /]
help
Obtenez de l'aide au niveau sensibilité du contexte
Avec le Management CLI, saisir la commande étenduehelp -commands
:[standalone@localhost:9999 /]
help --commands
- Pour plus d'informations sur une commande particulière, exécuter la commande
help
avec comme argument'--help'
.[standalone@localhost:9999 /]
deploy --help
L'information d'assistance du CLI s'affichera.
3.5.6. Utiliser le Management CLI en Mode par lot
Le traitement par lot permet à un certain nombre de requêtes d'être groupées par séquences et exécutées ensemble par unité. Si une des demandes opérationnelles d'une séquence échoue, tout le groupe d'opérations sera annulé.
Prérequis
Procédure 3.12. Commandes et opérations en mode par lot
Saisir un mode par lot
Saisir le mode par lot par la commandebatch
.[standalone@localhost:9999 /] batch [standalone@localhost:9999 / #]
Le mode par lot est indiqué par le signe (#
) dans l'invite.Ajouter les demandes opérationnelles au lot
Une fois que vous serez en mode par lot, saisir les demandes opérationnelles comme d'habitude. Les demandes opérationnelles sont ajoutées au lot dans l'ordre de saisie.Voir Section 3.5.8, « Utiliser les opérations et les commandes du Management CLI » pour obtenir des informations sur la façon de formater les demandes opérationnelles.Exécuter le lot
Une fois que toute la séquence de demandes opérationnelles est saisie, exécuter le lot avec la commanderun-batch
.[standalone@localhost:9999 / #] run-batch The batch executed successfully.
Voir Section 3.5.7, « Commandes CLI Mode Lot » pour obtenir une liste complète des commandes disponibles pour pouvoir travailler avec des lots.Les commandes de lots sont stockées dans des fichiers externes
Les commandes fréquemment exécutées peuvent être stockées dans un fichier texte externe et être chargées en passant le chemin d'accès complet au fichier comme argument à la commandebatch
ou exécutées directement en étant un argument à la commanderun-batch
.Vous pouvez créer un fichier de commande lot avec l'éditeur de texte. Chaque commande doit figurer sur une ligne par elle-même et la CLI doit être en mesure d'y accéder.La commande suivante chargera un fichiermyscript.txt
en mode lot. Toutes les commandes de ce fichier seront alors être prêtes à la modification ou à la suppression. De nouvelles commandes pourront être ajoutées. Les modifications effectuées au cours de cette session de lot ne persistera pas dans le fichiermyscript.txt
.[standalone@localhost:9999 /] batch --file=myscript.txt
Ce qui suit exécutera instantanément les commandes lot stockées dans le fichiermyscript.txt
[standalone@localhost:9999 /] run-batch --file=myscript.txt
La séquence de demandes opérationnelles saisies est effectuée sous forme de lot.
3.5.7. Commandes CLI Mode Lot
Tableau 3.2. Commandes CLI Mode Lot
Command Name | Description |
---|---|
list-batch | Liste des commandes et des opérations du lot en cours. |
edit-batch-line line-number edited-command | Modifier une ligne du lot en cours en donnant un numéro de ligne à modifier et la commande modidiée. Exemple : edit-batch-line 2 data-source disable --name=ExampleDS . |
move-batch-line fromline toline | Réorganiser les lignes dans le lot en spécifiant le numéro de ligne à déplacer comme premier argument et sa nouvelle position comme deuxième argument. Exemple : move-batch-line 3 1 . |
remove-batch-line linenumber | Supprimer la commande de lot à la ligne indiquée. Exemple : remove-batch-line 3 . |
holdback-batch [batchname] |
Vous pouvez reporter à plus tard ou stocker un lot en cours à l'aide de cette commande. Utilisez cette option si vous voulez soudainement exécuter quelque chose dans la CLI en dehors du lot. Pour revenir à ce lot en attente, tapez simplement
batch à nouveau à la ligne de commande CLI.
Si vous fournissez un nom de lot en utilisant la commande
holdback-batch , le lot sera stocké sous ce nom. Pour retourner au lot nommé, utilisez la commande batch batchname . L'appel de la commande batch sans un nom de lot va commencer un nouveau lot (sans nom). Il peut y avoir qu'un seul lot suspendu sans nom.
Pour voir une liste de tous les lots suspendus, utiliser la commande
batch -l .
|
discard-batch | Rejète le lot actif en cours. |
3.5.8. Utiliser les opérations et les commandes du Management CLI
Prérequis
Procédure 3.13. Créer, configurer et exécuter les requêtes
Construire la demande opérationnelle
Les demandes opérationnelles facilitent une interaction de bas niveau dans le modèle de gestion. Il s'agit d'une façon contrôlée de modifier les configurations du serveur. Une demande opérationnelle se présente en trois parties :- une adresse, avec une barre oblique devant (
/
). - un nom d'opération, avec deux points (
:
). - un groupe optionnel de paramètres, entre parenthèses (
()
).
Déterminer l'adresse
La configuration est présentée sous forme de ressources auxquelles s'adresser et de façon hiérarchique. Chaque noeud de ressources procure un groupe différent d'opérations. Une adresse utilise la syntaxe suivante :/node-type=node-name
- node-type correspond au type de noeud de ressource. Cela correspond à un nom d'élément dans la configuration XML.
- node-name correspond au nom du nœud. Cela correspond à l'attribut
nom
de l'élément dans la configuration XML. - Séparer chaque niveau de l'arborescence de ressources par une barre oblique (
/
).
Voir les fichiers de configuration XML pour déterminer l'adresse qui convient. Le fichierEAP_HOME/standalone/configuration/standalone.xml
contient la configuration d'un serveur autonome et les fichiersEAP_HOME/domain/configuration/domain.xml
etEAP_HOME/domain/configuration/host.xml
contiennent la configuration d'un domaine géré.Exemple 3.3. Exemple d'adresses d'opérations
Pour procéder à une opération dans le sous-système de journalisation, utiliser l'adresse suivante dans la demande opérationnelle :/subsystem=logging
Pour effectuer une opération sur la source de données Java, utiliser l'adresse suivante dans la demande opérationnelle :/subsystem=datasources/data-source=java
Déterminer l'opération
Les opérations diffèrent avec chaque type de nœud de ressource. Une opération utilise la syntaxe suivante ::operation-name
- operation-name correspond au nom de l'opération à demander.
Utiliser l'opérationread-operation-names
sur une adresse de ressources d'un serveur autonome pour lister les opérations disponibles.Exemple 3.4. Opérations disponibles
Pour énumérer toutes les opérations disponibles du sous-système de journalisation, saisir la requête suivante dans une serveur autonome :[standalone@localhost:9999 /] /subsystem=logging:read-operation-names { "outcome" => "success", "result" => [ "add", "read-attribute", "read-children-names", "read-children-resources", "read-children-types", "read-operation-description", "read-operation-names", "read-resource", "read-resource-description", "remove", "undefine-attribute", "whoami", "write-attribute" ] }
Déterminer un paramètre
Chaque opération a sans doute besoin de paramètres différents.Les paramètres utilisent la syntaxe suivante :(parameter-name=parameter-value)
- parameter-name correspond au nom du paramètre.
- parameter-value correspond à la valeur du paramètre.
- Les différents paramètres sont séparés par des virgules (
,
).
Afin de déterminer les paramètres qui conviennent, exécutez la commanderead-operation-description
sur un nœud de ressource, en faisant passer le nom de l'opération en tant que paramètre. Voir Exemple 3.5, « Déterminer les paramètres des opérations » pour plus de détails.Exemple 3.5. Déterminer les paramètres des opérations
Afin de déterminer les paramètres qui conviennent pour l'opérationread-children-types
sur le sous-système de journalisation, saisir la commanderead-operation-description
comme suit :[standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=read-children-types) { "outcome" => "success", "result" => { "operation-name" => "read-children-types", "description" => "Gets the type names of all the children under the selected resource", "reply-properties" => { "type" => LIST, "description" => "The children types", "value-type" => STRING }, "read-only" => true } }
Saisir toute la demande opérationnelle
Une fois que l'adresse, l'opération et tous les paramètres auront été sélectionnés, saisir la demande opérationnelle complète.Exemple 3.6. Exemple de demande opérationnelle
[standalone@localhost:9999 /]
/subsystem=web/connector=http:read-resource(recursive=true)
L'interface de gestion effectue la demande opérationnelle sur la configuration du serveur.
3.5.9. Références de Commandes de Management CLI
La section Section 3.5.5, « Comment obtenir de l'aide avec le Management CLI » décrit comment accéder aux fonctionnalités d'assistance du Management CLI. L'interface de gestion dispose d'une boîte de dialogue d'assistance avec des options générales et des options sensibles au contexte. Les commandes d'assistance dépendant du contexte de l'opération nécessitent une connexion à un contrôleur de domaine ou à un serveur autonome. Ces commandes ne seront pas affichées dans la liste, sauf si la connexion a été établie.
Tableau 3.3.
Commande | Description |
---|---|
batch | Démarrer le mode par lot en créant un nouveau lot ou, selon les lots existants retenus, réactiver l'un d'entre eux. Si il n'y a pas de lot existant retenu, cette commande sans argument va commencer un nouveau lot .S'il y a un lot sans nom existant retenu, cette commande le réactivera. S'il y a des lots existants retenus, mais avec nom, il peuvent être activés en exécutant cette commande avec ce nom comme argument. |
cd | Change le chemin du nœud en cours à l'argument. Le chemin du nœud en cours est utilisé comme adresse pour les requêtes opérationnelles qui ne contiennent pas la partie adresse. Si une opération n'inclut pas d'adresse, l'adresse incluse sera considérée comme relative au chemin du nœud en cours. Le chemin du nœud en cours peut finir en type de nœud. Dans ce cas, exécuter une opération en spécifiant un nom de nœud est suffisant, comme logging:read-resource. |
clear | Efface l'écran |
command | Vous permet d'ajouter, de supprimer ou de lister des commandes existantes de type standard. Une commande de type standard est une commande qui est assignée à un type de nœud spécifique et qui vous permet d'effectuer une opération disponible à une instance de ce type. Elle vous permet de modifier n'importe quelle propriété exposée par le type de n'importe quelle instance existante. |
connect | Connecte le contrôleur à l'hôte et au port spécifiés. |
connection-factory | Définit une usine de connexions |
data-source | Gère les configurations de sources de données JDBC dans le sous-système de la source de données. |
deploy | Déploie l'application désignée par le chemin d'accès au fichier ou bien, active une application qui est pré-existante, mais désactivée dans le référentiel. Si elle est exécutée sans argument, cette commande énumérera tous les déploiements existants. |
help | Affiche le message d'assistance. Peut être utilisé avec l'argument --commands pour fournir aux commandes données des résultats sensibles au contexte. |
history | Affiche l'historique en mémoire de la commande CLI et affiche un statut pour savoir si l'expansion de l'historique est activée ou non. Peut être utilisé avec des arguments pour effacer, désactiver, ou activer l'expansion de l'historique selon les besoins. |
jms-queue | Définit une file d'attente JMS dans le sous-système de messagerie. |
jms-topic | Définit un topic dans le sous-système de messagerie. |
ls | Lister les contenus du chemin d'accès au nœud. Par défaut, le résultat est imprimé dans des colonnes qui utilisent toute la largeur du terminal. Utiliser -l affichera les résultats sur la base d'un nom par ligne. |
pwd | Affiche le chemin d'accès du nœud pour le nœud en cours |
quit | Termine l'interface de ligne de commande. |
read-attribute | Affiche la valeur et, suivant les arguments, la description de l'attribut d'une ressource gérée. |
read-operation | Affiche la description d'une opération particulière, ou bien liste toutes les opérations si aucune n'est spécifiée. |
undeploy | Annule une demande lorsque celle-ci est exécutée avec le nom de l'application prévue. Peut être exécuté avec des arguments pour supprimer également l'application du référentiel. Imprime la liste de tous les déploiements existants si exécutée sans application spécifiée. |
version | Affiche la version de serveur d'application et les informations d'environnement. |
xa-data-source | Gére la configuration de la source de données JDBC XA du sous-système de la source de données. |
3.5.10. Référence aux Opérations de Management CLI
Les opérations du Management CLI peuvent être exposées par l'opération read-operation-names
décrite dans la rubrique Section 3.6.5, « Afficher les Noms de l'opération en utilisant le Management CLI ». Les descriptions des opérations peuvent être exposées par l'opération read-operation-descriptions
décrite dans la rubrique Section 3.6.4, « Affiche une description d'opération en utilisant le Management CLI ».
Tableau 3.4. Les opérations de Management CLI
Nom de l'opération | Description |
---|---|
add-namespace | Ajoute un mappage de préfixe d'espace-nom à la mappe d'attribut d'espace-nom. |
add-schema-location | Ajoute un schéma de mappage d'emplacement à la mappe d'attribut schema-locations. |
delete-snapshot | Efface un snapshot de la configuration serveur dans le répertoire de snapshots. |
full-replace-deployment | Ajoute le contenu précédemment téléchargé déploiement à la liste de contenu disponible, remplace le contenu existant du même nom dans le runtime et supprime le contenu remplacé dans la liste de contenu disponible. Voir lien pour plus de renseignements. |
list-snapshots | Liste les snapshots de la configuration du serveur sauvegardée dans le répertoire des snapshots. |
read-attribute | Affiche la valeur d'un attribut d'une ressource sélectionnée. |
read-children-names | Affiche le nom de tous les enfants d'une ressource donnée ayant le type donné. |
read-children-resources | Affiche des informations sur tous les enfants d'une ressource d'un type donné. |
read-children-types | Affiche les noms de types de tous les enfants pour la ressource sélectionnée. |
read-config-as-xml | Lit la configuration actuelle et l'affiche en format XML. |
read-operation-description | Affiche les détails d'une opération de la ressource donnée. |
read-operation-names | Affiche les noms de toutes les opérations de la ressource donnée. |
read-resource | Affiche les valeurs des attributs d'un modèle de ressource avec des informations complètes ou de base sur n'importe quelle ressource enfant. |
read-resource-description | Indique la description des attributs d'une ressource, les types de dépendants et les opérations. |
reload | Charge le serveur à nouveau en fermant tous les services et en redémarrant. |
remove-namespace | Supprime un mappage de préfixe d'espace-nom à la mappe d'attribut d'espace-nom. |
remove-schema-location | Supprime un schéma de mappage d'emplacement à la mappe d'attribut schema-locations. |
replace-deployment | Remplace le contenu existant du runtime par un contenu nouveau. Le nouveau contenu doit avoir été chargé auparavant dans le référentiel du contenu de déploiement. |
resolve-expression | Opération qui accepte une expression comme entrée ou un string pouvant être compris comme une expression, et résolu en fonction du système locale de propriétés et des variables d'environnement. |
resolve-internet-address | Prend un ensemble de critères de résolution d'interface et trouve une adresse IP sur une machine locale qui correspond au critère, ou échoue si aucune adresse IP correspondante n'est trouvée. |
server-set-restart-required | Met le serveur en mode «restart-required» |
shutdown | Ferme le serveur via un appel à System.exit(0) . |
start-servers | Démarre tous les serveurs configurés dans un Domaine géré qui n'est pas actuellement en cours d'exécution. |
stop-servers | Arrête tous les serveurs actuellement en cours d'exécution dans un Domaine géré. |
take-snapshot | Prend un snapshot de la configuration du serveur et la sauvegarde dans le répertoire des snapshots. |
upload-deployment-bytes | Indique si le contenu de déploiement du tableau d'octets inclus doit être ajouté au référentiel du contenu de déploiement. Notez que cette opération n'indique pas que le contenu doive être déployé au runtime. |
upload-deployment-stream | Indique si le contenu de déploiement disponible dans l'index des flux entrants doit être ajouté au référentiel du contenu de déploiement. Notez que cette opération n'indique pas que le contenu doive être déployé au runtime. |
upload-deployment-url | Indique si le contenu de déploiement disponible dans l'URL doit être ajouté au référentiel du contenu de déploiement. Notez que cette opération n'indique pas que le contenu doive être déployé au runtime. |
validate-address | Valide l'adresse de l'opération |
write-attribute | Indique la valeur d'un attribut d'une ressource sélectionnée. |
3.6. Opérations de l'interface CLI
3.6.1. Afficher les attributs d'une ressource par le Management CLI
L'opération read-attribute
est une opération globale utilisée pour lire la valeur d'exécution d'un attribut sélectionné. Peut être utilisée pour exposer uniquement les valeurs qui ont été définies par l'utilisateur, en ignorant toute valeur par défaut ou non définie. Les propriétés de la requête incluent les paramètres suivants.
Propriétés de requêtes
name
- Le nom de l'attribut pour obtenir la valeur sous la ressource sélectionnée.
include-defaults
- Un paramètre booléen qui peut être défini à
false
pour limiter les résultats de l'opération aux attributs qui ont été définis par l'utilisateur uniquement, et ignorer les valeurs par défaut.
Procédure 3.14. Affiche la valeur de runtime en cours pour un attribut sélectionné.
Exécuter l'opération
read-attribute
À partir du Management CLI, utiliser l'opérationread-attribute
pour afficher la valeur d'un attribut de ressource. Pour plus d'informations sur les requêtes d'informations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes du Management CLI ».[standalone@localhost:9999 /]
:read-attribute(name=name-of-attribute)
read-attribute
est la possibilité d'exposer la valeur d'exécution actuelle d'un attribut spécifique. Des résultats similaires peuvent être obtenus avec l'opération read-attribute
, mais seulement avec l'addition de la propriété de requête include-runtime
, et uniquement dans le cadre d'une liste de toutes les ressources disponibles pour ce nœud. L'opération read-attribute
est destinée aux requêtes d'attribut précises, comme le montre l'exemple suivant.
Exemple 3.7. Exécuter l'opération read-attribute
pour exposer l'IP d'interface publique.
read-attribute
pour renvoyer la valeur exacte dans le runtime en cours.
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address) { "outcome" => "success", "result" => "127.0.0.1" }
resolved-address
est une valeur de runtime, donc il ne s'affiche pas dans les résultats de l'opération read-resource
standard.
[standalone@localhost:9999 /] /interface=public:read-resource { "outcome" => "success", "result" => { "any" => undefined, "any-address" => undefined, "any-ipv4-address" => undefined, "any-ipv6-address" => undefined, "inet-address" => expression "${jboss.bind.address:127.0.0.1}", "link-local-address" => undefined, "loopback" => undefined, "loopback-address" => undefined, "multicast" => undefined, "name" => "public", "nic" => undefined, "nic-match" => undefined, "not" => undefined, "point-to-point" => undefined, "public-address" => undefined, "site-local-address" => undefined, "subnet-match" => undefined, "up" => undefined, "virtual" => undefined } }
resolved-address
ou des autres valeurs de runtime, vous devrez utiliser la propriété de requête include-runtime
.
[standalone@localhost:9999 /] /interface=public:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "any" => undefined, "any-address" => undefined, "any-ipv4-address" => undefined, "any-ipv6-address" => undefined, "inet-address" => expression "${jboss.bind.address:127.0.0.1}", "link-local-address" => undefined, "loopback" => undefined, "loopback-address" => undefined, "multicast" => undefined, "name" => "public", "nic" => undefined, "nic-match" => undefined, "not" => undefined, "point-to-point" => undefined, "public-address" => undefined, "resolved-address" => "127.0.0.1", "site-local-address" => undefined, "subnet-match" => undefined, "up" => undefined, "virtual" => undefined } }
La valeur de l'attribut du runtime en cours est affichée.
3.6.2. Afficher l'utilisateur qui est actif dans le Management CLI
L'opération whoami
est une opération globale utilisée pour identifier les attributs de l'utilisateur actif. L'opération expose l'identité de nom d'utilisateur et le domaine qui leur est attribué. L'opération whoami
est utile pour les administrateurs qui gèrent plusieurs comptes d'utilisateurs dans plusieurs domaines, ou pour aider à assurer le suivi des utilisateurs actifs à travers les instances de domaine avec plusieurs sessions de terminal et les comptes utilisateurs.
Procédure 3.15. Affiche l'utilisateur qui est actif dans le Management CLI par l'opération whoami
Exécuter l'opération
whoami
À partir du Management CLI, utiliser l'opérationwhoami
pour afficher le compte utilisateur actif.[standalone@localhost:9999 /]
:whoami
L'exemple suivant utilise la commandewhoami
dans une instance de serveur autonome pour montrer que l'utilisateur actif est leusername
, et que l'utilisateur est assigné au domaineManagementRealm
.Exemple 3.8. Utiliser la commande
whoami
dans une instance autonome[standalone@localhost:9999 /]:whoami { "outcome" => "success", "result" => {"identity" => { "username" => "username", "realm" => "ManagementRealm" }} }
Votre compte d'utilisateur actif en cours est affiché
3.6.3. Affiche les informations Système et Serveur dans le Management CLI
Procédure 3.16. Affiche les informations Système et Serveur dans le Management CLI
Exécuter la commande
version
À partir du Management CLI, saisir la commandeversion
:[domain@localhost:9999 /]
version
Les informations sur la version de votre serveur d'applications et sur votre environnement s'afficheront.
3.6.4. Affiche une description d'opération en utilisant le Management CLI
Procédure 3.17. Éxécuter la commande de Management CLI suivante
Exécuter l'opération
read-operation-description
À partir du Management CLI, utiliserread-operation-description
pour afficher des informations sur l'opération. L'opération requiert des paramètres supplémentaires dans le format d'une paire clé-valeur pour indiquer quelle opération afficher. Pour plus d'informations sur les requêtes d'informations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes du Management CLI ».[standalone@localhost:9999 /]
:read-operation-description(name=name-of-operation)
Exemple 3.9. Afficher la description de l'opération «list-snapshots»
list-snapshots
.
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots) { "outcome" => "success", "result" => { "operation-name" => "list-snapshots", "description" => "Lists the snapshots", "request-properties" => {}, "reply-properties" => { "type" => OBJECT, "value-type" => { "directory" => { "type" => STRING, "description" => "The directory where the snapshots are stored", "expressions-allowed" => false, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L }, "names" => { "type" => LIST, "description" => "The names of the snapshots within the snapshots directory", "expressions-allowed" => false, "required" => true, "nillable" => false, "value-type" => STRING } } }, "access-constraints" => {"sensitive" => {"snapshots" => {"type" => "core"}}}, "read-only" => false } }
La description est affichée pour l'opération choisie.
3.6.5. Afficher les Noms de l'opération en utilisant le Management CLI
Procédure 3.18. Éxécuter la commande de Management CLI suivante
Exécuter l'opération
read-operation-names
À partir du Management CLI, utiliser l'opérationread-operation-names
pour afficher les noms des opérations disponibles. Pour plus d'informations sur les requêtes d'informations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes du Management CLI ».[standalone@localhost:9999 /]
:read-operation-names
Exemple 3.10. Afficher les noms de l'opération en utilisant le Management CLI
read-operation-names
.
[standalone@localhost:9999 /]:read-operation-names
{
"outcome" => "success",
"result" => [
"add-namespace",
"add-schema-location",
"delete-snapshot",
"full-replace-deployment",
"list-snapshots",
"read-attribute",
"read-children-names",
"read-children-resources",
"read-children-types",
"read-config-as-xml",
"read-operation-description",
"read-operation-names",
"read-resource",
"read-resource-description",
"reload",
"remove-namespace",
"remove-schema-location",
"replace-deployment",
"resolve-expression",
"resolve-internet-address",
"server-set-restart-required",
"shutdown",
"take-snapshot",
"undefine-attribute",
"upload-deployment-bytes",
"upload-deployment-stream",
"upload-deployment-url",
"validate-address",
"validate-operation",
"whoami",
"write-attribute"
]
}
Les noms d'opérations disponibles sont affichés.
3.6.6. Afficher les ressources disponibles en utilisant le Management CLI
L'opération read-resource
est une opération globale utilisée pour lire la valeur des ressources. Peut être utilisée pour exposer des informations complètes ou de base sur les ressources des nœuds en cours ou des nœuds enfants, ainsi qu'un ensemble de propriétés de requêtes qui peuvent étendre ou limiter l'étendue des résultats de l'opération. Les propriétés de la requête incluent les paramètres suivants.
Propriétés de requêtes
recursive
- Pour savoir si on doit inclure récursivement des informations complètes sur les ressources enfant.
recursive-depth
- La précision des informations de ressources enfant incluses
proxies
- Si on doit inclure des ressources éloignées pour une recherche récursive. Par exemple, si on doit inclure les ressources niveau hôte à partir des Contrôleurs Hôtes esclave pour une demande de Contrôleur de domaines.
include-runtime
- Si on doit inclure des attributs de runtime dans la réponse, comme des valeurs d'attributs qui ne proviennent pas de la configuration persistante. Cette propriété de requête est définie sur false par défaut.
include-defaults
- Une propriété de demande booléenne qui sert à activer ou à désactiver la lecture des attributs par défaut. Si définie sur false, seuls les attributs définis par l'utilisateur seront renvoyés, ignorant ainsi ceux qui sont non définis.
Procédure 3.19. Éxécuter la commande de Management CLI suivante
Exécuter l'opération
read-resource
Avec le Management CLI, faites l'opérationread-resource
pour afficher les ressources disponibles.[standalone@localhost:9999 /]
:read-resource
L'exemple suivant vous montre comment il est possible d'utiliser l'opérationread-resource
dans une instance de serveur autonome pour exposer les informations de ressources générales. Les résultats ressemblent au fichier de configurationstandalone.xml
, qui affiche les ressources de système, les extensions, les interfaces et les sous-systèmes installés ou configurés pour l'instance du serveur. Ces résultats peuvent être interrogés directement.Exemple 3.11. Exécuter l'opération
read-resource
niveau racine[standalone@localhost:9999 /]:read-resource { "outcome" => "success", "result" => { "deployment" => undefined, "deployment-overlay" => undefined, "management-major-version" => 1, "management-micro-version" => 0, "management-minor-version" => 4, "name" => "longgrass", "namespaces" => [], "product-name" => "EAP", "product-version" => "6.1.0.GA", "release-codename" => "Janus", "release-version" => "7.2.0.Final-redhat-3", "schema-locations" => [], "system-property" => undefined, "core-service" => { "management" => undefined, "service-container" => undefined, "server-environment" => undefined, "platform-mbean" => undefined }, "extension" => { "org.jboss.as.clustering.infinispan" => undefined, "org.jboss.as.connector" => undefined, "org.jboss.as.deployment-scanner" => undefined, "org.jboss.as.ee" => undefined, "org.jboss.as.ejb3" => undefined, "org.jboss.as.jaxrs" => undefined, "org.jboss.as.jdr" => undefined, "org.jboss.as.jmx" => undefined, "org.jboss.as.jpa" => undefined, "org.jboss.as.jsf" => undefined, "org.jboss.as.logging" => undefined, "org.jboss.as.mail" => undefined, "org.jboss.as.naming" => undefined, "org.jboss.as.pojo" => undefined, "org.jboss.as.remoting" => undefined, "org.jboss.as.sar" => undefined, "org.jboss.as.security" => undefined, "org.jboss.as.threads" => undefined, "org.jboss.as.transactions" => undefined, "org.jboss.as.web" => undefined, "org.jboss.as.webservices" => undefined, "org.jboss.as.weld" => undefined }, "interface" => { "management" => undefined, "public" => undefined, "unsecure" => undefined }, "path" => { "jboss.server.temp.dir" => undefined, "user.home" => undefined, "jboss.server.base.dir" => undefined, "java.home" => undefined, "user.dir" => undefined, "jboss.server.data.dir" => undefined, "jboss.home.dir" => undefined, "jboss.server.log.dir" => undefined, "jboss.server.config.dir" => undefined, "jboss.controller.temp.dir" => undefined }, "socket-binding-group" => {"standard-sockets" => undefined}, "subsystem" => { "logging" => undefined, "datasources" => undefined, "deployment-scanner" => undefined, "ee" => undefined, "ejb3" => undefined, "infinispan" => undefined, "jaxrs" => undefined, "jca" => undefined, "jdr" => undefined, "jmx" => undefined, "jpa" => undefined, "jsf" => undefined, "mail" => undefined, "naming" => undefined, "pojo" => undefined, "remoting" => undefined, "resource-adapters" => undefined, "sar" => undefined, "security" => undefined, "threads" => undefined, "transactions" => undefined, "web" => undefined, "webservices" => undefined, "weld" => undefined } } }
Exécuter l'opération
read-resource
pour un nœud enfantL'opérationread-resource
peut être exécutée pour chercher les nœuds enfants à partir de la racine. La structure de l'opération commence par définir le nœud à exposer, puis s'ajoute à l'opération pour exécuter à ses côtés.[standalone@localhost:9999 /]
/subsystem=web/connector=http:read-resource
Dans l'exemple suivant, on peut exposer des informations de ressources spécifiques sur un composant de sous-système en redirigeant l'opérationread-resource
vers un nœud de sous-système web particulier.Exemple 3.12. Exposer les ressources de nœud enfant à partir d'un nœud racine
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource { "outcome" => "success", "result" => { "configuration" => undefined, "enable-lookups" => false, "enabled" => true, "executor" => undefined, "max-connections" => undefined, "max-post-size" => 2097152, "max-save-post-size" => 4096, "name" => "http", "protocol" => "HTTP/1.1", "proxy-name" => undefined, "proxy-port" => undefined, "redirect-port" => 443, "scheme" => "http", "secure" => false, "socket-binding" => "http", "ssl" => undefined, "virtual-server" => undefined } }
Les mêmes résultats sont possibles en utilisant la commandecd
pour naviguer dans les nœuds enfants et en exécutant l'opérationread-resource
directement.Exemple 3.13. Exposer les ressources de nœud enfant en changeant de répertoire
[standalone@localhost:9999 /] cd subsystem=web
[standalone@localhost:9999 subsystem=web] cd connector=http
[standalone@localhost:9999 connector=http] :read-resource { "outcome" => "success", "result" => { "configuration" => undefined, "enable-lookups" => false, "enabled" => true, "executor" => undefined, "max-connections" => undefined, "max-post-size" => 2097152, "max-save-post-size" => 4096, "name" => "http", "protocol" => "HTTP/1.1", "proxy-name" => undefined, "proxy-port" => undefined, "redirect-port" => 443, "scheme" => "http", "secure" => false, "socket-binding" => "http", "ssl" => undefined, "virtual-server" => undefined } }
Utiliser le paramètre récursif pour inclure des valeurs actives dans les résultats
Le paramètre récursif peut être utilisé pour exposer les valeurs de tous les attributs, y compris les valeurs non persistantes, celles qui sont passées au démarrage, ou les autres attributs normalement actifs du modèle d'exécution.[standalone@localhost:9999 /]
/interface=public:read-resource(include-runtime=true)
Par rapport à l'exemple précédent, l'inclusion de la propriété de requêteinclude-runtime
expose des attributs actifs supplémentaires, comme des octets envoyés ou des octets reçus par le connecteur HTTP.Exemple 3.14. Exposer des valeurs actives et supplémentaires par le paramètre
include-runtime
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true) { "outcome" => "success", "result" => { "any" => undefined, "any-address" => undefined, "any-ipv4-address" => undefined, "any-ipv6-address" => undefined, "inet-address" => expression "${jboss.bind.address:127.0.0.1}", "link-local-address" => undefined, "loopback" => undefined, "loopback-address" => undefined, "multicast" => undefined, "name" => "public", "nic" => undefined, "nic-match" => undefined, "not" => undefined, "point-to-point" => undefined, "public-address" => undefined, "resolved-address" => "127.0.0.1", "site-local-address" => undefined, "subnet-match" => undefined, "up" => undefined, "virtual" => undefined } }
3.6.7. Afficher les descriptions de ressources disponibles en utilisant le Management CLI
Procédure 3.20. Éxécuter la commande de Management CLI suivante
Exécuter l'opération
read-resource-description
À partir du Management CLI, utiliser l'opérationread-resource-description
pour lire et afficher les noms des ressources disponibles. Pour plus d'informations sur les requêtes d'opérations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes du Management CLI ».[standalone@localhost:9999 /]
:read-resource-description
Utiliser les paramètres en option
L'opérationread-resource-description
autorise l'utilisation de paramètres supplémentaires.- Utiliser le paramètre
operations
pour inclure les descriptions des opérations de la ressource.[standalone@localhost:9999 /]
:read-resource-description(operations=true)
- Utiliser le paramètre
inherited
pour inclure ou pour exclure des descriptions des opérations héritées de ressource. L'état par défaut est true.[standalone@localhost:9999 /]
:read-resource-description(inherited=false)
- Utiliser le paramètre
recursive
pour inclure les descriptions récursives des ressources dépendantes.[standalone@localhost:9999 /]
:read-resource-description(recursive=true)
- Utiliser le paramètre
locale
pour obtenir la description des ressources. Si « null », la locale régionale par défaut sera utilisée.[standalone@localhost:9999 /]
:read-resource-description(locale=true)
Les descriptions des ressources disponibles sont affichées.
3.6.8. Charger à nouveau le serveur d'applications à l'aide du Management CLI
Procédure 3.21. Charger à nouveau le serveur d'applications
Exécuter l'opération
reload
À partir du Management CLI, utiliser l'opérationreload
pour fermer le serveur via l'appel de systèmeSystem.exit(0)
. Pour plus d'informations sur les demandes d'opérations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes du Management CLI ».[standalone@localhost:9999 /]
:reload
{"outcome" => "success"}
Le serveur d'applications charge à nouveau en fermant tout d'abord tous les services et en démarrant le runtime à nouveau. Le Management CLI reconnecte automatiquement.
3.6.9. Fermer le serveur d'applications à l'aide du Management CLI
Procédure 3.22. Fermer le Serveur d'applications
Exécuter l'opération
shutdown
- À partir du Management CLI, utiliser l'opération
shutdown
pour fermer le serveur via l'appel de systèmeSystem.exit(0)
. Pour plus d'informations sur les requêtes d'opérations, voir le sujet Section 3.5.8, « Utiliser les opérations et les commandes du Management CLI ».- En mode autonome, utiliser la commande suivante :
[standalone@localhost:9999 /]
:shutdown
- En mode domaine, utiliser la commande suivante avec le nom d'hôte qui convient :
[domain@localhost:9999 /]
/host=master:shutdown
- Pour vous connecter à une instance CLI détachée et pour fermer le serveur, exécuter la commande suivante :
jboss-cli.sh --connect command=:shutdown
- Pour vous connecter à une instance CLI éloignée et pour fermer le serveur, exécuter la commande suivante :
[disconnected /] connect IP_ADDRESS Connected to IP_ADDRESS:PORT_NUMBER [192.168.1.10:9999 /] :shutdown
Remplacer l'IP_ADDRESS par l'adresse IP de votre instance.
Le serveur d'applications se ferme. Le Management CLI sera déconnecté car le runtime n'est pas disponible.
3.6.10. Configurer un attribut à l'aide du Management CLI
L'opération write-attribute
est une opération globale utilisée pour écrire ou modifier un attribut de la ressource sélectionnée. Vous pouvez utiliser l'opération pour rendre les modifications persistantes ou pour modifier les paramètres de configuration de vos instances de serveur géré. Les propriétés de la requête incluent les paramètres suivants.
Propriétés de requêtes
name
- Le nom de l'attribut pour définir la valeur sous la ressource sélectionnée.
value
- La valeur désirée de l'attribut sous la ressource sélectionnée. Peut être « null » si le modèle sous-jacent supporte des valeurs « null ».
Procédure 3.23. Configurer un attribut de ressource à l'aide du Management CLI
Exécuter l'opération
write-attribute
À partir du Management CLI, utiliser l'opérationwrite-attribute
pour modifier la valeur d'un attribut de ressource. L'opération peut être exécutée dans le nœud dépendant de la ressource, ou bien dans le nœud root du Management CLI où le chemin de ressource complet est spécifié.
Exemple 3.15. Désactiver le scanner de déploiement par l'opération write-attribute
write-attribute
pour désactiver le scanner de déploiement. L'opération est exécutée à partir d'un nœud root, en utilisant l'onglet de complétion de tâche pour pouvoir peupler le chemin de ressources qui convient.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false) {"outcome" => "success"}
read-attribute
.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled) { "outcome" => "success", "result" => false }
read-resource
. Dans l'exemple suivant, cette configuration particulière vous montre que l'attribut scan-enabled
est maintenant défini à false
.
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource { "outcome" => "success", "result" => { "auto-deploy-exploded" => false, "auto-deploy-xml" => true, "auto-deploy-zipped" => true, "deployment-timeout" => 600, "path" => "deployments", "relative-to" => "jboss.server.base.dir", "scan-enabled" => false, "scan-interval" => 5000 } }
L'attribut de ressource est mis à jour.
3.7. Historique des commandes de l'interface CLI
3.7.1. Utiliser l'Historique de commande à l'aide du Management CLI.
.jboss-cli-history
. Le fichier de l'historique est configuré par défaut pour enregistrer un maximum de 500 commandes CLI.
history
elle-même renverra l'historique de la session en cours, ou si accompagnée d'arguments, elle pourra désactiver, activer ou supprimer l'historique de la mémoire de session. Le Management CLI vous donne également la possibilité d'utiliser les flèches de votre clavier pour naviguer dans l'historique des commandes et des opérations.
Fonctions de l'historique du Management CLI
3.7.2. Afficher l'Historique de commandes à l'aide du Management CLI.
Procédure 3.24. Afficher l'Historique de commandes à l'aide du Management CLI.
Exécuter la commande
history
À partir du Management CLI, saisir la commandehistory
:[standalone@localhost:9999 /]
history
L'historique de la commande CLI stocké en mémoire depuis le démarrage du CLI ou la commande de suppression de l'historique est affiché.
3.7.3. Effacer l'Historique de commandes à l'aide du Management CLI.
Procédure 3.25. Effacer l'Historique de commandes à l'aide du Management CLI.
Exécuter la commande
history --clear
À partir du Management CLI, saisir la commandeversion
:[standalone@localhost:9999 /]
history --clear
L'historique des commandes enregistré depuis le démarrage du CLI est supprimé de la mémoire de session. L'historique de la commande est toujours présent dans le fichier .jboss-cli-history
qui est sauvegardé dans le répertoire d'accueil de l'utilisateur.
3.7.4. Désactiver l'Historique de commandes à l'aide du Management CLI.
Procédure 3.26. Désactiver l'Historique de commandes à l'aide du Management CLI.
Exécuter la commande
history --disable
À partir du Management CLI, saisir la commandehistory --disable
:[standalone@localhost:9999 /]
history --disable
Les commandes passées dans le CLI ne seront pas enregistrées dans la mémoire ou dans un fichier .jboss-cli-history
sauvegardé dans le répertoire d'accueil de l'utilisateur.
3.7.5. Activer l'Historique de commandes à l'aide du Management CLI.
Procédure 3.27. Activer l'Historique de commandes à l'aide du Management CLI.
Exécuter la commande
history --enable
À partir du Management CLI, saisir la commandehistory --enable
:[standalone@localhost:9999 /]
history --enable
Les commandes passées dans le CLI seront enregistrées dans la mémoire ou dans un fichier .jboss-cli-history
sauvegardé dans le répertoire d'accueil de l'utilisateur.
3.8. La journalisation d'auditing de l'interface de gestion
3.8.1. La Journalisation d'auditing de l'interface de gestion
Note
3.8.2. Activer la Journalisation d'auditing de l'interface de gestion par le Management CLI
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
3.8.3. Formateur pour la Journalisation d'auditing de l'interface de gestion
Tableau 3.5. Champs de formateur JSON
Attribut | Description |
---|---|
include-date | Valeur booléenne qui définit si l'horodatage est oui ou non inclus dans les archives log formatées. |
date-separator | Chaîne contenant des caractères pour séparer la date du reste des messages log formatés. Sera ignoré si include-date =false . |
date-format | Format de date utilisé pour les horodatages compris par java.text.SimpleDateFormat. Ignoré si include-date =false . |
compact | Si défini sur true , formatera le JSON sur une seule ligne. Il y a sans doute encore des valeurs contenant de nouvelles lignes, donc s'il est important pour vous d'avoir l'enregistrement total sur une seule ligne, définir escape-new-line ou escape-control-characters à true . |
escape-control-characters | Si défini sur true , échapera tous les caractères de contrôle (entrées ASCII à valeur décimales < 32) avec le code ASCII en octale ; par exemple, une nouvelle ligne devient '#012'. Si défini sur true , remplacera escape-new-line =false . |
escape-new-line | Si défini sur true, échappera toutes les nouvelles lignes avec le code ASCII en octale, comme par exemple "#012". |
3.8.4. Gestionnaire de fichiers de journalisation de l'auditing de l'interface de gestion
Tableau 3.6. Champs de journalisation d'audit de Gestionnaire de fichiers.
Attribut | Description | Lecture seule |
---|---|---|
formateur | Le nom d'un formateur JSON à utiliser pour formater les enregistrements de journalisation. | False |
path | Le chemin d'accès du fichier de journalisation de l'auditing | False |
relative-to | Le nom d'un chemin d'accès déjà nommé, ou d'un des chemins standard fournis par le système. Si relative-to est donné, la valeur de l'attribut du chemin d'accès sera traité comme relative au chemin spécifié par cet attribut. | False |
failure-count | Le nombre d'échecs de journalisation depuis l'initialisation du gestionnaire. | True |
max-failure-count | Le nombre maximum d'échecs de journalisation avant de désactiver ce gestionnaire. | False |
disabled-due-to-failure | true si ce gestionnaire était désactivé à cause des échecs de journalisation. | True |
3.8.5. Gestionnaire de fichier Syslog de journalisation de l'auditing de l'interface de gestion
- http://www.ietf.org/rfc/rfc3164.txt
- http://www.ietf.org/rfc/rfc5424.txt
- http://www.ietf.org/rfc/rfc6587.txt
Tableau 3.7. Champs de Gestionnaire Syslog
Champ | Description | Lecture seule |
---|---|---|
formateur | Le nom du formateur à utiliser pour formater les enregistrements de journalisation. | False |
failure-count | Le nombre d'échecs de journalisation depuis l'initialisation du gestionnaire | True |
max-failure-count | Le nombre maximum d'échecs de journalisation avant de désactiver ce gestionnaire. | False |
disabled-due-to-failure | True si ce gestionnaire était désactivé à cause des échecs de journalisation. | True |
syslog-format | Format Syslog: RFC-5424 ou RFC-3164. | False |
max-length | La taille maximum d'un message de journalisation (en octets), comprenant l'en-tête. Si non défini, la valeur par défaut sera de 1024 octets si le syslog-format est RFC3164, ou 2048 octets si le syslog-format est RFC5424. | False. |
truncate | Indique si un message doit ou non tronquer le message quand la longueur en octets est supérieure à la longueur maximale. Si la valeur est définie sur false, les messages seront divisés et envoyés avec les mêmes valeurs d'en-tête. | False |
3.8.6. Activer la Journalisation d'auditing de l'interface de gestion par le Serveur Syslog.
Note
/host=HOST_NAME
aux commandes /core-service
si vous devez appliquer les changements à un domaine géré.
Procédure 3.28. Activer la Journalisation sur un Serveur Syslog
Créer un Gestionnaire Syslog nommé
msyslog
[standalone@localhost:9999 /]batch [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter) [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514) [standalone@localhost:9999 /]run-batch
Ajouter une référence au Gestionnaire Syslog.
[standalone@localhost:9999 /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add
Les entrées de journalisation de l'auditing de l'interface de gestion sont alors enregistrées sur le serveur syslog.
3.8.7. Options de Journalisation d'auditing de l'interface de gestion
Options de configuration
- log-boot
- Si défini sur
true
, quand on démarre le serveur, les opérations de gestion seront incluses dans le log d'auditing, sinonfalse
. Notons que la valeur par défaut est false. - log-read-only
- Si défini sur
true
, toutes les opérations d'auditing seront journalisées. Si défini surfalse
, seules les opérations qui changeront le modèle seront journalisées. La valeur par défaut est : false.
3.8.8. Champs de Journalisation d'auditing de l'interface de gestion
Tableau 3.8. Champs de Journalisation d'auditing de l'interface de gestion
Nom de champ | Description |
---|---|
type | Peut avoir pour valeur core , indiquant ainsi qu'il s'agit d'une opération de gestion, ou jmx indiquant une provenance de sous-système JMX (voir le sous-système JMX pour la configuration de la Journalisation de l'auditing du sous-système JMX). |
r/o | true si l'opération ne modifie pas le modèle de gestion, sinon false . |
booting | true si l'opération a été exécutée à l'amorçage, false si elle a été exécutée une fois que le serveur était en route. |
version | Numéro de version de l'instance JBoss EAP. |
user | Nom d'utilisateur de l'utilisateur authentifié. Si l'opération a été journalisée via le CLI sur le même ordinateur que le serveur en cours d'exécution, l'utilisateur spécial $local sera utilisé. |
domainUUID | Identifiant pour relier toutes les opérations tandis qu'elles sont propagées du contrôleur de domaines vers ses serveurs, ses contrôleurs hôtes, et ses serveurs de contrôleurs hôtes esclaves. |
access | Cela peut avoir une des valeurs suivantes : NATIVE, HTTP, JMX. NATIVE - l'opération provient de l'interface de gestion native, par exemple le CLI. HTTP - l'opération provient de l'interface HTTP de domaine, par exemple la Console d'administration. JMX - l'opération provient du sous-système de JMX. Voir JMX pour savoir comment configurer la journalisation del'auditing pour JMX. |
remote-address | l'adresse du client qui exécute l'opération. |
success | true si l'opération a réussi, false si non. |
ops | Les opérations en cours. Liste des opérations sérialisées dans JSON. Au démarrage, cela correspondra à toutes les opérations résultant du traitement XML. Une fois démarré, la liste contiendra normalement une seule entrée. |
Chapitre 4. Gestion des utilisateurs
4.1. Création d'utilisateur
4.1.1. Ajouter Utilisateur pour les Interfaces de gestion
Les Interfaces de gestion sont sécurisées par défaut dans JBoss EAP 6 car il n'y a aucun compte utilisateur initialement disponible, sauf si vous avez installé la plateforme à l'aide de l'installateur graphique. Il s'agit d'une précaution de sécurité pour empêcher les violations de sécurité des systèmes distants pour cause d'erreur de configuration simple. L'accès non-HTTP local est protégé par un mécanisme SASL, avec une négociation qui passe entre le client et le serveur chaque fois que le client se connecte pour la première fois à partir de l'hôte local.
Note
Procédure 4.1. Créer l'utilisateur administratif d'origine pour les interfaces de gestion distantes
Invoquer le script
add-user.sh
ouadd-user.bat
script.Passez au répertoireEAP_HOME/bin/
. Invoquer le script qui convient à votre système d'exploitation.- Red Hat Enterprise Linux
[user@host bin]$
./add-user.sh- Microsoft Windows Server
C:\bin>
add-user.bat
Choisissez d'utiliser un utilisateur Management.
Appuyer sur ENTER pour sélectionner l'optiona
pour ajouter un utilisateur Management. Cet utilisateur sera ajouté au domaineManagementRealm
et il sera autorisé à effectuer des opérations de gestion par la Management Console basée web ou par le Management CLI basé sur la ligne de commande. Autre alternative,b
, ajoutera l'utilisateur au domaineApplicationRealm
, et ne fournit aucune permission particulière. Ce domaine est fourni pour être utilisé avec des applications.Saisir le nom d'utilisateur et le mot de passe que vous souhaitez.
Quand on vous y invite, saisir le nom d'utilisateur et le nom de passe. On vous demandera de saisir le mot de passe une seconde fois pour confirmer.Saisissez les informations sur votre groupe.
Ajouter le groupe ou les groupes auxquels l'utilisateur appartient. Si l'utilisateur appartient à plusieurs groupes, saisir une liste séparée par des virgules. Laisser vide s'il n'y a pas de groupes pour l'utilisateur.Vérifier les informations et confirmer.
On vous invitera à confirmer les informations. Quand vous serez satisfait, saisiryes
.Décidez si l'utilisateur représente une instance de serveur de JBoss EAP 6 à distance.
En plus des administrateurs, un autre type d'utilisateur qui a parfois besoin d'être ajouté à JBoss EAP 6 dans le domaineManagementRealm
est un utilisateur qui représente une autre instance de JBoss EAP 6, et qui a besoin d'être authentifié pour rejoindre un groupement en tant que membre. L'invite suivante vous permet de désigner votre utilisateur supplémentaire dans ce but. Si vous sélectionnezyes
, on vous donnera une valeursecret
de hachage, qui représentera le mot de passe de l'utilisateur, que vous aurez besoin d'ajouter dans un fichier de configuration différent. Dans le but de cette tâche, répondreno
à cette question.Saisir des utilisateurs supplémentaires.
Vous pouvez saisir des utilisateurs supplémentaires si vous le souhaitez, en répétant la procédure. Vous pouvez également les ajouter à tout moment sur un système en cours d'exécution. Au lieu de choisir le domaine de sécurité par défaut, vous pouvez ajouter des utilisateurs d'autres domaines afin d'ajuster leurs autorisations.Créer des utilisateurs en mode non interactif.
Vous pouvez créer des utilisateurs en mode non interactif, en l'indiquant dans chaque paramètre de ligne de commande. Cette approche n'est pas recommandée sur les systèmes partagés, parce que les mots de passe seront visibles dans les fichiers de journalisation (log) et dans les fichiers d'historique. La syntaxe de la commande, pour le domaine de gestion, est la suivante :[user@host bin]$
./add-user.sh usernamepasswordPour utiliser le domaine d'application, utiliser le paramètre-a
.[user@host bin]$
./add-user.sh -a usernamepassword- Vous pouvez supprimer la sortie normale du script add-user en passant le paramètre
--silent
. Cela s'applique uniquement si un minimum de paramètres,nom d'utilisateur
etmot de passe
, ont été indiqués. Le message d'erreur apparaîtra toujours.
Tout utilisateur que vous ajoutez est activé dans les domaines de sécurité que vous avez indiqués. Les utilisateurs actifs dans le domaine ManagementRealm
sont en mesure de gérer la plateforme JBoss EAP 6 à partir de systèmes éloignés.
Voir également :
4.1.2. Passer des Arguments au script add-user de la Gestion Utilisateur
add-user.sh
ou add-user.bat
interactivement ou vous pouvez passer des arguments par la ligne de commande. Cette section décrit les options qui se présentent pour passer des arguments de ligne de commande au script add-user.
add-user.sh
ou add-user.bat
, consulter Section 4.1.3, « Arguments de commande Add-user » .
add-user.sh
ou add-user.bat
, consulter Section 4.1.5, « Exemples de lignes de commande de script Add-user » .
4.1.3. Arguments de commande Add-user
add-user.sh
ou add-user.bat
.
Tableau 4.1. Arguments de commande Add-user
Argument de ligne de commande | Valeur d'argument | Description |
---|---|---|
-a
|
N/A
|
Cet argument demande de créer un utilisateur dans le domaine de l'application. S'il est omis, un utilisateur sera créé par défaut dans le domaine de gestion.
|
-dc
|
DOMAIN_CONFIGURATION_DIRECTORY
|
Cet argument spécifie le répertoire de configuration de domaine qui contient les fichiers de propriétés. S'il est omis, le répertoire par défaut sera
EAP_HOME/domain/configuration/ .
|
-sc
|
SERVER_CONFIGURATION_DIRECTORY
|
Cet argument spécifie un répertoire de configuration de serveur autonome différent qui contient les fichiers de propriétés. S'il est omis, le répertoire par défaut sera
EAP_HOME/standalone/configuration/ .
|
-up
--user-properties
|
USER_PROPERTIES_FILE
|
Cet argument spécifie le nom d'un autre fichier de propriétés utilisateur. Il peut correspondre à un chemin absolu ou il peut correspondre à un nom de fichier utilisé en conjonction avec l'argument
-sc ou -dc qui spécifie le répertoire de configuration alternatif.
|
-g
--group
|
GROUP_LIST
|
Une liste séparée par des virgules de groupes à assigner à cet utilisateur.
|
-gp
--group-properties
|
GROUP_PROPERTIES_FILE
|
Cet argument spécifie le nom d'un autre fichier de propriétés de groupe. Il peut correspondre à un chemin absolu ou il peut correspondre à un nom de fichier utilisé en conjonction avec l'argument
-sc ou -dc qui spécifie le répertoire de configuration alternatif.
|
-p
--password
|
PASSWORD
|
Le mot de passe utilisateur. Le mot de passe doit remplir les critères suivants :
|
-u
--user
|
USER_NAME
|
Le nom de l'utilisateur.
|
-r
--realm
|
REALM_NAME
|
Le nom du domaine utilisé pour sécuriser les interfaces de gestion. S'il est omis, la valeur par défaut sera "ManagementRealm".
|
-s
--silent
|
N/A
|
Exécuter le script add-user sans sortie vers la console.
|
-h
--help
|
N/A
|
Afficher les informations d'utilisation du script add--user.
|
4.1.4. Spécifier des Fichiers de Propriétés alternatifs pour les Informations de Gestion des Utilisateurs
Par défaut, les informations utilisateur et rôle créés à l'aide du script add-user.sh
ou Add-user.bat
sont stockées dans des fichiers de propriétés situés dans le répertoire de configuration de serveur. Les informations de configuration du serveur sont stockées dans le répertoire EAP_HOME/standalone/configuration/
et les informations de configuration de domaine sont stockées dans le répertoire EAP_HOME/domaine/configuration/
. Cette rubrique décrit comment substituer les noms de fichier et emplacements par défaut.
Procédure 4.2. Spécifier des Fichiers de Propriétés alternatifs
- Pour spécifier un autre répertoire pour la configuration du serveur, utilisez l'argument
-sc
. Cet argument spécifie un autre répertoire qui contiendra les fichiers de propriétés de configuration de serveur. - Pour spécifier un répertoire alternatif de configuration de domaine, utiliser l'argument
-dc
. Cet argument spécifie un répertoire alternatif qui contient les fichiers de propriétés de configuration de domaines. - Pour spécifier un fichier de configuration utilisateur différent, utiliser l'argument
-up
ou--user-properties
. Peut correspondre à un chemin complet ou à un nom de fichier utilisé en conjonction avec-sc
ou-dc
spécifiant le répertoire de configuration alternatif. - Pour spécifier un fichier de configuration groupe différent, utiliser l'argument
-up
ou--group-properties
. Peut correspondre à un chemin complet ou à un nom de fichier utilisé en conjonction avec-sc
ou-dc
spécifiant le répertoire de configuration alternatif.
Note
add-user
a pour but d'opérer sur des fichiers de propriétés existants. Tout fichier de propriété alternatif spécifié dans un argument de ligne de commande devra sortir ou vous verrez l'erreur suivante :
JBAS015234: No appusers.properties files found
4.1.5. Exemples de lignes de commande de script Add-user
add-user.sh
ou add-user.bat
. À moins que cela soit notifié, ces commandes supposent la configuration d'un serveur autonome.
Exemple 4.1. Créer un utilisateur qui appartienne à un groupe unique en utilisant les fichiers de propriétés par défaut.
EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest'
- L'utilisateur
appuser1
est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.EAP_HOME/standalone/configuration/application-users.properties
EAP_HOME/domain/configuration/application-users.properties
- L'utilisateur
appuser1
ayant pour groupeguest
est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.EAP_HOME/standalone/configuration/application-roles.properties
EAP_HOME/domain/configuration/application-roles.properties
Exemple 4.2. Créer un utilisateur qui appartienne à plusieurs groupes en utilisant les fichiers de propriétés par défaut.
EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest,app1group,app2group'
- L'utilisateur
appuser1
est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.EAP_HOME/standalone/configuration/application-users.properties
EAP_HOME/domain/configuration/application-users.properties
- L'utilisateur
appuser1
ayant pour groupesguest
,app1group
, etapp2group
est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.EAP_HOME/standalone/configuration/application-roles.properties
EAP_HOME/domain/configuration/application-roles.properties
Exemple 4.3. Créer un utilisateur ayant des privilèges admin dans le domaine par défaut en utilisant les fichiers de propriétés par défaut.
EAP_HOME/bin/add-user.sh -u 'adminuser1' -p 'password1!' -g 'admin'
- L'utilisateur
adminuser1
est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.EAP_HOME/standalone/configuration/mgmt-users.properties
EAP_HOME/domain/configuration/mgmt-users.properties
- L'utilisateur
adminuser1
ayant pour groupeadmin
est ajouté aux fichiers de propriétés suivantes par défaut qui contiennent les informations utilisateur.EAP_HOME/standalone/configuration/mgmt-groups.properties
EAP_HOME/domain/configuration/mgmt-groups.properties
Exemple 4.4. Créer un utilisateur qui appartienne à un groupe unique en utilisant des fichiers de propriétés alternatifs pour stocker des informations.
EAP_HOME/bin/add-user.sh -a -u appuser1 -p password1! -g app1group -sc /home/someusername/userconfigs/ -up appusers.properties -gp appgroups.properties
- L'utilisateur
appuser1
est ajouté aux fichiers de propriétés suivantes et ce fichier est maintenant le fichier par défaut qui contient les informations utilisateur./home/someusername/userconfigs/appusers.properties
- L'utilisateur
appuser1
ayant pour groupeapp1group
est ajouté aux fichiers de propriétés suivantes et ce fichier est maintenant le fichier par défaut qui contient les informations utilisateur./home/someusername/userconfigs/appgroups.properties
Chapitre 5. Réseau et configuration de port
5.1. Interfaces
5.1.1. Les interfaces
domain.xml
, host.xml
et standalone.xml
comprennent tous des déclarations d'interface. Les critères de déclaration peuvent référencer une adresse générique ou spécifier un ensemble de caractéristiques qu'une interface ou une adresse doit avoir pour pouvoir établir une correspondance valide. Les exemples suivants illustrent plusieurs configurations possibles de déclarations d'interface, généralement définies soit dans le fichier de configuration standalone.xml
ou host.xml
. Cela permet à des groupes d'hôtes distants de maintenir leurs propres attributs d'interfaces spécifiques, tout en permettant une référence aux groupes d'interfaces dans le fichier de configuration domain.xml
du contrôleur de domaine.
inet-address
indiquée pour le groupes de noms relatifs management
et public
.
Exemple 5.1. Un groupe d'interfaces créé avec une adresse inet
<interfaces> <interface name="management"> <inet-address value="127.0.0.1"/> </interface> <interface name="public"> <inet-address value="127.0.0.1"/> </interface> </interfaces>
any-address
pour déclarer une adresse générique.
Exemple 5.2. Un groupe global créé avec une déclaration générique
<interface name="global"> <!-- Use the wild-card address --> <any-address/> </interface>
externe
.
Exemple 5.3. Un groupe externe créé avec un NIC
<interface name="external"> <nic name="eth0"/> </interface>
Exemple 5.4. Un groupe par défaut créé avec des valeurs conditionnelles spécifiques
<interface name="default"> <!-- Match any interface/address on the right subnet if it's up, supports multicast, and isn't point-to-point --> <subnet-match value="192.168.0.0/16"/> <up/> <multicast/> <not> <point-to-point/> </not> </interface>
5.1.2. Configurer les interfaces
standalone.xml
et host.xml
offrent trois interfaces nommées avec jetons d'interfaces relatives pour chacune. Vous pouvez utiliser la Console de gestion ou le Management CLI pour configurer des attributs et valeurs supplémentaires indiquées dans le tableau ci-dessous. Vous pouvez également remplacer les liaisons d'interfaces relatives par des valeurs spécifiques selon les besoins. Notez que si vous le faites, vous serez incapable de passer une valeur d'interface en cours d'exécution de serveur, car -b
peut seulement substituer une valeur relative.
Exemple 5.5. Configuration d'interface par défaut
<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> <interface name="unsecure"> <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/> </interface> </interfaces>
Tableau 5.1. Attributs et valeurs d'interface
Élément d'interface | Description |
---|---|
any | Élément vide de type exclusion d'adresse, utilisé pour forcer le critère de sélection. |
any-address | Élément vide indiquant que les sockets qui utilisent cette interface doivent être liés à une adresse générique. L'adresse générique IPv6 (::) sera utilisée à moins que la propriété système java.net.preferIpV4Stack soit définie sur true, dans lequel cas, l'adresse générique (0.0.0.0) IPv4 sera utilisée. Si un socket est lié à une adresse anylocal IPv6 sur une machine dual-stack, il pourra accepter le trafic IPv6 et IPv4 ; si lié à l'adresse IPv4 anylocal (mappées IPv4), il ne peut accepter que le trafic IPv4. |
any-ipv4-address | Élément vide indiquant que les sockets qui utilisent cette interface doivent être liés à une adresse générique (0.0.0.0) IPv4. |
any-ipv6-address | Élément vide indiquant que les sockets qui utilisent cette interface doivent être liés à une adresse générique (::). IPv6. |
inet-address | Soit une adresse IP en notation à points IPV6 ou IPV4, ou un nom d'hôte qui puisse être résolu. |
link-local-address | Élément vide indiquant qu'une partie du critère de sélection d'une interface doit si oui ou non il a une adresse associée local-link. |
loopback | Élément vide indiquant qu'une partie du critère de sélection d'une interface est de savoir s'il s'agit oui ou non d'une interface de loopback. |
loopback-address | Une adresse de loopback qui ne peut pas réellement être configurée sur l'interface de loopback de la machine. Diffère d'inet-addressType car la valeur donnée sera utilisée même si aucune carte réseau possédant l'adresse IP associée ne peut être trouvée. |
multicast | Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être si oui ou non il y a un support multi-diffusion. |
nic | Le nom d'une interface de réseau (e.g. eth0, eth1, lo). |
nic-match | Une expression standard à laquelle faire correspondre les noms des interfaces de réseau disponibles sur la machine pour trouver une interface qui convienne. |
not | Élément vide de type exclusion d'adresse, utilisé pour forcer le critère de sélection. |
point-to-point | Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être si elle a oui ou non une interface d'un point à un autre. |
public-address | Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être si elle a oui ou non une adresse publiquement routable. |
site-local-address | Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être ou non une adresse associée à à son site-local |
subnet-match | Une adresse IP réseau et le nombre de bits dans le préfixe de réseau de l'adresse, sous la forme « / » ; par exemple"192.168.0.0/16". |
up | Élément vide indiquant qu'une partie du critère de sélection d'une interface est active ou non. |
virtual | Élément vide indiquant qu'une partie du critère de sélection d'une interface doit être ou non une interface virtuelle. |
Configuration des attributs d'une interface
Sélectionner le Management CLI ou la Console de gestion pour configurer vos attributs d'interface selon les besoins.Configurer les attributs d'interface par le Management CLI
Utiliser le Management CLI pour ajouter de nouvelles interfaces et pour écrire des nouvelles valeurs dans dans les attributs de l'interface.Ajouter une nouvelle interface
Utiliser l'opérationadd
(ajouter) pour créer une nouvelle interface selon les besoins. Vous pouvez exécuter cette commande à partir de la racine de la session de Management CLI, qui, dans l'exemple suivant, crée un nouveau titre de nom d'interface interfacename, avecinet-address
déclaré ainsi 12.0.0.2./interface=interfacename/:add(inet-address=12.0.0.2)
Modifier les attributs d'une interface
Utiliser l'opérationwrite
pour écrire une nouvelle valeur dans un attribut. Vous pouvez utiliser l'onglet de complétion pour terminer la chaîne de commande en cours, ainsi que pour exposer les attributs disponibles. L'exemple suivant met à jour la valeur de l'inet-address
à 12.0.0.8/interface=interfacename/:write(inet-address=12.0.0.8)
Modifier les attributs d'une interface
Confirmer que les valeurs ont changé en exécutantread-resource
accompagné du paramètreinclude-runtime=true
pour exposer toutes les valeurs actives en cours du modèle de serveur.[standalone@localhost:9999 interface=public]
:read-resource(include-runtime=true)
Configurer les attributs d'interface par la Console de gestion
Utiliser la Console de gestion pour ajouter des nouvelles interfaces et pour écrire des nouvelles valeurs dans les attributs de l'interface.Connectez-vous à la Console de gestion.
Connectez-vous à la Console de gestion de votre instance de Serveur autonome ou Managed Domain (Domaine géré).Si vous utilisez le Managed Domain, sélectionner le profil qui convient.
Sélectionner l'onglet Profiles en haut à droite, puis sélectionner le profil qui convient à partir du menu Profile en haut et à gauche de l'écran suivant.Sélectionner l'item Interfaces à partir du menu de navigation.
Sélectionner l'item de menu Interfaces à partir du menu de navigation.Ajouter une nouvelle interface
- Cliquer sur le bouton Add (ajouter).
- Saisir les valeurs qui conviennent pour les Name (Nom), Inet Address (Adresse Inet) et Address Wildcard (Adresse générique).
- Cliquer sur le bouton Save pour terminer.
Modifier les attributs d'une interface
- Sélectionner l'interface à modifier et cliquer sur le bouton Edit.
- Saisir les valeurs qui conviennent pour les Name (Nom), Inet Address (Adresse Inet) et Address Wildcard (Adresse générique).
- Cliquer sur le bouton Save pour terminer.
5.2. Groupes de liaisons de sockets
5.2.1. Groupes de liaisons de sockets
domain.xml
et standalone.xml
. D'autres sections de la configuration peuvent alors faire référence à ces sockets par leur nom logique, plutôt que d'avoir à inclure tous les détails de la configuration de socket. Cela permet de référencer des configurations de sockets relatives qui peuvent varier sur des machines différentes.
Exemple 5.6. Liaisons de sockets par défaut pour la configuration du serveur autonome.
standalone.xml
sont groupés sous standard-sockets
. Ce groupe est aussi référencé dans l'interface publique
, en utilisant la même méthodologie de référencement logique.
<socket-binding-group name="standard-sockets" default-interface="public"> <socket-binding name="http" port="8080"/> <socket-binding name="https" port="8443"/> <socket-binding name="jacorb" port="3528"/> <socket-binding name="jacorb-ssl" port="3529"/> <socket-binding name="jmx-connector-registry" port="1090" interface="management"/> <socket-binding name="jmx-connector-server" port="1091" interface="management"/> <socket-binding name="jndi" port="1099"/> <socket-binding name="messaging" port="5445"/> <socket-binding name="messaging-throughput" port="5455"/> <socket-binding name="osgi-http" port="8090" interface="management"/> <socket-binding name="remoting" port="4447"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> </socket-binding-group>
Exemple 5.7. Liaisons de sockets par défaut pour la configuration du serveur autonome.
domain.xml
contiennent quatre groupes : standard-sockets
, ha-sockets
, full-sockets
et full-ha-sockets
. Ces groupes sont également référencés dans une interface appelée public
.
<socket-binding-groups> <socket-binding-group name="standard-sockets" default-interface="public"> <!-- Needed for server groups using the 'default' profile --> <socket-binding name="ajp" port="8009"/> <socket-binding name="http" port="8080"/> <socket-binding name="https" port="8443"/> <socket-binding name="osgi-http" interface="management" port="8090"/> <socket-binding name="remoting" port="4447"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> <socket-binding-group name="ha-sockets" default-interface="public"> <!-- Needed for server groups using the 'ha' profile --> <socket-binding name="ajp" port="8009"/> <socket-binding name="http" port="8080"/> <socket-binding name="https" port="8443"/> <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/> <socket-binding name="jgroups-tcp" port="7600"/> <socket-binding name="jgroups-tcp-fd" port="57600"/> <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/> <socket-binding name="jgroups-udp-fd" port="54200"/> <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/> <socket-binding name="osgi-http" interface="management" port="8090"/> <socket-binding name="remoting" port="4447"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> <socket-binding-group name="full-sockets" default-interface="public"> <!-- Needed for server groups using the 'full' profile --> <socket-binding name="ajp" port="8009"/> <socket-binding name="http" port="8080"/> <socket-binding name="https" port="8443"/> <socket-binding name="jacorb" interface="unsecure" port="3528"/> <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/> <socket-binding name="messaging" port="5445"/> <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/> <socket-binding name="messaging-throughput" port="5455"/> <socket-binding name="osgi-http" interface="management" port="8090"/> <socket-binding name="remoting" port="4447"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> <socket-binding-group name="full-ha-sockets" default-interface="public"> <!-- Needed for server groups using the 'full-ha' profile --> <socket-binding name="ajp" port="8009"/> <socket-binding name="http" port="8080"/> <socket-binding name="https" port="8443"/> <socket-binding name="jacorb" interface="unsecure" port="3528"/> <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/> <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/> <socket-binding name="jgroups-tcp" port="7600"/> <socket-binding name="jgroups-tcp-fd" port="57600"/> <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/> <socket-binding name="jgroups-udp-fd" port="54200"/> <socket-binding name="messaging" port="5445"/> <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/> <socket-binding name="messaging-throughput" port="5455"/> <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/> <socket-binding name="osgi-http" interface="management" port="8090"/> <socket-binding name="remoting" port="4447"/> <socket-binding name="txn-recovery-environment" port="4712"/> <socket-binding name="txn-status-manager" port="4713"/> <outbound-socket-binding name="mail-smtp"> <remote-destination host="localhost" port="25"/> </outbound-socket-binding> </socket-binding-group> </socket-binding-groups>
standalone.xml
et domain.xml
du répertoire de l'application. La méthode recommandée pour gérer les liaisons consiste à utiliser la Console de gestion ou le Management CLI. Les avantages d'utiliser la Console de gestion est l'interface utilisateur graphique avec une écran de Groupe de liaisons de sockets dédié dans la section Configuration générale . Le Management CLI propose un API et un flux de travail basés ligne de commande qui permet le traitement par lots et l'utilisation de scripts aux niveaux supérieurs et inférieurs de la configuration de serveur d'applications. Les deux interfaces permettent la persistance des modifications ou bien leur enregistrement dans la configuration du serveur.
5.2.2. Configurer les liaisons de sockets
standard-sockets
, et ne peut pas créer de groupes supplémentaires. À la place, vous pouvez créer des fichiers de configuration de serveur autonome alternatif. Pour le domaine géré cependant, vous pouvez créer des groupes de liaisons de sockets et configurer les liaisons de socket qu'ils contiennent selon vos besoins. Le tableau suivant montre les attributs disponibles pour chaque liaison de sockets.
Tableau 5.2. Attributs de liaisons de sockets
Composant | Description | Rôle |
---|---|---|
Nom | Nom logique de la configuration de socket qui doit être utilisée ailleurs dans la configuration. | Requis |
Port | Port de base auquel un socket basé sur cette configuration doit être lié. Notez que les serveurs peuvent être configurés pour substituer cette valeur de base en appliquant une incrémentation ou décrémentation à toutes les valeurs de port. | Requis |
Interface | Nom logique de l'interface à laquelle un socket basé sur cette configuration doit être lié. Si non défini, la valeur de l'attribut "default-interface" du groupe de liaison de sockets enveloppant servira. | Option |
Adresse multi-diffusion | Si le socket doit être utilisé en multi-diffusion, c'est l'adresse multi-diffusion qu'il vous faut. | Option |
Port multi-diffusion | Lié au cycle de vie de la conversation. Le scope de la conversation correspond aux longueurs de la requête et de la session, et est contrôlé par l'application. | Option |
Port fixe | Si les contextes ne correspondent pas à vos besoins, vous pourrez définir des scopes personnalisés. | Option |
Configurer des liaisons de sockets dans des Groupes de liaisons de sockets
Sélectionner le Management CLI ou la Console de gestion pour configurer vos liaisons de sockets selon les besoins.Configurer les liaisons de sockets par le Management CLI
Sélectionner le Management CLI pour configurer les liaisons de sockets.Ajouter un nouvelle liaison de sockets
Utiliser l'opérationadd
(ajouter) pour créer une nouvelle configuration d'adresse si nécessaire. Vous pouvez exécuter cette commande à partir de la racine de la session de Management CLI, qui, dans l'exemple suivant, crée une nouvelle liaison de sockets intitulée newsocket, avec un attributport
déclaré comme 1234. Les exemples s'appliquent à la fois pour la modification des serveurs autonomes et des serveurs gérés sur la liaison de socketsstandard-sockets
comme montré ci-dessous.[domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)
Modifier les attributs de modèle
Utiliser l'opérationwrite-attribute
pour écrire une nouvelle valeur dans un attribut. Vous pouvez utiliser l'onglet de complétion pour aider à compléter la chaîne de commande que vous saisissez, et pour exposer les attributs disponibles. L'exemple suivant met à jour la valeurport
à 2020[domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)
Confirmer les attributs de modèle
Confirmer que les valeurs ont changé en exécutantread-resource
accompagné du paramètreinclude-runtime=true
pour exposer toutes les valeurs actives en cours du modèle de serveur.[domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource
Configurer les liaisons de sockets par la Console de gestion
Utiliser le Management CLI pour configurer les liaisons de sockets.Connectez-vous à la Console de gestion.
Connectez-vous à la Console de gestion de votre domaine géré ou de votre serveur autonome.Sélectionner le Profile tab
Sélectionner l'onglet Profiles en haut et à droite.Sélectionner l'élément Socket Binding à partir du menu de navigation.
Sélectionner l'élément de menu Socket Binding à partir du menu de navigation. Si vous utilisez un domaine géré, sélectionner le groupe désiré dans le menu Socket Binding Groups.Ajouter un nouvelle liaison de sockets
- Cliquer sur le bouton Add (ajouter).
- Saisir les valeurs qui conviennent pour les Name (Nom), Port (Port) et Binding Group (Groupe de liaisons).
- Cliquer sur le bouton Save pour terminer.
Modifier les attributs d'une interface
- Sélectionner la liaison de sockets à modifier et cliquer sur le bouton Edit.
- Saisir les valeurs qui conviennent pour les Name (Nom), Interface (Interface) etr Port (Port).
- Cliquer sur le bouton Save pour terminer.
5.2.3. Ports de réseau utilisés par JBoss EAP 6
- Le fait que vos groupes de serveurs utilisent le groupe de liaisons de sockets par défaut, ou un groupe de liaisons de sockets personnalisé.
- Des exigences de vos déploiements individuels.
Note
Groupes de liaison de socket par défaut
full-ha-sockets
full-sockets
ha-sockets
standard-sockets
Tableau 5.3. Référence aux Groupes de liaison de socket par défaut
Nom | Port | Port Multidiffusion | Description | full-ha-sockets | full-sockets | ha-socket | standard-socket |
---|---|---|---|---|---|---|---|
ajp | 8009 | Protocole Apache JServ. Utilisé pour le clustering HTTP et pour l'équilibrage des charges. | Oui | Oui | Oui | Oui | |
http | 8080 | Le port par défaut des applications déployées. | Oui | Oui | Oui | Oui | |
https | 8443 | Connexion cryptée-SSL entre les applications déployées et les clients. | Oui | Oui | Oui | Oui | |
jacorb | 3528 | Services CORBA pour les transactions JTS et autres services dépendants-ORB. | Oui | Oui | Non | Non | |
jacorb-ssl | 3529 | Services CORBA cryptés-SSL. | Oui | Oui | Non | Non | |
jgroups-diagnostics | 7500 | Multidiffusion. Utilisé pour découverte de pair dans les groupements HA. Non configurable par les Interfaces de gestion. | Oui | Non | Oui | Non | |
jgroups-mping | 45700 | Multicast. Utilisé pour découvrir l'appartenance de groupe d'origine dans un cluster HA. | Oui | Non | Oui | Non | |
jgroups-tcp | 7600 | Découverte de pairs unicast dans les groupements HA avec TCP. | Oui | Non | Oui | Non | |
jgroups-tcp-fd | 57600 | Utilisé pour la détection des échecs en TCP. | Oui | Non | Oui | Non | |
jgroups-udp | 55200 | 45688 | Découverte de pairs unicast dans les groupements HA avec UDP. | Oui | Non | Oui | Non |
jgroups-udp-fd | 54200 | Utilisé pour la détection des échecs par UDP. | Oui | Non | Oui | Non | |
messaging | 5445 | Service JMS. | Oui | Oui | Non | Non | |
messaging-group | Référencé par la diffusion HornetQ JMS et les groupes Discovery | Oui | Oui | Non | Non | ||
messaging-throughput | 5455 | Utilisé par JMS à distance. | Oui | Oui | Non | Non | |
mod_cluster | 23364 | Port multidiffusion pour la communication entre JBoss EAP 6 et l'équilibreur de charges HTTP. | Oui | Non | Oui | Non | |
osgi-http | 8090 | Utilisé par les composants internes qui utilisent le sous-système OSGi. Non configurable par les Interfaces de gestion. | Oui | Oui | Oui | Oui | |
remoting | 4447 | Utilisé pour l'invocation EJB. | Oui | Oui | Oui | Oui | |
txn-recovery-environment | 4712 | Gestionnaire de recouvrement des transactions JTA. | Oui | Oui | Oui | Oui | |
txn-status-manager | 4713 | Gestionnaire des transactions JTA / JTS. | Oui | Oui | Oui | Oui |
En plus des groupes de liaisons de socket, chaque contrôleur d'hôte ouvre deux ports supplémentaires pour la gestion :
- 9990 - Le port de Console de gestion
- 9999 - Le port utilisé par la Console de gestion et par le Management API
5.2.4. Valeurs de décalage des ports pour les Groupes de liaison de sockets par défaut
5.2.5. Configurer les Port Offset (valeurs de décalages de ports)
Configurer les Port Offset (valeurs de décalages de ports)
Sélectionner le Management CLI ou la Console de gestion pour configurer vos ports offsets.Configurer Port Offsets par le Management CLI
Sélectionner le Management CLI pour configurer vos ports offsets.Modifier les Ports Offsets
Utiliser l'opérationwrite-attribut
pour écrire une nouvelle valeur référence de port. L'exemple suivant met à jour la valeur dusocket-binding-port-offset
de server-two à 250. Ce serveur est membre du groupe hôte local par défaut. Un redémarrage est nécessaire pour que les modifications puissent prendre effet.[domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)
Confirmer les attributs de Port Offset
Confirmer que les valeurs ont changé en exécutantread-resource
accompagné du paramètreinclude-runtime=true
pour exposer toutes les valeurs actives en cours du modèle de serveur.[domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)
Configurer Port Offsets par la Console de Management
Sélectionner la Console de Management pour configurer vos ports offsets.Connectez-vous à la Console de gestion.
Connectez-vous à la Console de gestion de votre domaine géré.Sélectionner l'onglet Hosts
Sélectionner l'onglet Hosts en haut et à droite.Modifier les attributs de Port Offset
- Sélectionner le serveur dans la section
Configuration Name
et cliquer sur le bouton Edit. - Saisir les valeurs que vous désirez dans le champ Port Offset.
- Cliquer sur le bouton Save pour terminer.
5.3. IPv6
5.3.1. Configurer les Préférences de JVM Stack d'IPv6 Networking
- Résumé
- Cette section couvre l'activation du réseau IPv6 de l'installation JBoss EAP 6
Procédure 5.1. Désactiver la propriété IPv4 Stack Java
- Ouvrir le fichier qui convient à l'installation :
Pour le serveur autonome :
OuvrirEAP_HOME/bin/standalone.conf
.Pour un domaine géré :
OuvrirEAP_HOME/bin/domain.conf
.
- Modifier la propriété IPv4 Stack Java à false :
-Djava.net.preferIPv4Stack=false
Par exemple :# Specify options to pass to the Java VM. # if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true" fi
5.3.2. Configurer les déclarations d'interface du réseautage IPv6
Suivre ces étapes de configuration de l'adresse inet d'interface dans IPv6 par défaut:
Prérequis
Procédure 5.2. Configurer l'interface du réseautage IPv6
- Cliquer sur l'onglet Profile qui se trouve en haut et à droite de la console.
- Sélectionner l'option Interfaces qui se trouve sous General Configuration.
- Sélectionner l'interface réseau nommée à configurer.
- Cliquer sur le bouton Edit.
- Définir l'adresse inet à :
${jboss.bind.address.management:[ADDRESS]}
- Cliquez sur le bouton Enregistrer pour enregistrer les modifications.
- Démarrer le serveur à nouveau pour implémenter les changements.
5.3.3. Configurer les Préférences JVM Stacks des adresses IPv6
- Résumé
- Cette rubrique couvre la configuration de l'installation de JBoss EAP 6 pour qu'elle préfère les adresses IPv6 dans les fichiers de configuration.
Procédure 5.3. Configuration de l'installation JBoss EAP 6 pour qu'elle préfère les adresses IPv6
- Ouvrir le fichier qui convient à l'installation :
Pour le serveur autonome :
OuvrirEAP_HOME/bin/standalone.conf
.Pour un domaine géré :
OuvrirEAP_HOME/bin/domain.conf
.
- Ajouter la propriété Java suivante aux options de la Java VM
-Djava.net.preferIPv6Addresses=true
Par exemple :# Specify options to pass to the Java VM. # if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true" fi
Chapitre 6. Gestion des sources de données
6.1. Introduction
6.1.1. JDBC
6.1.2. Bases de données supportées par JBoss EAP 6
6.1.3. Types de sources de données
les sources de données
et les sources de données XA
.
6.1.4. L'exemple de source de données
Avertissement
6.1.5. Déploiement des fichiers -ds.xml
*-ds.xml
était requis dans le répertoire de déploiement de la configuration du serveur. Les fichiers *-ds.xml
peuvent toujours être déployés dans JBoss EAP 6, suivant le schéma de sources de données 1.1 disponible sous Schemas : http://www.ironjacamar.org/documentation.html.
Avertissement
Important
*-ds.xml
.
6.2. Pilotes JDBC
6.2.1. Installer un pilote JDBC avec la console de gestion
Avant que votre application puisse se connecter à une source de données JDBC, vos pilotes JDBC du fournisseur de votre source de données doivent être installés dans un endroit où JBoss EAP 6 puisse les utiliser. JBoss EAP 6 vous permettra de déployer ces pilotes comme tout autre déploiement. Cela signifie que vous pouvez les déployer sur plusieurs serveurs dans un groupe de serveurs, si vous utilisez un domaine géré.
Note
Vous devrez remplir les conditions suivantes avant de pouvoir effectuer cette tâche :
- Télécharger le pilote JDBC de votre fournisseur de base de données.
Procédure 6.1. Déployer le pilote JDBC
Accéder à la console de gestion
Déployez le fichier JAR dans votre serveur ou groupe de serveurs.
Si vous utilisez un domaine géré, déployez le fichier JAR dans un groupe de serveurs. Sinon, déployez-le sur votre serveur. Voir Section 9.2.2, « Déployer une application par la Console de gestion ».
Le pilote JDBC est déployé, et est disponible pour vos applications.
6.2.2. Installer un pilote JDBC comme core module
Vous devrez remplir les conditions suivantes avant de pouvoir effectuer cette tâche :
- Télécharger le pilote JDBC de votre base de données fournisseur. Voici les adresses de téléchargement pour le pilote JDBC : Section 6.2.3, « Adresses des téléchargements de pilotes JDBC ».
- En extraire l'archive
Procédure 6.2. Installer un pilote JDBC comme core module
- Créer une structure de chemin d'accès de fichier sous le répertoire
EAP_HOME/modules/
. Ainsi, pour un pilote MySQL JDBC, créer une structure de répertoire comme suit :EAP_HOME/modules/com/mysql/main/
. - Copier le pilote JDBC dans le sous-répertoire
main/
. - Dans le sous-répertoire
main/
, créer un fichiermodule.xml
ressemblant à l'exemple qui se trouve Section 7.1.1, « Modules ». Lemodule
XSD est défini dans le fichierEAP_HOME/docs/schema/module-1_2.xsd
. - Démarrer le serveur.
- Démarrer l'interface CLI.
- Exécuter la commande CLI suivante pour ajouter le module de pilote JDBC comme pilote :
/subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)
Exemple 6.1. Exemple de Commande CLI
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
Le pilote JDBC est maintenant installé et configuré comme core module. Il est maintenant prêt à être référencé par les sources de données d'application.
6.2.3. Adresses des téléchargements de pilotes JDBC
Tableau 6.1. Adresses des téléchargements du pilote JDBC
Fournisseur | Adresse de téléchargement |
---|---|
MySQL | |
PostgreSQL | |
Oracle | |
IBM | |
Sybase | |
Microsoft |
6.2.4. Accès aux Classes Spécifiques du fournisseur
Cette section couvre les étapes à suivre pour utiliser les classes spécifiques JDBC. Cela est utile quand une application a besoin d'utiliser une fonctionnalité spécifique à un fournisseur ne faisant pas partie de l'API JDBC.
Avertissement
Important
Important
Procédure 6.3. Ajouter une dépendance à l'application
Configurer le fichier
MANIFEST.MF
- Ouvrir le fichier
META-INF/MANIFEST.MF
de l'application dans un éditeur de texte. - Ajouter une dépendance au module JDBC et sauvegarder le fichier.
Dépendences : MODULE_NAME
Exemple 6.2. Exemple de dépendance
Dépendences: com.mysql
Créer un fichier
jboss-deployment-structure.xml
Créer un fichierjboss-deployment-structure.xml
dans le dossierMETA-INF/
ouWEB-INF
de l'application.Exemple 6.3. Exemple de fichier
jboss-deployment-structure.xml
<jboss-deployment-structure> <deployment> <dependencies> <module name="com.mysql" /> </dependencies> </deployment> </jboss-deployment-structure>
Exemple 6.4. Accède à l'API spécifique du fournisseur
import java.sql.Connection; import org.jboss.jca.adapters.jdbc.WrappedConnection; Connection c = ds.getConnection(); WrappedConnection wc = (WrappedConnection)c; com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();
6.3. Sources de données non-XA
6.3.1. Créer une source de données Non-XA avec les Interfaces de gestion
Cette section explique les étapes à suivre pour créer une source de données non-XA, en utilisant la Console de gestion ou le Management CLI.
Prérequis
- Le serveur JBoss EAP 6 doit être en cours d'exécution
Note
Procédure 6.4. Créer une Source de données par le Management CLI ou la Console de gestion
Management CLI
- Lancer l'outil CLI et connectez-vous à votre serveur.
- Exécuter la commande suivante pour créer une source de données non-XA, et configurer les variables comme il se doit :
data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --connection-url=CONNECTION_URL
- Activer la source de données :
data-source enable --name=DATASOURCE_NAME
Console de gestion
- Connectez-vous à la Console de gestion.
Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion
Mode autonome
Sélectionner l'onglet Profile en haut de la console.Mode Domaine
- Sélectionner l'onglet Profiles en haut de la console.
- Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
- Étendre le menu Subsystems qui se trouve à gauche de la console.
- Sélectionner Connector → Datasources à partir du menu à gauche de la console.
Créer une nouvelle source de données
- Sélectionner le bouton Add qui se trouve en haut du panneau Datasources.
- Saisir les attributs de la nouvelle source de données de l'assistant Create Datasource et appuyez sur Next.
- Saisir les informations sur le pilote JDBC dans l'assistant Create Datasource et appuyez sur Next.
- Saisir les paramètres de connexion dans l'assistant Create Datasource et appuyez sur Done.
La source de données non-Xa a été ajoutée au serveur. Elle est maintenant visible dans le fichier standalone.xml
ou le fichier domain.xml
, ainsi que dans les interfaces de gestion.
6.3.2. Modifier une source de données Non-XA avec les Interfaces de gestion
Cette section explique les étapes à suivre pour modifier une source de données non-XA, en utilisant la Console de gestion ou le Management CLI.
Prérequis
Note
jta
soit défini à true
.
Procédure 6.5. Modifier une Source de données non-XA
Management CLI
- Utiliser la commande
write-attribute
pour configurer un attribut de source de données :/subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
- Charger à nouveau le serveur pour confirmer les changements :
:reload
Console de gestion
Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion
Mode autonome
Sélectionner l'onglet Profile en haut de la console.Mode Domaine
- Sélectionner l'onglet Profiles en haut de la console.
- Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
- Étendre le menu Subsystems qui se trouve à gauche de la console.
- Sélectionner Connector → Datasources à partir du menu à gauche de la console.
Modifier la source de données
- Sélectionner la source de données qui convient à partir de la liste Available Datasources. Les attributs de la source de données sont affichés dans le panneau Attributes ci-dessous.
- Sélectionner le bouton Edit pour modifier les attributs de la source de données.
- Modifier les attributs de la source de données et sélectionner le bouton Save quand c'est fait.
La source de données non-Xa a été configurée. Elle est maintenant visible dans le fichier standalone.xml
ou le fichier domain.xml
, ainsi que dans les interfaces de gestion.
- Pour créer une nouvelle source de données. voir : Section 6.3.1, « Créer une source de données Non-XA avec les Interfaces de gestion ».
- Pour supprimer la source de données, voir Section 6.3.3, « Supprimer une source de données Non-XA avec les Interfaces de gestion ».
6.3.3. Supprimer une source de données Non-XA avec les Interfaces de gestion
Ce sujet couvre les étapes requises pour supprimer une source de données non-XA de JBoss EAP 6, en utilisant la Console de gestion ou le Management CLI.
Prérequis
Procédure 6.6. Supprimer un source de données non-XA
Management CLI
- Exécuter la commande suivante pour supprimer une source de données non-XA :
data-source remove --name=DATASOURCE_NAME
Console de gestion
Naviguer dans le panneau Datasources qui se trouve dans la Console de gestion
Mode autonome
Sélectionner l'onglet Profile en haut de la console.Mode Domaine
- Sélectionner l'onglet Profiles en haut de la console.
- Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
- Étendre le menu Subsystems qui se trouve à gauche de la console.
- Sélectionner Connector → Datasources à partir du menu à gauche de la console.
- Sélectionner la source de données enregistrée à supprimer, et cliquer sur le bouton Remove qui se trouve en haut et à droite de la console.
La source de données non-XA a été supprimée dans le serveur.
- Pour créer une nouvelle source de données, voir : Section 6.3.1, « Créer une source de données Non-XA avec les Interfaces de gestion ».
6.4. Sources de données XA
6.4.1. Créer une source de données XA avec les Interfaces de gestion
Conditions préalables :
Cette section explique les étapes à suivre pour créer une source de données XA, en utilisant la Console de gestion ou le Management CLI.
Note
Procédure 6.7. Créer une source de données XA en utilisant le Management CLI ou la Console de gestion
Management CLI
- Exécuter la commande suivante pour créer une source de données XA, et configurer les variables comme il se doit:
xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS
Configurer les propriétés de la source de données XA
Définir le nom du serveur
Exécuter la commande suivante pour configurer le nom du serveur de l'hôte :/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOSTNAME)
Définir le nom de la base de données
Exécuter la commande suivante pour configurer le nom de la base de données :/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)
- Activer la source de données :
xa-data-source enable --name=XA_DATASOURCE_NAME
Console de gestion
Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion
Mode autonome
Sélectionner l'onglet Profile en haut de la console.Mode Domaine
- Sélectionner l'onglet Profiles en haut de la console.
- Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
- Étendre le menu Subsystems qui se trouve à gauche de la console.
- Sélectionner Connector → Datasources à partir du menu à gauche de la console.
- Sélectionner l'onglet XA Datasource.
Créer une nouvelle source de données XA
- Sélectionner le bouton Add qui se trouve en haut du panneau Datasources.
- Saisir les attributs de la nouvelle source de données XA de l'assistant Create XA Datasource et appuyez sur Next.
- Saisir les informations sur le pilote JDBC dans l'assistant Create XA Datasource et appuyez sur Next.
- Modifier les propriétés et appuyer sur Next.
- Saisir les paramètres de connexion dans l'assistant Create XA Datasource et appuyer sur Done.
La source de données XA a été ajoutée au serveur. Elle est maintenant visible dans le fichier standalone.xml
ou le fichier domain.xml
, ainsi que dans les interfaces de gestion.
Voir également :
6.4.2. Modifier une base de données XA par les interfaces de gestion
Cette section explique les étapes à suivre pour modifier une source de données XA, en utilisant la Console de gestion ou le Management CLI.
Prérequis
Procédure 6.8. Modifier une source de données XA en utilisant le Management CLI ou la Console de gestion
Management CLI
Configurer les attributs de source de données XA
Utiliser la commandewrite-attribute
pour configurer un attribut de source de données :/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
Configurer les propriétés de la source de données XA
Exécuter la commande suivante pour configurer une sous-ressource de source de données XA :/subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)
- Charger à nouveau le serveur pour confirmer les changements :
:reload
Console de gestion
Naviguez dans le panneau Datasources qui se trouve dans la Console de gestion
Mode autonome
Sélectionner l'onglet Profile en haut de la console.Mode Domaine
- Sélectionner l'onglet Profiles en haut de la console.
- Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
- Étendre le menu Subsystems qui se trouve à gauche de la console.
- Sélectionner Connector → Datasources à partir du menu à gauche de la console.
- Sélectionner l'onglet XA Datasource.
Modifier la source de données
- Sélectionner la source de données XA qui convient à partir de la liste Available XA Datasources. Les attributs de la source de données XA sont affichés dans le panneau Attributes ci-dessous.
- Sélectionner le bouton Edit pour modifier les attributs de la source de données.
- Modifier les attributs de la source de données XA et sélectionner le bouton Save quand c'est fait.
La source de données XA a été configurée. Les changements sont maintenant visibles dans le fichier standalone.xml
ou le fichier domain.xml
, ainsi que dans les interfaces de gestion.
- Pour créer une nouvelle source de données, voir : Section 6.4.1, « Créer une source de données XA avec les Interfaces de gestion ».
- Pour supprimer la source de données, voir Section 6.4.3, « Supprimer une source de données XA avec les Interfaces de gestion ».
6.4.3. Supprimer une source de données XA avec les Interfaces de gestion
Ce sujet couvre les étapes requises pour supprimer une source de données XA de JBoss EAP 6, en utilisant la Console de gestion ou le Management CLI.
Prérequis
Procédure 6.9. Supprimer une source de données XA en utilisant le Management CLI ou la Console de gestion
Management CLI
- Exécuter la commande suivante pour supprimer une source de données :
xa-data-source remove --name=XA_DATASOURCE_NAME
Console de gestion
Naviguer dans le panneau Datasources qui se trouve dans la Console de gestion
Mode autonome
Sélectionner l'onglet Profile en haut de la console.Mode Domaine
- Sélectionner l'onglet Profiles en haut de la console.
- Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
- Étendre le menu Subsystems qui se trouve à gauche de la console.
- Sélectionner Connector → Datasources à partir du menu à gauche de la console.
- Sélectionner l'onglet XA Datasource.
- Sélectionner la source de données XA enregistrée à supprimer, et cliquer sur le bouton Remove qui se trouve en haut et à droite de la console.
La source de données XA a été supprimée dans le serveur.
- Pour ajouter une nouvelle source de données, voir : Section 6.4.1, « Créer une source de données XA avec les Interfaces de gestion ».
6.4.4. XA Recovery
6.4.4.1. Les modules de recouvrement XA
com.arjuna.ats.jta.recovery.XAResourceRecovery
.
6.4.4.2. Configurer les modules de recouvrement
Tableau 6.2. Attributs de configuration générale
Attribut | Description |
---|---|
recovery-username |
Le nom d'utilisateur qui doit être utilisé par le module de recouvrement pour se connecter à la ressource de recouvrement.
|
recovery-password |
Le mot de passe qui doit être utilisé par le module de recouvrement pour se connecter à la ressource de recouvrement.
|
recovery-security-domain |
Le domaine de sécurité qui doit être utilisé par le module de recouvrement pour se connecter à la ressource de recouvrement.
|
recovery-plugin-class-name |
Si vous devez utiliser un module de recouvrement personnalisé, définissez cet attribut au nom complet de classe du module. Le module doit étendre la classe
com.arjuna.ats.jta.recovery.XAResourceRecovery .
|
recovery-plugin-properties |
Si vous utilisez un module de récupération personnalisée qui requiert des propriétés à définir, définissez cet attribut à la liste de paires key=value séparée par des virgules pour les propriétés.
|
Informations de configuration spécifiques au fournisseur
- Oracle
- Si la source de données Oracle n'est pas configurée correctement, vous apercevrez sans doute les erreurs suivantes dans votre sortie de journalisation :
WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
Pour résoudre cette erreur, veillez à ce que l'utilisateur Oracle configuré dansrecovery-username
ait bien accès aux tableaux utiles au recouvrement. L'énoncé SQL suivant affiche les attributions d'instances correctes Oracle 11g ou Oracle 10g R2 corrigées pour le bogue 5945463 d'Oracle.GRANT SELECT ON sys.dba_pending_transactions TO recovery-username; GRANT SELECT ON sys.pending_trans$ TO recovery-username; GRANT SELECT ON sys.dba_2pc_pending TO recovery-username; GRANT EXECUTE ON sys.dbms_xa TO recovery-username;
Si vous utilisez une version Oracle 11g antérieure à 11g, modifier l'énoncé finalEXECUTE
ainsi:GRANT EXECUTE ON sys.dbms_system TO recovery-username;
- PostgreSQL
- Voir la documentation PostgreSQL pour obtenir des instructions sur la façon d'activer des transactions (ex. XA) préparées. La version 8.4-701 du pilote JDBC de PostgreSQL a un bogue dans
org.postgresql.xa.PGXAConnection
qui empêche le recouvrement dans certaines situations. Cela a été résolu dans les nouvelles versions. - MySQL
- Basé sur http://bugs.mysql.com/bug.php?id=12161, le recouvrement de transactions XA ne fonctionnait pas dans certaines versions de MySQL 5. Cela a été corrigé dans MySQL 6.1. Voir l'URL du bogue ou la documentation MySQL pour obtenir davantage d'informations.
- IBM DB2
- IBM DB2 s'attend à ce que la méthode
XAResource.recover
soit appelée uniquement pendant la phase de resynchronisation désignée qui se produit lorsque le serveur d'applications est redémarré après un accident ou une panne. Il s'agit d'une décision de conception pour l'implémentation de DB2, qui est en dehors du dessein de cette documentation.
6.5. Sécurité des bases de données
6.5.1. Sécurité des bases de données
- Domaines de sécurité : Section 10.6.1, « Les domaines de sécurité ».
Exemple 6.5. Exemple de domaine de sécurité
<security> <security-domain>mySecurityDomain</security-domain> </security>
Exemple 6.6. Exemple de mots de passe
<security> <user-name>admin</user-name> <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password> </security>
6.6. Configuration des sources de données
6.6.1. Paramètres de source de données
Tableau 6.3. Les paramètres de source de données communs aux sources XA ou non-XA
Paramètre | Description |
---|---|
jndi-name | Le nom JNDI unique pour la source de données. |
pool-name | Le nom du pool de gestion de la source de données. |
activé | Indique si la source de données est activée. |
use-java-context |
Indique si on doit relier la source de données au JNDI global.
|
spy |
Activer la fonctionnalité
spy sur la couche JDBC. Cela journalisera tout le trafic JDBC dans la source de données. Le paramètre logging-category doit également être défini à org.jboss.jdbc .
|
use-ccm | Activer le gestionnaire de connexion cache. |
new-connection-sql | Un énoncé SQL qui exécute quand la connexion est ajoutée au pool de connexion. |
transaction-isolation |
Un parmi :
|
url-delimiter | Le délimiteur d'URLs d'une connexion url pour les bases de données clusterisées HA (Haute disponibilité). |
url-selector-strategy-class-name | Une classe qui implémente l'interface org.jboss.jca.adapters.jdbc.URLSelectorStrategy . |
sécurité |
Contient des éléments dépendants en tant que paramètres de sécurité. Voir Tableau 6.8, « Paramètres de sécurité ».
|
validation |
Contient des éléments dépendants en tant que paramètres de validation. Voir Tableau 6.9, « Paramètres de validation ».
|
timeout |
Contient des éléments dépendants en tant que paramètres de timeout. Voir Tableau 6.10, « Paramètres de timeout ».
|
énoncé |
Contient des éléments dépendants en tant que paramètres d'énoncés. Voir Tableau 6.11, « Paramètres d'instruction ».
|
Tableau 6.4. Paramètres de source de données non-xa
Paramètre | Description |
---|---|
jta | Active l'intégration JTA pour les sources de données non-XA. Ne s'applique pas aux sources de données XA. |
connection-url | L'URL de connexion du pilote JDBC. |
driver-class | Le nom complet de la classe de pilote JDBC. |
connection-property |
Propriétés de connexions arbitraires passées à la méthode
Driver.connect(url,props) . Chaque connection-property indique une paire name/value. Le nom de la propriété provient du nom, et la valeur provient du contenu de l'élément.
|
pool |
Contient des éléments dépendants en tant que paramètres de pooling. Voir Tableau 6.6, « Les paramètres de pool communs aux sources XA ou non-XA ».
|
Tableau 6.5. Paramètres de source de données XA
Paramètre | Description |
---|---|
xa-datasource-property |
Une propriété pour assigner la classe d'implémentation
XADataSource . Spécifiée par name=value. Si une méthode setter existe, dans le format setName , la propriété sera définie en appelant une méthode setter sous le format setName(value) .
|
xa-datasource-class |
Le nom complet de la classe d'implémentation de
javax.sql.XADataSource .
|
pilote |
Unique référence au module de chargeur de classe qui contient le pilote JDBC. Le format accepté est driverName#majorVersion.minorVersion.
|
xa-pool |
Contient des éléments dépendants en tant que paramètres de pooling. Voir Tableau 6.6, « Les paramètres de pool communs aux sources XA ou non-XA » et Tableau 6.7, « Paramètres du pool XA »
|
recouvrement |
Contient des éléments dépendants en tant que paramètres de recouvrement. Voir Tableau 6.12, « Paramètres de recouvrement ».
|
Tableau 6.6. Les paramètres de pool communs aux sources XA ou non-XA
Paramètre | Description |
---|---|
min-pool-size | Le nombre minimum de connexions contenues par un pool. |
max-pool-size | Le nombre maximum de connexions qu'un pool peut contenir |
Pré-remplissage | Indique si l'on doit essayer de pré-remplir un pool de connexion. Un élément vide indique une valeur true . La valeur par défaut est false . |
use-strict-min | Indique si la taille du pool est stricte. false par défaut. |
flush-strategy |
Indique si le pool est vidé en cas d'erreur. Les valeurs acceptées sont :
La valeur par défaut est
FailingConnectionOnly .
|
allow-multiple-users | Indique si plusieurs utilisateurs pourront avoir accès à la source de données par la méthode getConnection(user, password), et si les types de pools internes ont une influence sur ce comportement. |
Tableau 6.7. Paramètres du pool XA
Paramètre | Description |
---|---|
is-same-rm-override | Indique si la classe javax.transaction.xa.XAResource.isSameRM(XAResource) retourne true ou false . |
entrelacement | Indique si on doit activer l'entrelacement pour les fabriques de connexion XA. |
no-tx-separate-pools | Indique si on doit créer des sous-répertoires distincts pour chaque contexte. Cela est nécessaire pour les sources de données Oracle, qui ne permettent pas aux connexions XA d'être utilisées à la fois à l'intérieur et à l'extérieur d'une transaction de JTA |
pad-xid | Indique si on doit remplir le Xid. |
wrap-xa-resource |
Indique si on doit inclure XAResource dans une instance
org.jboss.tm.XAResourceWrapper .
|
Tableau 6.8. Paramètres de sécurité
Paramètre | Description |
---|---|
user-name | Le nom d'utilisation pour créer une nouvelle connexion. |
mot de passe | Le mot de passe à utiliser pour créer une nouvelle connexion |
security-domain | Contient le nom d'un gestionnaire de sécurité JAAS, qui gère l'authentification. Ce nom correspond à l'attribut application-policy/name de la configuration de connexion JAAS. |
reauth-plugin | Définit un plugin d'authentification à nouveau pour la ré authentification de connexions physiques. |
Tableau 6.9. Paramètres de validation
Paramètre | Description |
---|---|
valid-connection-checker |
Une mise en œuvre d'interface
org.jboss.jca.adaptors.jdbc.ValidConnectionChecker qui fournit une méthode SQLException.isValidConnection(Connection e) pour valider une connexion. Une exception signifie que la connexion est détruite. Cela remplace le paramètre check-valid-connection-sql s'il est présent.
|
check-valid-connection-sql | Un énoncé SQL pour vérifier la validité d'un pool de connexion. Peut être appelé quand une connexion gérée est tirée d'un pool. |
validate-on-match |
Indique si la validation de niveau de connexion est exécutée lorsqu'une fabrique de connexions essaie de correspondre à une connexion gérée pour un ensemble donné.
Spécifier « true » pour
Validate-on-match n'est généralement pas effectué conjointement avec la spécification « true » de background-validation . Validate-on-match est nécessaire lorsqu'un client doit avoir une connexion validée avant l'utilisation. Ce paramètre est true par défaut.
|
background-validation |
Indique que les connexions sont validées sur un thread d'arrière-plan. La validation de l'arrière-plan (Background validation) est une optimisation de performance lorsque non utilisé avec
validate-on-match . Si Validate-on-match est sur true, l'utilisation de background-validation pourrait entraîner des contrôles redondants. La validation de l'arrière-plan pourrait provoquer une mauvaise connexion (une connexion qui irait mal entre le moment de l'analyse de validation et avant d'être donnée au client), l'application cliente doit par conséquent tenir compte de cette possibilité.
|
background-validation-millis | La durée, en millisecondes, pendant laquelle la validation d'arrière-plan exécute. |
use-fast-fail |
Si défini sur true, échoue une allocation de connexion lors de la première tentative, si la connexion est non valide. La valeur par défaut est
false .
|
stale-connection-checker |
Une instance de
org.jboss.jca.adapters.jdbc.StaleConnectionChecker qui produit une méthode booléenne isStaleConnection(SQLException e) . Si cette méthode renvoie un true , l'exception sera contenue dans org.jboss.jca.adapters.jdbc.StaleConnectionException , qui correspond à une sous-classe de SQLException .
|
exception-sorter |
Une instance de
org.jboss.jca.adapters.jdbc.ExceptionSorter qui fournit une méthode booléenne isExceptionFatal(SQLException e) . Cette méthode validera si une exception est envoyée à toutes les instances d'un javax.resource.spi.ConnectionEventListener en tant que message connectionErrorOccurred .
|
Tableau 6.10. Paramètres de timeout
Paramètre | Description |
---|---|
use-try-lock | Utiliser tryLock() au lieu de lock() . Vous essayerez ainsi d'obtenir un verrou pour le nombre de secondes configurées, avant le timeout, au lieu d'échouer immédiatement quand le verrou n'est pas disponible. La valeur par défaut est de 60 secondes. Par exemple, pour définir un timeout de 5 minutes, définir <use-try-lock> 300</use-try-lock> . |
blocking-timeout-millis | La durée maximale, en millisecondes, de blocage lorsque vous attendez une connexion. Après que ce délai soit dépassé, une exception sera levée. Cela bloque uniquement pendant que vous attendez un permis de connexion et ne lève pas d'exception si la création d'une nouvelle connexion prend beaucoup de temps. Par défaut, 30000, qui correspond à 30 secondes. |
idle-timeout-minutes |
La durée maximale, en minutes, avant qu'une connexion inactive soit fermée. La durée maximale réelle dépend de la durée d'analyse de l'idleRemover, qui correspond à la moitié du plus petit
idle-timeout-minutes de n'importe quel pool.
|
set-tx-query-timeout |
Indique si on doit définir le timeout d'interrogation par rapport au temps qui reste avant le timeout de transaction. Si aucune transaction n'existe, on utilisera le timeout de recherche qui a été configuré. La valeur par défaut est
false .
|
query-timeout | Timeout pour les recherches, en secondes. La valeur par défaut est « no timeout ». |
allocation-retry | Le nombre de tentatives de connexion avant d'envoyer une connexion. La valeur par défaut est 0 , pour qu'une exception puisse être envoyée à la première défaillance. |
allocation-retry-wait-millis |
Le temps, en millisecondes, qu'il faut attendre avant de retenter d'allouer une connexion. La valeur par défaut est 5 000, soit 5 secondes.
|
xa-resource-timeout |
Si la valeur est non nulle, elle passe à la méthode
XAResource.setTransactionTimeout .
|
Tableau 6.11. Paramètres d'instruction
Paramètre | Description |
---|---|
track-statements |
Indique si l'on doit vérifier les instructions non fermées lorsqu'une connexion est renvoyée à un pool ou qu'une instruction est retournée dans le cache d'instruction préparée. Si false, les instructions ne seront pas suivies.
Valeurs valides
|
prepared-statement-cache-size | Le nombre d'instructions préparées par connexion, dans le cache LRU (le moins souvent utilisé récemment). |
share-prepared-statements |
Indique si le fait de demander la même instruction deux fois sans la fermer utilise la même instruction préparée sous-jacente. La valeur par défaut est
false .
|
Tableau 6.12. Paramètres de recouvrement
Paramètre | Description |
---|---|
recover-credential | Une paire nom d'utilisateur/mot de passe ou domaine de sécurité pour le recouvrement. |
recover-plugin |
Une mise en œuvre de la classe
org.jboss.jca.core.spi.recoveryRecoveryPlugin à utiliser pour le recouvrement.
|
6.6.2. Les URL de connexion de sources de données
Tableau 6.13.
Source de données | URL de connexion |
---|---|
PostgreSQL | jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME |
MySQL | jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME |
Oracle | jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID |
IBM DB2 | jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME |
Microsoft SQLServer | jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME |
6.6.3. Extensions de sources de données
Tableau 6.14. Extensions de sources de données
Extension de sources de données | Paramètre de configuration | Description |
---|---|---|
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter | <exception-sorter> | Vérifie si SQLException est fatal pour la connexion sur laquelle l'exception a été lancée |
org.jboss.jca.adapters.jdbc.spi.StaleConnection | <stale-connection-checker> | Wraps stale SQLExceptions in a org.jboss.jca.adapters.jdbc.StaleConnectionException |
org.jboss.jca.adapters.jdbc.spi.ValidConnection | <valid-connection-checker> | Vérifie si une connexion est valide pour être utilisée par l'application |
Implémentations des extensions
- Générique
- org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
- org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
- org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
- org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
- PostgreSQL
- org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
- org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
- MySQL
- org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
- org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
- org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
- IBM DB2
- org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
- org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
- org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
- Sybase
- org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
- org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
- Microsoft SQLServer
- org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
- Oracle
- org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
- org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
- org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
6.6.4. Voir les statistiques de sources de données
jdbc
et pool
qui utilisent des versions modifiées des commandes ci-dessous :
Procédure 6.10.
/subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
Note
include-runtime=true
et à ce que tous les statistiques soient en runtime uniquement et la valeur par défaut est false
.
6.6.5. Statistiques de bases de données
Le tableau suivant montre une liste des statistiques principaux de sources de données pris en charge :
Tableau 6.15. Statistiques principaux
Nom | Description |
---|---|
ActiveCount |
Le nombre de connexions actives. Chacune de ces connexions est soit utilisée par une application, ou disponible via pool
|
AvailableCount |
Le nombre de connexions disponibles dans le pool
|
AverageBlockingTime |
Le durée moyenne passée à bloquer l'obtention d'un verrou exclusif sur le pool. La valeur est en millisecondes.
|
AverageCreationTime |
Le durée moyenne passée à créer une connexion. La valeur est en millisecondes.
|
CreatedCount |
Le nombre de connexions créées.
|
DestroyedCount |
Le nombre de connexions détruites.
|
InUseCount |
Le nombre de connexions actuellement utilisées.
|
MaxCreationTime |
La durée maximum pour créer une connexion. La valeur est en millisecondes.
|
MaxUsedCount |
Le nombre maximum de connexions utilisées
|
MaxWaitCount |
Le nombre maximum de requêtes attendant une connexion en même temps.
|
MaxWaitTime |
Le durée maximum à attendre un verrou exclusif sur le pool.
|
TimedOut |
Le nombre de connexions expirées
|
TotalBlockingTime |
Le durée à attendre un verrou exclusif sur le pool. La valeur est en millisecondes.
|
TotalCreationTime |
La durée passée à créer des connexions. La valeur est en millisecondes.
|
WaitCount |
Le nombre de requêtes en attente de connexion.
|
Le tableau suivant montre une liste des statistiques JDBC de sources de données pris en charge :
Tableau 6.16. Statistiques JDBC
Nom | Description |
---|---|
PreparedStatementCacheAccessCount |
Le nombre de fois qu'un cache d'énoncé a été accédé.
|
PreparedStatementCacheAddCount |
Le nombre d'énoncés ajoutés au cache de l'énoncé.
|
PreparedStatementCacheCurrentSize |
Le nombre d'énoncés préparés et que l'on peut appeler, actuellement mis en cache dans un cache d'énoncé.
|
PreparedStatementCacheDeleteCount |
Le nombre d'énoncés rejetés du cache.
|
PreparedStatementCacheHitCount |
Le nombre de fois que des énoncés de cache ont été utilisés.
|
PreparedStatementCacheMissCount |
Le nombre de fois qu'une requête d'énoncé a pu être réglée par un énoncé d'un cache.
|
6.7. Exemples de sources de données
6.7.1. L'exemple de source de données PostgreSQL
Exemple 6.7.
<datasources> <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS"> <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url> <driver>postgresql</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter> </validation> </datasource> <drivers> <driver name="postgresql" module="org.postgresql"> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données PostgreSQL ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="org.postgresql"> <resources> <resource-root path="postgresql-9.1-902.jdbc4.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.2. Exemple de source de données PostgreSQL XA
Exemple 6.8.
<datasources> <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS"> <driver>postgresql</driver> <xa-datasource-property name="ServerName">localhost</xa-datasource-property> <xa-datasource-property name="PortNumber">5432</xa-datasource-property> <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"> </valid-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"> </exception-sorter> </validation> </xa-datasource> <drivers> <driver name="postgresql" module="org.postgresql"> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données PostgreSQL XA ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="org.postgresql"> <resources> <resource-root path="postgresql-9.1-902.jdbc4.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.3. Exemple de source de données MySQL
Exemple 6.9.
<datasources> <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS"> <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url> <driver>mysql</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter> </validation> </datasource> <drivers> <driver name="mysql" module="com.mysql"> <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données MySQL ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-5.0.8-bin.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.4. Exemple de source de données MySQL XA
Exemple 6.10.
<datasources> <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS"> <driver>mysql</driver> <xa-datasource-property name="ServerName">localhost</xa-datasource-property> <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter> </validation> </xa-datasource> <drivers> <driver name="mysql" module="com.mysql"> <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données MySQL XA ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-5.0.8-bin.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.5. L'exemple de source de données Oracle
Note
Exemple 6.11.
<datasources> <datasource jndi-name="java:/OracleDS" pool-name="OracleDS"> <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url> <driver>oracle</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter> </validation> </datasource> <drivers> <driver name="oracle" module="com.oracle"> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données Oracle ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.oracle"> <resources> <resource-root path="ojdbc6.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.6. Exemple de Source de données d'Oracle XA
Note
Important
user
est une valeur définir par l'utilisateur pour pouvoir se connecter à partir de JBoss à Oracle :
- GRANT SELECT ON sys.dba_pending_transactions TO user;
- GRANT SELECT ON sys.pending_trans$ TO user;
- GRANT SELECT ON sys.dba_2pc_pending TO user;
- GRANT EXECUTE ON sys.dbms_xa TO user; (If using Oracle 10g R2 (patched) or Oracle 11g)OUGRANT EXECUTE ON sys.dbms_system TO user; (If using an unpatched Oracle version prior to 11g)
Exemple 6.12.
<datasources> <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS"> <driver>oracle</driver> <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property> <security> <user-name>admin</user-name> <password>admin</password> </security> <xa-pool> <is-same-rm-override>false</is-same-rm-override> <no-tx-separate-pools /> </xa-pool> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter> </validation> </xa-datasource> <drivers> <driver name="oracle" module="com.oracle"> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données Oracle XA ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.oracle"> <resources> <resource-root path="ojdbc6.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.7. Exemple de source de données Microsoft SQLServer
Exemple 6.13.
<datasources> <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS"> <connection-url>jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url> <driver>sqlserver</driver> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker> </validation> </datasource> <drivers> <driver name="sqlserver" module="com.microsoft"> <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class> </driver> </datasources>
module.xml
pour la source de données Microsoft SQLServer ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.microsoft"> <resources> <resource-root path="sqljdbc4.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.8. Exemple de source de données Microsoft SQLServer XA
Exemple 6.14.
<datasources> <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS"> <driver>sqlserver</driver> <xa-datasource-property name="ServerName">localhost</xa-datasource-property> <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property> <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property> <security> <user-name>admin</user-name> <password>admin</password> </security> <xa-pool> <is-same-rm-override>false</is-same-rm-override> </xa-pool> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker> </validation> </xa-datasource> <drivers> <driver name="sqlserver" module="com.microsoft"> <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données Microsoft SQLServer XA ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.microsoft"> <resources> <resource-root path="sqljdbc4.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.9. Exemple de source de données IBM DB2
Exemple 6.15.
<datasources> <datasource jndi-name="java:/DB2DS" pool-name="DB2DS"> <connection-url>jdbc:db2:ibmdb2db</connection-url> <driver>ibmdb2</driver> <pool> <min-pool-size>0</min-pool-size> <max-pool-size>50</max-pool-size> </pool> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter> </validation> </datasource> <drivers> <driver name="ibmdb2" module="com.ibm"> <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données IBM DB2 ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.ibm"> <resources> <resource-root path="db2jcc.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.10. Exemple de source de données IBM DB2 XA
Exemple 6.16.
<datasources> <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS"> <driver>ibmdb2</driver> <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property> <security> <user-name>admin</user-name> <password>admin</password> </security> <xa-pool> <is-same-rm-override>false</is-same-rm-override> </xa-pool> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker> <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter> </validation> <recovery> <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin"> <config-property name="EnableIsValid">false</config-property> <config-property name="IsValidOverride">false</config-property> <config-property name="EnableClose">false</config-property> </recover-plugin> </recovery> </xa-datasource> <drivers> <driver name="ibmdb2" module="com.ibm"> <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données IBM DB2 XA ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.ibm"> <resources> <resource-root path="db2jcc.jar"/> <resource-root path="db2jcc_license_cisuz.jar"/> <resource-root path="db2jcc_license_cu.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.11. L'exemple de source de données Sybase
Exemple 6.17.
<datasources> <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true"> <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter> </validation> </datasource> <drivers> <driver name="sybase" module="com.sybase"> <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class> <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données Sybase ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.sybase"> <resources> <resource-root path="jconn2.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
6.7.12. L'exemple de source de données Sybase
Exemple 6.18.
<datasources> <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true"> <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property> <xa-datasource-property name="ServerName">myserver</xa-datasource-property> <xa-datasource-property name="PortNumber">4100</xa-datasource-property> <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property> <security> <user-name>admin</user-name> <password>admin</password> </security> <validation> <background-validation>true</background-validation> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter> </validation> </xa-datasource> <drivers> <driver name="sybase" module="com.sybase"> <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class> <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class> </driver> </drivers> </datasources>
module.xml
pour la source de données Sybase XA ci-dessus.
<module xmlns="urn:jboss:module:1.1" name="com.sybase"> <resources> <resource-root path="jconn2.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
Chapitre 7. Configuration des modules
7.1. Introduction
7.1.1. Modules
- Modules statiques
- Les modules statiques sont prédéfinis dans le répertoire
EAP_HOME/modules/
du serveur d'application. Chaque sous-répertoire représente un module et contient un ou plusieurs fichiers JAR et un fichier de configuration (module.xml
). Le nom de ce module est défini dans le fichiermodule.xml
. Toutes les API fournies par le serveur d'application sont fournies en tant que modules statiques, comme les API Java EE ainsi que d'autres API comme JBoss Logging.Exemple 7.1. Exemple de fichier module.xml
<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-5.1.15.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
Le nom du module,com.mysql
, doit correspondre à la structure du répertoire du module.La création de modules statiques personnalisés peut être utile si plusieurs applications sont déployées sur un même serveur utilisant les mêmes bibliothèques de tierce partie. Au lieu d'un regroupement de ces bibliothèques pour chaque application, un module contenant ces bibliothèques peut être créé et installé par l'administrateur JBoss. Les applications peuvent ensuite déclarer une dépendance explicite sur les modules statiques personnalisés. - Modules dynamiques
- Les modules dynamiques sont créés et chargés par le serveur d'application pour chaque déploiement JAR ou WAR (ou sous-déploiement d'un EAR). Le nom d'un module dynamique est dérivé du nom de l'archive déployée. Comme les déploiements sont chargés sous forme de modules, ils peuvent configurer des dépendances et peuvent être utilisés comme dépendances par d'autres déploiements.
7.1.2. Modules globaux
7.1.3. Les dépendances de modules
Exemple 7.2. Les dépendances de module
- Le Module A déclare une dépendance explicite sur le Module C, ou bien
- Le Module B exporte ses dépendances sur le Module C.
7.1.4. Isolement du chargeur de classes d'un sous-déploiement
7.2. Désactiver l'isolement de module de sous-déploiement pour tous les déploiements
Avertissement
Arrêter le serveur
Arrêter le serveur JBoss EAP.Ouvrir le fichier de configuration du serveur
Ouvrir le fichier de configuration du serveur dans un éditeur de texteCe fichier sera différent pour un domaine géré ou un serveur autonome. De plus, des emplacements et des noms de fichier non-défauts peuvent être utilisés. Les fichiers de configuration par défaut sontdomain/configuration/domain.xml
etstandalone/configuration/standalone.xml
pour les domaines gérés et les serveurs autonomes respectivement.Chercher la configuration de sous-système EE
Chercher la configuration de sous-système EE. L'élément<profile>
du fichier de configuration contient plusieurs éléments du sous-système. L'élément du sous-système a comme espace-nom deurn:jboss:domain:ee:1.0
.<profile> ... <subsystem xmlns="urn:jboss:domain:ee:1.0" /> ...
La configuration par défaut a une balise en fermeture automatique unique mais une configuration personnalisée peut avoir des balises d'ouverture ou de fermeture distinctes (éventuellement avec d'autres éléments à l'intérieur) comme ceci :<subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
Remplacer les balises en fermeture automatique si nécessaire
Si l'élément de sous-système EE est une balise en fermeture automatique unique, remplacez-la par les balises d'ouverture ou de fermeture qui conviennent ainsi :<subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
Ajouter l'élément ear-deployments-isolated
Ajouter l'élémentear-subdeployments-isolated
comme dépendant de l'élément du sous-système EE et ajouter le contenu defalse
comme suit :<subsystem xmlns="urn:jboss:domain:ee:1.0" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
Démarrer le serveur
Lancer à nouveau le serveur JBoss EAP pour qu'il commence à exécuter avec la nouvelle configuration.
Le serveur va maintenant exécuter avec l'isolement de module de sous-déploiement désactivé pour tous les déploiements.
7.3. Ajouter un module à tous les déploiements
Prérequis
- Vous devez connaître le nom des modules qui ont été ajoutés comme modules globaux. Voir Section 7.4.1, « Les modules inclus » pour obtenir la liste des modules statiques inclus dans JBoss EAP 6. Si le module est dans un autre déploiement, voir Section 7.4.2, « Nommage de modules dynamiques » pour déterminer le nom du module.
Procédure 7.1. Ajouter un module à la liste des modules globaux
- Connectez-vous à la console de gestion. Section 3.4.2, « Se conncecter à la console de gestion »
- Naviguez dans le panneau EE Subsystem.
Mode autonome
Sélectionner l'onglet Profile qui se trouve en haut de la console.Mode Domaine
- Sélectionner l'onglet Profiles qui se trouve en haut de la console.
- Sélectionner le profil qui convient à partir du menu déroulant en haut à gauche.
- Étendre le menu Subsystems qui se trouve à gauche de la console.
- Sélectionner Container → EE à partir du menu à gauche de la console.
- Cliquer sur le bouton Add dans la section Subsystem Defaults. La boîte de dialogue Create Module apparaîtra.
- Saisir alors le nom du module et le slot de module, en option.
- Cliquer sur le bouton Enregistrer pour ajouter le nouveau module global, ou bien cliquer sur le lien Annuler pour annuler.
- Si vous cliquez sur le bouton Enregistrer, la boîte de dialogue va se fermer et le module spécifié sera ajouté à la liste des modules globaux.
- Si vous cliquez sur le bouton Annuler, la boîte de dialogue se fermera et il n'y aura aucun changement.
Les modules ajoutés à la liste des modules globaux seront ajoutés en tant que dépendances à chaque déploiement.
7.4. Référence
7.4.1. Les modules inclus
asm.asm
ch.qos.cal10n
com.google.guava
com.h2database.h2
com.sun.jsf-impl
com.sun.jsf-impl
com.sun.xml.bind
com.sun.xml.messaging.saaj
gnu.getopt
javaee.api
javax.activation.api
javax.annotation.api
javax.api
javax.ejb.api
javax.el.api
javax.enterprise.api
javax.enterprise.deploy.api
javax.faces.api
javax.faces.api
javax.inject.api
javax.interceptor.api
javax.jms.api
javax.jws.api
javax.mail.api
javax.management.j2ee.api
javax.persistence.api
javax.resource.api
javax.rmi.api
javax.security.auth.message.api
javax.security.jacc.api
javax.servlet.api
javax.servlet.jsp.api
javax.servlet.jstl.api
javax.transaction.api
javax.validation.api
javax.ws.rs.api
javax.wsdl4j.api
javax.xml.bind.api
javax.xml.jaxp-provider
javax.xml.registry.api
javax.xml.rpc.api
javax.xml.soap.api
javax.xml.stream.api
javax.xml.ws.api
jline
net.sourceforge.cssparser
net.sourceforge.htmlunit
net.sourceforge.nekohtml
nu.xom
org.antlr
org.apache.ant
org.apache.commons.beanutils
org.apache.commons.cli
org.apache.commons.codec
org.apache.commons.collections
org.apache.commons.io
org.apache.commons.lang
org.apache.commons.logging
org.apache.commons.pool
org.apache.cxf
org.apache.httpcomponents
org.apache.james.mime4j
org.apache.log4j
org.apache.neethi
org.apache.santuario.xmlsec
org.apache.velocity
org.apache.ws.scout
org.apache.ws.security
org.apache.ws.xmlschema
org.apache.xalan
org.apache.xerces
org.apache.xml-resolver
org.codehaus.jackson.jackson-core-asl
org.codehaus.jackson.jackson-jaxrs
org.codehaus.jackson.jackson-mapper-asl
org.codehaus.jackson.jackson-xc
org.codehaus.woodstox
org.dom4j
org.hibernate
org.hibernate.envers
org.hibernate.infinispan
org.hibernate.validator
org.hornetq
org.hornetq.ra
org.infinispan
org.infinispan.cachestore.jdbc
org.infinispan.cachestore.remote
org.infinispan.client.hotrod
org.jacorb
org.javassist
org.jaxen
org.jboss.as.aggregate
org.jboss.as.appclient
org.jboss.as.cli
org.jboss.as.clustering.api
org.jboss.as.clustering.common
org.jboss.as.clustering.ejb3.infinispan
org.jboss.as.clustering.impl
org.jboss.as.clustering.infinispan
org.jboss.as.clustering.jgroups
org.jboss.as.clustering.service
org.jboss.as.clustering.singleton
org.jboss.as.clustering.web.infinispan
org.jboss.as.clustering.web.spi
org.jboss.as.cmp
org.jboss.as.connector
org.jboss.as.console
org.jboss.as.controller
org.jboss.as.controller-client
org.jboss.as.deployment-repository
org.jboss.as.deployment-scanner
org.jboss.as.domain-add-user
org.jboss.as.domain-http-error-context
org.jboss.as.domain-http-interface
org.jboss.as.domain-management
org.jboss.as.ee
org.jboss.as.ee.deployment
org.jboss.as.ejb3
org.jboss.as.embedded
org.jboss.as.host-controller
org.jboss.as.jacorb
org.jboss.as.jaxr
org.jboss.as.jaxrs
org.jboss.as.jdr
org.jboss.as.jmx
org.jboss.as.jpa
org.jboss.as.jpa.hibernate
org.jboss.as.jpa.hibernate
org.jboss.as.jpa.hibernate.infinispan
org.jboss.as.jpa.openjpa
org.jboss.as.jpa.spi
org.jboss.as.jpa.util
org.jboss.as.jsr77
org.jboss.as.logging
org.jboss.as.mail
org.jboss.as.management-client-content
org.jboss.as.messaging
org.jboss.as.modcluster
org.jboss.as.naming
org.jboss.as.network
org.jboss.as.osgi
org.jboss.as.platform-mbean
org.jboss.as.pojo
org.jboss.as.process-controller
org.jboss.as.protocol
org.jboss.as.remoting
org.jboss.as.sar
org.jboss.as.security
org.jboss.as.server
org.jboss.as.standalone
org.jboss.as.threads
org.jboss.as.transactions
org.jboss.as.web
org.jboss.as.webservices
org.jboss.as.webservices.server.integration
org.jboss.as.webservices.server.jaxrpc-integration
org.jboss.as.weld
org.jboss.as.xts
org.jboss.classfilewriter
org.jboss.com.sun.httpserver
org.jboss.common-core
org.jboss.dmr
org.jboss.ejb-client
org.jboss.ejb3
org.jboss.iiop-client
org.jboss.integration.ext-content
org.jboss.interceptor
org.jboss.interceptor.spi
org.jboss.invocation
org.jboss.ironjacamar.api
org.jboss.ironjacamar.impl
org.jboss.ironjacamar.jdbcadapters
org.jboss.jandex
org.jboss.jaxbintros
org.jboss.jboss-transaction-spi
org.jboss.jsfunit.core
org.jboss.jts
org.jboss.jts.integration
org.jboss.logging
org.jboss.logmanager
org.jboss.logmanager.log4j
org.jboss.marshalling
org.jboss.marshalling.river
org.jboss.metadata
org.jboss.modules
org.jboss.msc
org.jboss.netty
org.jboss.osgi.deployment
org.jboss.osgi.framework
org.jboss.osgi.resolver
org.jboss.osgi.spi
org.jboss.osgi.vfs
org.jboss.remoting3
org.jboss.resteasy.resteasy-atom-provider
org.jboss.resteasy.resteasy-cdi
org.jboss.resteasy.resteasy-jackson-provider
org.jboss.resteasy.resteasy-jaxb-provider
org.jboss.resteasy.resteasy-jaxrs
org.jboss.resteasy.resteasy-jsapi
org.jboss.resteasy.resteasy-multipart-provider
org.jboss.sasl
org.jboss.security.negotiation
org.jboss.security.xacml
org.jboss.shrinkwrap.core
org.jboss.staxmapper
org.jboss.stdio
org.jboss.threads
org.jboss.vfs
org.jboss.weld.api
org.jboss.weld.core
org.jboss.weld.spi
org.jboss.ws.api
org.jboss.ws.common
org.jboss.ws.cxf.jbossws-cxf-client
org.jboss.ws.cxf.jbossws-cxf-factories
org.jboss.ws.cxf.jbossws-cxf-server
org.jboss.ws.cxf.jbossws-cxf-transports-httpserver
org.jboss.ws.jaxws-client
org.jboss.ws.jaxws-jboss-httpserver-httpspi
org.jboss.ws.native.jbossws-native-core
org.jboss.ws.native.jbossws-native-factories
org.jboss.ws.native.jbossws-native-services
org.jboss.ws.saaj-impl
org.jboss.ws.spi
org.jboss.ws.tools.common
org.jboss.ws.tools.wsconsume
org.jboss.ws.tools.wsprovide
org.jboss.xb
org.jboss.xnio
org.jboss.xnio.nio
org.jboss.xts
org.jdom
org.jgroups
org.joda.time
org.junit
org.omg.api
org.osgi.core
org.picketbox
org.picketlink
org.python.jython.standalone
org.scannotation.scannotation
org.slf4j
org.slf4j.ext
org.slf4j.impl
org.slf4j.jcl-over-slf4j
org.w3c.css.sac
sun.jdk
7.4.2. Nommage de modules dynamiques
- Les déploiements des fichiers WAR et JAR sont nommés selon le format suivant :
deployment.DEPLOYMENT_NAME
Par exemple,inventory.war
etstore.jar
auront les mêmes noms de module quedeployment.inventory.war
etdeployment.store.jar
respectivement. - Les sous-déploiements des archives Enterprise sont nommés selon le format suivant :
deployment.EAR_NAME.SUBDEPLOYMENT_NAME
Ainsi, le sous-déploiementreports.war
, qui se trouve dans l'archive enterpriseaccounts.ear
, aura le nom de module dudeployment.accounts.ear.reports.war
.
Chapitre 8. Valves globales
8.1. Valves
8.2. Valves globales
8.3. Les valves d'authentification
org.apache.catalina.authenticator.AuthenticatorBase
et elle remplace la méthode authenticate()
8.4. Installation d'une Valve globale
Prérequis :
- La valve doit déjà avoir été créée et empaquetée dans un fichier JAR.
- Un fichier
module.xml
doit déjà avoir été créé pour le module.Voir Section 7.1.1, « Modules » pour un exemple de fichiermodule.xml
.
Procédure 8.1. Installer un Module Global
Créer un répertoire d'installation de module
Vous devrez créer un répertoire pour le module à installer dans le répertoire de modules du serveur d'applications.EAP_HOME/modules/system/layers/base/MODULENAME/main
$ mkdir -P /usr/share/jboss/modules/system/layers/base/MyValveModule/main
Copier les fichiers
Copier le JAR et les fichiersmodule.xml
dans le répertoire créé dans l'étape 1.$ cp MyValves.jar modules.xml /usr/share/jboss/modules/system/layers/base/MyValveModule/main
8.5. Configuration d'une Valve globale
Procédure 8.2. Configuration d'une Valve globale
Activer la Valve
Utiliser l'opérationadd
pour ajouter une nouvelle saisie Valve./subsystem=web/valve=VALVENAME:add(module="MODULENAME",class-name="CLASSNAME")
Vous devrez indiquer les valeurs suivantes :VALVENAME
, le nom utilisé pour cette valve dans la configuration de l'application.MODULENAME
, le module qui contient la valeur en cours de configuration.CLASSNAME
, le nom de classe de la valve spécifique dans le module.
/subsystem=web/valve=clientlimiter:add(module="clientlimitermodule",class-name="org.jboss.samplevalves.restrictedUserAgentsValve")
En option : spécifier les paramètres
Si la valve a des paramètres de configuration, spécifier les dans l'opérationadd-param
./subsystem=web/valve=testvalve:add-param(param-name="NAME", param-value="VALUE")
/subsystem=web/valve=testvalve:add-param( param-name="restricteduseragents", param-value="^.*MS Web Services Client Protocol.*$" )
Chapitre 9. Déploiement d'applications
9.1. Les déploiements d'applications
Administration
Management CLI
Développement
Scanner de déploiement
9.2. Déployer avec la console de gestion
9.2.1. Gérer le déploiement d'une application à l'aide de la Console de gestion
9.2.2. Déployer une application par la Console de gestion
Prérequis
Procédure 9.1. Déployer une application par la Console de gestion
Naviguer dans le panneau Manage Deployments de la Console de gestion.
- Sélectionner l'onglet Runtime en haut de la console.
- Déplier le menu
Domain
ouStandalone
(s'il ne l'est pas déjà). - Sélectionner l'option Manage Deployments à partir du menu à gauche de la console.
Déployer une application
La méthode de déploiement variera suivant que vous déployez dans une instance de serveur autonome ou dans un domaine géré.Déployer dans une instance de serveur autonome.
Le tableau Available Deployment Content affiche tous les déploiements d'applications disponibles et leurs statuts.Activer l'application dans une instance de serveur autonome
Cliquer sur le bouton Enable du tableau Deployments pour activer le déploiement de l'application.Confirmer
Cliquer sur le bouton confirm pour confirmer que l'application puisse être activée dans l'instance du serveur.
Déployer dans un domaine géré.
La section Deployment Content contient un tableau Content Repository qui affiche tous les déploiements d'applications et leurs statuts.Activer l'application dans un domaine géré
Cliquer sur le bouton Add dans le tableau Content Repository.Sélectionner les groupes de serveurs
Cocher les cases pour chaque groupe de serveurs dans lesquels vous souhaitez ajouter l'application et cliquer sur le bouton Save pour continuer.Confirmer
Cliquer sur l'onglet Server Group Deployments pour afficher le tableau Server Groups. Votre application sera maintenant déployée dans les groupes de serveurs que vous avez sélectionnés.
L'application est déployée sur le serveur qui convient ou dans le groupe de serveurs qui convient.
9.2.3. Retirer le déploiement d'une application à l'aide de la Console de gestion
Prérequis
Procédure 9.2. Retirer le déploiement d'une application à l'aide de la Console de gestion
Naviguer dans le panneau Manage Deployments de la Console de gestion.
- Sélectionner l'onglet Runtime en haut de la console.
- Déplier le menu
Domain
ouStandalone
(s'il ne l'est pas déjà). - Sélectionner l'option Manage Deployments à partir du menu à gauche de la console.
Supprimer le déploiement d'une application
La méthode de suppression du déploiement variera suivant que vous déployez dans une instance de serveur autonome ou dans un domaine géré.Supprimer le déploiement d'une instance de serveur autonome.
Le tableau Available Deployment Content affiche tous les déploiements d'applications disponibles et leurs statuts.Désactiver l'application dans une instance de serveur autonome
Cliquer sur le bouton Disable du tableau Deployments pour désactiver le déploiement de l'application.Confirmez que vous souhaitez désactiver l'application
Cliquer sur le bouton confirm pour confirmer que l'application puisse être désactivée dans l'instance du serveur.
Supprimer le déploiement à partir d'un domaine géré
La section Deployment Content contient un tableau Content Repository. Available Deployment Content affiche tous les déploiements d'applications disponibles et leurs statuts.Désactiver l'application dans un domaine géré
Cliquer sur l'onglet Server Groups pour afficher les groupes de serveurs et le statut de leurs applications déployées.Sélectionner le groupe de serveurs
Cliquer sur le nom du serveur dans le tableau Server Group pour supprimer un déploiement.Désactiver l'application à partir du serveur sélectionné
Cliquer sur le bouton disable pour désactiver l'application d'un serveur sélectionné.Confirmez que vous souhaitez désactiver l'application
Cliquer sur le bouton confirm pour confirmer que l'application puisse être désactivée dans l'instance du serveur.Répéter la suppression du déploiement pour les groupes de serveurs qui restent.
Répéter au besoin pour d'autres groupes de serveur. Le statut de l'application est confirmé pour chaque groupe de serveurs dans le tableau Deployments.
L'application n'est pas déployée à partir d'un serveur qui convient ou d'un groupe de serveurs.
9.3. Déployer part l'interface de commandes CLI
9.3.1. Gérer le déploiement d'une application à l'aide du Management CLI
9.3.2. Déployer une application dans un domaine géré à l'aide du Management CLI
Prérequis
Procédure 9.3. Déployer une application dans un domaine géré
Exécuter la commande
deploy
Par l'intermédiaire du Management CLI, saisir la commandedeploy
ainsi que le chemin d'accès vers le déploiement de l'application. Inclure le paramètre--all-server-groups
afin de déployer tous les groupes de serveurs.[domain@localhost:9999 /]
deploy /path/to/test-application.war --all-server-groups
- Sinon, définir des groupes de serveurs particuliers de déploiement avec le paramètre
--server-groups
.[domain@localhost:9999 /]
deploy /path/to/test-application.war --server-groups=server_group_1,server_group_2
Veuillez noter qu'un déploiement réussi ne crée pas de sortie vers le CLI.
L'application indiquée est maintenant déployée dans un groupe de serveurs de votre domaine géré.
9.3.3. Supprimer le déploiement d'une application dans un domaine géré à l'aide du Management CLI
Prérequis
Procédure 9.4. Supprimer le déploiement d'une application dans un domaine géré
Exécuter la commande
undeploy
Par l'intermédiaire du Management CLI, saisir la commandeundeploy
ainsi que le nom de fichier du déploiement de l'application. On peut retirer le déploiement de l'application à partir de n'importe quel groupe de serveur dans lequel elle a été déployée à l'origine en ajoutant le paramètre--all-relevant-server-groups
.[domain@localhost:9999 /]
undeploy
test-application.war--all-relevant-server-groups
Veuillez noter qu'une suppression de déploiement réussie ne crée pas de sortie vers le CLI.
L'application spécifiée n'est plus déployée maintenant.
9.3.4. Déployer une application dans une Serveur autonome à l'aide du Management CLI
Prérequis
Procédure 9.5. Déployer une application dans un serveur autonome
Exécuter la commande
deploy
Avec Management CLI, saisir la commandedeploy
avec le chemin d'accès vers le déploiement de l'application.[standalone@localhost:9999 /]
deploy /path/to/test-application.war
Veuillez noter qu'un déploiement réussi ne crée pas de sortie vers le CLI.
L'application indiquée est maintenant déployée dans un serveur autonome.
9.3.5. Supprimer le déploiement d'une application dans un serveur autonome à l'aide du Management CLI
Prérequis
Procédure 9.6. Supprimer le déploiement d'une application dans un serveur autonome
Exécuter la commande
undeploy
Avec Management CLI, saisir la commandeundeploy
avec le nom du fichier du déploiement de l'application.[standalone@localhost:9999 /]
undeploy test-application.war
Veuillez noter qu'une suppression de déploiement réussie ne crée pas de sortie vers le CLI.
L'application spécifiée n'est désormais plus déployée.
9.4. Déployer avec le scanneur de déploiement
9.4.1. Gérer le déploiement d'applications dans le scanneur de déploiement
9.4.2. Déployer une application dans une instance de serveur autonome par un scanneur de déploiement
Prérequis
Cette tâche présente une méthode de déploiement des applications dans une instance de serveur autonome par le scanneur de déploiement. Comme il est indiqué dans la section Section 9.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de Management Console ou de Management CLI sont recommandées pour la gestion des applications dans les environnements de production.
Procédure 9.7. Utiliser le scanneur de déploiement pour déployer les applications.
Copier le contenu dans le dossier de déploiement
Copier le fichier de l'application dans un dossier de déploiement qui se situeEAP_HOME/standalone/deployments/
.Modes d'analyses de déploiements
Le déploiement d'une application varie entre un mode d'analyse de déploiement manuel ou automatique.Déploiement automatique
Le scanneur de déploiement saisit un changement d'état d'un dossier et crée un fichier de marquage, comme expliqué dans la section Section 9.4.5, « Référence pour les fichiers de marquage de scanneur de déploiement ».Déploiement manuel
Le scanneur de déploiement a besoin d'un fichier de marqueurs pour déclencher le processus de déploiement. L'exemple suivant utilise la commande Unixtouch
pour créer un nouveau fichier.dodeploy
.Exemple 9.1. Déploiement par la commande
touch
[user@host bin]$
touch
$EAP_HOME/standalone/deployments/example.war.dodeploy
Le fichier de l'application est déployé sur le serveur d'applications. Un fichier de marquage est créé dans le dossier de déploiement pour indiquer la réussite du déploiement, et l'application est marquée comme Enabled
dans la console de gestion.
Exemple 9.2. Contenu du dossier de déploiement après le déploiement.
example.war example.war.deployed
9.4.3. Supprimer le déploiement d'une application dans une instance de serveur autonome par un scanneur de déploiement
Prérequis
Cette tâche présente une méthode de retrait de déploiement d'applications en provenance d'une instance de serveur autonome qui ont été déployées par le scanneur de déploiement. Comme il est indiqué dans la section Section 9.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de Management Console ou de Management CLI sont recommandées pour la gestion des applications dans les environnements de production.
Note
Procédure 9.8. Retirer le déploiement d'une application à l'aide d'une des méthodes suivantes
Supprimer le déploiement de l'application
Il existe deux méthodes pour supprimer un déploiement d'application suivant que vous souhaitiez supprimer l'application d'un dossier de déploiement ou bien que vous souhaitiez uniquement modifier son statut de déploiement.Retirer un déploiement par suppression du fichier de marquage
Supprimer le fichier de marquageexample.war.deployed
de l'application qui est déployée pour commencer le retrait de déploiement de l'application du runtime.- Résultat
- Le scanneur de déploiement retire l'application et crée un fichier de marquage
example.war.undeployed
. L'application demeure dans le dossier de déploiement.
Retirer le déploiement en supprimant l'application
Supprimer l'application depuis le répertoire de déploiement pour encourager le scanneur de déploiement à commencer le retrait du déploiement de l'application du runtime.- Résultat
- Le scanneur de déploiement retire l'application et crée un fichier de marquage
filename.filetype.undeployed
. L'application n'est plus présente dans le dossier de déploiement.
Le fichier de l'application n'est plus déployé dans le serveur d'applications et n'est plus visible dans l'écran Deployments de la Console de gestion.
9.4.4. Redéploiement d'une application dans une instance de serveur autonome par le scanneur de déploiement
Prérequis
Cette tâche présente une méthode de retrait de déploiement d'applications dans une instance de serveur autonome qui a été déployée par le scanneur de déploiement. Comme il est indiqué dans la section Section 9.1, « Les déploiements d'applications », cette méthode est retenue pour la commodité des développeurs, où les méthodes de Management Console ou de Management CLI sont recommandées pour la gestion des applications dans les environnements de production.
Procédure 9.9. Déployer à nouveau une application dans un serveur autonome
Redéploiement de l'application
Il existe trois méthodes possibles pour redéployer une application déployée par le scanner de déploiement. Ces méthodes déclenchent le scanneur de déploiement pour initier un cycle de déploiement, et peuvent être choisies en fonction des préférences personnelles.Redéploiement par modification du fichier de marquage
Déclencher le redéploiement du scanneur de déploiement en modifiant l'horodatage d'accès du fichier. Dans l'exemple Linux suivant, on utilise une commande Unixtouch
.Exemple 9.3. Redéployer par la commande Unix
touch
[user@host bin]$
touch
EAP_HOME/standalone/deployments/example.war.dodeployRésultatLe scanneur de déploiement a détecté un changement dans le fichier de marquage et a déployé à nouveau l'application. Un nouveau fichier de marquage
.deployed
remplace le précédent.Déployer à nouveau en créant un nouveau fichier de marquage
.dodeploy
Déclencher le redéploiement du scanneur de déploiement en créant un nouveau fichier de marquage.dodeploy
. Voir les instructions de déploiement du manuel qui se trouvent dans Section 9.4.2, « Déployer une application dans une instance de serveur autonome par un scanneur de déploiement ».Déployer à nouveau en supprimant le fichier de marquage
Comme décrit dans Section 9.4.5, « Référence pour les fichiers de marquage de scanneur de déploiement », la suppression du fichier de marquage.deployed
va déclencher un retrait de déploiement et créera un marqueur.undeployed
. Supprimer le marqueur de suppression de déploiement déclenchera le cycle de déploiement à nouveau. Voir Section 9.4.3, « Supprimer le déploiement d'une application dans une instance de serveur autonome par un scanneur de déploiement » pour obtenir des informations supplémentaires.
Le fichier de l'application est déployé à nouveau.
9.4.5. Référence pour les fichiers de marquage de scanneur de déploiement
Les fichiers de marquage font partie du sous-système du scanneur de déploiement. Ces fichiers indiquent le statut d'une application dans un répertoire de déploiement de l'instance du serveur autonome. Un fichier de marquage a le même nom que l'application, avec un suffixe de fichier qui indique l'état du déploiement de l'application. Le tableau suivant définit les types et les réponses de chaque fichier de marquage.
Exemple 9.4. Exemple de fichier de marquage
testapplication.war
.
testapplication.war.deployed
Tableau 9.1. Définitions de types de fichiers de marquage
Suffixe du nom de fichier | Origine | Description |
---|---|---|
.dodeploy | Utilisateur généré | Indique que le contenu doit être déployé ou redéployé dans le runtime. |
.skipdeploy | Utilisateur généré | Désactive l'autodéploiement d'une application si présent. Utile pour bloquer temporairement l'auto-déploiement d'un contenu explosé, empêchant ainsi le risque de modifications de contenu imcomplètes d'être rendues live. Peut être utile pour le contenu compressé, bien que le scanneur détecte les changements en cours dans le contenu compressé et attend qu'ils soient terminés. |
.isdeploying | Système généré | Indique l'initiation du déploiement. Le fichier de marquage sera effacé quand le processus de déploiement sera complété. |
.deployed | Système généré | Indique que le contenu a été déployé. Le déploiement du contenu sera supprimé si le fichier est effacé. |
.failed | Système généré | Indique les échecs de déploiement. Le fichier de marquage contient des informations sur la cause de l'échec. Si le fichier de marquage est supprimé, le contenu sera rendu visible dans l'auto-déploiement à nouveau. |
.isundeploying | Système généré | Indique une réponse suite à la suppression d'un fichier .deployed . Le déploiement du contenu sera supprimé et le marqueur sera effacé automatiquement dès complétion. |
.undeployed | Système généré | Indique si le contenu a été déployé. La suppression du fichier de marquage n'a pas d'impact sur le re-déploiement du contenu. |
.pending | Système généré | Indique que les instructions de déploiement devront être envoyées au serveur suite à la résolution d'un problème qui a été detecté. Ce marqueur sert de blocage de déploiement global. Le scanneur ne demandera pas au serveur de déployer ou de supprimer un déploiement de contenu tant que cette condition existe. |
9.4.6. Référence pour attributs de scanneur de déploiement
write-attribute
. Pour plus d'informations sur les options de configuration, se référer à la section suivante Section 9.4.8, « Configurer le scanneur de déploiement avec le Management CLI ».
Tableau 9.2. Attributs de scanneur de déploiement
Nom | Description | Type | Valeur par défaut |
---|---|---|---|
auto-deploy-exploded | Permet le déploiement automatique d'un contenu éclaté sans nécessiter un fichier de marquage .dodeploy . Recommandé pour les scénarios de développement de base uniquement pour empêcher le déploiement d'applications éclatées de se produire lors de changements du développeur ou du système d'exploitation. | Booléen | False |
auto-deploy-xml | Autorise le déploiement automatique d'un contenu XML sans besoin de fichier de marquage .dodeploy . | Booléen | True |
auto-deploy-zipped | Autorise le déploiement automatique d'un contenu compressé sans besoin de fichier de marquage .dodeploy . | Booléen | True |
deployment-timeout | La durée nécessaire en secondes pour que le scanneur de déploiement puisse permettre un déploiement avant annulation. | Long | 600 |
path | Définit le chemin du système de fichier à scanner. Si l'attribut relative-to est spécifié, la valeur path agira comme un ajout relatif à ce répertoire ou chemin d'acccès. | String | déploiements |
relative-to | Référence à un chemin de système de fichier défini dans la section paths du fichier de configuration XML du serveur. | String | jboss.server.base.dir |
scan-enabled | Autorise le scanning automatique des applications par scan-interval au démarrage. | Booléen | True |
scan-interval | L'intervalle en millisecondes entre les balayages de référentiels. Une valeur inférieure à 1 empêche le scanneur d'opérer au démarrage. | Int | 5000 |
9.4.7. Configurer le scanneur de déploiement
9.4.8. Configurer le scanneur de déploiement avec le Management CLI
Bien qu'il existe plusieurs méthodes de configuration du scanneur de déploiement, le Management CLI permet d'exposer et de modifier les attributs par l'utilisation de batch scripts ou en temps réel. Vous pouvez modifier le comportement du scanneur de déploiement par l'utilisation de l'attribut lecture read-attribute
et des opérations de ligne de commande write-attribute
. Davantage d'informations sur les attributs de scanneur de déploiement sont définis dans la rubrique .
standalone.xml
.
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1"> <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/> </subsystem>
Procédure 9.10. Configurer le scanneur de déploiement
Déterminer les attributs de scanner de déploiement à configurer
Pour configurer le scanneur de déploiement par le Management CLI, vous devrez tout d'abord exposer les noms d'attribut qui conviennent. Vous pouvez faire cela grâce à l'opérationread-resources
au nœud root, ou bien par la commandecd
pour passer au nœud dépendant du sous-système. Vous pouvez également afficher les attributs par la commandels
à ce niveau.Exposer les attributs de scanneur de déploiement par l'opération
read-resource
Utiliser l'opérationread-resource
pour exposer les attributs définis par la ressource de scanneur de déploiement par défaut.[standalone@localhost:9999 /]/subsystem=deployment-scanner/scanner=default:read-resource { "outcome" => "success", "result" => { "auto-deploy-exploded" => false, "auto-deploy-xml" => true, "auto-deploy-zipped" => true, "deployment-timeout" => 600, "path" => "deployments", "relative-to" => "jboss.server.base.dir", "scan-enabled" => true, "scan-interval" => 5000 } }
Exposer les attributs de scanneur de déploiement par la commande
ls
Utiliser la commandels
avec l'argument-l
en option pour afficher une table de résultats qui incluent des attributs de nœud, des valeurs et types de sous-système. Vous pouvez en apprendre davantage sur la commandels
et ses arguments en exposant l'entréels --help
. Pour plus d'informations sur le menu help du Management CLI, voir la section Section 3.5.5, « Comment obtenir de l'aide avec le Management CLI ».[standalone@localhost:9999 /] ls -l /subsystem=deployment-scanner/scanner=default ATTRIBUTE VALUE TYPE auto-deploy-exploded false BOOLEAN auto-deploy-xml true BOOLEAN auto-deploy-zipped true BOOLEAN deployment-timeout 600 LONG path deployments STRING relative-to jboss.server.base.dir STRING scan-enabled true BOOLEAN scan-interval 5000 INT
Configurer le scanneur de déploiement par l'opération
write-attribute
Une fois que vous avez déterminé le nom de l'attribut à modifier, utiliser la commandewrite-attribute
pour spécifier le nom de l'attribut et la nouvelle valeur à indiquer. Les exemples suivants sont tous exécutés au niveau du nœud dépendant, qui peut être accédé en utilisant la commandecd
et la saisie semi-automatique via la touche TAB pour passer au nœud de scanneur par défaut.[standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
Active le déploiement automatique du contenu explosé.
Utiliser l'opérationwrite-attribute
pour activer le déploiement automatique du contenu d'application explosé.[standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-exploded,value=true) {"outcome" => "success"}
Désactiver le déploiement automatique du contenu XML
Utiliser l'opérationwrite-attribute
pour désactiver le déploiement automatique du contenu d'application explosé.[standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-xml,value=false) {"outcome" => "success"}
Désactiver le déploiement automatique du contenu compressé
Utiliser la commandewrite-attribute
pour désactiver le déploiement automatique du contenu d'applications compressé.[standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-zipped,value=false) {"outcome" => "success"}
Configurer l'attribut du chemin d'accès
Utiliser l'opérationwrite-attribute
pour modifier l'attribut de chemin d'accès, pour substituer la valeur de l'exemplenewpathname
par un nouveau nom de chemin d'accès que le scanneur de déploiement puisse surveiller. Notez que le serveur aura besoin que le nouveau chargement prenne effet.[standalone@localhost:9999 scanner=default] :write-attribute(name=path,value=newpathname) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } }
Configurer l'attribut du chemin relatif
Utiliser l'opérationwrite-attribute
pour modifier la référence relative du chemin du système de fichier ainsi définie dans la section des chemins d'accès du fichier de configuration XML. Notez que le serveur aura besoin que le nouveau chargement prenne effet.[standalone@localhost:9999 scanner=default] :write-attribute(name=relative-to,value=new.relative.dir) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } }
Désactiver le scanneur de déploiement
Utiliser l'opérationwrite-attribute
pour désactiver le scanneur de déploiement en définissant la valeurscan-enabled
à false.[standalone@localhost:9999 scanner=default] :write-attribute(name=scan-enabled,value=false) {"outcome" => "success"}
Changer l'intervalle de balayage
Utiliser l'opérationwrite-attribute
pour modifier l'intervalle de balayage de 5 000 millisecondes à 10 000 millisecondes.[standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000) {"outcome" => "success"}
Vos modifications de configuration sont sauvegardées dans le scanneur de déploiement.
9.5. Déployer avec Maven
9.5.1. Gestion du déploiement d'applications dans Maven
9.5.2. Déployer une application dans Maven
Prérequis
Cette tâche vous montre une méthode pour déployer des applications dans Maven. L'exemple fourni utilise l'application jboss-as-helloworld.war
qui se trouve dans la collection Jboss EAP 6 Quickstarts. Le projet helloworld
contient un fichier POM qui initialise le jboss-as-maven-plugin
. Ce plugin fournit des simples opérations pour déployer ou supprimer le déploiement d'applications vers ou en provenance du serveur d'applications.
Procédure 9.11. Déployer une application dans Maven.
Exécuter la commande de déploiement de Maven dans une session de terminal
Ouvrir la session de terminal et naviguez dans le répertoire qui contient les exemples Quickstart.- Exécuter la commande de déploiement Maven pour déployer l'application. Si l'application est déjà en cours d'exécution, elle sera déployée à nouveau.
[localhost]$ mvn package jboss-as:deploy
Confirmer le déploiement de l'application
Voir le résultat dans la fenêtre du terminal
Le déploiement peut être confirmé si vous regardez les entrées de journalisation de l'opération dans la fenêtre du terminal.Exemple 9.5. Confirmation Maven pour l'application helloworld
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3 seconds [INFO] Finished at: Mon Oct 10 17:22:05 EST 2011 [INFO] Final Memory: 21M/343M [INFO] ------------------------------------------------------------------------
Voir les résultats dans la fenêtre du terminal du serveur
Le déploiement peut également être confirmé dans le flux de statut de l'instance du serveur d'applications actives.Exemple 9.6. Confirmation du serveur d'applications pour l'application helloworld
17:22:04,922 INFO [org.jboss.as.server.deployment] (pool-1-thread-3) Contenu ajouté dans /home/username/EAP_HOME/standalone/data/content/2c/39607b0c8dbc6a36585f72866c1bcfc951f3ff/content 17:22:04,924 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "jboss-as-helloworld.war" 17:22:04,954 INFO [org.jboss.weld] (MSC service thread 1-3) Processing CDI deployment: jboss-as-helloworld.war 17:22:04,973 INFO [org.jboss.weld] (MSC service thread 1-2) Starting Services for CDI deployment: jboss-as-helloworld.war 17:22:04,979 INFO [org.jboss.weld] (MSC service thread 1-4) Starting weld service 17:22:05,051 INFO [org.jboss.web] (MSC service thread 1-2) registering web context: /jboss-as-helloworld 17:22:05,064 INFO [org.jboss.as.server.controller] (pool-1-thread-3) Deployed "jboss-as-helloworld.war"
L'application est déployée dans le serveur d'applications.
9.5.3. Supprimer le déploiement d'une application dans Maven
Prérequis
Cette tâche vous montre une méthode pour supprimer le déploiement des applications dans Maven. L'exemple fourni utilise l'application jboss-as-helloworld.war
qui se trouve dans la collection Jboss EAP 6 Quickstarts. Le projet helloworld
contient un fichier POM qui initialise le jboss-as-maven-plugin
. Ce plugin fournit des simples opérations pour déployer ou supprimer le déploiement d'applications vers ou en provenance du serveur d'applications.
Procédure 9.12. Supprimer un déploiement d'application dans Maven
Exécuter la commande de déploiement de Maven dans une session de terminal
Ouvrir la session de terminal et naviguez dans le répertoire qui contient les exemples Quickstart.Exemple 9.7. Passes au répertoire d'application helloworld
[localhost]$ cd /path/to/EAP_Quickstarts/helloworld
- Exécuter la commande de suppression de déploiement.
[localhost]$ mvn jboss-as:undeploy
Confirmer la suppression du déploiement de l'application
Voir le résultat dans la fenêtre du terminal
La suppression du déploiement peut être confirmée si on observe les entrées de journalisation de la fenêtre de terminal.Exemple 9.8. Confirmation Maven pour l'application helloworld
[INFO] ------------------------------------------------------------------------ [INFO] Building JBoss AS Quickstarts: Helloworld [INFO] task-segment: [jboss-as:undeploy] [INFO] ------------------------------------------------------------------------ [INFO] [jboss-as:undeploy {execution: default-cli}] [INFO] Executing goal undeploy for /home/username/EAP_Quickstarts/helloworld/target/jboss-as-helloworld.war on server localhost (127.0.0.1) port 9999. Oct 10, 2011 5:33:02 PM org.jboss.remoting3.EndpointImpl <clinit> INFO: JBoss Remoting version 3.2.0.Beta2 Oct 10, 2011 5:33:02 PM org.xnio.Xnio <clinit> INFO: XNIO Version 3.0.0.Beta2 Oct 10, 2011 5:33:02 PM org.xnio.nio.NioXnio <clinit> INFO: XNIO NIO Implementation Version 3.0.0.Beta2 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1 second [INFO] Finished at: Mon Oct 10 17:33:02 EST 2011 [INFO] Final Memory: 11M/212M [INFO] ------------------------------------------------------------------------
Voir les résultats dans la fenêtre du terminal du serveur
La suppression du déploiement peut également être confirmée dans le flux de statut de l'instance du serveur d'applications d'applications actives.Exemple 9.9. Confirmation du serveur d'applications pour l'application helloworld
17:33:02,334 INFO [org.jboss.weld] (MSC service thread 1-3) Stopping weld service 17:33:02,342 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) Stopped deployment jboss-as-helloworld.war in 15ms 17:33:02,352 INFO [org.jboss.as.server.controller] (pool-1-thread-5) Undeployed "jboss-as-helloworld.war"
La suppression du déploiement de l'application provient du serveur d'applications.
9.6. Contrôler l'ordre des Applications déployées dans JBoss EAP 6
Procédure 9.13. Contrôle de l'ordre de déploiement dans EAP 6.0.X
- Crée des scripts CLI qui déploient et retirent les déploiements d'applications dans un ordre séquentiel quand le serveur est à l'Arrêt/Démarrage.
- CLI prend également en charge le concept de mode batch qui permet de grouper les commandes et les opérations et les exécuter ensemble comme une unité atomique. Si au moins une des commandes ou opérations échoue, toutes les autres commandes et opérations exécutées avec succès dans le lot seront annulées.
Procédure 9.14. Contrôler l'ordre de déploiement dans EAP 6.1.X
- Créer (s'il n'existe pas encore) un fichier
jboss-all.xml
dans le dossierapp.ear/META-INF
oùapp.ear
est l'archive d'application qui dépend d'une autre archive d'application à déployer avant. - Effectuer une saisie
jboss-deployment-dependencies
dans ce fichier comme indiqué ci-dessous. Notez que dans la liste ci-dessous,framework.ear
est l'application de dépendance qui doit être déployée avant que l'archive d'applicationapp.ear
ne le soit.<jboss umlns="urn:jboss:1.0"> <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> <dependency name="framework.ear" /> </jboss-deployment-dependencies> </jboss>
9.7. Remplacement du descripteur de déploiement
Procédure 9.15. Remplacer le descripteur de déploiement en utilisant le Management CLI
app.war
et que vous souhaitez remplacer son fichier WEB-INF/web.xml
avec un autre fichier web.xml
situé dans /home/user/web.xml
.
- Ajouter une superposition de déploiement (deployment overlay) et y ajouter du contenu. Vous pouvez y parvenir de deux façons :
Utilisation d'une arborescence DMR
/deployment-overlay=myoverlay:add
/deployment-overlay=myoverlay/content=WEB-INF\/web.xml:add(content={url=file:///home/user/web.xml})
Si vous le souhaitez, vous pouvez ajouter des règles de contenu en utilisant le deuxième code.
Utilisation des méthodes de facilité
deployment-overlay add --name=myoverlay --content=WEB-INF/web.xml=/home/user/web.xml
Lier la superposition à une archive de déploiement
deployment-overlay link --name=myoverlay --deployments=app.war
Vous pouvez spécifier plusieurs noms d'archives séparés par des virgules./deployment-overlay=myoverlay/deployment=app.war:add
Veuillez noter que le nom d'archive de déploiement n'a pas besoin d'exister sur le serveur pour l'instant. Vous devez indiquer le nom, mais il ne sera pas encore lié à un déploiement.
Déployer à nouveau l'application
/deployment=app.war:redeploy
Chapitre 10. Sécuriser JBoss EAP 6
10.1. La sécurité du sous-système
Si le mode de sujet deep copy est désactivé (par défaut), la copie d'une structure de données de sécurité se réfère à l'original uniquement au lieu de copier toute la structure de données. Ce comportement est plus efficace, mais enclin à la corruption des données si plusieurs threads possédant la même identité effacent le sujet lors d'un vidage ou d'une déconnexion.
Vous pouvez définir des propriétés de sécurité dans tout le système, qui sont appliquées à la classe java.security.Security class
.
Un domaine de sécurité est un ensemble de configuration de sécurité déclarative Java Authentication and Authorization Service (JAAS) qu'une ou plusieurs applications utilisent pour contrôler l'authentification, l'autorisation, l'auditing de et le mapping. Trois domaines de sécurité sont inclus par défaut: jboss-ejb-policy
, jboss-web-policy
, et other
. Vous pouvez créer autant de domaines de sécurité que vous souhaitez pour accommoder les besoins de vos applications.
10.2. Structure du sous-système de sécurité
Exemple 10.1. Exemple de configuration de sous-système de sécurité
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-management> ... </security-management> <security-domains> <security-domain name="other" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="RealmUsersRoles" flag="required"> <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/> <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/> <module-option name="realm" value="ApplicationRealm"/> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domain name="jboss-ejb-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> </security-domains> <vault> ... </vault> </subsystem>
<security-management>
, <subject-factory>
et <security-properties>
ne sont pas présents dans la configuration par défaut. Les éléments <subject-factory>
et <security-properties>
ont été désapprouvés sur JBoss EAP 6.1 et versions ultérieures.
10.3. Configurer le sous-système de sécurité
- <security-management>
- Cette section remplace les comportements de haut niveau du sous-système de sécurité. Chaque paramètre est optionnel. Il est rare de modifier ces paramètres sauf pour le mode de sujet Deep Copy.
Option Description deep-copy-subject-mode Indiquez si l'on doit copier ou lier les tokens de sécurité pour la sécurité des threads.authentication-manager-class-name Indiquer un nom de classe d'implémentation AthentificationManager alternatif à utiliser.authorization-manager-class-name Indiquer un nom de classe d'implémentation AthorizationManager alternatif à utiliser.audit-manager-class-name Indiquer un nom de classe d'implémentation Audit Manager alternatif à utiliser.identity-trust-manager-class-name Indiquer un nom de classe d'implémentation IdentityTrustManager alternatif à utiliser.mapping-manager-class-name Indiquer le nom de classe d'implémentation MappingManager à utiliser. - <subject-factory>
- La fabrique de sujets contrôle la création d'instances de sujets. Elle utilise sans doute le gestionnaire d'authentification pour vérifier l'appelant. L'utilisation principale du sujet est la création d'un sujet par les composants JCA. Il est rare que l'on ait besoin de modifier la fabrique de sujets.
- <security-domains>
- Un élément de conteneur qui contient plusieurs domaines de sécurité. Un domaine de sécurité peut contenir des informations sur des modules d'authentification, d'autorisation, de mappage, et d'auditing, ainsi qu'une autorisation JASPI et une configuration JSSE. Votre application indique ainsi un domaine de sécurité pour gérer ses informations de sécurité.
- <security-properties>
- Contient des noms et valeurs définis dans la classe java.security.Security
10.4. Mode de sujet Deep Copy
10.5. Activer le Mode de sujet Deep Copy
Procédure 10.1. Activer le mode de sécurité Deep Copy à partir de la Console de gestion
Connectez-vous à la Console de gestion.
La console de gestion est normalement disponible à par un URL commme http://127.0.0.1:9990/. Ajuster cette valeur pour qu'elle corresponde à vos besoins.Domaine géré : sélectionner le profil qui convient.
Dans un domaine géré, le sous-système de sécurité est configuré par profil, ou vous pouvez activer ou désactiver le mode de sécurité Deep Copy pour chacun, de manière indépendante.Pour sélectionner un profil, cliquer sur Profiles en haut et à droite de l'affichage console, puis sélectionner le profil que vous souhaitez modifier à partir de la case de sélection Profile en haut et à gauche.Ouvrir le menu de configuration Security Subsystem.
Étendre l'item de menu Security à droite de la console de gestion, puis cliquer sur le lien Security Subsystem.Modifier deep-copy-subject-mode.
Cliquer sur le bouton Edit. Cocher la case qui se trouve à côté de Deep Copy Subjects: pour activer le mode Copier Sujet (copy subject).
Si vous préférez utiliser le Management CLI pour activer cette option, utiliser une des commandes suivantes.
Exemple 10.2. Domaine géré
/profile=full/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)
Exemple 10.3. Serveur autonome
/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)
10.6. Domaines de sécurité
10.6.1. Les domaines de sécurité
10.6.2. Picketbox
- Section 10.6.5, « L'autorisation » et contrôle d'accès
- Section 10.6.9, « Security Mapping » des principaux, rôles et attributs
10.6.3. Authentification
10.6.4. Configurer l'authentification dans un Domaine de sécurité
Procédure 10.2. Configurer l'authentification dans un Domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système d'authentification.
Cliquer sur l'étiquette Authentification en haut de l'affichage s'il n'a pas déjà été sélectionné.La zone de configuration est divisée en deux : Login Modules et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune peut inclure plusieurs attributs et options.Ajouter un module de connexion
Cliquer sur le bouton Add pour ajouter un module de police d'authentification JAAS. Remplir les informations pour votre module. Le Code est le nom de classe de votre module. Les Flags contrôlent la façon dont le module est lié à d'autres modules de polices d'authentification du même domaine de sécurité.Explication des indicateursLa spécification Java Enterprise Edition 6 fournit l'explication suivante sur les marqueurs des modules de sécurité. La liste suivante provient de http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Consulter ce document pour obtenir des informations plus détaillées.
Marqueur Détails requis Le LoginModule est requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.pré-requis Le LoginModule est requis pour la réussite. En cas de succès, l'authentification continue vers le bas de la liste LoginModule. En cas d'échec, le contrôle est renvoyé immédiatement à l'application (l'authentification ne continue pas son chemin le long de la liste LoginModule).suffisant The LoginModule n'est pas nécessaire pour aboutir. S'il ne réussit pas, le contrôle retourne immédiatement à l'application (l'authentification ne se déroule pas vers le bas de la liste LoginModule). S'il échoue, l'authentification se poursuit vers le bas de la liste LoginModule.option Le LoginModule n'est pas requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option : ajouter ou supprimer un module
Pour ajouter des options à votre module, cliquer sur leurs entrées dans la liste Login Modules, et sélectionner l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Utiliser le bouton Remove pour supprimer l'option.
Votre module d'authentification est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
jboss.security.security_domain
Par défaut, chaque module de connexion défini dans un domaine de sécurité a l'option de module jboss.security.security_domain
ajoutée automatiquement. Cette option cause des problèmes avec les modules de connexion, qui vérifient que seules les options connues soient définies. Le module de connexion Kerberos d'IBM com.ibm.security.auth.module.Krb5LoginModule
est l'un d'entre eux.
true
en démarrant la plate-forme JBoss EAP 6. Ajouter ce qui suit pour démarrer les paramètres.
-Djboss.security.disable.secdomain.option=true
10.6.5. L'autorisation
10.6.6. Configurer l'autorisation pour un domaine de sécurité
Procédure 10.3. Configurer l'autorisation pour un domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système d'autorisation.
Cliquer sur l'étiquette Authorization en haut de l'affichage si elle n'a pas déjà été sélectionnée.La zone de configuration est divisée en deux: Policies et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune d'elle peut inclure plusieurs attributs ou options.Ajouter une police.
Cliquer sur le bouton Add pour ajouter un module de police d'autorisation JAAS. Remplir les informations pour votre module. Le Code est le nom de classe de votre module. Les Flags contrôlent la façon dont le module est lié à d'autres modules de polices d'autorisation du même domaine de sécurité.Explication des indicateursLa spécification Java Enterprise Edition 6 fournit l'explication suivante sur les marqueurs des modules de sécurité. La liste suivante provient de http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA. Consulter ce document pour obtenir des informations plus détaillées.
Marqueur Détails requis Le LoginModule est requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.pré-requis Le LoginModule est requis pour la réussite. En cas de succès, l'autorisation continue vers le bas de la liste LoginModule. En cas d'échec, le contrôle est renvoyé immédiatement à l'application (l'autorisation ne continue pas son chemin le long de la liste LoginModule).suffisant The LoginModule n'est pas nécessaire pour aboutir. S'il ne réussit pas, le contrôle retourne immédiatement à l'application (l'autorisation ne se déroule pas vers le bas de la liste LoginModule). S'il échoue, l'authentification se poursuit vers le bas de la liste LoginModule.option Le LoginModule n'est pas requis pour la réussite. En cas de réussite ou d'échec, l'autorisation continuera son chemin dans la liste du LoginModule.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Flags (indicateurs) en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option : ajouter, éditer, ou supprimer un module
Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Login Modules, et sélectionner l'onglet Module Options dans la section Details qui se trouve en bas de la page. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Pour la modifier, cliquer sur la clé et modifier. Utiliser le bouton Remove pour supprimer l'option.
Votre module de police de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
10.6.7. Security Auditing
10.6.8. Configurer Security Auditing
Procédure 10.4. Configurer Security Auditing pour un domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine autonome, l'onglet est intitulé Profile. Dans un domaine géré, sélectionner le profil à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système Auditing.
Cliquer sur l'étiquette Audit en haut de l'affichage si elle n'a pas déjà été sélectionnée.La zone de configuration est divisée en deux : Provider Modules et Details. Le module de fournisseur est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices d'autorisation, et chacune peut inclure plusieurs attributs et options.Ajouter un module de fournisseur.
Cliquer sur le bouton Add pour ajouter un module de fournisseur. Remplir la section Code avec le nom de classe du module du fournisseur.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Vérifier que le module fonctionne
Le but d'un module d'auditing est d'offrir un moyen de surveiller les événements dans le sous-système de sécurité. Ce monitoring peut être réalisé sous la forme d'écriture dans un fichier de journalisation, des notifications email ou autre mécanisme d'audit mesurable.Par exemple, JBoss EAP 6 inclut le moduleLogAuditProvider
par défaut. S'il est activé par les étapes décrites ci-dessus, ce module d'audit écrira des notifications de sécurité dans un fichieraudit.log
qui se situe dans le sous-dossierlog
du répertoireEAP_HOME
.Pour vérifier si les étapes ci-dessus fonctionnent dans le contexteLogAuditProvider
, procédez à une action qui risque de déclencher une notification, puis vérifier le fichier de journalisation de l'audit.Pour obtenir une liste complète des Modules Security Auditing Provider, voir : Section 11.4, « Modules Security Auditing Provider inclus »Option : ajouter, éditer, ou supprimer un module
Si vous avez besoin d'ajouter des options à votre module, cliquer sur leurs entrées dans la liste Module, et sélectionner l'onglet Module Options dans la section Details de la page. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Pour modifier une option existante, la supprimer en cliquant sur l'étiquette Remove, et l'ajouter à nouveau grâce aux options qui conviennent en cliquant sur le bouton Add.
Votre module d'audit de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
10.6.9. Security Mapping
10.6.10. Configurer le Security Mapping dans un domaine de sécurité
Procédure 10.5. Configurer le Mappage de sécurité pour un Domaine de sécurité
Ouvrir l'affichage détaillé du domaine de sécurité.
Cliquer sur l'étiquette Profiles en haut et à droite de la console de gestion. Dans un domaine autonome, l'onglet est intitulé Profile. Dans un domaine géré, sélectionner le profile à modifier à partir de la case de sélection Profile en haut et à gauche de l'affichage du profil. Cliquer sur l'item de menu Security sur la gauche, et cliquer sur Security Domains à partir du menu déroulant. Cliquer sur le lien View pour obtenir le domaine de sécurité que vous souhaitez modifier.Naviguer dans la configuration du sous-système de Mapping
Cliquer sur l'étiquette Mapping en haut de l'affichage si elle n'a pas déjà été sélectionnée.La zone de configuration est divisée en deux : Modules et Details. Le module de connexion est l'unité de base de configuration. Un domaine de sécurité peut inclure plusieurs polices de mapping, et chacune peut inclure plusieurs attributs et options.Ajouter un module.
Cliquer sur le bouton Add pour ajouter un module de police de mapping. Remplir les informations pour votre module. Le Code est le nom de classe du module. Le champ Type se rapporte au type de mapping effectué par ce module. Les valeurs autorisées sont les suivantes : principal, rôle, attribut ou identifiant.Une fois que vous aurez ajouté votre module, vous pourrez modifier son Code ou ses Type en cliquant sur le bouton Edit dans la section Details de l'écran. Veillez à ce que l'onglet Attributes soit bien sélectionné.Option : ajouter, éditer ou supprimer un module
Pour ajouter des options à votre module, cliquer sur leurs entrées dans la liste Modules, et sélectionner l'onglet Module Options dans la section Details. Cliquer sur le bouton Add, et fournir la clé et la valeur de l'option. Pour modifier une option existante, la supprimer en cliquant sur l'étiquette Remove, et ajouter la nouvelle valeur. Utiliser le bouton Remove pour supprimer une option.
Votre module de mappage de sécurité est ajouté au domaine de sécurité, et est rendu disponible immédiatement auprès des applications qui utilisent le domaine de sécurité.
10.6.11. Utiliser un domaine de sécurité dans votre application
Pour utiliser un domaine de sécurité dans votre application, vous devez tout d'abord configurer le domaine dans le fichier de configuration du serveur ou dans le fichier de descripteur de l'application. Ensuite, vous devez ajouter les annotations requises à l'EJB qui l'utilisent. Cette rubrique décrit les étapes requises pour utiliser un domaine de sécurité dans votre application.
Avertissement
Procédure 10.6. Configurez votre application pour qu'elle puisse utiliser un domaine de sécurité
Définir le domaine de sécurité
Vous pouvez définir le domaine de sécurité soit dans le fichier de configuration du serveur, soit dans le fichier du descripteur de l'application.Configurez le domaine de sécurité dans le fichier de configuration du serveur
Le domaine de sécurité est configuré dans le sous-système desécurité
du fichier de configuration du serveur. Si l'instance de JBoss EAP 6 s'exécute dans un domaine géré, il s'agira du fichierdomain/configuration/domain.xml
. Si l'instance de JBoss EAP 6 s'exécute comme un serveur autonome, ce sera le fichierstandalone/configuration/standalone.xml
.Les domaines de sécuritéother
,jboss-web-policy
, etjboss-ejb-policy
sont fournis par défaut dans JBoss EAP 6. L'exemple XML suivant a été copié à partir du sous-système desécurité
dans le fichier de configuration du serveur.<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="other" cache-type="default"> <authentication> <login-module code="Remoting" flag="optional"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> <login-module code="RealmDirect" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> </login-module> </authentication> </security-domain> <security-domain name="jboss-web-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> <security-domain name="jboss-ejb-policy" cache-type="default"> <authorization> <policy-module code="Delegating" flag="required"/> </authorization> </security-domain> </security-domains> </subsystem>
Vous pouvez configurer des domaines de sécurité supplémentaires selon les besoins par la console de gestion ou par l'interface CLI.Configurer le domaine de sécurité dans le fichier de descripteur de l'application.
Le domaine de sécurité est spécifié dans l'élément enfant<security-domain>
de l'élément<jboss-web>
du fichierWEB-INF/jboss-web.xml
de l'application. L'exemple suivant configure un domaine de sécurité nommémy-domain
.<jboss-web> <security-domain>my-domain</security-domain> </jboss-web>
Il s'agit d'une des configurations que vous pouvez indiquer dans le descripteurWEB-INF/jboss-web.xml
.
Ajoutez l'annotation requise à l'EJB.
Vous pouvez configurer la sécurité dans EJB par les annotations@SecurityDomain
et@RolesAllowed
. L'exemple de code EJB suivant limite l'accès au domaine de sécuritéother
aux utilisateurs ayant pour rôleguest
(invité).package example.ejb3; import java.security.Principal; import javax.annotation.Resource; import javax.annotation.security.RolesAllowed; import javax.ejb.SessionContext; import javax.ejb.Stateless; import org.jboss.ejb3.annotation.SecurityDomain; /** * Simple secured EJB using EJB security annotations * Allow access to "other" security domain by users in a "guest" role. */ @Stateless @RolesAllowed({ "guest" }) @SecurityDomain("other") public class SecuredEJB { // Inject the Session Context @Resource private SessionContext ctx; /** * Secured EJB method using security annotations */ public String getSecurityInfo() { // Session context injected using the resource annotation Principal principal = ctx.getCallerPrincipal(); return principal.toString(); } }
Pour obtenir des exemples de code supplémentaires, voir le quickstartejb-security
dans le package JBoss EAP 6 Quickstarts disponible à partir du portail clients de Red Hat.
10.6.12. Java Authorization Contract for Containers (JACC)
10.6.12.1. Java Authorization Contract for Containers (JACC)
10.6.12.2. Configurer la sécurité JACC (Java Authorization Contract for Containers)
jboss-web.xml
pour y inclure les paramètres qu'il faut.
Pour ajouter JACC au domaine de sécurité, ajouter la police d'autorisation JACC
à la pile d'autorisations du domaine de sécurité, avec l'indicateur requis
. Voici un exemple de domaine de sécurité avec support JACC. Cependant, le domaine de sécurité est configuré dans la console de gestion ou Management CLI, plutôt que directement dans le code XML.
<security-domain name="jacc" cache-type="default"> <authentication> <login-module code="UsersRoles" flag="required"> </login-module> </authentication> <authorization> <policy-module code="JACC" flag="required"/> </authorization> </security-domain>
Le fichier jboss-web.xml
se trouve dans META-INF/
ou dans le répertoire WEB-INF/
de votre déploiement, et contient des ajouts ou remplacements de configuration spécifique JBoss pour le conteneur web. Pour utiliser votre domaine de sécurité activé-JACC, vous devrez inclure l'élément <security-domain>
, et aussi définir l'élément <use-jboss-authorization>
sur true
. L'application suivante est configurée correctement pour pouvoir utiliser le domaine de sécurité JACC ci-dessus.
<jboss-web> <security-domain>jacc</security-domain> <use-jboss-authorization>true</use-jboss-authorization> </jboss-web>
La façon de configurer les EJB pour qu'ils utilisent un domaine de sécurité et pour qu'ils utilisent JACC diffère des applications Web. Pour un EJB, vous pouvez déclarer des method permissions (permissions de méthode) sur une méthode ou sur un groupe de méthodes, dans le descripteur ejb-jar.xml
. Dans l'élément <ejb-jar>
, chaque élément <method-permission>
dépendant contient des informations sur les rôles JACC. Voir l'exemple de configuration pour plus d'informations. La classe EJBMethodPermission
fait partie de l'API Java Enterprise Edition 6, et est documentée dans http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html.
Exemple 10.4. Exemple de permissions de méthode JACC dans un EJB
<ejb-jar> <method-permission> <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description> <role-name>employee</role-name> <role-name>temp-employee</role-name> <method> <ejb-name>EmployeeService</ejb-name> <method-name>*</method-name> </method> </method-permission> </ejb-jar>
jboss-ejb3.xml
qui se trouve dans l'élément enfant <security>
. En plus du domaine de sécurité, vous pouvez également spécifier le run-as principal, qui change le principal que l'EJB exécute.
Exemple 10.5. Exemple de déclaration de domaine de sécurité dans un EJB
<security> <ejb-name>*</ejb-name> <security-domain>myDomain</security-domain> <run-as-principal>myPrincipal</run-as-principal> </security>
10.6.13. JASPI (Java Authentication SPI for Containers)
10.6.13.1. Sécurité Java Authentication SPI pour Conteneurs (JASPI)
10.6.13.2. Configuration de la sécurité Java Authentication SPI pour conteneurs (JASPI)
<authentication-jaspi>
à votre domaine de sécurité. La configuration est similaire à celle d'un module d'authentification standard, mais les éléments de module de login sont inclus dans l'élément <login-module-stack>
. La structure de configuration est la suivante :
Exemple 10.6. Structure de l'élément authentication-jaspi
<authentication-jaspi> <login-module-stack name="..."> <login-module code="..." flag="..."> <module-option name="..." value="..."/> </login-module> </login-module-stack> <auth-module code="..." login-module-stack-ref="..."> <module-option name="..." value="..."/> </auth-module> </authentication-jaspi>
EAP_HOME/domain/configuration/domain.xml
ou dans le fichier EAP_HOME/standalone/configuration/standalone.xml
.
10.7. Sécurité dans l'interface de gestion
10.7.1. Configuration Sécurité Utilisateur par défaut
Toutes les interfaces de gestion de JBoss EAP 6 sont sécurisées par défaut. Cette sécurité existe sous deux formes :
- Les interfaces locales sont sécurisées par un contrat SASL entre des clients locaux et le serveur auquel ils se connectent. Ce mécanisme de sécurité repose sur la capacité du client à accéder au système de fichiers local. C'est parce que l'accès au système de fichiers local permettrait au client d'ajouter un utilisateur ou encore de modifier la configuration pour déjouer les autres mécanismes de sécurité. Cela est conforme au principe selon lequel si l'accès physique au système de fichiers est réussi, les autres mécanismes de sécurité sont superflus. Le mécanisme passe par quatre étapes :
Note
L'accès HTTP est considéré comme éloigné, même si vous vous connectez à l'hôte local par HTTP.- Le client envoie un message au serveur incluant une requête pour authentifier le mécanisme SASL local.
- Le serveur génère un token unique, qu'il écrit dans un fichier unique, et envoie un message au client avec le chemin d'accès fichier complet.
- Le client lit le token dans le fichier et l'envoie au serveur, pour vérifier qu'il a l'accès local au système de fichiers.
- Le serveur vérifie le token et efface le fichier.
- Les clients distants, y compris HTTP, utilisent une sécurité basée domaine. Le domaine par défaut qui comprend les autorisations pour configurer la plate-forme JBoss EAP 6 à distance en utilisant les interfaces de gestion est
ManagementRealm
. Un script est fourni pour vous permettre d'ajouter des utilisateurs à ce domaine (ou à des domaines que vous créez). Pour plus d'informations sur la façon d'ajouter des utilisateurs, voir le chapitre Getting Started de JBoss EAP 6 Installation Guide. Pour chaque utilisateur, le nom d'utilisateur, un mot de passe haché et le domaine sont stockés dans un fichier.- Domaine géré
EAP_HOME/domain/configuration/mgmt-users.properties
- Serveur autonome
EAP_HOME/standalone/configuration/mgmt-users.properties