Scott, Neat to see someone else's approach. The "fast method" you have there probably could be worked into what's been merged. Another approach (maybe simpler) would just be stand up a parallel ASG with the new AMI.
I like making the AutoScale Group do the instance provisioning, versus your approach of provisioning the instance and then moving it to an ASG. From what I can tell, your module doesn't seem to be idempotent -- so if it's run, it's always going to act. The feature I added only updates instances if they have a launch config that is different from what's currently assigned to the ASG. So it's safe to run again (or continue a run that failed for some reason), without having to cycle through all the instances again. We will be publishing an article on some different approaches that we've worked through for doing this "immutablish" deploy stuff sometime next week. On Thu, Sep 11, 2014 at 2:04 PM, Scott Anderson <[email protected]> wrote: > 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 a topic in the > Google Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/JXiZgm36sHU/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- James Martin Solutions Architect Ansible, Inc. -- 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/CAMP2DW5tC%3DZkyPFALX5Axc%2B_7dHeyJ%2BPiAen3Daq3PbEHDnRxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
