WildFly Unzip Installation: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(78 intermediate revisions by the same user not shown)
Line 1: Line 1:
<br>
<br>
<br>
<center><font color=red>In process of being migrated from https://home.feodorov.com:9443/wiki/Wiki.jsp?page=JBoss7UnzipInstallation</font></center>
=Internal=
=Internal=
* [[WildFly Installation#Subjects|WildFly Installation]]
* [[WildFly Installation#Subjects|WildFly Installation]]
=Relevance=
* EAP 6, EAP 7


=Overview=
=Overview=


This document describes the WildFly "manual" installation procedure. It consists in unzipping a release zip file and configuring the deployment. It applies to both standalone and domain mode for WildFly and EAP releases. Additional configuration such as enabling SSL, adding data sources, adding HA to the domain controller, etc. can be performed after the installation. The examples below mention "jboss", as the procedure was applied to an EAP installation.
This document describes the WildFly "manual" installation procedure. It consists in unzipping a release zip file and configuring the deployment. It applies to both standalone and domain mode for WildFly and EAP releases. Additional configuration such as enabling SSL, adding data sources, [[WildFly High Availability Domain Controller|adding HA to the domain controller]], etc. can be performed after the installation. The examples below mention "jboss", as the procedure was applied to an EAP installation.
 
The entire installation procedure has been automated with [[em]] to create EAP-based Amazon EC2 environments.


=Extract Release from ZIP File=
=Extract Release from ZIP File=
The operations described below apply to both standalone and domain mode installation, and in case of domain mode installation, they must be repeated on all hosts of the domain, unless specified otherwise.
==Extraction User==
Unzip in place ''as the user intended to run the server''.  For example, if the application server will be run by an "eap" user, become that user and extract under that user's identity. If there are no sufficient permissions on the parent directory, temporarily lessen the permission during the unzip operation, then restore more restrictive permissions on the parent folder.
==Unzip==
<pre>
unzip .../jboss-eap-6.4.0.zip
</pre>
The operation will create a <tt>./jboss-eap-6.4</tt> directory.
==Apply Patches if Necessary==
Note that the above example refers to an "unpatched" deployment. If patches are available, and their installation is desired, start the EAP instance in standalone mode and apply the patches in place:
<pre>
cd jboss-eap-7.0/bin
./standalone.sh
./jboss-cli.sh -c
patch apply /home/eap/jboss-eap-7.0.4-patch.zip
</pre>
==Create a Symbolic Link==
<pre>
ln -s ./jboss-eap-6.4 jboss
</pre>
If patches were applied, modify the original directory to reflect the patch level, and then create the link:
<pre>
mv jboss-eap-7.0 jboss-eap-7.0.4
ln -s ./jboss-eap-7.0.4 jboss
</pre>
==Optional for a Standalone Installation==
If you perform a standalone installation you can remove the <tt>domain</tt> subdirectory to reduce the clutter and confusion. You won't need it.
==Optional on a Host Controller and/or Domain Controller==
This applies when we install a host controller and when the host controller is also the domain controller: the <tt>standalone</tt> directory can be removed.
<pre>
cd jboss
rm -r standalone
cd bin
rm standalone *
</pre>
==Optional on a non-Windows Machine==
The <tt>*.bat</tt> files from <tt>bin</tt> can be removed.
<pre>
cd jboss/bin
rm *.bat
</pre>
=Post-Install Configuration=
==Post-Install Configuration User==
Perform all post-install configuration operations as the JBoss runtime user.
==Unset the <tt>JBOSS_HOME</tt> Environment Variable==
If the <tt>JBOSS_HOME</tt> value is accidentally set to point to another WildFly deployment, it will interfere with the next steps, so it is best if you unset it.
==Security==
Add a management user, conventionally named <tt>admin</tt>. Note that this user does not represent the identity used by a [[WildFly_Domain_Mode_Concepts#Subordinate_Host_Controller|subordinate host controller]] to connect to the domain controller, that will be configured later. The procedure is described here:
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Adding Users to WildFly Security Realms#Add_a_User_to_the_Management_Realm|Adding a User to the Management Realm]]
</blockquote>
==Network==
Configure the bind addresses for management and public interfaces. The bind address of the management interface can be set externally with <tt>jboss.bind.address.management</tt> system property. The bind address of the public interface can be set externally with <tt>jboss.bind.address</tt> system property.
<blockquote style="background-color: Gold; border: solid thin Goldenrod;">
:<br>Note that in domain mode, host controllers connect to the domain controller's [[WildFly_Management_Interfaces#The_Native_API_Endpoint|management interface native endpoint]] to get domain configuration, so the domain controller management functions have to be externally accessible over the management interface, hence the management interface has to be visible on the management (internal) network. A subordinate host controller does not have to expose its management interface. The public interface must be configured on all hosts and accessible externally, provided that the server instances must be available externally.
:For more details see [[WildFly_Domain_Mode_Concepts#Domain_Controller.2FHost_Controller_Communication|Domain Controller/Host Controller Communication]]<br><br>
</blockquote>
===Standalone Node===
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly System Properties#jboss.bind.address_for_Standalone_Node|Set '<tt>jboss.bind.address</tt>' as described here]]
</blockquote>
===Domain Controller===
Will be described in detail in the [[#Domain_Controller_Configuration|Domain Controller Configuration]] section below.
===Subordinate Host Controller===
Will be described in detail in the [[#Subordinate_Host_Controller_Configuration|Subordinate Host Controller Configuration]] section below.
=Extra Standalone Configuration=
Some of the <tt>standalone-*.xml</tt> files can be removed if you know that you are not going to use those profiles.
=Domain Controller Configuration=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[WildFly Domain Controller Post-Install Configuration]]
:[[Start WildFly as a Service on Linux]]
</blockquote>
=Subordinate Host Controller Configuration=
<blockquote style="background-color: Gold; border: solid thin Goldenrod;">
:<br>The domain controller must be fully configured, up and running when configuring subordinated host controllers, since we need to interact with the domain controller during the subordinated host controller installation (create users, etc.)<br><br>
</blockquote>
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Subordinate WildFly Host Controller Post-Install Configuration]]
</blockquote>
=Start WildFly as a Service on Linux=
<blockquote style="background-color: #f9f9f9; border: solid thin lightgrey;">
:[[Start WildFly as a Service on Linux]]
</blockquote>
=Smoke Tests=
==Automatic Startup==
The installation procedure should have configured the System V/systemd startup scripts, so reboot the host in question. JBoss should start automatically and correctly upon reboot:
<pre>
reboot
...
journalctl -u jboss-host-controller.service
...
Feb 16 13:49:42 dc1 systemd[1]: Starting EAP Host Controller Service...
...
Feb 16 13:49:55 dc1 jboss-host-controller[760]: [  OK  ]
Feb 16 13:49:55 dc1 systemd[1]: Started EAP Host Controller Service.
</pre>
==Control Scripts==
Exercise the control scripts, the instance must stop/start correctly.
===systemd===
<pre>
systemctl stop jboss|jboss-host-controller
...
journalctl -u jboss-host-controller.service
Feb 16 13:49:55 dc1 systemd[1]: Started EAP Host Controller Service.
Feb 16 13:52:50 dc1 systemd[1]: Stopping EAP Host Controller Service...
Feb 16 13:52:50 dc1 jboss-host-controller[760]: *** JBossAS process (2099) received TERM signal ***
Feb 16 13:52:51 dc1 jboss-host-controller[2245]: Stopping jboss-as: [  OK  ]
Feb 16 13:52:51 dc1 systemd[1]: Stopped EAP Host Controller Service.
</pre>
<pre>
systemctl start jboss|jboss-host-controller
...
journalctl -u jboss-host-controller.service
...
Feb 16 13:54:08 dc1 systemd[1]: Starting EAP Host Controller Service...
...
Feb 16 13:54:14 dc1 systemd[1]: Started EAP Host Controller Service.
</pre>
===System V===
<pre>
service jboss|jboss-host-controller stop
service jboss|jboss-host-controller start
</pre>
==Logs and Files==
Verify that <tt>$JBOSS_HOME/domain/log</tt> is created and it is owned by the user supposed to run JBoss.
Verify that <tt>console.log</tt>, <tt>host-controller.log</tt>, <tt>process-controller.log</tt> ... exist in the log directory.
Verify that <tt>$JBOSS_HOME/domain/servers</tt> contains directories corresponding to the servers declared in <tt>host.xml</tt>.
==Java Processes==
<pre>
ps -ef | grep java | grep --color "\-D\[.*\]"
</pre>
Look for "Process Controller", "Host Controller" and the "Server: ..."
Optionally, add this to the JBoss account:
<pre>
alias jbprocs='ps -ef | grep java | grep --color "\-D\[.*\]"'
</pre>
Alos see [[JBoss Convenience Aliases]].
==Startup Errors==
For each server, cat <tt>$JBOSS_HOME/domain/servers/<server-name>/log/server.log</tt> and make sure the server started with no errors.
<pre>
cat server.log | grep ERROR
cat server.log | grep WARN
</pre>
You should get zero errors and warnings.
Repeat the same operations after reboot.
==Connect with CLI==
<pre>
cd $JBOSS_HOME/bin
jboss-cli.sh
</pre>
<font color=red>'''TODO:''' more details here.</font>
==Cluster Topology==
Verify cluster topology with the CLI: [[WildFly CLI - Navigate Domain Topology]]
Verify cluster topology with the management console: [[WildFly Management Console - Navigate Domain Topology]]

Latest revision as of 22:19, 13 March 2017

Internal

Relevance

  • EAP 6, EAP 7

Overview

This document describes the WildFly "manual" installation procedure. It consists in unzipping a release zip file and configuring the deployment. It applies to both standalone and domain mode for WildFly and EAP releases. Additional configuration such as enabling SSL, adding data sources, adding HA to the domain controller, etc. can be performed after the installation. The examples below mention "jboss", as the procedure was applied to an EAP installation.

The entire installation procedure has been automated with em to create EAP-based Amazon EC2 environments.

Extract Release from ZIP File

The operations described below apply to both standalone and domain mode installation, and in case of domain mode installation, they must be repeated on all hosts of the domain, unless specified otherwise.

Extraction User

Unzip in place as the user intended to run the server. For example, if the application server will be run by an "eap" user, become that user and extract under that user's identity. If there are no sufficient permissions on the parent directory, temporarily lessen the permission during the unzip operation, then restore more restrictive permissions on the parent folder.

Unzip

unzip .../jboss-eap-6.4.0.zip

The operation will create a ./jboss-eap-6.4 directory.

Apply Patches if Necessary

Note that the above example refers to an "unpatched" deployment. If patches are available, and their installation is desired, start the EAP instance in standalone mode and apply the patches in place:

cd jboss-eap-7.0/bin
./standalone.sh
./jboss-cli.sh -c 
patch apply /home/eap/jboss-eap-7.0.4-patch.zip

Create a Symbolic Link

ln -s ./jboss-eap-6.4 jboss

If patches were applied, modify the original directory to reflect the patch level, and then create the link:

mv jboss-eap-7.0 jboss-eap-7.0.4
ln -s ./jboss-eap-7.0.4 jboss

Optional for a Standalone Installation

If you perform a standalone installation you can remove the domain subdirectory to reduce the clutter and confusion. You won't need it.

Optional on a Host Controller and/or Domain Controller

This applies when we install a host controller and when the host controller is also the domain controller: the standalone directory can be removed.

cd jboss
rm -r standalone
cd bin
rm standalone *

Optional on a non-Windows Machine

The *.bat files from bin can be removed.

cd jboss/bin
rm *.bat

Post-Install Configuration

Post-Install Configuration User

Perform all post-install configuration operations as the JBoss runtime user.

Unset the JBOSS_HOME Environment Variable

If the JBOSS_HOME value is accidentally set to point to another WildFly deployment, it will interfere with the next steps, so it is best if you unset it.

Security

Add a management user, conventionally named admin. Note that this user does not represent the identity used by a subordinate host controller to connect to the domain controller, that will be configured later. The procedure is described here:

Adding a User to the Management Realm

Network

Configure the bind addresses for management and public interfaces. The bind address of the management interface can be set externally with jboss.bind.address.management system property. The bind address of the public interface can be set externally with jboss.bind.address system property.


Note that in domain mode, host controllers connect to the domain controller's management interface native endpoint to get domain configuration, so the domain controller management functions have to be externally accessible over the management interface, hence the management interface has to be visible on the management (internal) network. A subordinate host controller does not have to expose its management interface. The public interface must be configured on all hosts and accessible externally, provided that the server instances must be available externally.
For more details see Domain Controller/Host Controller Communication

Standalone Node

Set 'jboss.bind.address' as described here

Domain Controller

Will be described in detail in the Domain Controller Configuration section below.

Subordinate Host Controller

Will be described in detail in the Subordinate Host Controller Configuration section below.

Extra Standalone Configuration

Some of the standalone-*.xml files can be removed if you know that you are not going to use those profiles.

Domain Controller Configuration

WildFly Domain Controller Post-Install Configuration
Start WildFly as a Service on Linux

Subordinate Host Controller Configuration


The domain controller must be fully configured, up and running when configuring subordinated host controllers, since we need to interact with the domain controller during the subordinated host controller installation (create users, etc.)

Subordinate WildFly Host Controller Post-Install Configuration

Start WildFly as a Service on Linux

Start WildFly as a Service on Linux

Smoke Tests

Automatic Startup

The installation procedure should have configured the System V/systemd startup scripts, so reboot the host in question. JBoss should start automatically and correctly upon reboot:

reboot
...
journalctl -u jboss-host-controller.service
...
Feb 16 13:49:42 dc1 systemd[1]: Starting EAP Host Controller Service...
...
Feb 16 13:49:55 dc1 jboss-host-controller[760]: [  OK  ]
Feb 16 13:49:55 dc1 systemd[1]: Started EAP Host Controller Service.

Control Scripts

Exercise the control scripts, the instance must stop/start correctly.

systemd

systemctl stop jboss|jboss-host-controller
...
journalctl -u jboss-host-controller.service
Feb 16 13:49:55 dc1 systemd[1]: Started EAP Host Controller Service.
Feb 16 13:52:50 dc1 systemd[1]: Stopping EAP Host Controller Service...
Feb 16 13:52:50 dc1 jboss-host-controller[760]: *** JBossAS process (2099) received TERM signal ***
Feb 16 13:52:51 dc1 jboss-host-controller[2245]: Stopping jboss-as: [  OK  ]
Feb 16 13:52:51 dc1 systemd[1]: Stopped EAP Host Controller Service.
systemctl start jboss|jboss-host-controller
...
journalctl -u jboss-host-controller.service
...
Feb 16 13:54:08 dc1 systemd[1]: Starting EAP Host Controller Service...
...
Feb 16 13:54:14 dc1 systemd[1]: Started EAP Host Controller Service.

System V

service jboss|jboss-host-controller stop
service jboss|jboss-host-controller start

Logs and Files

Verify that $JBOSS_HOME/domain/log is created and it is owned by the user supposed to run JBoss.

Verify that console.log, host-controller.log, process-controller.log ... exist in the log directory.

Verify that $JBOSS_HOME/domain/servers contains directories corresponding to the servers declared in host.xml.

Java Processes

ps -ef | grep java | grep --color "\-D\[.*\]"

Look for "Process Controller", "Host Controller" and the "Server: ..."

Optionally, add this to the JBoss account:

alias jbprocs='ps -ef | grep java | grep --color "\-D\[.*\]"'

Alos see JBoss Convenience Aliases.

Startup Errors

For each server, cat $JBOSS_HOME/domain/servers/<server-name>/log/server.log and make sure the server started with no errors.

cat server.log | grep ERROR
cat server.log | grep WARN

You should get zero errors and warnings.

Repeat the same operations after reboot.

Connect with CLI

cd $JBOSS_HOME/bin
jboss-cli.sh

TODO: more details here.

Cluster Topology

Verify cluster topology with the CLI: WildFly CLI - Navigate Domain Topology

Verify cluster topology with the management console: WildFly Management Console - Navigate Domain Topology