Now that I’m back from Sydney, I have had a bit more of a change to play with my shiny new MediaTemple grid server account. It looks like I will be pushing 88 Miles over to it over the weekend – everything is setup and ready to go, and just have to do the migrating. I though I would share with you a few thinks I found out along the way…
Setting up the Rails environment
The instructions on the media temple site are pretty good, there are just a few caveats I would make. Firstly, I’ve now started using capistrano to deployment, so I decided to change a few of the directory structures away from how MT suggests. The steps I took are as follows changes from the MT instructions are emphasised (replace testapp with you apps name – obviously):
cd $HOME/../../containers
mkdir rails && cd rails
mkdir testapp && cd testapp
mtr add testapp $PWD/current
For those of you playing at home, you may have noticed that the /current directory, doesn’t yet exist. Correct! This will get created by capistrano.
Setting up Capistrano
Everything was pretty straight forward in the deploy.rb file. The only gotchas I cam across were specific to my installation:
If your svn repository has a space in it, wrap it in single quotes when assigning the :repository variable, i.e:
set :repository, “‘svn://svn.server.com/path/to/your repository'”
If your svn repository requires a username and password for checkout or export, use the :svn_username variable, i.e:
set :svn_username,
Proc.new { “username –password password” }
The only other modification I needed to make to the deploy file was the addition of the restart task. Because MT uses custom scripts to restart containers, the restart script needs to call them reather than trying to mess with the Apache or Mongrel processes. I also discovered that my secure certificate wasn’t functioning correctly (I’ll explain why in a second) so there is a fix for that here as well.
desc “Restart the rails container”
task :restart, :roles => :app do
run “mtr generate_htaccess test_app”
run “echo ‘RequestHeader set X_FORWARDED_PROTO “https“ env=HTTPS’ >> #{deploy_to}/current/public/.htaccess”
run “mtr create_link test_app”
run “mtr restart test_app”
end
end
Line 3 uses a MT script to make some modifications to the apps .htaccess file. Because Mt proxies all requests to the apps Mongrel server, the standard .htaccess doesn’t cut the mustard.
Line 4 makes another modification to the .htaccess file. Because I’m slack, I pull a neat trick when I do SSL. I maintain a global list of pages that require SSL – when a user browsers to that page, they automatically get redirected to the secure version if required. And the same works the other way – if they browser away from a secure page to a non-secure page, they get re-directed to the non-secure version. Unfortunately, because of the way MT proxies the request, the Mongrel server knows nothing about whether the connection is secure of not (i.e request.ssl? always returns false). Thankfully, there is a fix for this in Rails – if you include the X_FORWARDED_PROTO=https header in the request, rails knows what is going on. This line checks for the environmental variable HTTPS (Which is a flag that is set if the server is in SSL mode) and if it is, sends the modified header, which makes everything good again.
Line 5 links the web directory to the rails container and line6 restarts the server. Nice and easy!