WildFly Isolated Self-Contained Domain Profile: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(10 intermediate revisions by the same user not shown)
Line 10: Line 10:
=Overview=
=Overview=


This article contains step-by-step instructions to create isolated domain JBoss Multiple domains can be stood up following the same procedure, on a single host. The procedure also applies to EAP. The only place where the name of the profile is externalized is the <tt>$JBOSS_HOME/profiles</tt>'s sub-directory that actually contains the profile. For this procedure to work, the name of the sub-directory must be the name of the profile. All files, directories and configuration under that sub-directory should be name agnostic, so profiles can be copied across without need for reconfiguration.
This article contains step-by-step instructions to create isolated domain JBoss Multiple domains can be stood up following the same procedure, on a single host, provided that appropriate port offsets are provided. The procedure also applies to EAP. The only place where the name of the profile is externalized is the <tt>$JBOSS_HOME/profiles</tt>'s sub-directory that actually contains the profile. For this procedure to work, the name of the sub-directory must be the name of the profile. All files, directories and configuration under that sub-directory should be name agnostic, so profiles can be copied across without need for reconfiguration.


=Create a new profile sub-directory in $JBOSS_HOME/profiles=
=Create a new profile sub-directory in $JBOSS_HOME/profiles=
Line 31: Line 31:


  cd $JBOSS_HOME/domain/configuration
  cd $JBOSS_HOME/domain/configuration
  cp application-* default-server-logging.properties domain.xml host-* host.xml.* logging.properties mgmt-* ../../profiles/domain01/configuration
  cp application-* default-server-logging.properties domain.xml host.xml logging.properties mgmt-* ../../profiles/domain01/configuration


The authentication credentials copied as part of the application-* and mgmt-* file transfer could be further modified in place by a custom <tt>add-user.sh</tt> script, described below:
The authentication credentials copied as part of the application-* and mgmt-* file transfer could be further modified in place by a custom <tt>add-user.sh</tt> script, described below:
Line 57: Line 57:
=Copy the initial version of the .conf file=
=Copy the initial version of the .conf file=


Copy <tt>$JBOSS_HOME/bin/standalone.conf</tt> as <tt>$JBOSS_HOME/profiles/node01/profile.conf</tt>.
Copy <tt>$JBOSS_HOME/bin/domain.conf</tt> as <tt>$JBOSS_HOME/profiles/domain01/profile.conf</tt>.


<pre>
cp $JBOSS_HOME/bin/domain.conf $JBOSS_HOME/profiles/domain01/profile.conf
cp $JBOSS_HOME/bin/standalone.conf $JBOSS_HOME/profiles/node01/profile.conf
</pre>


Use the standard name "profile.conf".
Use the standard name "profile.conf".
Line 67: Line 65:
=Create the run file=
=Create the run file=


Create the run file in <tt>$JBOSS_HOME/profiles/node01</tt>. Use the standard name "run". Make sure to use the same standalone*.xml configuration file as the one that was previously copied under "configuration".
Create the run file in <tt>$JBOSS_HOME/profiles/domain01</tt>. Use the standard name "run".


<pre>
<syntaxhighlight lang='bash'>
#!/bin/bash
#!/bin/bash


port_offset=0
domain_config_file=domain.xml
server_config_file=standalone-ha.xml


reldir=$(dirname $0)
reldir=$(dirname $0)
Line 80: Line 77:
[ "${profile_dir}" = "." ] && profile_dir=$(pwd)
[ "${profile_dir}" = "." ] && profile_dir=$(pwd)


