I got all excited this morning reading TechCrunch with their post about Rackspace Offerering Cloud Computing with Mosso. Once I clicked through to investigate further it seems the ‘new’ cloud hosting is just their old hosting plan with 30GB of storage slashed off (down to 50GB) so they can charge you 0.50/GB a month for any overage.

It’s the deal of the century!? a bonus $15/month to get back to their old limit of 80GB. Still no shell access, and still $25-85/month per Rails site.

I had high hopes for Mosso and Rails but after trying them I felt I was being nickeled and dimed, the lack of SSH didn’t bother me as they’re good about installing stuff for you, the kicker was $20/month if you wanted to add SSL. I also didn’t see marked speed improvements over shared (or grid) hosts like Media Temple (who host this blog, but not on the grid on a VPS).

All my Rails sites continue to be hosted on SliceHost, actually my secret recipe is a combo of Media Temple for email, FTP, and static stuff then either DNS trickery or .htaccess rewrites to apps on SliceHost. The best of both worlds.

Anyway I call shenanigans on Mosso.

My non-stop quest to find decent shared Rails hosting may be complete. I was pretty pumped about Media Temple’s Grid supporting Rails but each of the half-dozen RoR sites I’ve deployed to the Grid haven’t been ripping it up performance wise. An issue with an unresolved grid error when trying to cache pages had me scrambling to SliceHost. However SliceHost is bare bones, and system administration makes me want to shoot myself in the noggin. SliceHost did introduce me to LiteSpeed which - in my opinion - is the easiest and most stable way to deploy Rails. If I only had one app that I was working on full time SliceHost would be fine, I use Rails mainly to build CMS solutions for my clients so I still need email, stats, ftp etc. to be easy for them (not me) to manage. The brief was to find a shared host with all the bells and whistles that runs Rails on LiteSpeed with a healthy RAM allocation.

The choices came down to a VPS with Eleven2 or Mosso.

