Improved router syntax for Action Controller

The router syntax in Rails 3 has been completely revamped to build on the work from Rails 2 and provide a more elegant and flexible way to provide completely RESTful access for controllers. To get started see the new routing guide.

Brand new Action Mailer

Action Mailer was previously a bit of a hybrid, part controller, part model. Rails 3 sees Action Mailer completely rewritten purely as a controller, it now behaves much more like Action Controller. The new Action Mailer guide describes how to get going.

New query engine for Active Record

Active Record has adopted a new query engine to make complex queries more consistent and manageable. Execution of queries is now delayed until actually required and not when defined. For an introduction to the new query engine check out the new new Active Record guide.

Bundler

Traditionally, managing the dependencies for your Rails app deployment can be a bit of a nightmare. While Capistrano, Rake and other partial solutions make automating things easier, they’re often not elegant or simple. Bundler provides a complete solution to managing gems, libraries, frameworks and plugins that your app depends on. The latest release of the Brightbox deployment gem offers full support for Bundler.

Other improvements include built in XSS protection, an official plugins API, Agnosticism with plugins, Active Model callbacks & validations, better handling of character encoding and many more. For a more comprehensive list of changes see the release notes.

Rails 3 on your Brightboxes

Getting up and running with Rails 3 on your Brightboxes should be as simple as you’re used to with your existing Rails 2 apps.

Prerequisites

Rails 3 requires Ruby 1.8.7 or higher, Ruby 1.8.6 is no longer supported. If you’re using Hardy based Brightboxes you’ll need to upgrade the standard Ruby Enterprise Edition package, Lucid based Brightboxes include 1.8.7 by default. Ruby 1.9.2 is also supported, though we don’t have packages for it just yet.

Full support for Rails 3 deployment was added to the Brightbox deployment gem in version 2.3.7, so if you’re using an older version you’ll need to update. Don’t forget to update the brightbox-server-tools on your boxes too! The gem now has full bundler support for managing gem dependencies so if you’re using bundler you no longer need to define gems in your deployment recipe. Bundler is now our recommended solution for handling dependencies.

You’ll also need RubyGems 1.3.7 or newer. New Brightboxes include our 1.3.7 rubygems package for Ubuntu, if you’re running an older version you can upgrade like so

sudo apt-get update
sudo apt-get install rubygems

We’d also recommend running your app with the latest version of Phusion Passenger, especially if you plan on running Rails 2 and 3 side-by-side.

Installation

Installing Rails 3 is as simple as

gem install rails --version 3.0.0

Deployment

You can deploy your Rails 3 apps using the Brightbox gem just like you’re used to. Make sure you’re using the latest release of the gem which contains some new features to improve Rails 3 support.

Documentation

For more information on using Rails 3 see the newly updated official documentation. For help with running Rails 3 on your Brightbox, including information on running Rails 2 & 3 side-by-side see our Rails 3 wiki page.

Today I’m pleased to announce a new revision of the Brightbox Deployment Gem, version 2.3.6. This release fixes some of the issues reported to us by our users, along with a few extra features.

The documentation on the wiki has been updated with the new fixes and features. If you have any tips or find any errors just let us know.

NEW FEATURES

Apt Package Dependencies

Just as you can currently define gems your application relies on and have them automatically installed onto your servers, you can now do the same with apt packages. Define them in your deploy.rb and they’ll be installed before installing your required rubygems, which means you can use it to install apt packages that gems depend on. As an example, the nokogiri gem depends on a couple of apt packages.

depend :remote, :apt, "libxml2-dev"
depend :remote, :apt, "libxslt1-dev"
depend :remote, :gem, "nokogiri", ">= 0"

Intermediate SSL Certificates

Support for Intermediate SSL Certificates in Apache has been added, meaning you no longer need to manually edit the Apache config files directly. Just add one line to your deploy.rb and the gem now takes care of updating the Apache config for you. An example SSL configuration:

set :ssl_certificate, "my_cert.pem"
set :ssl_key, "my_cert.key"
set :ssl_intermediate, "intermediate.crt"

See the wiki page for Adding SSL Support to Apache for more information.

Deploy.local.rb

A common issue we’ve seen with is setting the deploy password. If you put it in deploy.rb, then it inevitably ends up in your source control repository, which is a bad idea. A workaround we’ve suggested in the past is to have a deploy.local.rb file, which isn’t tracked by source control, and load that from within your deploy.rb file. This allows you to have the password (or any other sensitive settings) defined, but kept outside your source control.

As part of this release, the gem now has official support for a deploy.local.rb file. If it exists, the gem will load it in for you.

For more information see the Advanced Gem Settings page on the wiki.

Disable (re)generating webserver config

If you’ve made manual changes to your webserver (apache or nginx) configuration, then you don’t want an accidental deploy:setup to overwrite your configs. Up until now you just had to avoid running the command, but now there’s a setting to disable it for you.

set :generate_webserver_config, false

FIXES AND ENHANCEMENTS

• Max Age setting now accepts a number as well as a string
• deploy:initial reloads Apache so the new config is loaded

