5

From what I can tell, one can't change the Amazon RDS (RDS) endpoint of an existing Elastic Beanstalk (EB) instance?

If that is the case, than you can't have your code deployed to a stage server, stage DB, tested, then promoted to use the prod DB?

So how do you deploy stage without having to test against the prod db?

Given prod and stage, I thought the strategy would be something like this:

  • Snapshot prod RDS
  • Create stage with new code and point it at the snapshot
  • QA stage
  • Point stage to prod RDS
  • Change load balancer to send traffic to stage
Improve this question

2 Answers 2

Reset to default
0

I'm not familiar with Beanstalk, so take this with a grain of salt.

As I understand it, an A/B deploy strategy works kind of like this:

  1. A is in prod.
  2. B is in staging.
  3. Deploy to B until you like it.
  4. Make B Prod, turning A to Stage.
  5. GOTO 1

Databases are terribly stateful, and don't take well to swapping like that. As I've seen it done, step 3 up there is done kind of like...

  1. Snapspot A-prod into B.
  2. Run migrations on B.
  3. Run test series to validate it works.
  4. If tests, fail, GOTO 1 and repeat. Else, continue.
  5. During B-cluster promotion, apply known-good migration steps to prod database.

The tricky part here is the database indirection. For this, I suggest going Route53. During the deploy process:

  1. Stop all testing activity, and code-update the B cluster.
  2. Update the B-Database record to point to prod-database.
  3. During the deploy, run your migrations.
  4. Bring the B cluster into prod, which will be using the now-updated cluster.
  5. Stop the A cluster.
  6. Update A-Database record to point to Staging.
  7. Snapshot prod onto the test database.

You get the idea.

Improve this answer
2
  • thanks for the detailed response. I think my main problem here is Beanstalk's (EB) RDS endpoint limitations. In your third section, you can't do step 2. This is because the EB instance was initially associated with the stage database, you can't update it to be associated with the prod database later.
    – Ryan
    Feb 1, 2016 at 0:06
  • I guess you could spin up a 3rd EB instance once your code is tested, associate it with the prod DB, deploy code, run migrations and change the load balancer to route to this 3rd instance. Seems like extra work for no reason.
    – Ryan
    Feb 1, 2016 at 0:08
0

As I can see your idea are CI/CD Workflow. Using the AWS Beanstalk you may doing that thing (your idea) using the env.yml. Here in about the env.yml further reading https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-cfg-manifest.html

I hope that helps you.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .