Guide de démarrage

Les utilisateurs peuvent également être créés de manière non interactive en passant des paramètres au script add-user. Cette approche n'est pas recommandée sur des systèmes partagés, car les mots de passe seront visibles dans les journaux et fichiers d'historiques. Pour plus d'information, consulter Exécuter l'utilitaire Ajout d'utilisateur de manière non interactive.

Vous pouvez exécuter le script add-user de manière non interactive en passant des arguments en ligne de commande. Le nom d'utilisateur et mot de passe doivent être fournis.

Créer un utilisateur appartenant à plusieurs groupes

La commande suivante ajoute un utilisateur de gestion (mgmtuser1) avec les groupes guest et mgmtgroup.

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'

Spécifier un fichier de propriétés alternatif

Par défaut, les informations de groupe et d'utilisateur créés à l'aide du script add-user sont stockés dans des fichiers de propriété situés dans le répertoire de configuration de serveur.

Les informations utilisateur sont stockées dans les fichiers de propriété suivants :

Les informations de groupe sont stockées dans les fichiers de propriété suivants :

Les noms de fichiers de propriété et de répertoires par défaut peuvent être remplacés. La commande suivante ajoute un nouvel utilisateur, indiquant un nom et emplacement différents pour les fichiers de propriété utilisateur.

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser2' -p 'password1!' -sc '/path/to/standaloneconfig/' -dc '/path/to/domainconfig/' -up 'newname.properties'

Le nouvel utilisateur a été ajouté aux fichiers de propriétés utilisateur désormais situés dans /path/to/standaloneconfig/newname.properties et /path/to/domainconfig/newname.properties. Veuillez noter que ces fichiers doivent déjà exister afin d'éviter une erreur.

Pour obtenir une liste complète de tous les arguments add-user disponibles ainsi que leur utilité, utiliser l'argument --help ou consulter la section Add-User Utility Arguments.

L'interface en ligne de commande (CLI) est un outil d'administration en ligne de commande pour JBoss EAP.

Utiliser l'interface CLI pour démarrer et stopper les serveurs, déployer et retirer les déploiements d'applications, configurer les paramètres du système, ou encore, effectuer d'autre tâches administratives. Les opérations peuvent être effectuées par mode lots, ce qui permet à plusieurs tâches d'ëtre exécutées en groupe.

Plusieurs commandes de terminal courantes sont disponibles, telles que ls, cd et pwd. L'interface CLI prend également en charge la saisie automatique avec la touche «Tab ».

Pour obtenir des informations supplémentaires sur la façon d'utiliser l'interface de gestion CLI, y compris les commandes et opérations, la syntaxe, et comment exécuter par lots, voir le guide Interface de commandes (CLI) de JBoss EAP.

Lancement de l'interface CLI

$ EAP_HOME/bin/jboss-cli.sh

Connexion à un serveur en cours d'exécution

connecter

Ou vous pouvez lancer l'interface CLI et vous connecter en une seule fois à l'aide de la commande EAP_HOME/bin/jboss-cli.sh --connect.

Afficher l'aide

Utiliser la commande suivante pour afficher l'aide générale.

aide

Utiliser la commande suivante pour obtenir de l'aide pour une commande spécifique.

deploy --help

Quitter l'interface CLI

Quitter

Afficher les paramètres de système

La commande suivante utilise l'opération read-attribute pour afficher si l'exemple de source de donnée est activé.

/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)
{
    "outcome" => "success",
    "result" => true
}

Pour les exécutions en domaine géré, il convient de spécifier le profil à mettre à jour en faisant précéder la commande par /profile=PROFILE_NAME.

/profile=default/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)

Mettre à jour les paramètres système

La commande suivante utilise l'opération write-attribute pour désactiver l'exemple de source de donnée.

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)

Démarrer les serveurs

L'interface CLI peut également être utilisée pour démarrer et arrêter les serveurs lors d'une exécution dans un domaine géré.

