8

We are just about to move from a monolithic architecture to an auto-scaled group and I'm not sure how I should be running my database migrations (Laravel).

I am thinking that a script will run when a new box comes online, this will git pull my latest code down. Should this script also execute my database migration? I am not sure how I can get it run on only one box?

alecxe
  • 849
  • 1
  • 16
  • 36
Mick
  • 221
  • 1
  • 4

2 Answers2

1

How are you doing your deploys? Nuke + rebuild the ASG (whether one node at a time, or by replacing the whole group at once), or do you have a script that redeploys all of your active nodes?

And also, how are you triggering your deploys?

Ideally you want to be running/triggering deploys from some form of CI server like Bamboo or Jenkins. If you're doing this, you can run your DB migrations from the build server (or its component build agent instances).

This would allow you greater control over your environment, as you could, for example, restore DB from snapshot if the deployment fails.

maplebird
  • 686
  • 3
  • 7
1

Many orm's store migration state in the DB itself, but if you do it 'manually' its not hard to build yourself either. Just have a "migrationstate" table where all executed migrations are stored. That way when a node comes online it can simply check that table against its local "migrations" folder, and execute what's missing - this should cause only your first node after a version bump to execute the migrations.

As a side note: CloudFoundry solves this by allowing each instance (node) in your scale set to access its identifier. The first one gets 0, the next 1 etc. That way a node knows if its the first one, and can execute migrations. I don't think ASGs have the same.

Trondh
  • 381
  • 1
  • 6