casperfabricius.com

Geoffry Grosenbach is cool. And I’ve struggled with the same issues as he has, albeit I’ve been able to build on his work in my own deployment setup. So of course I had to attend his talk on deploying to shared hosts, although most of what he said wasn’t new to me. Geoff’s entertaining and well-designed presentation focused on three areas: How to design a site to run a shared host, how to maintain the site, and how to troubleshoot problems.

Design
First of all, Geoff suggested that only really small sites should be deployed to a shared host. By small, it is not as much disk space, as how much memory and how many CPU cycles the site requires running smoothly. You are restricted on all these three factors on most shared hosts, but you also have the benefit of running on multiple servers – usually the database server will quite powerful, you will have a separate mail server, etc.

Another important thing in designing the application is caching. Geoff explained, that by using the caches_page macro, an html file will automatically be created upon the first hit, and after that; the web server will simply serve that static page without even invoking Ruby, Rails, FastCGI or anything else. The html file is stored in a directory structure that corresponds to the mapping of the action, so if you have for instance the action /da-DK/blogs/show/1, it will store that particular blog for that particular language. So that sounds like quite a big possibility to improve on speed. In order to expire the cached pages, a cache_sweeper needs to be implemented.

Maintaince
Geoff underlined that you need to make sure you don’t have too many zombie FastCGI processes running on your shared host, since you are restricted on number of processes. Maybe Mongrel will be the holy grail giving a nice, reliable way to run sites on a shared host, Geoff said, and this was somewhat confirmed by the “Deploying Rails” presentation by Ezra Zygmuntowicz the following day, stating that the future of Rails deployment definately belongs to Mongrel.

For monitoring our Rails applications, Geoff suggested Montastic.com or dwatch, which he has written a great tutorial on using.

Troubleshooting
Finally, Geoff gave some advice on how to debug and fix your problems when your site is not working on the server. The hash-bang (or is it she-bang?) lines has to actually point to place Ruby exists on the server, and it is a good idea to set export RAILS_ENV="production" in the ~/.bashrc or ~/.bash_profile to indicate that this the production site, instead of hardcoding it in environment.rb or relying on the shared host to set it.

./script/about, ./script/server –e production and ./script/console production are all good indicators of whether or not the actual site are running on the shared host, but also, the various logs produced can be good indicators of where the problem is, especially apache_log, production.log and fast_cgi.log.

Conclusion
Deploying Rails can be frustrating, and deploying it to a shared host with no control and lots restrictions can be a nightmare, so, as Geoff started out by saying, his talk was not a tutorial or a lesson, it was therapy.

But really the morale here is: Don’t use shared hosts for Rails, and if you do, make sure it’s only very small applications, or only for test purposes. As Ezra said at his talk on deployment: “Rails is a pig”. Once you want people to actually use your site, you should go with a Virtual Private Server (VPS) – or of course a dedicated setup if you can afford it – since you will get a certain amount of memory guaranteed, and you will have less users pr. machine. Ezra adds that you always go for a VPS host that uses XEN, since this platform uses almost no resources on its own.

Kiran Dandekar made an entertaining point out of demonstrating the variety of information that has be made available about him in different contexts like business, community, family or alumni. The problem is, he stated, that identities and identity attributes are site centric on the web, so you have to start from scratch entering this information on every site and even identifying yourself, as opposed to when you – for example – board in the airport, and all the airline need to verify your identity is your driver’s license. The driver’s license is not issued by the airline, but nevertheless is accepted to identify you, because the issuer of the identity is trusted.

Kiran and his coworkers at Verisign want to make this possible on the web – enter OpenID: An open, extensible, perpetual and not least user managed authentication service that anyone can use, and anyone can use. Ideally, everyone should have just one single ID – a domain – and password to identify themselves everywhere on the web. Why a domain? Because domains are the only truly global unique identifier today – a username is too narrow a scope. Kiran underlined that OpenID focus solely on authentication (or identity, as they called it), and that authorization and access control are still left to completely to the site.

OpenID also provides a profile, so each person only has to enter her data once, and are then able to decide which pieces of personal information each site should be allowed to access. The information is provided through attributes, and the concept is that you can do a “challenge”, e.g. ask “Is user 21 or older?” and get back true or false without ever learning the users birthdate.

OpenID is supposed to be fairly easy to use with Rails, as both gems and plugins has been created to work with it, so since all sites need user authentication anyway, it might be worth a shot. Examples of real sites using OpenID include LiveJournal, Wikimedia, ClaimID and several others.

Curt Hibbs, the creator of Instant Rails, says he created the package basically because he is lazy, and he wants to make as easy as possible to get up and running with Rails for himself and anyone else as possible. I’ve used Instant Rails myself once, as a kind of staging environment on a Windows 2003 server, and I was curious to find out more about this out-of-the-box solution for Rails.

The most interesting stuff that came out of Hibbs’ relatively short presentation, was the plans for a version 2 of Instant Rails. Hibbs criticized several areas of Instant Rails 1.x, in particular that it is only available for Windows, that it uses old versions of Apache and MySQL and that the user interface sucks! Version 2 will be a complete rewrite featuring:

• Cross-platform support (Windows, OSX, Linux)
• Webbased manager application written in Rails with a vastly improved UI
• Ability to manage the sites remotely
• Apache 2 and MySQL 5
• Integrated support for RadRails

The last thing is interesting since I am using RadRails for my Rails development. The RadRails guys was right in the front row of the Instant Rails presentation, so guess they have ganged up with Hibbs here at RailsConf. The integration means, that if you install RadRails inside the Instal Rails directory (which can be anywhere), Instant Rails will, when started, detect RadRails and automatically setup the path to Ruby and Rails, and also create projects for the sites hosted by that Instant Rails instance. I don’t know if I can use that for anything, but it could be handy for getting people up and running fast.