Disclaimer: Eventhough we aren’t deploying the Custodian Console under GlassFish, we spent some time playing and this overview may help some lost soul out there. (And some of the knowledge was transferrable to our current deployment method.)
GlassFish v3 is a reference implementation of Java EE 6. Quite a mouthful. For Rails developers: it uses some of the latest and greatest technology available on the Java 6 Enterprise Edition, and that means the deployment environment is going to need JDK 6 (Java Development Kit), which clocks in between 42-63MB.
The GlassFish application server has first class support for two deployment methods for Rails applications:
(Technically, you could use the GlassFish gem and deploy your applications this way, but it seems to be the same style of deployment you all know and love with mongrel/thin/unicorn/etc – and who wants to read another article about that?)
The differences between the deployment methods are subtle but important: a WAR can have JRuby bundled with it, whereas you’ll need to install JRuby separately with directory deployment. A WAR deploy can get you closer to a self-contained application, if that is your goal. Additionally, with the WAR file, you can drop it into the GlassFish autodeploy directory and the application server will automagically detect it and deploy. (We use Warbler, a library that will take a Rails application and package it up in a WAR with JRuby and jruby-rack, both of which you need.)
A note on asadmin: Most of what you do with GlassFish will be done using the asadmin command. In fact, it seems to be the hub of the GlassFish universe.
Installation is a simple affair – just head over to GlassFish v3 Downloads and pick your poison. There is a GUI installer for Windows, Solaris, Linux and MacOSX. Thankfully, there is also a platform independent zip file.
Here is where it gets interesting(?) … *deep breath* This GlassFish “server” can house multiple domains, which in turn, have many server instances, and these server instances are where your applications are deployed. *whew!* A good resource for truly understanding the GlassFish architecture is GlassFish Administration by Xuekun Kou (also on Safari Books Online). Luckily, with the out-of-the-box install you get a default domain (domain1) and a default server instance. Remember that GlassFish is intended to do all the fancy things that a Java application server can do, so you can have clustering, multiple domains, multiple applications running in a single domain, the same application running on multiple server instances – pretty much whatever you can think of.
Deploy That App!
So, GlassFish is installed. You need asadmin to get things going.
> asadmin start-domain
This command will, um, start the domain. (If you had the war file in autodeploy, or if the application had been previously deployed, it would be deployed/started during domain initialization.) GlassFish features a fairly complete administrative UI which is available at http://yourserver:4848. The admin site takes a little bit to start up as GlassFish doesn’t load anything until it is requested, this includes your Rails application. That first request is a biggie! From the admin site you can monitor performance, view logs, change settings, and all kinds of fun stuff. Take a look around, and ask yourself, “Do I really need any/all of this?”.
Deploy from a directory or “It sounds easy but it may be the same dance you do now”
Remember, if you aren’t bundling JRuby with your application you’ll need to tell GlassFish where it is …
> asadmin configure-jruby-container --jruby.home=/path/to/jruby-x.x.x
and you’ll need to have all the gems installed, etc, etc. (Sound familiar?) In this case, it would be wise to have your gems vendored in your Rails application. From the directory above your rails application run:
> $GLASSFISH_HOME/bin/asadmin deploy your-rails-app/
This will deploy the application to your server at http://localhost:3000/your-rails-app. Any errors will be available in $GLASSFISH_HOME/domains/domain1/logs/server.log
Deploy from a WAR or “It sounds easy and it is“
Assuming you’ve got your Rails application all WAR’d up (using Warbler, of course). Warbler ensures that JRuby, jruby-rack, and all your gems are included.
> asadmin deploy /path/to/your-rails-app.war
This will deploy your application to your server at http://localhost:3000/your-rails-app. Same as above. Notice you didn’t have to do anything to tell GlassFish about JRuby or the gems. Nice!
Alternatively, you can drop your-rails-app.war in $GLASSFISH_HOME/domains/domain1/autodeploy and GlassFish will do the rest.
Making your app the root application (and changing the deployed app name)
You may want your rails application to be available at http://localhost:3000/ (or the root of the server). Again, asadmin is your friend:
> asadmin deploy --contextroot / /path/to/your-rails-app.war
Now your application is served at the root of the GlassFish server instance.
Want to change the name of the deployed application?
> asadmin deploy --name myapp /path/to/your-rails-app.war
Now you have http://localhost:3000/myapp
As mentioned earlier, GlassFish would seem to shine when used for internal application deployments where you want to leverage existing infrastructure by hosting multiple Rails application within a single GlassFish install or using the GlassFish clustering options. Imagine using Capistrano to just push up the newest WAR and having GlassFish autodeploy that, no more stopping and starting your webservers! The monitoring and administration would also provide you with insight that isn’t provided in other Rails installation methods.
We played with GlassFish for a bit and decided that for our purposes it was a bit heavy. What were we looking for?:
- easy deployment (not just for internal techies)
- ability to provide a zip file with everything needed in it, no install needed
- no admin UI
- deploy without dependence on a central command (asadmin anyone?) – we could have used autodeploy here
- smallest download possible
- least amount of external dependencies (GlassFish requires the JDK and your run-of-the-mill Rails app isn’t going to need all that!)
Keep in mind our Custodian Console is a Rails application installed at customer sites, we do not always have direct access to the servers so we need deployment to be fire and forget. This led us to pursue Tomcat as an alternative and this set up will be the topic of a future post.