/host=HOST_NAME/server-config=server-one:start

La console de gestion est un outil administratif basé web pour la plateforme JBoss EAP.

Utilisez la console de gestion pour démarrer et arrêter des serveurs, déployer et annuler le déploiement des applications, régler les paramètres du système et apporter des modifications persistantes à la configuration du serveur. La console de gestion a également la capacité d'effectuer des tâches administratives, avec des notifications directes lorsque les modifications effectuées par l'utilisateur actuel exigent que l'instance du serveur soit redémarrée ou rechargée.

Dans un domaine géré, les instances de serveur et les groupes de serveurs d'un même domaine peuvent être gérés de façon centralisée à partir de la Console de gestion du contrôleur de domaine.

Pour une instance JBoss EAP exécutée sur l'hôte local à l'aide du port de gestion par défaut, la console de gestion peut être accédée par un navigateur web sur http://localhost:9990/console/App.html. Vous devrez vous authentifier avec un utilisateur possédant des permissions pour accéder à la console de gestion.

La console de gestion fournit les onglets de navigation et de gestion de votre serveur autonome JBoss EAP ou de votre domaine géré suivants :

Les fichiers de configuration du serveur autonome se situent dans le répertoire EAP_HOME/standalone/configuration. Un fichier séparé existe pour chacun des quatre profils prédéfinis (default, ha, full, full-ha).

Par défaut, le démarrage de JBoss EAP en tant que serveur autonome utilise le fichier standalone.xml. Pour démarrer JBoss EAP avec une configuration différente, utiliser l'argument --server-config. Par exemple,

$ EAP_HOME/bin/standalone.sh --server-config=standalone-full.xml

Les fichiers de configuration du domaine géré se situent dans le répertoire EAP_HOME/domain/configuration.

Par défaut, le démarrage de JBoss EAP en tant que domaine géré utilise le fichier host.xml. Pour démarrer JBoss EAP avec une configuration différente, utiliser l'argument --host-config. Par exemple,

$ EAP_HOME/bin/domain.sh --host-config=host-master.xml

Afin de restaurer la configuration du serveur JBoss EAP, les éléments situés aux emplacements suivants doivet être sauvegardés :

Pour aider à la maintenance et à la gestion du serveur, JBoss EAP crée une version horodatée du fichier de configuration original au moment du démarrage. Toutes les modifications de configuration supplémentaires suite aux opérations de gestion entraîneront la sauvegarde automatique du fichier d'origine, et une copie de travail de l'instance sera alors conservée en tant que référence et pour la restauration. De plus, les instantanés de configuration peuvent être effectués, représentant des copies à un moment précis de la configuration du serveur actuel. Ces instantanés peuvent être enregistrés et chargés par un administrateur.

Les exemples suivants utilisent le fichier standalone.xml, mais le même processus s'applique aux fichiers domain.xml et host.xml.

Effectuer un instantané

Utiliser l'interface CLI pour effectuer un instantané des configurations actuelles.

:take-snapshot
{
    "outcome" => "success",
    "result" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20151022-133109702standalone.xml"
}

Lister les instantanés

Utiliser l'interface CLI pour énumérer tous les instantanés effectués.

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
        "names" => [
            "20151022-133109702standalone.xml",
            "20151022-132715958standalone.xml"
        ]
    }
}

Supprimer un instantané

Utiliser l'interface CLI pour supprimer un instantané.

:delete-snapshot(name=20151022-133109702standalone.xml)

Démarrer le serveur avec un instantané

Le serveur peut être démarré à l'aide d'un instantané ou d'une version de configuration automatiquement enregistrée.

JBoss EAP vous autorise à utiliser des expressions pour définir des propriétés remplaçables à la place de valeurs littérales dans la configuration. Les expressions utilisent le format ${PARAMETER:DEFAULT_VALUE}. Si le paramètre spécifié est défini, alors la valeur du paramètre sera utilisée. Sinon, la valeur par défaut fournie sera utilisée.

