{"id":498,"date":"2011-09-20T20:30:23","date_gmt":"2011-09-21T03:30:23","guid":{"rendered":"http:\/\/blog.networkpresence.co\/?p=498"},"modified":"2011-10-17T07:15:51","modified_gmt":"2011-10-17T14:15:51","slug":"how-to-setup-ruby-on-rails-hosting-using-apache-from-development-to-production","status":"publish","type":"post","link":"http:\/\/blog.networkpresence.co\/?p=498","title":{"rendered":"How to setup Ruby on Rails Hosting using Apache, from Development to Production"},"content":{"rendered":"

In addition to the ‘development Ruby on Rails’ environment and Appliance VPS<\/a> product, we’ve recently worked through the software requirements and dependencies of a ‘production’ Ruby on Rails hosting environment and VPS.<\/p>\n

The following technical information outlines the broad sysadmin actions required to bring a ‘development’ Ruby on Rails application online within an Apache webserver & seperate VPS\/system for hosting the application to the Internet in a ‘production’ setting (as opposed to running the application within “rails server” for testing).<\/p>\n

Some assumptions that ‘complicate’ this deployment (complications which are dealt with in the actions outlined below) are that the development Ruby on Rails environment is Ruby 1.9.x and Rails 3.0.9.
\nThis effectively means that most of the easily installable Operating System packages for (say) Debian or Ubuntu Linux aren’t going to work out, in that most Linux-based operating systems install Ruby 1.8.x and an older version of Rails & RubyGems, along with an older version of the Apache module that’s commonly used to present Ruby software to the web, being the “Passenger<\/a>” module. Finally, we’ll assume in the following that you’re hosting the web application on a 64 bit Debian 6 (“Squeeze” by name) VPS.<\/p>\n

So to “productionise” a Ruby 1.9.x and Rails 3.0.9 developed web application means that much software must be installed from source code or from the distributions made available from the software’s site itself, rather than just Operating System packages.<\/p>\n

Based on the above requirements and assumptions, here’s the process for getting the relevant software onto a ‘vanilla’ Debian 6 system, with all commands run as the ‘root’ Linux user:<\/p>\n

a) With a ‘minimal’ Debian 6 64 bit (x86_64) system, install the following Debian Packages after upgrading the Debian 6 system to the latest version of ‘base’ packages ie: an apt-get upgrade<\/code><\/p>\n

apt-get install ruby1.9.1 libruby1.9.1
\napt-get install build-essential
\napt-get install apache2-prefork-dev
\napt-get install libapr1-dev
\napt-get install libaprutil1-dev apache2
\napt-get install libxslt-dev libxml2-dev
\napt-get install curl libcurl4-openssl-dev<\/code><\/p>\n

Then either (or both) of the following depending on what DB environment is required by the Ruby on Rails application:<\/p>\n

apt-get install libsqlite3-dev sqlite3
\napt-get install mysql-server libmysqlclient16 libmysqlclient-dev mysql-client mysql-common<\/code><\/p>\n

If you’re installing the mysql-server package, it will ask you to specify the mySQL ‘root’ user’s password.<\/p>\n

The above yields ‘ruby’ as the binary\/executable ‘\/usr\/bin\/ruby1.9.1’, so to have the command line ‘ruby’ command, you can create a Linux ‘symlink’ of \/usr\/bin\/ruby1.9.1 to \/usr\/bin\/ruby
\nie:
\nln -s \/usr\/bin\/ruby1.9.1 \/usr\/bin\/ruby<\/code><\/p>\n

b) Download & install RubyGems from http:\/\/rubyforge.org\/projects\/rubygems\/<\/a> to the system, extract that file, cd into that extracted directory & run ‘ruby setup.rb<\/code>‘<\/p>\n

cd \/usr\/local\/src\/
\nwget http:\/\/rubyforge.org\/frs\/download.php\/75309\/rubygems-1.8.10.tgz
\ntar xzf rubygems-1.8.10.tgz
\ncd rubygems-1.8.10
\nruby setup.rb<\/code><\/p>\n

Then, as above, if you want the ‘gem’ command-line executable, then do:<\/p>\n

ln -s \/usr\/bin\/gem1.9.1 \/usr\/bin\/gem<\/code><\/p>\n

c) Use Gem to install the following Gems:
\n(If you don’t need mysql, then you may not need to install it)<\/p>\n

gem install mysql
\ngem install fastthread<\/code><\/p>\n

