ActiveMessaging is a great piece of code, but at first glance it appears to have a couple of wrinkles

• The standard configuration doesn’t support load balancing (so that you can talk to another broker if your normal one isn’t responding).
• The queues and topics you want to speak to are defined at class level – which is a problem if you want the queues to be dynamically defined based upon data values.

But thanks to Ruby, YAML and a bit of lateral thinking you can get around these issues.

ActiveMessaging uses the Stomp Gem under the hood, and that can do load balancing by itself. So all you have to do is get ActiveMessaging to pass the relevant incantations down to the Stomp Gem – intact. And you do that with a bit of fancy YAML. The trick is to add your host configurations to the login configuration entry in hash format like this:

 production:
    adapter: stomp
    login:
      :randomize: true
      :hosts:
      - :login: myloginid1
        :passcode: mypassword1
        :host: broker-host-1.somedomain.co.uk
      - :login: myloginid2
        :passcode: mypassword2
        :host: broker-host-2.somedomain.co.uk

The Stomp Connection class checks login to see if it is a hash and if it is uses that in preference to anything else. You can setup anything Stomp understands within that Hash. Check the class code for details.

The beauty of this approach is that it is entirely in the configuration. Your Rails code doesn’t need to know about it. The reconnection happens automatically in the background.

I’ve used an observer class within Rails to handle the message sending. It watches a model and sends messages when stuff is created and updated – nicely separating the concerns. But I wanted to talk to different queues depending upon what was in the model. So the standard ActiveMessaging::MessageSender approach didn’t seem appropriate.

After a bit of digging around it turns out that you can get hold of the broker connection directly rather than going via the Gateway.

client = ActiveMessaging::Gateway.connection

Then you can send to any queue you like, not just the ones defined up front in messaging.rb:

client.send("/queue/#{some_variable}", body, headers)

This is a lower level connection and you lose the filter chains and some error checking. However if you need it, it’s there.

I have released v2.1.2 of the Brightbox deployment gem onto Rubyforge today. This update to the gem is thanks to all the feedback we’ve received from customers over the summer.

The documentation on the wiki has been updated to cover the new features and fixes. If you have any tips or find any errors, you can edit the wiki yourself, or just let us know.

NEW FEATURES

Cluster support

The gem handles mongrels that are not on the same server as the web server. All you need do is set the mongrel host to ‘:remote’ and the gem will work out from your :app definitions where the mongrels are.

Nginx SSL support

Those using Nginx can now deploy SSL automatically in the same way as Apache.

Enhanced shared area management

We’ve improved the shared area system so that it now works globally across all your servers (assuming you have a shared network drive). Simply set global_shared_path to a directory on the network and list your shared directories and files in global_shared_dirs and global_shared_files.

Adjustable monit monitoring

You can now increase (or decrease) the amount of memory and cpu your mongrels are allowed to use and change the url that monit checks to determine if your application is working properly.

‘Rich’ maintenance page

Many customers are unhappy with the slightly stark standard Capistrano maintenance page. So we’ve improved the system allowing you to have a fully styled static web site where the simple maintenance page once lived.

Simple staging environment

The gem has been altered so that it will work properly with the standard Capistrano multistage extensions.

Easier management of rake tasks

Two new tasks have been created so that you can easily change and extend the rake tasks that are run after code deployment.

FIXES AND ENHANCEMENTS
Other improvements include:

• REST verbs now work with page cached content.
• The apache deflate module is on by default.
• The gem now detects which web server you have in place and manipulates the correct one.
• Separate error pages for each of the 5xx error pages on Nginx.
• Going into maintenance returns the correct 503 error and doesn’t change the URL.
• Static assets are cached aggressively in the browser, with fine control available in deploy.rb if required.

This guide is designed for the Intrepid Ibex version of Ubuntu (8.10) with a small addendum covering Hardy Heron (8.04.1).

The Debian/Ubuntu networking system is a bit opaque. It works via a default script in /etc/network/interfaces and is described in interfaces(5). (run man interfaces to read it).

This gives you all the standard entries, but it also points out that other packages can install scripts that extend the options the interfaces file understands. And that is how you configure Ethernet bonding.

Configure your switch

Almost certainly you will have to activate LACP on the relevant ports on your switch to get automatic bonding to work. How you do this depends on your switch. (On my test HP 1800-8G switch I just use the web interface and check a couple of boxes).

For Intrepid and Hardy

1. Install the bonding enslave programs and network scripts:

   apt-get install ifenslave

2. Shutdown any active network interfaces you intend to use with bonding

   sudo -s
   ifdown eth0
   ifdown eth1
   etc, etc...

3. Comment out the ethernet configurations from /etc/network/interfaces

   #auto eth0
   #iface eth0 inet dhcp

4. Add in the bonding configuration into /etc/network/interfaces

   auto bond0
   iface bond0 inet dhcp
     slaves all
     bond-mode 4
     bond-miimon 100

5. Bring up the interface with:

   sudo ifup bond0

This brings up a bonded interface using the 802.3ad Link Aggregation Control Protocol (LACP) which is by far the easiest way of configuring a resilient trunk if your switch supports it (and even quite small switches do these days).