Les sources prises en charge pour résoudre les expressions sont les propriétés système, variables d'environnement et de l'archivage sécurisé. Pour les déploiements uniquement, la source peut correspondre à des propriétés répertoriées dans un fichier META-INF/jboss.properties qui se trouve dans l'archive de déploiement. Pour les types de déploiement qui prennent en charge les sous-déploiements, la résolution est étendue à tous les sous-déploiements si le fichier de propriété se trouve dans le déploiement externe (par ex. EAR). Si le fichier de propriétés se trouve dans le sous-déploiement, alors la résolution est étendue à ce sous-déploiement.

L'exemple ci-dessous à partir du fichier de configuration standalone.xml définit le inet-address pour l'interface public à 127.0.0.1 à moins que le paramètre jboss.bind.address soit défini.

<interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>

Le paramètre jboss.bind.address peut être défini au démarrage de EAP en tant que serveur autonome avec la commande suivante :

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

Expressions imbriquées

Les expressions peuvent être imbriquées, ce qui permet une utilisation plus avancée des expressions au lieu de valeurs fixes. Le format d'une expression imbriquée ressemble à celui d'une expression normale, mais une expression est imbriquée dans l'autre, comme par exemple :

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

Les expressions imbriquées sont évaluées de façon récursive, donc l'expression inner est d'abord évaluée, puis outer. Les expressions peuvent également être récursives, lorsque l'évaluation d'une expression entraîne une autre expression, qui est à son tour évaluée. Les expressions imbriquées sont autorisées partout où les expressions sont autorisées, à l'exception des commandes CLI de gestion.

Une expression imbriquée peut être utilisée si le mot de passe utilisé dans une définition de source de donnée est masqué. La configuration pour la source de donnée peut contenir la ligne suivante :

<password>${VAULT::ds_ExampleDS::password::1}</password>

La valeur de ds_ExampleDS peut être remplacée avec une propriété de système (datasource_name) à l'aide d'une expression imbriquée. La configuration de la source de données peut contenir à la place la ligne suivante :

<password>${VAULT::${datasource_name}::password::1}</password>

JBoss EAP doit tout d'abord évaluer l'expression ${datasource_name}, puis l'ajouter à une plus grande expression et évaluer l'expression qui en résulte. L'avantage de cette configuration est que le nom de la source de données se soustrait de la configuration fixe

Remplacement de propriété basée descripteur

La configuration d'application - par exemple, les paramètres de connexion de la source de données - varient normalement entre le développement, les tests, et les environnements de production. Cette variation est parfois accommodée par les build system scripts, car la spécification Java EE ne contient pas de méthode pour externaliser ces configurations. Dans JBoss EAP 6, vous pouvez utiliser le remplacement de propriété basée descripteur pour gérer la configuration en externe.

Le remplacement de propriété basée descripteur remplace les propriétés basées sur des descripteurs, ce qui vous permet de supprimer les hypothèses concernant l'environnement de l'application et la chaîne de construction. Les configurations spécifiques à l'environnement peuvent être spécifiées dans les descripteurs de déploiement à la place des annotations ou des build system scripts. Vous pouvez fournir la configuration dans les fichiers ou en tant que paramètres en ligne de commande.

Il existe plusieurs indicateurs dans le sous-système EE qui contrôlent si le remplacement de propriété est appliqué.

Le remplacement de descripteur spécifique à JBoss est contrôlé par l'indicateur jboss-descriptor-property-replacement et activé par défaut. Une fois activées, les propriétés peuvent être remplacées dans les descripteurs de déploiement suivants :

La commande d'interface CLI suivante peut être utilisée pour activer ou désactiver le remplacement de propriété dans les descripteurs spécifiques à JBoss :

/subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

Le remplacement de descripteur Java EE est contrôlé par l'indicateur spec-descriptor-property-replacement et désactivé par défaut. Une fois activées, les propriétés peuvent être remplacées dans les descripteurs de déploiement suivants :