#
export DOMAIN_CONF=${reldir}/profile.conf
# The node name is how a JBoss instance identifies itself in a cluster. If you intend to
# stand up a cluster comprising of multiple JBoss nodes running on the same host, then it
# makes sense to maintain configuration for those nodes in different profile
# sub-directories under the same 'profile' directory. The node name will be inferred from
# the name of the profile directory. This is the default behavior. However, if you intend
# to stand up a cluster where the nodes run on different hosts,  then it is better to use
# the same name for the profile directory across nodes  (management uniformity across the
# cluster) and infer the node name from the host name.
#
node_name=${profile_dir##*/}
#node_name=$(hostname -s)
 
export RUN_CONF=${reldir}/profile.conf


#
#
# Use ${PROFILE_DIR} in ${RUN_CONF} definitions
# Use ${PROFILE_DIR} in ${DOMAIN_CONF} definitions
#
#
export PROFILE_DIR=$(dirname $0)
export PROFILE_DIR=$(dirname $0)
Line 102: Line 86:
unset JBOSS_HOME
unset JBOSS_HOME


${reldir}/../../bin/standalone.sh \
${reldir}/../../bin/domain.sh \
  --server-config=${server_config_file} \
  --domain-config=${domain_config_file} \
  -Djboss.server.base.dir=${reldir} \
  -Djboss.domain.base.dir=${reldir}
-Djboss.node.name=${node_name} \
-Djboss.socket.binding.port-offset=${port_offset}


</pre>
</syntaxhighlight>


then:
then:


<pre>
chmod a+x run
chmod a+x run
</pre>
 
For cluster nodes running on the same host, increment 'jboss.socket.binding.port-offset' accordingly.
 
<font color=red>
TODO: add logic that will calculate the binding port offset based on the nodeXX.sh index.
</font>
 
==jboss.node.name==
 
The node name is how a JBoss instance identifies itself in a cluster. If you intend to stand up a cluster comprising of multiple JBoss nodes running on the same host, then it makes sense to maintain configuration for those nodes in different profile sub-directories under the same 'profile' directory. The node name will be automatically inferred from the name of the profile directory. This is the default behavior. However, if you intend to stand up a cluster where the nodes run on different hosts,  then it is better to use the same name for the profile directory across nodes  (management uniformity across the cluster) and infer the node name from the host name. More details about jboss.node.name are available here: [[WildFly System Properties#jboss.node.name|jboss.node.name]].


=jboss-cli Support=
=jboss-cli Support=
Line 132: Line 102:
=Start-up=
=Start-up=


If the instance was configured correctly,  <tt>data</tt>, <tt>log</tt> and <tt>tmp</tt> will be created in <tt>$JBOSS_HOME/profiles/node01</tt>.
If the instance was configured correctly,  <tt>data</tt>, <tt>log</tt>, <tt>servers</tt> and <tt>tmp</tt> will be created in <tt>$JBOSS_HOME/profiles/domain01</tt>.

Latest revision as of 20:09, 5 September 2017

Relevance

EAP 6.4.

Internal

Overview

This article contains step-by-step instructions to create isolated domain JBoss Multiple domains can be stood up following the same procedure, on a single host, provided that appropriate port offsets are provided. The procedure also applies to EAP. The only place where the name of the profile is externalized is the $JBOSS_HOME/profiles's sub-directory that actually contains the profile. For this procedure to work, the name of the sub-directory must be the name of the profile. All files, directories and configuration under that sub-directory should be name agnostic, so profiles can be copied across without need for reconfiguration.

Create a new profile sub-directory in $JBOSS_HOME/profiles

cd $JBOSS_HOME/profiles
mkdir domain01

This is the only place where the domain profile name is externalized.

Create the directory structure

cd $JBOSS_HOME/profiles/domain01
mkdir ./configuration

Copy necessary artifacts

Maintain the name of the server configuration files, this way we know what they are. 

cd $JBOSS_HOME/domain/configuration
cp application-* default-server-logging.properties domain.xml host.xml logging.properties mgmt-* ../../profiles/domain01/configuration

The authentication credentials copied as part of the application-* and mgmt-* file transfer could be further modified in place by a custom add-user.sh script, described below:

Custom add-user.sh Script

Create a custom profiles/domain01/add-user.sh shell wrapper to allow modification of this profile's authentication credential files. Note that both -sc (the location the server config directory) and -dc (the location of the domain config directory) must point to the same profiles/domain01/configuration directory, otherwise undesired effects such as modifying the standalone files will happen. 

#!/bin/bash

reldir=$(dirname $0)

unset JBOSS_HOME

${reldir}/../../bin/add-user.sh -sc ${reldir}/configuration -dc ${reldir}/configuration

then: 

chmod a+x add-user.sh

When attempting to add users to an isolated self-contained domain profile, make sure you use the script provided with the profile, and NOT the $JBOSS_HOME/bin script, because is you use the $JBOSS_HOME/bin script, the users won't be added to the profile's user files, but to the default user files. For more details see: Adding a User to an Isolated Self-Contained Standalone Profile.

Copy the initial version of the .conf file

Copy $JBOSS_HOME/bin/domain.conf as $JBOSS_HOME/profiles/domain01/profile.conf. 

cp $JBOSS_HOME/bin/domain.conf $JBOSS_HOME/profiles/domain01/profile.conf

Use the standard name "profile.conf".

Create the run file

Create the run file in $JBOSS_HOME/profiles/domain01. Use the standard name "run". 

#!/bin/bash

domain_config_file=domain.xml

reldir=$(dirname $0)

profile_dir=${reldir##*/}
[ "${profile_dir}" = "." ] && profile_dir=$(pwd)

export DOMAIN_CONF=${reldir}/profile.conf

#
# Use ${PROFILE_DIR} in ${DOMAIN_CONF} definitions
#
export PROFILE_DIR=$(dirname $0)

unset JBOSS_HOME

${reldir}/../../bin/domain.sh \
 --domain-config=${domain_config_file} \
 -Djboss.domain.base.dir=${reldir}

then: 

chmod a+x run

jboss-cli Support

Simply use $JBOSS_HOME/bin/jboss-cli.sh. This is possible because the CLI wrapper queries (or needs to be provided explicitly) the address of the node to connect to. For more details on CLI see WildFly CLI.

Start-up

If the instance was configured correctly, data, log, servers and tmp will be created in $JBOSS_HOME/profiles/domain01.

Retrieved from "https://kb.novaordis.com/index.php?title=WildFly_Isolated_Self-Contained_Domain_Profile&oldid=28059"