That gives you a software base to bring your Ruby on Rails application development directory over from your development environment to this system and copy that development directory tree to the directory where you’d like it served from on this production server. eg: \/var\/www\/app\/<\/p>\n

Once you’ve done so & we’ll assume that it’s been copied to the directory \/var\/www\/app, you then should ensure that your app has a running environment compatible with this production environment, rather than the development environment, which in the case of the dev. environment we refer to in our previous post<\/a> (being Ruby 1.9.x, RSpec, Rails 3.0.9, etc) means that all RSpec Tests should pass. Again, as per the development RoR environment outlined, this is accomplished with the following actions:<\/p>\n

a) Remove the ‘rake’ directory from the development environment and check your ‘Gemfile’ to be sure that it lists any specific Gem version numbers that you may want.<\/p>\n

cd \/var\/www\/app\/
\nrm -rf rake
\nvi Gemfile<\/code><\/p>\n

b) Then run the bundle install<\/code> command to install the Ruby on Rails environment compatible with this production system and also (crucially) all the Gems that your application needs, and that may take some time as it downloads & installs the relevant Gems listed in your Gemfile.<\/p>\n

Of course, if your Gemfile is small or non-existant, you can iterate with ‘gem install ‘ and usually this will involve a minimum of:<\/p>\n

gem install rake
\ngem install rails --version=3.0.9
\ngem install sqlite3<\/code>
\n…<\/p>\n

c) If you’re using RSpec (which we recommend<\/a>), then all tests should run now without error:<\/p>\n

cd \/var\/www\/app
\nbundle exec rspec spec\/<\/code><\/p>\n

This gets your application working on the production system’s software environment, so now’s the time to get everything installed for Apache to be able to serve your Ruby on Rails application’s content.<\/p>\n

As above, we’ve already installed Apache2 and its Development environment, so we now need to install the Passenger Gem and compile the Passenger Apache2 module itself. This is done with the following:<\/p>\n

gem install passenger<\/code><\/p>\n

Which among its actions, installs the following executable command:<\/p>\n

\/usr\/bin\/passenger-install-apache2-module<\/code><\/p>\n

Running “passenger-install-apache2-module” steps through the process of validating your software environment (that it’s able to build the Passenger module etc & the common pre-req’ software needed is installed initially above from Debian\/Ubuntu Linux Packages) and goes through the process of downloading the latest\/relevant Passenger Module’s code and building and installing it.<\/p>\n

The final output of ‘passenger-install-apache2-module’ looks something like:<\/p>\n

——————————————–
\nThe Apache 2 module was successfully installed.<\/p>\n

Please edit your Apache configuration file, and add these lines:<\/p>\n

LoadModule passenger_module \/usr\/lib\/ruby\/gems\/1.9.1\/gems\/passenger-3.0.9\/ext\/apache2\/mod_passenger.so
\n PassengerRoot \/usr\/lib\/ruby\/gems\/1.9.1\/gems\/passenger-3.0.9
\n PassengerRuby \/usr\/bin\/ruby1.9.1<\/p>\n

After you restart Apache, you are ready to deploy any number of Ruby on Rails
\napplications on Apache, without any further Ruby on Rails-specific
\nconfiguration!<\/p>\n

Deploying a Ruby on Rails application: an example<\/p>\n

Suppose you have a Rails application in \/somewhere. Add a virtual host to your
\nApache configuration file and set its DocumentRoot to \/somewhere\/public:<\/p>\n


\n ServerName www.yourhost.com
\n DocumentRoot \/somewhere\/public # <-- be sure to point to 'public'!\n
\n AllowOverride all # <-- relax Apache security settings\n Options -MultiViews # <-- MultiViews must be turned off\n <\/Directory>
\n <\/VirtualHost><\/p>\n

And that’s it! You may also want to check the Users Guide for security and
\noptimization tips, troubleshooting and other useful information:<\/p>\n

\/usr\/lib\/ruby\/gems\/1.9.1\/gems\/passenger-3.0.9\/doc\/Users guide Apache.html<\/p>\n

——————————————–<\/p><\/blockquote>\n

These broad\/general instructions require the following actions in a Debian Apache2 context:<\/p>\n

a) Put the string “LoadModule passenger_module \/usr\/lib\/ruby\/gems\/1.9.1\/gems\/passenger-3.0.9\/ext\/apache2\/mod_passenger.so” into the file \/etc\/apache2\/mods-available\/passenger.load<\/code><\/p>\n

