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.
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