Summary
The first part of my post shows how to create a Rails application on scripts.mit.edu. By default, the application will use the Rails version that is installed on scripts, which will usually be behind the edge version. The second part of the post copies the application to the developer's computer, and modifies it to use the latest version of Rails. The third part of the post describes the steps needed to deploy a new version of the application back on the scripts.mit.edu servers.
Creating the Application
In the steps below, replace costan with your Athena username, and substitute sixprep with the name of your application.
- SSH into Athena: ssh costan@linux.mit.edu
- Sign up for scripts.mit.edu and MySQL: add scripts; signup-web; signup-sql
- Generate the Rails application: add scripts; scripts-rails app_name
- When prompted to enter 1 or 2, enter 1 (you're a user, not a group).
- Add the application name to the Desired address: field. For example: http://costan.scripts.mit.edu/app_name
- When asked to press Enter to continue, check your application's directory. It should be something along the lines of ~/web_scripts/app_name
- Verify that the application works by pointing Firefox to http://costan.scripts.mit.edu/app_name/
The scripts-rails tool uses the rails command on the server,
- Open a command shell in your Eclipse workspace: cd ~/workspace
- Copy the application: scp -r costan@linux.mit.edu:~/web_scripts/app_name .
- Go into the application: cd app_name
- Hack around a configuration bug: ln -s . public/app_name
- Install the latest version of Rails: sudo gem install rails
- See what the latest version of Rails is (this example assumes 2.3.5): rails -v
- Edit config/environment.rb to say RAILS_GEM_VERSION='2.3.5'
- Update the configuration files: rake rails:update
- Add a requirement (the line below) for the Rack gem to your app's config/environment.rb:
config.gem 'rack', :version => '1.0.1'
- Vendor Rails: rake rails:freeze:gems VERSION=2.3.5
- Vendor any other gems that your application uses: rake gems:unpack:dependencies
- Follow the steps below to deploy the application back to scripts.mit.edu, and verify that it still works.
The command sequence below will update your application in an almost safe way.
- Go into the application directory: cd ~/workspace/app_name
- Copy the application to scripts: scp -r . costan@linux.mit.edu:~/web_scripts/app_name
NOTE: I'm using scp for simplicity. You'll probably want to put sixprep under version control, then remove web_scripts/app_name and check it out from the repository.
- SSH into a scripts server:
ssh costan@linux.mit.edu
ssh -k scripts
- Go into the application directory: cd app_name
- Build any new native gems you might have added: rake gems:build
- Apply database migrations: RAILS_ENV=production rake db:migrate
The upgrade process is almost safe. The following things can go wrong:
- a FastCGI worker is spawned with new code, works on the old database schema, and trashes the data (window of opportunity: HTTP requests between steps 2 and 6, assuming the request makes FastCGI spawn a new worker process)
- a FastCGI worker caching the old code works on the new database schema, and trashes the data (window of opportunity: HTTP request between steps 6 and 7, assuming the requests hits a live FastCGI worker)
Discussion
This is my method for hosting Rails applications on scripts.mit.edu. It is simple, and it allows me to use the latest version of Rails. There are other strategies that work well.
For example, you could use the version of Rails on scripts.mit.edu (rails -v to find the version on scripts, then gem install rails --version 2.3.2 to install a specific version of Rails). The scripts.mit.edu team back-ported the fixes for security vulnerabilities since 2.3.2 came out, and intends to do so in the future. This might be a better solution, if you don't plan to be proactive about testing and updating your application whenever a new Rails release comes out.
One more thing - in case you're wondering, you will not be able to use scripts.mit.edu with its current software with Rails 3. The reason is that the scripts server use Ruby 1.8.6, and Rails 3 requires Ruby 1.8.7 or above. Unfortunately, Ruby cannot be vendored :)
I hope you found this post useful, and I'm looking forward to your questions and suggestions in the comments.
Acknowledgements
Alice Li and Christopher Luna helped me iron out some bugs in this post by following earlier versions of it.