There are other modes and options available in the bonding driver all of which can now be specified in the interfaces file. Full gory details in the bonding.txt.gz file in the current linux-doc package.

Similarly you can specify which network interfaces you want to use as the slaves to the bonding driver e.g. slaves eth0 eth1. Look at the documentation in /usr/share/doc/ifenslave-2.6/README.Debian for more details.

Extra Work for Hardy

Hardy’s ifenslave scripts are a little more primitive than Intrepid. It doesn’t auto-load the bonding module the first time you try to use it and it doesn’t set the options automatically. You have to do that the old fashioned way.

1. Create a file called bonding in /etc/modprobe.d with the following config in it.

   alias bond0 bonding
   options bond0 mode=4 miimon=100

2. Load the module into the kernel

   sudo modprobe bond0

3. Clear out any failed bond interface by running ifdown

   sudo ifdown bond0

4. Bring the bond interface up.

   sudo ifup bond0

5. Once you done this once, the system will ensure that the module is loaded automatically on subsequent reboots and the network brought up.

If you have this problem you should upgrade to Rubygems 1.2.0 or greater, which handles the index in a different and less resource intensive way. You will have to install the Rubygems update by hand. I have added some instructions to the wiki about how to do this.

The Ruby details are here: http://www.ruby-lang.org/en/news/2008/08/23/dos-vulnerability-in-rexml/ and the instructions for applying the monkey patch fix for Rails is on the security google group: http://groups.google.com/group/rubyonrails-security/browse_thread/thread/9fb60a1e22a88d30/330bcb96de877996#330bcb96de877996

Just to reiterate – this fault will affect the majority of Rails applications across all versions of Rails, whether you think you are processing XML or not, and we would urge all our customers (and all Rails users for that matter) to patch their applications until there is an upgrade to the Ruby libraries correcting the error.

Today we tagged and released v2.0.2 of our new Brightbox deployment gem on Rubyforge. It should be available just as soon as the main gem repository synchronises, or you can grab it from our testing repository at http://gems.brightbox.net/testing/

Documentation for the gem is on the wiki. If you have any tips or find any errors, please feel free to update the wiki yourself (or drop us a note if you’re shy!)

This gem is a complete rewrite, to take advantage of the latest features of Capistrano and Rails. The Gem works with latest versions of Capistrano (v2.0.2 of the gem has been updated to work with Capistrano 2.4 as well as 2.3) and supports the deployment of Rails applications with a slant towards those created with Rails v2.x

NEW FEATURES SINCE BETA

NGINX support

The gem creates configurations for both Apache and NGINX so that those who prefer to use NGINX can use the gem as well as their favourite webserver.

Apache SSL support

If you set :ssl_certificate to the path of an SSL certificate stored on your server then the gem will create an SSL configuration for that site. (Note that there can only be one SSL site per Brightbox due to limitations in the way Apache uses certificates).

Simple local shared area management

The capistrano release management system shares certain directories and files between releases – log files and the public/system directory. We have extended that function so that you can create your own directories and files that are shared between releases. Simply set the :local_shared_dirs and :local_shared_files variables and the Brightbox gem will make sure those areas are always shared between releases. Great for upload directories or for sharing the config/database.yml between releases.

Documented config/deploy.rb

We have included documentation for all the Brightbox features directly in the config/deploy.rb. Find the feature section, uncomment the appropriate lines and alter to suit.

Monit management

If you stop an application monit will stop monitoring it until you start it again. This should eliminate a lot of noise from monit.

NEW FEATURES

Deploy with a single command

You can deploy a Rails application onto the Brightbox system with a single command deploy:initial. We’ve tried to reduce the amount of work required to get an application working. You can follow our simplified initial deployment guide on our wiki

Focus on new deployment

The Brightbox gem is designed to allow you to quickly deploy an application to your new Brightbox. We’ve created sensible defaults for many of the Brightbox command options, and trimmed as much of the fat as we can from the deployment process. But because the gem generates Capistrano files you can tailor this starting point to your exact needs using the full power of Capistrano.

Deploy your working copy

The gem uses the new ‘:none’ scm option in Capistrano that simply zips up the current directory and deploys it on the server. No more messing around with version control security until you’re ready. Just deploy and go.

Checks your database configuration

The gem will check the database.yml for the Rails environment you are deploying to and will warn you if any of the details do not conform to Brightbox Standards.

Automatically creates databases and gems

Rails now has rake commands for creating databases and installing required gems. Where these are available the recipes will use them automatically. For Rails 2.0 users we’ve created a simple ‘stop gap’ rake task that you can use to specify your required gems.

Separate server and client gems

Once the gem is released all new brightboxes will come with the server gem preinstalled. For older boxes you will need to install the server tools manually. Log into your brightbox and run:

sudo gem install brightbox-server-tools -y --no-ri --no-rdoc

Logs Rotated

The gem asks the operating system to monitor the size of the application logs and rotate them when they get too big or too old. No longer should a neglected log file bring your server to its knees.

Mongrels Cleaned

Mongrel tend to be dirty when it falls over and leaves PID files lying around to trap the unwary. The new gem cleans up dirty PID files before it restarts.

