Answers: <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-26T10:36:19.757Z
Answers: 2017-11-26T10:36:19.757Z
Answers: Trondh
Answers: <p>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?</p>
  
  <p>And also, how are you triggering your deploys?</p>
  
  <p>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).</p>
  
  <p>This would allow you greater control over your environment, as you could, for example, restore DB from snapshot if the deployment fails.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-27T07:49:59.470Z
Answers: At the moment we just SSH onto the production box and pull the code. In reality I think that most of the time we will only have one node. I was thinking we would use Code Deploy. We don't yet have much experience of AWS/Devops and are just trying to find a simple way to get started with a load balance and ASG.
Answers: Mick
Answers: CC BY-SA 3.0
Answers: 2017-09-27T18:35:36.227Z
Answers: AWS CodeDeploy is great, and scales long-term once you get larger and start using more servers.
  
  If for the moment, you're manually SSHing to deploy, you can always have a separate script that runs DB migrations.  I.e. you would run the normal deployment script via CodeDeploy, and the database migration manually off one node.
  
  If you're not building a CI server that can run Liquibase any time soon, you can also look into other software like Datical:
  https://aws.amazon.com/blogs/devops/database-continuous-integration-and-automated-release-management-workflow-with-aws-and-datical-db/
Answers: maplebird
Answers: CC BY-SA 3.0
Answers: 2017-09-26T23:19:47.687Z
Answers: 2017-09-26T23:19:47.687Z
Answers: maplebird
Body: <p>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).</p>
  
  <p>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?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-09-26T15:52:55.950Z
Comments: I'm assuming by moving from monolithic to auto-scaled, you are referring to your database specifically. Are you using AWS RDS? If not, have you looked into it? https://aws.amazon.com/blogs/database/scaling-your-amazon-rds-instance-vertically-and-horizontally/
Comments: Preston Martin
Comments: CC BY-SA 3.0
Comments: 2017-09-26T15:58:48.757Z
Comments: Yes, we are using RDS. No I am scaling and load balancing the EC2 instances where the application runs.
Comments: Mick
Comments: CC BY-SA 3.0
Comments: 2017-09-27T08:00:26.000Z
Comments: One solution is to use something like flyway or liquibase that can run idempotent updates on DB, this way each node starting can try to update the DB and do nothing if the migration already happened.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-09-27T18:37:23.700Z
Comments: Fair warning, Flyway marks migrations as complete only after they've been run.  if you fire up Flyway concurrently from several nodes, there's a good chance they'll try to do the same migration at once, which can cause problems.
Comments: maplebird
Tags: <amazon-web-services><autoscaling>
Title: How to run database migrations in an auto-scaled group
UserDisplayName: Mick
ThreadText: # How to run database migrations in an auto-scaled group
  
  (Asked by: username_0 on 2017-09-26)
  
  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?
  
  **Tags:** amazon-web-services, autoscaling
  
  > **Comments:**
  > **username_1**: I'm assuming by moving from monolithic to auto-scaled, you are referring to your database specifically. Are you using AWS RDS? If not, have you looked into it? https://aws.amazon.com/blogs/database/scaling-your-amazon-rds-instance-vertically-and-horizontally/  
  > **username_0**: Yes, we are using RDS. No I am scaling and load balancing the EC2 instances where the application runs.  
  > **username_2**: One solution is to use something like flyway or liquibase that can run idempotent updates on DB, this way each node starting can try to update the DB and do nothing if the migration already happened.  
  > **username_3**: Fair warning, Flyway marks migrations as complete only after they've been run.  if you fire up Flyway concurrently from several nodes, there's a good chance they'll try to do the same migration at once, which can cause problems.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_4 on 2017-11-26. Score: 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.
  
  
  ---
  
  ### Answer by username_3 on 2017-09-26. Score: 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.
  
  > **Comments:**
  > **username_0**: At the moment we just SSH onto the production box and pull the code. In reality I think that most of the time we will only have one node. I was thinking we would use Code Deploy. We don't yet have much experience of AWS/Devops and are just trying to find a simple way to get started with a load balance and ASG.  
  > **username_3**: AWS CodeDeploy is great, and scales long-term once you get larger and start using more servers.  If for the moment, you're manually SSHing to deploy, you can always have a separate script that runs DB migrations.  I.e. you would run the normal deployment script via CodeDeploy, and the database migration manually off one node.  If you're not building a CI server that can run Liquibase any time soon, you can also look into other software like Datical: https://aws.amazon.com/blogs/devops/database-continuous-integration-and-automated-release-management-workflow-with-aws-and-datical-db/  
  
  ---
  
  