Daniel Hoelbling-Inzko talks about programming
Today I deployed my very first Ruby on Rails application to a production server and failed. And I didn't fail so much because Rails is hard to deploy (the opposite is true) - but rather because Rails prevented me from doing something stupid!
But I digress, let's start at the beginning: I already wrote about my server setup last week and today was the time to deploy a Rails3 application to my Apache/Passenger.
The Passenger documentation really made things easy. I just cloned my repository to a folder and setup everything accordingly. Then I did the obvious
chown -R www-data:www-data . so the www-data user Apache uses has full access to the whole application directory and fired up my browser.
And it didn't work. Passenger was obviously running as I was able to load files from the /public folder without a problem, but the routes inside my application only returned errorcode 500.
Why? Simple: Passenger by default assumes you are running in a production environment so it will load that up from your database.yml. So I had to make sure that those settings where correct (easy one).
Next problem on the list was that any
rake commands you are running on the server still assume you are using the development environment. So in order to create your databases and migrate the schema you have to do a:
rake db:create RAILS_ENV="production" rake db:migrate RAILS_ENV="production"
Otherwise db:create and db:migrate will always run against the development environment settings inside database.yml.
But once that problem was solved, I was still getting 500s.. So I opened the
/log/production.log and found another gem I really liked:
rake assets:precompile fixed that, but boy was I impressed.
Especially when coming from a .NET environment where up to this date the
<= .. => syntax does not safely URL-Encode the value (and it took them 10 years to release the safe
<: ..> alternative, having a framework that throws you into the pit of success is exhilarating.