Posts tagged “rails”

Develop and deploy on the same box with Capistrano 2007/07/22

You're crazy if you're not deploying Rails apps with Capistrano. This tool makes it dead-simple to push your latest Subversion to your production server, run database migrations and restart your server all in one simple command. Plus with extra tasks like cold_deploy, getting a new box added to the pool is a snap. One problem, though — this tool was designed with real environments in mind, and my one-box setup for development and production doesn't quite fit in. If you're in the same boat, fear not, I have a solution.

The root of this problem is the assumption that your development and production server environments are identical. But when deploying to localhost, using the same mongrel_cluster.yml is just not an option, since you need to use separate ports for your development and production versions.

We need to user two different mongrel_cluster.yml files, one for production and one for development. We can leave the development version out of Subversion and create the production version over again on each deploy. But how do we deal with actually restarting the server?

It turns out Capistrano creates a directory structure that supports this directly, since the *.pid files in the log/ directory are symlinked into place and persist between deployments. So it seems like we can just create the config file and restart the server, right?

Wrong. deploy.rb's run command doesn't quite work like your average, everyday shell script. To help it out, I created a shell script that handles the server restart. The shell script allows me to change directories into the application directory and set the PATH variable so mongrel_rails can be found.

Putting it all together, here is config/deploy.rb: 

set :application, 'halvesies'
set :repository, 'protocol://repository/url'


role :web, 'localhost'
role :app, 'localhost'
role :db, 'localhost'


set :deploy_to, '/path/to/production/app'


task :restart, :roles => [:web, :app, :db] do
    run "#{deploy_to}/current/config/restart.sh"
end
And here is config/restart.sh: 
#!/bin/sh
cd /path/to/production/app/current
export PATH="$PATH:/var/lib/gems/1.8/bin"
mongrel_rails cluster::configure -e production -p 11001 -a 127.0.0.1 -N 3
mongrel_rails cluster::restart
cd -
And after all of this, you still deploy your site by just running cap deploy.

Comments (1)

Google-burned 2007/07/07

So I'm setting up a server for a project I'm starting (more on that as it develops), following my own instructions (http://old.richarddcrowley.org/blog/view/123). It turns out they're not quite right anymore and I can't figure it out.

I'm getting constant 403 errors even though RewriteLog seems to indicate that my rewrites are happening correctly. The solution is of course to google for the solution, but in most of my searches, my old site is the top result. Uh oh.

But I figured it out thanks to Server Watch forum users. In a nutshell, Ubuntu now forces you to explicitly enable more bits of the Apache proxying system by hand. Thus: 

a2enmod proxy
a2enmod proxy_balancer
a2enmod proxy_http
a2enmod proxy_ftp
a2enmod proxy_connect

Comments (0)

Other tags: