I'm writing a series of blog posts on How to Create and Configure WebSphere Liberty Cluster End-to-End. This particular post focuses on setting up Front-End Web Server. Below listed are all the posts in this series:
- How to Create and Configure WebSphere Liberty Cluster End-to-End
- How to Deploy Application in WebSphere Liberty Cluster
- How to Setup Front-End Web Server for WebSphere Liberty Cluster
 | ||
| Diagram 1.0 Example Topology: WLP Collective with Front-End & Deployment Server |
Note: in order to complete all the steps in this blog post, first you need to complete required steps in blog posts 1, and 2 in this series as stated above.
IHS powered by Apache with Plug-in for WebSphere Application Server (WAS) uses pre-configured workload management (WLM) policies to dispatch web requests to the appropriate cluster members and their containers. Having front-end web server like IHS also helps to boost security. To prevent single point of failure at the web server level, deploy an additional (backup or active) web server.
If you like to compare/review any other available front-end option, refer to Selecting a front end for your WebSphere Application Server topology.
Install IHS and IHS Plug-in for WAS
Note: In the example topology above IHS and Plug-in is installed and configured on Machine: 05.Providing installation instruction of IHS/Apache is out of scope for this post. This post assumes that you have Apache/IHS instance available to configure and integrate with WLP server. If you need to install IHS and WAS plug-in for IHS, refer to following:
For IHS:
https://www.ibm.com/support/knowledgecenter/en/SS7JFU_8.5.5/com.ibm.websphere.ihs.doc/ihs/tihs_silentinstall.html.
For Plug-in:
Installing the Web Server Plug-ins using the command line
Generate WAS plugin for IHS.
Generating WAS plug-in for IHS (plugin-cfg.xml) is easy but somehow trickier in WLP. Starting version 16.0.0.3, pluginUtility command comes with WLP, which makes it easy to generate plugin-cfg.xml. In fact from version 16.0.0.3, plugin-cfg.xml for each WLP server is generated automatically (triggered by different server events). You can see something like this in messages.log
com.ibm.ws.webcontainer.osgi.mbeans.PluginGenerator I SRVE9103I: A configuration file for a web server plugin was automatically generated for this server at /opt/ibm/wlp/usr/servers/wlpSrv02/logs/state/plugin-cfg.xml.See Automatic generation of the plugin-cfg.xml file in IBM Knowledge Center for more details.
And with the help of
pluginUtility, we can either merge individual plugin-cfg.xml or generate a brand new merged plugin-cfg.xml. As part of this exercise, we are going to generate merged plugin-cfg.xml. See command in action below:
$> cd /opt/ibm/wlp/bin |
As per input command above, it generates
plugin-cfg.xml under /tmp, which we will review later.For
pluginUtility command details and all available options, refer to pluginUtility command page at IBM Knowledge Center.
Note: If you are using WLP version 8.5.5.x where
pluginUtility command is not available, you can call the generateClusterPluginConfig operation on the ClusterManager MBean to generate a merged plugin-cfg.xml file for all started cluster members. For working code example, refer to topic Generating a merged plug-in configuration for Liberty servers at IBM Knowledge Center.| Troubleshooting: If your plugin-cfg.xml file generation fails with following error: The generation of the webserver plugin configuration file failed for the target collective controller. Analyze the logs of the target collective controller to diagnose the problem. And you see following message in your Collective Controller messages.log
... FFDC1015I: An FFDC Incident has been created: "java.net.NoRouteToHostException: No route to host (Host unreachable) com.ibm.ws.collective.repository.internal.ClusterManager 323" at ffdc_17.11.11_18.08.48.0.log
It is possibly caused by the firewall on the server machine(s). Make sure to open port(s) (listed in the server.xml) for communications on all member server(s) as well as controller.
|
Here is how our generated
plugin-cfg.xml looks like:
<?xml version="1.0" encoding="UTF-8"?>
|
As you can see, I've highlighted few lines above and let's discuss about those.
pluginUtilitydoes not create keystore related files (plugin-key.kdbandplugin-key.sth) referenced in theplugin-cfg.xmlfile. Later in the post, we will talk how to create these file manually.- Generated
plugin-cfg.xmlhas default values. If you need to generate plugin-cfg.xml with certain values, definepluginConfigurationelement (see below) inserver.xmland regenerate theplugin-cfg.xml.
<pluginConfiguration webserverPort="80"
webserverSecurePort="443"
sslKeyringLocation="path/to/sslkeyring"
sslStashfileLocation="path/to/stashfile"
sslCertlabel="definedbyuser"/>
For all available configuration attributes of pluginConfiguration, see IBM Knowledge Center
Establishing Secure communication between IHS/Plug-in and WLP servers
As you can see in the generatedplugin-cfg.xml, it has both http and https transport definitions. Https transport references the plugin-key.kdb/sth files, however, these files are
not generated by pluginUtility. So, we need to create them manually. Below, you'll find two ways to create them:1) Create key database (kdb) file and import Signer Certificate. For this purpose, you can use 'gskcmd' or 'IKEYMAN' that are installed as part of IHS. Below I'll show how to use 'gskcmd'.
$> cd /opt/IBM/HTTPServer/bin# member root certificate can be extracted from trust.jks file under # ${server.config.dir}/resources/security directory. |
2) Convert JKS file into KDB file. The following command takes jks file as an input and creates plugin-key.kdb, plugin-key.rdb, and plugin-key.sth files.
If you are using WAS generated keys, you can find signer certificate in trust.jks file on any member server under ${server.config.dir}/resources/security directory.
$> ./gskcmd -keydb -convert -db /tmp/trust.jks \ |
IHS Certificate
In order to secure communication between the client/browser and IHS, you need to have either CA signed certificate (preferred) or self-signed certificate for IHS. For this exercise, we are going to use self-signed certificate. Please note that if your front-end communication is not secure, then back-end communication (from plug-in to WAS WLP) is also going to be not secure (by default). If you like to know more detail on how it works, see Few Tips on Secure vs. Non-Secure WAS Web Server Plug-in Connection.Below command shows how to create a self-signed certificate using gskcmd:
$> cd /opt/IBM/HTTPServer/bin# create self signed cert:
|
IHS and plug-in Configuration
Now, we have everything in order to configure IHS and WAS plug-in for IHS. This configuration is very straight forward and can be done manually. For details refer to https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.wlp.doc/ae/twlp_admin_webserver_plugin.htmlVerify content of plugin-cfg.xml
- Make sure .kdb/.rdb/.sth file location is correct.
- log file location is correct.
- Both (http and https) transport definitions (host and port) are correct and resolvable from IHS server. You can do a telnet test for both http and https transport to verify.
Update plugin-cfg.xml if required.
Update httpd.conf
1) Add plug-in related configuration in httpd.conf:
LoadModule was_ap22_module /opt/IBM/WebSphere/Plugins/bin/64bits/mod_was_ap22_http.so
|
2) Add configuration for front-end secure communication
- Uncomment/enable the SSL module configuration directive.
- Create an SSL virtual host stanza in the httpd.conf file using the following examples and directives.
LoadModule ibm_ssl_module modules/mod_ibm_ssl.soListen 443<VirtualHost *:443>SSLDisableKeyFile "/opt/IBM/HTTPServer/ssl/ihs.kdb"
|
Start IHS:
#Start IHS:$> ./apachectl -k start
|
Review the
error_log (under /opt/IBM/HTTPServer/logs) and make sure it does not have any error and it loaded plug-in successfully
[Sat Nov 18 14:39:21.325566 2017] [ibm_ssl:notice] [pid 9:tid 139878623614720] Using GSKit version 8.0.50.77
|
And from http_plugin.log
[18/Nov/2017:14:39:21.39104] 00000009 07ac1700 - PLUGIN: Plugins loaded.
|
Access the application through IHS:
https://waslibhihs01/JavaHelloWorldApp
Hurray! Here is JavaHelloWorldApp
And, check the
access_log, you'll see something like this:
192.168.56.1 - - [18/Nov/2017:14:40:17 +0000] "GET /JavaHelloWorldApp/ HTTP/1.1" 200 705 13237 192.168.56.109:9444 +
|
If you encounter any issue, make sure Web Server Plug-in, WebSphere Liberty and IHS (powered by Apache) are compatible. Refer to Supported combinations of IBM HTTP Server, WebSphere Application Server, and the WebSphere WebServer Plug-in for more details.
Thank you coming so far! It is the end of this series!
Looks like you're really interested in WebSphere Liberty Profile, see my other related blog posts below:
- How to Create and Configure WebSphere Liberty Cluster End-to-End
- How to Deploy Application in WebSphere Liberty Cluster
- How to Setup Front-End Web Server for WebSphere Liberty Cluster (this post)
- Using Docker Secrets with IBM WebSphere Liberty Profile Application Server
- How to use WLP passwordUtilities feature for encryption/decryption