b) Put the following lines into \/etc\/apache2\/mods-available\/passenger.conf<\/code> file<\/p>\n

PassengerRoot \/usr\/lib\/ruby\/gems\/1.9.1\/gems\/passenger-3.0.9
\nPassengerRuby \/usr\/bin\/ruby1.9.1
\n# see all passenger module directives here: http:\/\/www.modrails.com\/documentation\/Users%20guide.html
\nPassengerDefaultUser www-data
\n<\/code><\/p>\n

*Note: Updated to correctly set the user that the Rails App runs as by Apache using “PassengerDefaultUser” directive, otherwise the Rails App runs as user ‘nobody’, not the user that the Apache is running as!<\/p>\n

c) Run (as root) to enable the configuration & settings for the Apache2 Passenger Module in the Debian\/Ubuntu context:<\/p>\n

a2enmod passenger<\/code><\/p>\n

Now you’re ready to just configure Apache to serve that directory (\/var\/www\/app in our example here) and there’s many ways to do that, but we’ll just outline using the defaults of Debian’s Apache2 package’s installed files here.<\/p>\n

a) Load the following to the top of: \/etc\/apache2\/sites-available\/default<\/code><\/p>\n


\n ServerAdmin webmaster@YOURDOMAIN<\/p>\n

##DocumentRoot \/var\/www
\n DocumentRoot \/var\/www\/app\/public
\n # <-- be sure to point to 'public'!\n
\n AllowOverride all
\n # <-- relax Apache security settings\n Options -MultiViews\n # <-- MultiViews must be turned off\n <\/Directory><\/code><\/p>\n

b) Restart Apache with that config:<\/p>\n

\/etc\/init.d\/apache2 restart<\/code><\/p>\n

c) Check for any Apache startup errors in \/var\/log\/apache2\/error.log<\/code> of which there should just be the usual Apache startup line mentioning the use of the Passenger module, like:<\/p>\n

[notice] Apache\/2.2.16 (Debian) Phusion_Passenger\/3.0.9 configured -- resuming normal operations<\/code><\/p>\n

Now, if you use a SQL Lite DB in your application during development, then you should move the sqlite3 DB to a ‘production’ mode, which is done either “by the book” with the command:<\/p>\n

cd \/var\/www\/app
\nrake db:create RAILS_ENV=production<\/code><\/p>\n

Which will create an empty ‘production’ DB.<\/p>\n

Or, you could just rename your ‘development’ DB file to the ‘production’ filename with:<\/p>\n

cd \/var\/www\/app
\ncp db\/development.sqlite3 db\/production.sqlite3<\/code><\/p>\n

This will preserve any DB contents from development into the production DB (which may or may not be what you want).<\/p>\n

If you use mySQL or such for your DB requirements, then now’s the time to ensure that your DB is available to your application on the production system (eg: use mysqldump or such to transfer the relevant DB over to the mysql server running on this production host).<\/p>\n

If you don’t do this, you may get the good ‘ole RoR Passenger error page of “Something went wrong” and if so, there may be nothing listed in the Apache error.log file, but you’ll see updated files in your app’s log\/ directory, so check \/var\/www\/app\/log\/production.log<\/code><\/p>\n

That’s about it, this process has reliably put a number of customer Ruby 1.9.x on Rails 3.0.9 externally developed web applications online to the Internet via Apache webservers on Debian 6 Linux.<\/p>\n

As always, feel free to contact us<\/a> as a customer if you have any queries.<\/p>\n","protected":false},"excerpt":{"rendered":"

In addition to the ‘development Ruby on Rails’ environment and Appliance VPS product, we’ve recently worked through the software requirements and dependencies of a ‘production’ Ruby on Rails hosting environment and VPS. The following technical information outlines the broad sysadmin … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[94,95,93,92,96,78,9],"class_list":["post-498","post","type-post","status-publish","format-standard","hentry","category-network-presence","tag-apache","tag-passenger","tag-rails","tag-ruby","tag-sql","tag-sysadmin","tag-vps"],"_links":{"self":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts\/498","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=498"}],"version-history":[{"count":12,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts\/498\/revisions"}],"predecessor-version":[{"id":564,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=\/wp\/v2\/posts\/498\/revisions\/564"}],"wp:attachment":[{"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=498"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=498"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.networkpresence.co\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=498"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}