FastCGI and Ruby on Rails
Posted by Jason Sat, 11 Jun 2005 09:42:00 GMT
Update, December 18: Since writing this, I’ve learned about deploying Rails with Apache. And yes, there are ways to do this that are much less painful. The Rails book mentions using FastCGI in static mode. In my opinion, running FastCGI in external mode is even better. Unfortunately, there’s very little documentation on this (not even in the Rails book), but I plan on blogging on it soon.
I think Ruby on Rails’ biggest weakness right now is deployment. Not to say it’s hard, it’s easy if you follow the directions. The problem is when you don’t follow the directions. Tracking down your mistake can be difficult.
At least I encountered a little difficulty while installing Typo. Since I already had one Rails application running, I figured that adding a second would not be a problem. I made a copy of the VirtualHost directive in my httpd.conf, made the required changes to the .htaccess and dispatch.fcgi files. I restarted Apache and it didn’t work. The hunt was on for my mistake.
Everything else running on Apache worked fine, and Typo still worked with WEBrick, so at least I knew the problem was in the FastCGI configuration, or possibly a file permissions issue. Since I’d had that problem before I first went to /tmp and looked through fastcgi.crash.log. The error message in there was pretty useless, so I just deleted all the old session files and tried again. Didn’t work. Since that was really the only problem I had encountered in the past, I was a little stuck.
Next was the root apache error_log. It only logged the birth FastCGI servers, so that wasn’t interesting. Next, I looked at the error_log for the blog’s virtual host. It logged the errors, but the message was also useless. After a little spell-checking and verification in dispatch.fcgi, I went to look at the logs that rails keeps. That’s where I noticed another fastcgi.crash.log. Inside there was the answer to my problem – the application was trying to access the (non-existant) development database. The environment was set up for development, not production. I had to go back to httpd.conf and add the FastCgiServer directive to set typo to use the production environment.
It was around an hour’s worth of frustration for a simple problem, and it was mostly due to how the number of logs I had to look at. That said, I don’t see a better solution. The two different apache logs is an definitely required even for a low-traffic site like mine. I don’t know if having two different fastcgi.crash.log files was necessary though – although I have a feeling I could have configured it to use a single log file. And of course, Rails’ log files are most important… So I don’t a clear improvement that could be made. As long as FastCGI is used, that’s the way it’s gonna have to be. And FastCGI is great as it is.
