For comparison: https://github.com/scottanderson42/ansible/blob/ec2_vol/library/cloud/ec2_asg_cycle
Still a work in progress (as you should be able to tell from the logging statements :-), but we've been using it in production for several months and it's (now) battle tested. The "Slow" method is unimplemented but is intended to be your Option 2. -scott On Sep 11, 2014, at 1:50 PM, Scott Anderson <[email protected]> wrote: > Wow, I wish I'd seen this conversation earlier. > > I have a module that does this, using something similar to option 1. > > My module respects multi-AZ load balancers and results in a completely > transparent deploy, *so long as* the code in the new AMI can run alongside > the old code. There's a start of two different methods, one which replaces a > single instance at a time and the other which fires up all the new instances > in the proper VPCs, waits for them to initialize, adds them to the elb and > ash, then terminates once they're all stable. > > You also have to set up session pinning and draining on the elb for it to > function correctly. Otherwise you can end up with someone getting assets from > two different code bases. > > There's actually a more reliable way to do it that involves using > intermediary instances, but we haven't gotten that far yet. > > -scott -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/D5B502F2-C5E4-4399-970E-E0B22FEC6736%40gmail.com. For more options, visit https://groups.google.com/d/optout.
