Deploy Ruby On Rails To A Shared Host (Part 1 – Application Setup)
Deploying a Ruby on Rails application to a shared host can be a difficult challenge. In this three part series of posts I will document the steps, I have taken, to deploy Rails applications to my shared host (Site5). While, these steps are specific to Site5, the majority of them are required by all shared hosts. In this first part I will document the setup of your Rails application. I will cover steps that can be taken before moving files to your server and which steps need to wait until after the transfer of files happens. Note: most of these steps are one time setup and won’t need to be repeated for future deployments.
There are a couple of things I will not cover. You’ll need SSH access to your server and an SSH client. Some shared hosts, including Site5, do not automatically give you SSH access and you’ll have to request it. For an SSH client I use putty, but feel free to use whatever you like. Also, along the same lines, I’m not going to cover how to transfer your files to the server. If you want feel free to look up my post on FileZilla.
Rails Application Setup:
The first 3 steps should be done before moving your application to the server.
1. You need to freeze rails in your application. Don’t rely on the shared host’s version of Rails as it could change at any moment. Don’t assume Rails will be backwards compatible. The work around (and what you should be doing anyway) is to freeze your Rails version. So Inside of your application’s directory do the following:
rake rails:freeze:gems
2. Update your dispatch.cgi directory and your dispatch.fcgi directory. I’ll have more on editing these files in Part 3 of this discussion, but just to get things running you’ll need to replace the top line of each of these files, which will look something like (#!c:/ruby/bin/ruby), with the following:
#!/usr/bin/ruby
This will not impact development on your local machine. Unless you are using FastCgi for development (not likely).
3. Setup you application’s root directory. This will tell Rails what controller and action should be called when the root directory is requested. If you haven’t set this yet than chances are that when you go to http://localhost:3000/ in development you are still getting the Riding Rails page. We obviously don’t want this in production.
There are two steps to configure the root directory. First, we need to delete the index.html page in your application’s public folder (your_app/public/index.html). Second, go into your application’s routes.rb file (your_app/config/routes.rb) and add the following line. Edit to use the controller and action you desire when the root of your application is requested:
map.connect '', :controller => 'your_controller', :action => 'action_to_be_seen_as_index'
Or if you are using Rails 2.0 or above:
map.root :controller => 'some_controller', :action => 'any action you want'
Now when you go to http://localhost:3000/ in development you should see the appropriate contents based on the controller and action you set above.
4. Production database setup. This may be an obvious one, but go out to your shared host and setup your database. Note the database name, username, and password. Take this information and update your database.yml file (your_app/config/database.yml) for the production environment.
5. Move files over to your server. Again, your on your own for this one.
The final steps need to be performed on the server. All files have been moved at this point and you will need to log into your account using your SSH client.
6. Edit your environment.rb file in your application’s config directory (yourapplication/config/environment.rb). Uncomment the following line:
ENV['RAILS_ENV'] ||= 'production'
You can use vi on the server to edit your files if you have no other way. The vi command:
vi ~/your_app/config/environment.rb
7. Next go to the root directory of your application (cd ~/your_app/) and run the database migration for production:
export RAILS_ENV=production rake db:migrate
8. (optional) You can setup a local gem store to control your own Ruby gems. This is not necessary if you’re going to freeze your gems, but I like the idea of controlling my own gems on the server. I’m going to defer directions on this one to a post I found. Gem Store Article
The next part of this series I will cover server setup.
References
No comments yet
Leave a reply
RSS - Posts