Announcement: TorqueBox

18 May 2009

java jboss rails ruby

I announced the TorqueBox project today.

It's the coolest platform for your Ruby applications, ever. Really.

New JBoss-Rails Release & Reminder

03 December 2008

java jboss jruby rails

Just a reminder, in case anyone didn't make the jump..

My Ruby/Rails/JBoss blogging is going on over at Odd Thesis these days.

That includes this announcement about the 1.0.0-Beta-2 release that just popped.

Workblog

10 November 2008

java jbor jboss rails

Just when I've trained my boss to read this blog to keep up with my status, I go and launch another blog, specifically for my workstuff. In addition to blogs about JBoss things, it'll include other documentation for building, installing and using the related projects. The projects are grouped into constellations based around theses. Hence the name:

In addition to being a new blog, it's also my attempt to eat my own dogfood and prove it all works in the Real World.

The Odd Thesis site runs entirely on the JBoss-Rails stack.

I'll still blog random crap here at fnokd, but if you're looking for my JBoss experiments, add the Odd Thesis feed to your reader. I've initially imported appropriate posts and comments from this blog.

Preliminary slides for JBoss-Rails at RubyCamp

18 October 2008

java jboss ruby rubycamp slides

Thanks to the typical demo demons, I've been unable to get everything functioning perfect for instantaneous clustering on EC2 by tomorrow.

Oh well.

But here's the first draft of some slides I'm taking with me to the Raleigh RubyCamp.

It's a BarCamp style event, so I anticipate the slides probably changing throughout the day. I'll published updates if needed.

Boot up JBoss

16 October 2008

java jboss rails thincrust virtualization vmware

On my path towards clustering a Rails app on JBoss on EC2, I stumbled across Bryan Kearney and the other Thincrust guys. With their help, I now have a JBoss AS5 + jboss-rails "appliance" ready to roll.

Grab the raw image or the VMWare image, and play along at home.

Fire up the image in your favorite virtualization environment. I give my virtual machine at least a gig of RAM. Marvel at the pretty Grub splash screen, courtesy of James Cobb (JBoss.org designer).

Let it boot on up, and you'll notice a handful of things:

  • Very few things roll across during boot. The image is an assembly of "just enough" OS bits.
  • Before JBoss boots, "Installing Appliance" or "Updating Appliance" will scroll by. This is the Thincrust magic that allows adjustment of the appliance in a consistent and controlled manner (via Puppet).
  • JBoss AS 5 (with rails deployer) starts at boot.

You can login with root password of thincrust.

The login prompt will tell you the IP address of the appliance, since it probably booted off DHCP. JBoss will be up and running at http://<IP_ADDRESS>:8080/.

You can su jboss, whose $HOME is /opt/jboss/jboss-as5, which coincidentally is $JBOSS_HOME. The default configuration is used to start the AS. Logs are under /opt/jboss/jboss-as5/server/default/log/. And to deploy, just drop something into /opt/jboss/jboss-as5/server/default/deploy/ and it'll hot-deploy.

To control the service, as root:

  • service jboss stop
  • service jboss start
  • service jboss status

I'll make the RPMs used to build this available sometime soon. Until then, you can poke around the bits I use to create the RPMs ultimately used by Thincrust to build the appliance image. They are packaged in a way that makes my Red Hat brethren throw up in their mouths a little bit.

Also, once I test'em on EC2, I'll throw out public AMIs for testing.

By no means is this complete. This just marked a nice spike of a milestone along the way. There's still plenty of things that'll poke you in the eye if you're not careful. Always wear your safety harness. Drink plenty of fluids. Keep away from children.

Stumbling through technology

11 October 2008

ec2 java jboss puppet thincrust virtualization

It can sometimes be funny, the paths we take.

Once I'd verified that a Rails app deployed on JBoss would indeed cluster, I sat in my farmhouse, looking at my lone little Mac. Not much of a cluster to play with.

So I started looking at Amazon EC2, which is truly very nice, particularly when paired with Elasticfox.

Of course, firing up a cluster on EC2 requires a nicely-produced, ready-to-boot machine image or a lot of manual configuration on each node.

Sacha pointed me to another group within Red Hat: Thincrust.

Thincrust configures a Fedora disk image with "just enough" OS bits, and provides a way to add/update applications on it. It's a happy mixture of Kickstart, Puppet and Yum.

The goal is to make it easy to produce "appliance" images that could be flung onto machines, real or virtual. Need a Git server? Fire up the Git appliance on the cloud. Need a Drupal server? Fire one of those up. Need a JBoss server or cluster? We're working on that..

Thincrust is built upon Fedora. My Mac is not. But VMWare Fusion lets me run Fedora. So I can create Fedora-based Thincrust images. Which I'll deploy on EC2. Which is running Xen, probably on RHEL. And ultimately allowing you to run your Ruby-on-Rails applications on a Java stack.

There are times I can't remember exactly which OS, language, or virtualization environment I should be thinking in.

Reminder: RaleighRubyCamp

30 September 2008

barcamp java jruby raleigh ruby

Don't forget, in a few weeks at the Red Hat offices in Raleigh, there will be an unconference-style Ruby BarCamp on October 18th.

My plan is to put together a few clumps of slides, prepare a cluster on EC2, and see if anyone wants to hear about JBoss Rails. I'll of course put them online sometimes before/during/after the camp, since that's part of the rules.

