|
|
| Home > Apache Geronimo v1.0 > Documentation > Apache Geronimo v1.0 - User's Guide > Performance and high availability > Remote HTTPd Server |
Apache Geronimo comes in two flavors depending on the Web container you decide to use. You may choose between the Tomcat or Jetty distributions. If you want to place a HTTPd in front of Geronimo you will have to configure it in such way it can forward client requests to Geronimo.
This article will cover two different ways on how Apache HTTPd can be configured to forward client requests to Geronimo, this is configuring it as a reverse proxy using the "built-in" mod_proxy module or configuring the Jakarta Tomcat Connector mod_jk available with the Apache Tomcat source.
When configuring a reverse proxy in the Apache HTTPd, that configuration will work for any distribution of Geronimo (Tomcat or Jetty) you may have without the need for any additional configuration on the Geronimo side.
When configuring the Jakarta Tomcat Connector, additional configuiration will be required. There will be a number of new terms that will be addressed as needed but keep in mind the scope of this article is to configure a two-tier scenario with a remote HTTPd.
Based on these two alternatives, this article is organized in the following sections:
In order to set a common ground for this configuration example, here is a list with the versions tested:
This is the simplest way to re-route requests from the Apache HTTPd to the Geronimo servers (or any other server you may have). To use this feature you will need to enable some specific modules and add a few lines to the HTTPd configuration. These steps are described next.
You may need to add more ProxyPass directives depending on the requirements of your application. The last ProxyPassreverse directive captures the responses from the Geronimo server and masks the URL as it would be directly responded by the Apache HTTPd hiding the identity/location of the Geronimo server.
 | In this example the console has been enabled just for demonstation purposes. In a production environment you will not want to have the console accessible from the other network (normally the Internet). Having the console accessible represents a big security exposure.
The rule is that everything should have restricted access, normally a firewall would be placed in between the HTTP and the application server (depending on the topology) and you should map just the minumum resources necessary to have your application working from the other side. |
If both HTTPd and Geronimo servers are in the same machine you can use localhost for the redirection, when the servers are located in different machines you would have to specify the URL for the Geronimo server.
As the result of this configuration, when you point your browser to http://locahost/console, the request will be redirected to http://localhost:8080/console. This option allows to re-route URLs and ports.
The communication between the HTTP server and Geronimo can be also done via AJP connectors. By default, both Apache Geronimo distributions (Jetty and Tomcat) have already predefined one AJP v13 listener, the ports where these listeners are defined varies from one distribution to the other.
This section will cover the configuration for both Geronimo distributions as the steps are very similar (if not equal).
The Jakarta Tomcat Connector mod_jk module is provided as a connector from Apache Tomcat source, Jetty (and obviously Tomcat) is fully compatible with this connector. This module is avaiable when you download the Tomcat source, but also is available for download separately, refer to the following URL for the proper version for your system.
http://tomcat.apache.org/download-connectors.cgi
In addition to the mod_jk you will require the workers.properties file, also available with the Apache Tomcat source distribution. This properties file tells the mod_jk plugin how to connect to the Geronimo server. For a detailed explanation on all the available options for configuring the Jakarta Tomcat Connector visit the following URL:
http://tomcat.apache.org/connectors-doc/config/workers.html
 | For practical purposes, the module mod_jk_1.2.6_2.0.50.dll for Windows and the workers.properties are included in the Attachments section in this article. |
Download the appropriate mod_jk for your platform from the Tomcat web site, rename it to mod_jk.dll (or .so depending on your platform) and copy it into the <httpd_home>\modules directory. Download and extract the workers.properties from the Apache Tomcat source (alternatively, download it from the Attachments section) to the <httpd_home>\conf directory.
Edit the httpd.conf file located in the <httpd_home>\conf directory to load the Jakarta Tomcat Connector mod_jk module. Add the following lines at the end of the httpd.conf file.
LoadModule jk_module modules/mod_jk.dll # Loads the Jakarta Tomcat Connector module JkWorkersFile <httpd_home>\conf\workers.properties # Tells the module the location of the workers.properties file JkLogFile <httpd_home>\logs\mod_jk.log # Specifies the location for this module's specific log file JkLogLevel info # Sets the module's log level to info JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # Sets the module's log time stamp format JkAutoAlias <httpd_home>\config-store # Automatically Alias webapp context directories into the Apache document space. JkMount /console/* ajp13 # Sets a mount point from a context to a Tomcat worker. In this case will allow access (forward the request) to the console.
JkMount will map anything behind /console/ to the worker ajp13. The name ajp13 is defined in the workers.properties file which is described next. You will need to add more JkMount directives depending on the applications you want to be accessed via the remote HTTPd.
| In this example the console has been enabled just for demonstation purposes. In a production environment you will not want to have the console accessible from the other network (normally the Internet). Having the console accessible represents a big security exposure.
The rule is that everything should have restricted access, normally a firewall would be placed in between the HTTP and the application server (depending on the topology) and you should map just the minumum resources necessary to have your application working from the other side. |
The workers.properties, among other things, tells the HTTPd where the Geronimo server is, what version of AJP should use and the port where Geronimo is listening.
Edit the workers.properties file located in the <httpd_home>\conf directory to match your environment. The following example is an excerpt from the workers.properties file with just the variables you should focus on.
workers.java_home=<java_home> # Sets the JAVA_HOME ps=\ # For Windows systems use back slash "\" , for Unix systems use forward slash "/" worker.ajp13.port=8009 # Use default 8009 for Apache Tomcat # Change this value to 8019 for Jetty worker.ajp13.host=localhost # Specifies the location of the Geronimo server. Use default localhost for single-tier scenarios. Specify the hostname of the Geronimo server for multi-tier environments. worker.ajp13.type=ajp13 # Sets the version of AJP used. The AJP listeners defined in Geronimo are AJP v13.
From this example note how the name of the worker is defined, look at the variables definition worker.ajp13.* , ajp13 is the worker name you specified earlier in the httpd.conf.
As a last step, stop and restart the Apache HTTPd to ensure these changes are loaded.
For testing this configuration make sure both Geronimo and HTTPd are up and running.
, you should see the Geronimo Administration Console. , you should see the Apache HTTPd welcome page. , you shoud be redirected to the Geronimo Administration Console. Note at the end of the URL there is a "/", failing to include this / will result in a Not Found error triggered by the Jakarta Tomcat Connector module.