Every Brightbox runs Ubuntu, which is an operating system built on top of the GPL Linux kernel. Our infrastructure is built upon Xen, Apache, Nginx, MySQL, Nagios and many other open source software projects; not least of which are Ruby and Rails themselves.

But whilst we benefit from this software, without contribution, free software is nothing, so we contribute anything we can. The most obvious of these are the Brightbox deployment gem and its associated server-side tools. These are extensions to Capistrano that help you get your application onto your Brightbox as quickly and easily as possible.

We also have our apt repository where we repackage a number of free software projects to make configuring your Brightbox as easy as possible. More details on the repository are available on the wiki, but the most notable are our Passenger and Ruby Enterprise Edition packages.

However, nowadays, the real place for sharing your code is on Github. We have a number of projects available there, ranging from the tiny to the large.

These include:

• Flashing rails

  A rails plugin that makes it simple to display flash messages in your views in a consistent manner.

• Rujitsu

  A simple gem that collects together a number of convenience methods and various helpers.

• RSpec-rails extensions

  A gem that tidies up specifying your code with RSpec-Rails.

• Object Factory

  Brightbox’s very own answer to Factory Girl or Machinist that lets you build your test data with minimal configuration and no fixtures.

• Altered Beast and Redmine.

  We have taken our own forks of two popular Rails applications. David’s version of Altered Beast handles the Brightbox forums and Redmine handles our internal bug tracking and task lists.

• Warren and Bigwig

  Last, but by no means least, we have Warren and Bigwig. These are our wrappers to AMQP and RabbitMQ.

  We use RabbitMQ internally to deliver messages across our various infrastructure systems and needed a simple way to interface our ruby code to Rabbit (which is implemented in Erlang).

  This led to Warren, our wrapper over the AMQP protocol that make it simple to post messages onto the queue.

  In order to receive and act on those messages, we also built Bigwig (no prizes for spotting the rabbit references there), which takes those messages and responds. Bigwig matches each incoming message against a set of plugins, each plugin being small and focused on a particular task. Unrecognised messages are discarded, ensuring that rogue commands can’t wreak havoc upon our network.
  UPDATE: It turns out that Bigwig isn’t quite ready yet, as a big chunk has been rewritten. We’ll get it out there as soon as we can.

As these are all free software projects, please take a look inside and poke around. Any suggestions, improvements, patches or forks will be gratefully received. Also, stay tuned for an announcement on a major project we are looking to start in the next couple of weeks.

Update 2: We’ve also put the code for Isitruby19.com onto Github, under an MIT licence. Please go to the forum if you have any questions.

Version 2.3 of the gem fixes some issues reported to us by our users. A quick summary of the changes from the release notes:

• Removed the Capistrano task which calls the db:check:config rake task. This task was introduced to help with a common config mistake, but just resulted in a different mistake becoming common.
• Removed the Capistrano task which calls rake gems:install. Running this as sudo was causing some permissions errors caused by initialising the Rails stack as root.
• Fixed how we track the commands the gem depends upon, the deploy:check command now works as expected.
• Gem dependencies are now installed by listing them in deploy.rb, extra examples have been added to the boilerplate deploy file.

The change in the way we handle gem dependencies was the reasoning behind making this a minor version release. Previously we simply called the inbuilt Rails 2.2 gem install task.  However we found some issues where customers with fresh deployments when running this command as root would result in files being created that could not then be removed during subsequent deployments. We took the decision to use the inbuilt capistrano dependencies to handle the installation of remote gems (examples are available inside the deploy.rb that the brightbox command automatically generates for you).

Update 24/2/2009: We’ve just pushed a new version, 2.3.2 that changes slightly how the gem dependencies work. You now specify a dependency with an alternate source in your deploy.rb like this:

depend :remote, :gem, "tmm1-amqp", ">=0.6.0", :source => "http://gems.github.com"

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.

It’s largely just a maintenance release, which means no Capistrano v2.0 support just yet, it still requires Capistrano 1.4.1. Cap 2.0 support is in the works though and will be released soon.

A quick summary of the changes:

• Fixes default Monit config bug (changes totalmem to mem, no more false memory overage alarms!)
• Fails out if MySQL database exists on cold_deploy (you really shouldn’t be running a cold_deploy a second time anyway)
• Adds reconfigure task (for easy adding of mongrels or domain changes)
• Archives Apache configs on cold_deploy or reconfigure
• Fixes Capistrano 1.4 dependency (will pull in v1.4.1 if necessary now)
• Changes default Apache log location to /var/log/web (for new cold_deploys or reconfigures)

Remember that you need to upgrade the Brightbox gem both in your development environment and on your Brightbox.

The HOWTO on deploying your Rails app using the Brightbox is here as usual.

Jason Fried (37signals) was right and I should have listened:

..we don’t have release dates. It’s a great way to make sure things are never late.

Also, in response to some good early feedback, John’s been working on a deployment gem that will make it super simple to deploy your Ruby on Rails apps to Brightbox.