Multiple instances of AS on OSX

29 September 2008

java jboss osx

Rysiek asked me to elucidate my clustering on OSX...

By default, it seems that OSX provides exactly 1 localhost address, unlike RHEL. I normally make use of 127.0.0.1/24 when I'm deploying on Linux, and figured I'd do the same on OSX.

To accomplish this, you need to create some new localhost IPs to play with.

  
sudo ifconfig lo0 alias 127.0.0.10 up
sudo ifconfig lo0 alias 127.0.0.11 up
sudo ifconfig lo0 alias 127.0.0.12 up

Now, when you run your AS with ./run.sh, just pass -b 127.0.0.10 or -b 127.0.0.11 etc, and the entire stack will bind to that IP address.

At this point, I'm allowing each AS instance to share a work directory and such, which is probably not exactly the safest thing to be doing. Normally each cluster node would be a discrete machine with its own JBOSS_HOME.

For the apache config, in /private/etc/apache2/httpd.conf, I uncommented the line to allow vhost file loading:

  
# Virtual hosts
Include /private/etc/apache2/extra/httpd-vhosts.conf

Then, in the httpd-vhosts.conf file I fixed it up to include my virtual host for the head-end load-balancing stuff.

The <VirtualHost> is only barely conformant, and even the DocumentRoot is gratuitous, really. It looks like this:

  
<VirtualHost *:80>
  ServerName app.local.ballast
  DocumentRoot "/Users/bob/public_html"

  RewriteEngine on

  RewriteMap    lb      'prg:/Users/bob/bin/load_balancer local.ballast 1 3'
  RewriteRule   ^/(.*)$ ${lb:$1}           [P,L]
</VirtualHost>

What that is doing is passing each requested path to the load_balancer script I've borrowed from I-don't-know-'where. It returns an augmented URL pointing to one of my localhost-bound nodes.

  
#!/usr/bin/env perl
##
##  lb.pl -- load balancing script
##

$| = 1;

$name   = $ARGV[0];         # the hostname base
$first  = $ARGV[1];         # the first server (not 0 here, because 0 is myself)
$last   = $ARGV[2];         # the last server in the round-robin

$cnt = 0;
while (<STDIN>) {
    $server = sprintf("node%d.%s", $cnt+$first, $name);
    $cnt = (($cnt+1) % ($last+1-$first));
    print "http://$server:8080/$_";
}

If a path of /foo/bar is handed to it on STDIN, it'll return something in the format of http://node1.local.ballast:8080/foo/bar or http://node2.local.ballast:8080/foo/bar.

Through the magic of /etc/hosts those friendly names point to the localhost bound AS cluster nodes, along with app.local.ballast pointing to good old traditional 127.0.0.1, where httpd is normally listening. That's my head-end from the httpd-vhosts.conf.

  
127.0.0.1       localhost app.local.ballast

127.0.0.10      node1.local.ballast
127.0.0.11      node2.local.ballast
127.0.0.12      node3.local.ballast

Fire up a browser and I surf to http://app.local.ballast/, apache answers, and immediately and invisibly proxies the request to port 8080 of one of my localhost-bound JBoss AS instances.

Nice.

JBoR: Will it cluster?

29 September 2008

clustering java jboss jbosscache jruby rails

JBoss on Rails will indeed cluster!

After modifying and dropping my jboss-rails.deployer into an 'all' configured server of JBoss AS 5, and firing up 3 instances on my localhost (non-trivial on OSX...):

  
10:43:28,409 INFO  [RPCManagerImpl] Received new cluster view: [127.0.0.10:63740|2] [127.0.0.10:63740, 127.0.0.11:63747, 127.0.0.12:63749]
10:43:28,435 INFO  [RPCManagerImpl] Cache local address is 127.0.0.12:63749
10:43:28,469 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Poblano' 2.2.0.GA

And I've got 3 nodes running the same Rails app, all sharing a cookie and a JBossCache cache. Nick Sieger's JRuby-Rack handles binding the Rails session to the actual servlet session, and JBossCache takes care of the rest.

A little 8-line perl round-robinning load-balancer is wired up through mod_rewrite in my Apache httpd.conf to throw requests to each of the nodes. Anything set in the session is immediately available at the next request which lands at a different node.

Further down the line, we can look at a clustered cache for caching AR models and view fragments. Not too shabby.

It should be fairly easy to create a nice Amazon EC2 AMI with Fedora+AS5+jboss-rails, plus some better Rake/capistrano tasks, and make for quick cluster deployment. Any EC2 experts wanting to jump in?

Print like you mean it

23 September 2008

eclipse enscript java printing

When digging through code, I find it's good to print it out, wander off away from the machine, and do some reading.

But if you print any reasonable-sized chunk of code from Eclipse, you'll be carrying around several reams of paper, since Eclipse apparently thinks we're all blind illiterates.

For the past decade, my friend & mentor Jim Crossley and I have been passing the same encscript alias back and forth. I recently had to request it from him again. (Mental note: put it in SCM somewhere...)

  alias print='enscript --color=blackwhite -E -T4 -M Letterdj -C -2 -fCourier@5/5 -r $*'

It'll spew out your code in landscape mode, syntax-highlighted, two columns of 90 lines each (180 lines total per page), with line-numbers and a nice-looking header.

Many times, this allows you to fit an entire class on a single sheet without any gratuitous wrapping due to Eclipse's 24pt font usage.