Why I didn’t go with Eleven2: they use Cpanel, hate it. They bat .500 with user’s hosting reviews, and I’m not sure which is worse; non-functioning forum, non-functioning server-status, or a knowledege base that has a grand total of 17 non-sales answers, hey at least the office cam was working (tip’o'the day: if your office cam resembles a 24/7 voyeur porn site it’s probably not boosting sales).

Why I went with Mosso: their custom control panel is as good as (mt)’s, rave reviews from a friend in the business, they can bill your clients directly for recurring hosting fees (second on my headache list after sysadmin), and so far their support rocks.

A hosting company is only as good as their support and in the first couple of days I haven’t been on hold once, two rings and in. On other hosts as soon as I uttered the words "Ruby on…" the fear in their voice would grow. Now not everyone at Mosso is a Rails expert, but when they said an expert would look into my problem they weren’t just trying to get me to go away. This afternoon I needed to get ImageMagick working on a Rails site, I called up support and within one hour ImageMagick was not only installed for my Rails site but for all Rails sites system wide (it should have been already, but that’s still pretty impressive!).

I’ll be keeping my SliceHost server for the heavy apps but everything else will make it over to Mosso (Rails, PHP, and even the two stray .NET sites I still have). $100/month plus $25 per Rails app seems expensive until you realize that any site that uses Rmagick or Typo/Mephisto on (mt) is going to require the $25 128mb upgrade anyways.

We’ll see how it goes but so far it’s been "set it and forget it" with Mosso.

PS deploying a Rails app on Mosso is pretty simple

1. Freeze Rails and any gems (which you should do on all shared hosts)

2. Upload

3. Reload your app in the control panel

Tom at the wishlisting.com blog has a comprehensive tutorial on setting up Ruby on Rails (with a load balancer and Rmagick) on a Media Temple (dv) server. He deserves praise for installing ImageMagick without a package manager, which can turn into a marathon event of yak-shaving.

Here’s how to stop your site’s uploads or other static file directories disappering after doing a ‘cap deploy’ with Capistrano. Capistrano is actually behaving exactly as it should. The problem is that the ‘uploads’ directory is being left behind in release purgatory while the other files happily move on up to the castle in the sky that is the current release.

The solution is to have all uploads stored in a directory outside of the release system. As usual the smart folks who made Capistrano are way ahead of us, if you do a ‘ls’ in your apps path (on your remote machine) you’ll see four directories

$ ls
current  releases  revisions.log  shared

‘cd’ into shared/system (cd shared/system) and create an uploads directory (mkdir uploads). Next create a Capistrano task in config/deploy.rb (on your local machine) that symlinks the public uploads directory in the latest release to the shared/system/uploads directory. The example below would be the task for using Capistrano on Media Temple’s Grid Server …

task :after_update_code, :roles => :app do
  run "ln -nfs /home/#{site}/containers/rails/#{application}/shared/system/uploads #{release_path}/public/uploads"
end

That’s it! Your uploads are now release agnostic.

This tutorial will walk you through setting up everything you need to deploy Rails apps on Media Temple’s Grid Server. The information on each part of the setup is available elsewhere but I thought it would be helpful to have it all in one place. The tutorial will cover setting up a rails container, creating ssh keys on the server, installing rails, creating a subversion repository, and deploying your app with Capistrano.

Prerequisites: You have a (gs) hosting account setup, a SSH client (OS X Terminal.app or PuTTy if you use Windows), and no fear of Unix commands.

Throughout the tutorial I’ll be calling the rails app ‘myapp’ replace that with the name of your application and ‘mydomain.com’ replace that with your domain.

1. SETUP THE RAILS CONTAINER

Log into your Media Temple account center and click on the ‘GridContainers’ control

In the Container List click ‘manage’ on the Ruby on Rails container

Enable the container by clicking ‘enable container’

Select ‘(gs) Container Base’ if you app will require the base amount of RAM, from experience unless you’re doing processor intensive things like resizing very large images with RMagick the base container will be fine.

Confirm the selection on the next page and then wait for your container to be enabled (takes about 5 min). Once you have the container enabled go back the main control panel, click ‘Server Administrator’ and make sure you have SSH enabled.

Since this is a Rails app you’ll most likely need a database, go back to the main control panel and click ‘Manage Databases’

Click ‘Add A Database’

Then in the ‘Specify Your Database Name’ field enter ‘myapp_production’ it’s actual name will then be db#{sitenumber}_myapp_production (sitenumber being your MT site number). Choose MySQL or PostgreSQL from ‘Select Database Type’ and click next.

The container is set up, next up SSH Keys.

2. SSH KEYS

SSH keys will allow you to log into your server without a password; "wait, no password, isn’t that insecure?" actually it’s more secure as long as you and only you have access to your local machine. Although SSH is very secure it’s still possible (though unlikely) for your password to be intercepted when you login. Setting up SSH keys, as the name implies, creates a key on the server that maps to your local machine (a known host), you then no longer have to enter your password when you login in which is safer and requires less memorizing and typing (my two least favorite things!).

Fire up the OS X Terminal (or PuTTy), once it launches you’ll be in your home directory. Type

$ ssh-keygen -t dsa

that will generate the keys on your local machine, change into the .ssh directory

$ cd .ssh

and copy the keys to your server (replacing ‘mydomain’ with your domain)

$ scp id_dsa.pub serveradmin%mydomain@mydomain:./id_dsa.pub

log into your server the old fashioned way

$ ssh serveradmin%mydomain@mydomain

then setup the keys and make sure no other users can read them (each command on a seperate line)

$ mkdir .ssh
$ cd .ssh
$ touch authorized_keys2
$ chmod 600 authorized_keys2
$ cat ../id_dsa.pub >> authorized_keys2
$ rm ../id_dsa.pub

Now when you login you won’t be asked for your password.

3. INSTALL RAILS

Log in (or remain logged in to) the server using you brand new keys.

Then setup another option to save typing your password over and over.

$ mtr generate_config

entering your username (serveradmin%mydomain@mydomain) and password. Then set up ruby gems (each command on a seperate line).

$ mtr setup_rubygems
$ source ~/.bash_profile
$ gem update --system --source=http://gems.mediatemple.net/

then install rails NOTE: running Rails 2.0 as a RubyGem is not yet supported see this article

$ gem install rails -y

and the appropriate database driver, for MySQL

$ gem install mysql --source=http://gems.mediatemple.net/

or for PostgreSQL

$ gem install postgres --source=http://gems.mediatemple.net/

Next install Mongrel

gem install mongrel --source=http://gems.mediatemple.net -v 1.1.1

If you wanted to you could now create a Rails app on the server, but first we’ll create a subversion repository…

4. SETUP A SUBVERSION REPOSITORY

Subversion is a great tool for tracking changes to an application when working with a team of developers or even or your own. You can roll back code to a previous revision and avoid overwriting another person’s work. On your Media Temple server change into your home directory then into the ‘data’ directory.

$ cd $home
$ cd data

and create a ’svn’ directory.

$ mkdir svn

Subversion is already installed on Media Temple so creating a repository is a one line affair

$ svnadmin create --fs-type fsfs svn/repository

That will create the ‘repository’ inside of the svn directory, next we set up the standard directories for Subversion. You need to type the complete path to your repository when adding directories. First find out your site number

$ pwd

This will spit out something like

/home/123/users/.home/data

‘123′ is your site number. In the command below replace mysitenum with that number (Note: using the backslash character means you can type multiple lines before issuing the command).

$ svn mkdir --message="Setting up the directories..." \
> file:///home/mysitenum/data/svn/repository/trunk \
> file:///home/mysitenum/data/svn/repository/tags \
> file:///home/mysitenum/data/svn/repository/branches

Running that command also commited your first revision to the repository (that was easy). The –message option lets others know what changes happened during a revision.

You can now load a rails app into your repository. On your local machine change into the rails app for the site you’re working with.

$ cd path/to/my/app

You’ll know if you’re in the right place if you type ‘ls’ and get a list of rails folders

$ ls
README          components      doc             public          tmp
Rakefile        config          lib             script          vendor
app             db              log             test

Subversion stores revisions in the ‘trunk’ check that out into your rails app (making sure to change mydomain.com and mysitenum to your variables). Note: the ‘.’ after trunk is required (it means do this here)

$ svn checkout svn+ssh://serveradmin%mydomain.com@mydomain.com/home/mysitenum/data/svn/repository/trunk .

Before we commit any files to the repository we should set some files to be ignored, like logs. First add all the files

$ svn add *

Then set the files you want to ignore

$ svn propset svn:ignore "*.log" log
$ svn revert log/*

Now you can commit your site to the repository

$ svn commit --message="Ini Rails App."

And update your code just to be sure you’re on the latest revision

$ svn update

You should get a message ‘At revision 2.’. Your app is now under version control! And the best reason to have it under version control is… Capistrano.

5. DEPLOYMENT WITH CAPISTRANO

Capistrano makes deploying your app as easy as typing one line, but first you need to set it up. Again on your local machine install Capistrano [UPDATE] Some people have had problems with Capistrano 2.0, I’ve changed the command to install 1.4 [/UPDATE]

$ sudo gem install capistrano -v 1.4.0

Then install Media Temple’s Capistrano

$ gem install mt-capistrano --source=http://gems.mediatemple.net/

And apply Capistrano to your app (make sure you’re in your app’s directory, note the ‘.’ means apply to ‘this’ location)

$ cap --apply-to . myapp

Next download the Media Temple deploy recipe from http://gems.mediatemple.net/deploy.rb (overwriting the one Capistrano made in myapp/config) then open deploy.rb and add your app’s info (all the lines that begin with ’set’):

require ‘mt-capistrano‘

set :site,         "mysitenum"
set :application,  "myapp"
set :webpath,      "myapp.mydomain.com"
set :domain,       "mydomain.com"
set :user,         "serveradmin%mydomain.com"
set :password,     "xxxxxxxx"

# repository on (gs)
set :repository, "svn+ssh://#{user}@#{domain}/home/#{site}/data/svn/repository/trunk"

# repository elsewhere
#set :repository, “svn+ssh://user@other.com/usr/local/svn/repo/app1/trunk”
#set :repository, "https://other.com/usr/local/svn/repo/app1/trunk”
#set :svn_password, “xxxxxxx”

# these shouldn’t be changed
role :web, "#{domain}"
role :app, "#{domain}"
role :db,  "#{domain}", :primary => true
set :deploy_to,    "/home/#{site}/containers/rails/#{application}"

#set :migrate_env, "VERSION=0"

#task :after_update_code, :roles => :app do
#  put(File.read(’deploy/database.yml.mt’), "#{release_path}/config/database.yml", :mode => 0444)
#end

task :after_symlink, :roles => :app do
  run "#{mtr} -u #{user} -p #{password} generate_htaccess #{application}"
end

save the file and then modify your config/database.yml file to use the Media Temple database for your production environment.

production:
  adapter: mysql
  database: db123_myapp_production
  username: db123
  password: xxxxxxxx
  host: internal-db.s123.gridserver.com

then run a subversion status

$ svn status

you should see a couple of new files in there with ‘?’ before them, that means subversion doesn’t know about them. To add them type

$ svn add config/deploy.rb
$ svn add lib/tasks/capistrano.rake

Then commit them to the repository and update your local copy (Note: -m is shorthand for –message).

$ svn commit -m="config deploy.rb"
$ svn update

Now we can deploy the app so it will be live on your Grid Server domain. Run each of these commands on one line:

$ cap mt_add
$ cap setup
$ cap update_code
$ cap symlink
$ cap migrate
$ cap mt_create_link
$ cap mt_start

If all the commands ran succesfully go to myapp.mydomain.com and view your site! Now open myapp/public/index.html (the default ruby splash page) and change the header <h1> from ‘Welcome aboard’ to ‘Welcome to Capistrano Deployment on MT’ save the file and do a svn commit

$ svn commit -m="welcome page header change"
$ svn update

then with your update safely in the repository you just do ‘cap deploy’

$ cap deploy

Then go check your site and see the change! Any time you make an update you want to push live commit it to subversion and then cap deploy, That’s it!