WildFly Isolated Self-Contained Standalone Profile
Jump to navigation
Jump to search
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.
Create the directory structure
cd $JBOSS_HOME/profiles/node01 mkdir ./configuration; mkdir ./deploymentsThe "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.