La commande d'interface CLI suivante peut être utilisée pour activer ou désactiver le remplacement de propriétés dans les descripteurs Java EE :

/subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

<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="private">
    <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

Par défaut, JBoss EAP lie ces interfaces à 127.0.0.1, mais ces valeurs peuvent être remplacées lors de l'exécution en définissant la propriété appropriée. Par exemple, l'inet-address de l'interface public peut être définie au démarrage de JBoss EAP en tant que serveur autonome par la commande suivante.

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

Sinon, vous pouvez utiliser l'argument -b dans la ligne de commande de démarrage du serveur. Pour plus d'informations sur les options de démarrage d'un serveur, voir Server Runtime Arguments.

Les interfaces de réseau sont déclarées en indiquant un nom logique et des critères de sélection pour une interface physique. Les critères de sélection peuvent faire référence à une adresse wildcard ou indiquer un ensemble d'une ou plusieurs caractéristiques qu'une interface ou adresse doit avoir afin d'obtenir une correspondance valide. Pour obtenir une liste de tous les critères de sélection d'interface disponibles, consulter la section Interface Attributes.

Les interfaces peuvent être configurées à l'aide de la console de gestion ou l'interface CLI. Voici plusieurs exemples d'ajout et de mise à jour d'interfaces. La commande d'interface CLI est affichée en premier, suivie par le fichier XML de configuration correspondant.

Ajouter une interface avec une valeur NIC

Ajouter une nouvelle interface avec une valeur NIC de eth0.

/interface=external:add(nic=eth0)

<interface name="external">
   <nic name="eth0"/>
</interface>

Ajouter une interface avec plusieurs valeurs conditionnelles

Ajouter une nouvelle interface correspondant à une interface/adresse sur le sous-réseau approprié si l'interface/adresse est active, prend en charge les multi-diffusion et n'est pas une liaison point à point.

/interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true})

<interface name="default">
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>

Mettre à jour un attribut d'interface

Mettre à jour la valeur inet-address par défaut de l'interface publique, en maintenant la propriété jboss.bind.address pour permettre à cette valeur d'être définie à l'exécution.

/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0}")

<interface name="public">
    <inet-address value="${jboss.bind.address:192.168.0.0}"/>
</interface>

Ajouter une interface à un serveur dans un domaine géré

/host=master/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1)

<servers>
   <server name="SERVER_NAME" group="main-server-group">
      <interfaces>
         <interface name="INTERFACE_NAME">
            <inet-address value="127.0.0.1"/>
         </interface>
      </interfaces>
   </server>
</servers>

Les ports de gestion ont été consolidés dans JBoss EAP 7. Par défaut, JBoss EAP 7 utilise le port 9990 pour la gestion native (interface CLI) et gestion HTTP (console de gestion web). Le port 9999, utilisé en tant que port de gestion natif dans JBoss EAP 6, n'est plus utilisé mais peut être activé si besoin.

Si HTTPS est activé pour la console de gestion, alors le port 9993 est utilisé par défaut.

JBoss EAP comprend un groupe de liaison de socket pour chacun des quatre profils prédéfinis (default, ha, full, full-ha).

Pour des informations détaillées sur les liaisons de sockets par défaut, telles que les descriptions et ports par défaut, merci de consulter la section Default Socket Bindings.

Serveur autonome

Pour une exécution à l'aide d'un serveur autonome, un seul groupe de liaisons de sockets est défini par fichier de configuration. Chaque fichier de configuration autonome (standalone.xml, standalone-ha.xml, standalone-full.xml, standalone-full-ha.xml) définit les liaisons de sockets pour les technologies utilisées par son profil correspondant.

Par exemple, le fichier de configuration autonome (standalone.xml) spécifie les liaisons de sockets ci-dessous.

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <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>

Domaine géré

Lors d'une exécution dans un domaine géré, tous les groupes de liaisons de sockets sont définis dans le fichier domain.xml. Il existe quatre groupes de liaisons de sockets prédéfinis :

