Hey Ro, If your database machine does not have ruby installed, then you probably shouldn't deploy to it. Just designate one of your app servers as your "db" server and you should be fine:
role :app, "app1", "app2" role :db", "app1", :primary => true The db role is only used for the database migrations, which (as you pointed out) can be run from any machine. Hope that helps, Jamis On May 25, 2007, at 10:54 AM, Rogelio J. Samour wrote: > So I have the following: > > role :app, "app1", "app2" # Two physically separate boxes running > mongrels (Ubuntu Server) > role :web, "www" # Physically separate Apache 2.2.4 box running > mod_proxy_balancer (Ubuntu Server) > role :db, "db1", :primary => true # Physically separate box > running mysql 5.x (Fedora) > > The problem is that it tries to run the migrations from db1 which > does *not* have ruby (or rake) installed. It is just a Database box. > > The questions: > 1). Why do I need to define that as a role if I could run `rake > db:migrate RAILS_ENV=production` from any of the app boxes? Is > there something else to the role :db than meets the eye? > 2). What would be the best way to make this work with a clustered > environment like the one mentioned above? > 3). (Not related to DBs) At what point in time does the deploy take > care of creating or renaming the database.yml.example to > database.yml? In my repo I have a database.yml.example... do I have > to write my own task that runs at some point in time and renames > this file on a deploy:cold ? > 4). The maintenance.html (web:disable and web:enable)... how are > you guys making that file show up? Is there something on your > apache/nginx/lighty vhost? > > Sorry I'm new to capistrano and especially new to Cap 2. > > TIA, > > Ro > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
