WildFly Isolated Self-Contained Standalone Profile
Relevance
- EAP 6.0.1
- EAP 6.3
- WildFly 9.0.2.Final
Internal
Overview
This article contains step-by-step instructions to create isolated clustered or non-clustered WildFly profiles. 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 node01
}}}
This is the only place where the profile name is externalized.
!!!2. Create the directory structure
{{{
cd $JBOSS_HOME/profiles/node01 mkdir ./configuration; mkdir ./deployments
}}}
The "deployments" directory must exist. It is fine if it's empty, but it has to be there, otherwise the JBoss instance will complain at boot.
!!!3. Copy necessary artifacts
Maintain the name of the server configuration files, this way we know what they are
{{{
cd $JBOSS_HOME/standalone/configuration cp application-* mgmt-* logging.properties standalone-full.xml ../../profiles/node01/configuration
}}}
Pick the appropriate standalone*.xml configuration file, depending on the type of the instance you're attempting to startup. The most typical is standalone.xml for a non-clustered instance, standalone-full-ha.xml for a clustered instance. For more on the differences between startup file, see:
|[JBoss 7 differences between standalone configuration files]
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:
!!!4. Custom add-user.sh Script
Create a custom profiles/node01/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/node01/configuration directory, otherwise undesired effects such as modifying the domain 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 }}}
!!!5. Copy the initial version of the .conf file
Copy $JBOSS_HOME/bin/standalone.conf in $JBOSS_HOME/profiles/node01/profile.conf.
{{{ cp $JBOSS_HOME/bin/standalone.conf $JBOSS_HOME/profiles/node01/profile.conf }}}
Use the standard name "profile.conf".
!!!6. Create the run file
Create it in $JBOSS_HOME/profiles/node01. Use the standard name "run"
{{{
- !/bin/bash
port_offset=0 server_config_file=standalone-full.xml
reldir=$(dirname $0)
profile=${reldir##*/} [ "${profile}" = "." ] && { profile=$(pwd); profile=${profile##*/}; }
export RUN_CONF=${reldir}/profile.conf
- Use ${PROFILE_DIR} in ${RUN_CONF} definitions
export PROFILE_DIR=$(dirname $0)
unset JBOSS_HOME
${reldir}/../../bin/standalone.sh \
--server-config=${server_config_file} \ -Djboss.server.base.dir=${reldir} \ -Djboss.node.name=${profile} \ -Djboss.socket.binding.port-offset=${port_offset}
}}}
then:
{{{
chmod a+x run
}}}
For cluster nodes, increment 'jboss.socket.binding.port-offset' accordingly.
TODO: add logic that will calculate the binding port offset based on the nodeXX.sh index.
!!!7. jboss-cli Support
Simply use $JBOSS_HOME/bin/jboss-cli.sh
!!!8. Start-up
If the instance was configured correctly, Template:Data, Template:Log and Template:Tmp will be created in $JBOSS_HOME/profiles/node01.