Coming Up for Air

Virtual Hosting using Apache and GlassFish

While many have found GlassFish to be a great choice for an internal application server, there are others that would like to push it a bit further, and use it in an ASP/ISP envrionment. Jan Luehe discussed GlassFish’s virtual hosting features in a recent blog entry. What I’d like to do in this entry is take the information that Jan presented, and walk through setting up a few different virtual hosting environments.

Terms to Know

Before we go too far, we need to make sure we’re all using various terms in the same manner. To summarize Shreedhar Ganapathy’s excellent discussion, a domain in GlassFish terms is an "administrative area." It should not be confused with DNS domains. A domain will have one or more servers defined. These servers correlate, roughly, with a ServerName in Apache’s httpd.conf (and, like a ServerName can have `ServerAlias`es, a server can be given aliases). For the sake of this discussion, we will not give any attention to clustering or load balancing.

Before a vhost environment can be set up, one must ask: Do the vhosts need to be completely separated from each other? That is to say, will the production environment need to be configured in such a way that an administrator for one group of servers can not touch another group of servers? If you intended to have one administrator admin all servers, you can probably get by with one domain. However, if you need to allow a user to administer his servers without having access to another user’s servers, then you will need to create additional domains. We’ll start with the simple case, and look at multiple servers in one domain.

One Domain, Multiple Servers

We’ll start by configuring GlassFish. We’ll use two vhosts, vh1 and vh2. To add a virtual server from the admin console, go to Configuration→HTTP Service→Virtual Servers:

virtual servers 01.thumbnail
Figure 1. Virtual Server screen

Click add, and fill out the form:

virtual servers 02.thumbnail
Figure 2. 'Adding a virtual server"

I’ve chosen to use http-listener-1 only, as I only care about http://vh1:8080/ being available. Repeat the process for server vh2. For those that prefer the command line, the server can be created with this command:

asadmin create-virtual-server --user admin --hosts vh1 --httplisteners http-listener-1 vh1
asadmin create-virtual-server --user admin --hosts vh2 --httplisteners http-listener-1 vh2

While there are a myriad of options regarding port usage, I like to have Apache handle requests on port 80, and forward requests for my vhosts to the appropriate server behind it, so let’s take a look at that configuration:

<VirtualHost *:80>
    ServerName vh1
    ProxyPass / http://vh1:8080/
    ProxyPassReverse / http://vh1:8080/
<VirtualHost *:80>
    ServerName vh2
    ProxyPass / http://vh2:8080/
    ProxyPassReverse / http://vh2:8080/

With that, your virtual hosts should be ready. To test that things are working correctly, let’s deploy two applications (which, I’m afraid, you’ll have to supply :) ).

app deployment 01.thumbnail
Figure 3. Deploying an app to a virtual server

Command line users can do:

asadmin deploy --virtualservers vh1 AppA.ear
asadmin deploy --virtualservers vh2 AppB.ear

With these apps deployed, http://vh1/AppA should get your app, while http://vh2/AppA should get a 404, and vice versa. If you deploy a third app and do not specify a virtual server:

asadmin deploy AppC.ear

then http://vh1/AppC and http://vh2/AppC will both work. Here are some rules to keep in mind:

  • If, when deploying an application, a virtual server is not specified, then the app is available to all servers in that domain.

  • If an application is deployed to one or more specific virtual servers, then it will not be available to any virtual servers not in that list.

  • Likewise, if an application is deployed to one or more specific virtual servers, then it will not be available to be used as the <strong>Default Web Module</strong> for any virtual servers not in that list.

Multiple Domains, Multiple Servers

If you need to segregate administrative control amongst users, such as in an ASP/ISP environment, then you will need multiple domains. When you setup the server, the default domain, domain1, is created for you. Since a domain is an administrative area, one can not use the admin console to create another domain, and must use the asadmin command line tool. A session might look something like this:

$ asadmin create-domain --portbase 5000 --profile developer mydomain
Please enter the admin user name>admin
Please enter the admin password>
Please enter the admin password again>
Please enter the master password [Enter to accept the default]:>
Please enter the master password again [Enter to accept the default]:>
Using port 5048 for Admin.
Using port 5080 for HTTP Instance.
Using port 5076 for JMS.
Using port 5037 for IIOP.
Using port 5081 for HTTP_SSL.
Using port 5038 for IIOP_SSL.
Using port 5039 for IIOP_MUTUALAUTH.
Using port 5086 for JMX_ADMIN.
Domain being created with profile:developer, as specified on command line or environment.
Security Store used should be: JKS
Domain mydomain created.

The documentation has this to say about domains:

A domain, in addition to being an administrative boundary, is also a fully compliant Java EE Server. This means that you can can deploy your Java EE Applications to the domain and run them when the domain is started. A domain provides all the necessary environment and services that are essential to run the applications.

That being so, each domain will have its own set of ports. Note the use of the portbase option above. That instructs asadmin to start allocating ports starting at 5000 according to this pattern: * Admin port: portbase + 48, HTTP * Listener port: portbase ` + 80 * IIOP listener port: `portbase + 37 * JMX port: portbase + 86

We specified the developer profile, as we do not need clustering, high availability, etc., for our purposes here, but please note that option if you do indeed need those capabilities.

With our domain created and start (asadmin start-domain mydomain), we can now begin creating virtual servers and deploying applications in the same manner we did above. Note that, for those using Apache as the front end, the virtual host configuration will need to be adjusted accordingly:

<VirtualHost *:80>
    ServerName vh3
    ProxyPass / http://vh3:5080/
    ProxyPassReverse / http://vh3:5080/
<VirtualHost *:80>
    ServerName vh4
    ProxyPass / http://vh4:5080/
    ProxyPassReverse / http://vh4:5080/

and that your admin console is listening at http://localhost:5048/.


That should get you going! There are some details that have been glossed over (such as memory usage), but you should now have in your hands a step-by-step guide on creating, configuring, and maintaining virtual servers using GlassFish. If you have any questions, comments, corrections, etc., please feel free to leave a comment.

tags: GlassFish Java


Sample quote

Quote source