Hello,
Can someone explain me why Capistrano deploys rails code to both :web and :db
roles, not only to :app role, which is the only role that actually needs this
code.
In my setup I do not want to give any SSH access to :db servers other than
server management, which is done outside Capistrano. So why Capistrano
migrate task needs this access while it could to it from :app server, which
has all the means via the database connection.
The problem raises when the same rails codebase is deployed to different sites
at different times which all have the same database servers (of course
different databases via render("database.yml") method).
There is no telling, which version of this code is on the :db server, when I
run migrate on one of these sites, so I can not be sure this migrate does
what I expect it to do.
Whereas if migrate would run on :app, I would know exactly what I get even
with multiple sites of the same code at different versions all on the same
database server.
If someone can explain me this, I would appreciate it.
Best regards,
Laas Toom
Laas, In our configuration, we prefer to run migrations on the DB box, as well as to run our batch scripts (like billing and so forth) on the DB box as well. In particular, if you have multiple app servers and you invoke the "deploy_with_migrations" task, you don''t want the migration to run on each app server--you only want it to run once. With a single primary DB server, this behavior is easy to configure if the app is deployed to that machine. We deploy to :web, because the web server needs the contents of the / public directory, and (in our case) some of the contents of the / config directory. It also uses the /log directory, some things in the /script directory, and may use the /tmp directory True, we could pick and choose and complicate the deployment process, requiring people to specify what parts of the app were to be deployed to which box, but we opted for a less-software approach. It makes it easy to understand, and easy to get rolling. If the default tasks don''t suit you, you are welcome to change (or rewrite) them to your preference, locally. - Jamis On Apr 25, 2006, at 3:10 AM, Laas Toom wrote:> Hello, > > Can someone explain me why Capistrano deploys rails code to > both :web and :db > roles, not only to :app role, which is the only role that actually > needs this > code. > > In my setup I do not want to give any SSH access to :db servers > other than > server management, which is done outside Capistrano. So why Capistrano > migrate task needs this access while it could to it from :app > server, which > has all the means via the database connection. > > The problem raises when the same rails codebase is deployed to > different sites > at different times which all have the same database servers (of course > different databases via render("database.yml") method). > > There is no telling, which version of this code is on the :db > server, when I > run migrate on one of these sites, so I can not be sure this > migrate does > what I expect it to do. > Whereas if migrate would run on :app, I would know exactly what I > get even > with multiple sites of the same code at different versions all on > the same > database server. > > > If someone can explain me this, I would appreciate it. > > Best regards, > Laas Toom > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Hello, Jamis! Thank you for the explanation. Now I understand the reasons. We were doing something similar to your article "Using SwitchTower with multiple deployment stages", but problems arose when the staging and production databases live on the same server. So I thought I ask for the reasons the :db role is deployed to at all. We will probably go with RailsCron for the batch jobs and if I understand it correctly, this needs to be run on some :app server to take full advantage of it (over regular cron and script/runner), so I think we define one :app server as :primary, which gets to run the cron and I was thinking that this primary machine could be used for migrations also. But about the :web servers - you are correct, I did not see it clearly, because for now, :web and :app coincide in one server for us. Best regards, Laas On Tuesday 25 April 2006 6:35 pm Jamis Buck wrote:> Laas, > > In our configuration, we prefer to run migrations on the DB box, as > well as to run our batch scripts (like billing and so forth) on the > DB box as well. In particular, if you have multiple app servers and > you invoke the "deploy_with_migrations" task, you don''t want the > migration to run on each app server--you only want it to run once. > With a single primary DB server, this behavior is easy to configure > if the app is deployed to that machine. > > We deploy to :web, because the web server needs the contents of the / > public directory, and (in our case) some of the contents of the / > config directory. It also uses the /log directory, some things in > the /script directory, and may use the /tmp directory > > True, we could pick and choose and complicate the deployment process, > requiring people to specify what parts of the app were to be deployed > to which box, but we opted for a less-software approach. It makes it > easy to understand, and easy to get rolling. > > If the default tasks don''t suit you, you are welcome to change (or > rewrite) them to your preference, locally. > > - Jamis >