Chaque groupe de liaisons de sockets indique les liaisons de sockets pour les technologies utilisées par le profil correspondant. Par exemple, le groupe de liaisons de sockets full-ha-sockets définit plusieurs liaisons de sockets jgroups, utilisées par le profil full-ha pour la haute disponibilité.

<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="${jboss.ajp.port:8009}"/>
        <socket-binding name="http" port="${jboss.http.port:8080}"/>
        <socket-binding name="https" port="${jboss.https.port:8443}"/>
        <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-group>
    <socket-binding-group name="full-sockets" default-interface="public">
        <!-- Needed for server groups using the 'full' profile  -->
    ...
    </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="${jboss.ajp.port:8009}"/>
        <socket-binding name="http" port="${jboss.http.port:8080}"/>
        <socket-binding name="https" port="${jboss.https.port:8443}"/>
        <socket-binding name="iiop" interface="unsecure" port="3528"/>
        <socket-binding name="iiop-ssl" interface="unsecure" port="3529"/>
        <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" interface="private" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" interface="private" port="57600"/>
        <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" interface="private" port="54200"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        <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>

Lors de la définition d'une liaison de socket, vous pouvez configurer les attributs port et interface, ainsi que les paramètres de multidiffusion tels que multicast-address et multicast-port. Pour plus de détails sur tous les attributs de liaison de socket, voir la section Socket Binding Attributes section.

Les liaisons de socket peuvent être configurées à l'aide de la console de gestion ou l'interface CLI. Les étapes suivantes indiquent d'ajouter un groupe de liaison de socket et de configurer les paramètres de liaison de socket à l'aide de l'interface CLI.

L'exemple suivant montre à quoi la configuration XML peut ressembler après avoir effectué les étapes ci-dessus.

<socket-binding-groups>
    ...
    <socket-binding-group name="new-sockets" default-interface="public">
        <socket-binding name="new-socket-binding" interface="unsecure" port="1234"/>
    </socket-binding-group>
</socket-binding-groups>

Un décalage de port (Port offset) est une valeur de décalage chiffré qui vient s'ajouter aux valeurs de port données par le groupe de liaisons de sockets pour ce serveur. Cela permet au serveur d'hériter des valeurs de port définies dans son groupe de liaisons de sockets, avec un décalage pour veiller à ce qu'il n'entre pas en conflit avec les autres serveurs du même hôte. Par exemple, si le port HTTP du groupe de liaisons de sockets est 8080 et si votre serveur utilise un port offset de 100, son port HTTP sera 8180.

Voici un exemple de définition de décalage de port de 250 pour un serveur dans un domaine géré à l'aide de l'interface CLI.

/host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)

Les décalages de port peuvent être utilisés pour les serveurs dans un domaine géré et pour exécuter plusieurs serveurs autonomes sur le même hôte.

Vous pouvez indiquer un décallage de port quand vous démarrez un serveur autonome par la propriété jboss.socket.binding.port-offset.

$ EAP_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100

JBoss EAP contient une bonne série d'exemples de code quickstart (démarrage rapide) conçus pour aider les utilisateurs à commencer à rédiger des applications en utilisant différentes technologies Java EE 7. Les quickstarts peuvent être téléchargés à partir du portail client Red Hat.

Une fois les quickstarts téléchargés, ceux-ci peuvent être importés dans JBoss Developer Studio et déployés vers JBoss EAP.

Vous pouvez facilement créer et déployer des quickstarts à partir de la ligne de commande en utilisant Maven. Si vous n'avez pas encore installé Maven, voir le projet Apache Maven pour le télécharger et l'installer.

A README.md file is provided at the root directory of the quickstarts that contains general information about system requirements, configuring Maven, adding users, and running the quickstarts.

Chaque quickstart contient son propre fichier README.md fournissant les instructions spécifiques et les commandes Maven qui servent à exécuter ce quickstart.