Works alongside Capistrano

We’ve simplified the recipes so that, wherever possible, they augment the existing Capistrano deployment commands we all know and love rather than replacing them. That way your deployments gain the benefits of Capistrano improvements as well as improvements in the Brightbox gem. Free software at its best.

• Merb Support via Rack
• Lower VM Usage
• Better load balancing and non-blocking file uploads

The package is on our repository at http://apt.brightbox.net and built for Ubuntu 8.04 (Hardy).

I’ve had the pleasure of working with Hongli at Phusion to knock out a few bugs and make Phusion Passenger easier to package. That work has paid off and I was able to quickly release the updated Passenger package within minutes of getting the nod from the Phusion guys.

That’s why we love Free Software here at Brightbox.

The well-being of the Rails community is important to us, so we’d like to try and do what we can to keep it bubbling along nicely :)

One of the ideas that came up was some sort of Rails training network that would help bridge any skills gap. But before we do anything, we want to understand whether there is actually a skills gap, or just an “expectation gap” in either price or experience (anybody with any sort of Rails commercial experience is almost certainly gainfully employed at a good rate at the moment).

So, we’d like to hear from you if…

1) You’re in the market for Rails talent and would either be interested in using a Rails training programme, or interested in talking to ‘graduates’ of such a programme or

2) You’re a developer and you’d be interested in signing up for a Rails training programme and potentially getting your name in front of Rails employers.

Drop us an email to hello [at] the brightbox uk domain – we’ll gauge interest and take it from there.

The package is available from the Brightbox repository at http://apt.brightbox.net and is called ‘libapache2-mod-passenger’.

Brightboxes have the repository in place by default, but you can easily add the repository to your system with the following commands:

sudo sh -c 'echo "deb http://apt.brightbox.net hardy main" > /etc/apt/sources.list.d/brightbox.list'
sudo sh -c 'wget -q -O - http://apt.brightbox.net/release.asc | apt-key add -'
sudo apt-get update

There will be a beta Passenger Brightbox machine available soon and we’re probably going to need some volunteers to trial it out. So if you like your Rails Hosting bleeding edge then let me know and I’ll put you on the list.

If you do use the .deb, be warned that I’m changing it all the time at the moment as Passenger evolves and I’m following Passenger trunk very closely.

We’re proud to announce the beta version of our new Brightbox deployment gem. It is available from the Brightbox gem testing repository at http://gems.brightbox.net/testing. You can add this repository to your list by following these instructions.

This gem is a complete rewrite, to take advantage of the latest features of Capistrano and Rails. The Gem works with the current version of Capistrano (2.3) and supports the deployment of Rails 2.x applications.

FEATURES

Deploy with a single command

You can deploy a Rails application onto the Brightbox system with a single command (deploy:initial). We’ve tried to reduce the amount of work required to get an application working. You can follow our simplified initial deployment guide on our wiki

Focus on new deployment

The Brightbox gem is designed to allow you to quickly deploy an application to your new Brightbox. We’ve created sensible defaults for many of the Brightbox command options, and trimmed as much of the fat as we can from the deployment process. But because the gem generates Capistrano files you can tailor this starting point to your exact needs using the full power of Capistrano.

Deploy your working copy

The gem uses the new ‘:none’ scm option in Capistrano that simply zips up the current directory and deploys it on the server. No more messing around with version control security until you’re ready. Just deploy and go.

Automatically creates database configuration

The standard ‘mysql’ command allows you to put the database, username and password in a file called ‘.my.cnf’ in the ‘rails’ user home directory on the server. The mysql command will then read that file and logon to the database directly. If your application is short of a ‘production’ section in its config/database.yml then the recipes will take the contents of ‘.my.cnf’ and create a production section dynamically.

Automatically creates databases and gems

Rails now has rake commands for creating databases and installing required gems. Where these are available the recipes will use them automatically. For Rails 2.0 users we’ve created a simple ‘stop gap’ rake task that you can use to specify your required gems.

Separate server and client gems

Once the gem is released all new brightboxes will come with the server gem preinstalled. For older boxes you will need to install the server tools manually. Log into your brightbox and run:

sudo gem install brightbox-server-tools -y --no-ri --no-rdoc

Logs Rotated

The gem asks the operating system to monitor the size of the application logs and rotate them when they get too big or too old. No longer should a neglected log file bring your server to its knees.

Mongrels Cleaned

Mongrel tend to be dirty when it falls over and leaves PID files lying around to trap the unwary. The new gem cleans up dirty PID files before it restarts.

Works alongside Capistrano

We’ve simplified the recipes so that, wherever possible, they augment the existing Capistrano deployment commands we all know and love rather than replacing them. That way your deployments gain the benefits of Capistrano improvements as well as improvements in the Brightbox gem. Free software at its best.

NOW WE NEED YOUR HELP!

We’d like as many Brightbox customers to use the new gem and let us know what they think of it so that we can hone it to perfection. Please give it a go and then pop along to our Brightbox Beta discussion group (http://groups.google.com/group/brightbox-beta) and let us know any feedback or problems.