Best Practices for DB setup and migrations

[Ofer Nave]

I'm not using Moonshine, but I am trying to learn and use Capistrano and Puppet to deploy a Rails app to production for the first time, and there are some conceptual parts I'm stuck on.  I was hoping maybe someone here can help me since Moonshine is all about using Capistrano and Puppet to deploy a Rails app.

1) Which tool should be responsible for the initial setup of the production database (create, load schema, load seed data)?

2) Which tool should be responsible for the handling DB migrations when deploying a new version of the app?

The `rake db:*` commands have to be run from where the Rails app is installed, which is on the web nodes.  However, it only needs to be run once, and if I make it a part of the Puppetization of a web node, it will end up running on each node.  I can try to use the onlyif/unless attributes on the Exec resource type to see if the DB has been created already before running db:create or db:setup, but that doesn't address the possibility of a race condition when running puppet apply one more than one web node at a time.

I could make it part of the Puppetization of a db node, but then I have to install ruby and the Rails app on the db node, and that doesn't feel right either.

Then there's the issue of running DB migrations when deploying a new version of the app.  It seems to me it's not safe to have any web app instances running while the DB is being migrated, especially inconsistent versions, so I would assume the recommended process would be:

1) install new versions of app to all web nodes
2) bring down all web app instances
3) run the db migration from somewhere with a rails app (where? promote one web node to be special? because I hate that)
4) point the 'current' symlink to the new app version on all web nodes and start them up again

I assume this would be a task for Capistrano?

[Jamie Orchard-Hays]

Puppet is about configuring servers. Capistrano is about deploying your app onto a server. 1 and 2 both fall in the second category.

--
You received this message because you are subscribed to the Google Groups "Moonshine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to railsmachine-moon...@googlegroups.com.
To post to this group, send email to railsmachin...@googlegroups.com.
Visit this group at http://groups.google.com/group/railsmachine-moonshine.
For more options, visit https://groups.google.com/d/optout.

[Ofer Nave]

I see Capistrano's default task flow handles running db:migrate when you deploy a new version of your app, but where does the responsibility lie for running db:schema:load and db:seed the first time after the database is created?

-ofer

To unsubscribe from this group and stop receiving emails from it, send an email to railsmachine-moonshine+unsub...@googlegroups.com.

[Ofer Nave]

I'm also still unclear on how to resolve the timing issues when deploying to multiple nodes, and when/how to turn the apps off and on to avoid old code interacting with a migrated DB or vice versa.

I wrote up a detailed version of that question here:

http://stackoverflow.com/questions/27969490/how-to-avoid-timing-problems-when-running-dbmigrate-on-multiple-nodes

-ofer

On Wednesday, January 14, 2015 at 1:24:17 PM UTC-5, jamieorc wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to railsmachine-moonshine+unsub...@googlegroups.com.