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 On Thursday, September 11, 2014 10:31:30 AM UTC-4, Michael DeHaan wrote: > > I definitely would like to see the ec2 guide upgraded to teach more ec2 > concepts. > > It's largely a holdover from the very early days, and needs to show some > basics like using add_host together with ec2 (as is shown elsewhere) > but also some more idioms. > > I'd be quite welcome to see it mostly rewritten should you want to take a > stab at improving it. > > > > On Thu, Sep 11, 2014 at 8:31 AM, Will Thames <[email protected] > <javascript:>> wrote: > >> I have some relatively extensive documentation on ec2 - it might be a >> little too over the top for the user guide. >> >> http://willthames.github.io/2014/03/17/ansible-layered-configuration-for-aws.html >> >> If you want me to incorporate any or all of it into the user guide, I'd >> be happy to do so. >> >> I haven't done enough with asgs to contribute much (and it seems like >> James' docs are pretty good to go anyway) >> >> Will >> >> On Tuesday, September 9, 2014 3:21:14 AM UTC+10, Michael DeHaan wrote: >>> >>> >>> >>> On Sun, Sep 7, 2014 at 5:48 PM, James Martin <[email protected]> wrote: >>> >>>> Michael, >>>> >>>> The reason for having both was to spur this very discussion. :). >>>> Option 1 is a bit more complicated but more transparent, option 2 is much >>>> easier but less transparent. I'm more fond of option 2, and happy to make >>>> it the only one. BTW, are we talking about the docs or the actual feature? >>>> >>> >>> I'm not sure option 1 is transparent more so than more manual/explicit? >>> I guess if you mean "less abstracted", yes. I would prefer the one that >>> lets me forget more about how it works :) >>> >>> >>>> As far as what the instances are being replaced with-- the ASG is going >>>> to spin up new instances with the current launch configuration. With >>>> option >>>> 2, the module starts by building a list of which instances should be >>>> replaced. This list is made up of all instances that have not been >>>> launched with the current launch configuration. The module then bumps the >>>> size of the ASG by the replace_batch size. It then terminates >>>> replace_batch_size instances at a time, waits for the ASG to spin up new >>>> instances in their place and become healthy, then continues on down the >>>> list until there are no more left to replace. Then it sets the ASG size >>>> back to it's original value. >>>> >>> >>> Ok, so I'm thinking *MAYBE* in the examples, we show a call to ec2_lc to >>> show the launch config change prior to the invocation, so the user can see >>> this in context. >>> >>> Sidenote to all - our ec2 user guide in the docs are lacking, and I'm >>> open to having them mostly rewritten. Showing a more end to end tutorial, >>> maybe one ec2 simple one and another using ec2_lc/asg, would be really >>> awesome IMHO. >>> >>> >>>> James >>>> On Sep 7, 2014 3:26 PM, "Michael DeHaan" <[email protected]> wrote: >>>> >>>>> Hi James, >>>>> >>>>> Thanks! >>>>> >>>>> In reading the PR examples section, I'm curious why we might show >>>>> Option 1 if Option 2 is much cleaner and would be interested in details. >>>>> >>>>> Also, quick question - it's replacing all instances, but what's it >>>>> replacing them *with* ? >>>>> >>>>> Perhaps this is something we should show as well, where we indicate >>>>> how to specify what the new instance IDs would be. >>>>> >>>>> Can you help me grok additions? >>>>> >>>>> Thanks again! >>>>> >>>>> +## Option 2 +This does everything that Option 1 does, but is >>>>> contained inside the module. It's more opaque,+but the playbooks end >>>>> up being much clearer.+++- ec2_asg:+ name: myasg+ >>>>> health_check_period: 60+ health_check_type: ELB+ >>>>> replace_all_instances: yes+ min_size: 5+ max_size: 5+ >>>>> desired_capacity: 5+ region: us-east-1++ >>>>> >>>>> On Sun, Sep 7, 2014 at 2:49 PM, James Martin <[email protected]> >>>>> wrote: >>>>> >>>>>> Dan, >>>>>> >>>>>> I've been tinkering with this process for quite a while and have made >>>>>> a pull request to ansible core that I believe does what you are looking >>>>>> for: >>>>>> >>>>>> https://github.com/ansible/ansible/pull/8901 >>>>>> >>>>>> As Michael stated, we will be releasing a blog post that's going to >>>>>> go more in depth in describing a few different ways to perform updates >>>>>> to >>>>>> ASG's that use pre-baked AMIs (this module approach being one of them). >>>>>> >>>>>> I appreciate any feedback/testing you can provide on that pull >>>>>> request of course. The documentation is inline in the module source. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> - James >>>>>> >>>>>> >>>>>> On Sun, Sep 7, 2014 at 2:23 PM, Michael DeHaan <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> James Martin is working on a 2-3 part blog post on *exactly* this >>>>>>> subject, which I believe we're going to be posting this week, which >>>>>>> shows a >>>>>>> couple of ways to do it. >>>>>>> >>>>>>> I've included him on this mailing list thread if he wants to share >>>>>>> some cliff-notes. >>>>>>> >>>>>>> --Michael >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Sep 7, 2014 at 2:08 PM, Daniel Langer <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm trying to use Ansible to do a rolling deploy against an ELB >>>>>>>> linked to an auto-scaling group (ASG), using a pre-baked AMI. My ideal >>>>>>>> process would go something like this >>>>>>>> >>>>>>>> 1. Get the current membership of the ASG >>>>>>>> 2. Update the launch configuration for the ASG >>>>>>>> 3. For each member: >>>>>>>> 3a. Create an instance using the new AMI >>>>>>>> 3b. Associate the instance with the ASG >>>>>>>> 3c. Terminate the original instance >>>>>>>> >>>>>>>> The other option I was considering was: >>>>>>>> >>>>>>>> 1. Get the current membership of the ASG >>>>>>>> 2. Update the launch configuration for the ASG >>>>>>>> 3. For each member: >>>>>>>> 3a. Terminate the instance >>>>>>>> 3b. Wait until the ASG has noticed and launched a new instance >>>>>>>> before continuing >>>>>>>> >>>>>>>> For the former, I don't see a way using the built-in EC2 modules to >>>>>>>> associate an instance with an ASG. For the latter, I'm not clear how >>>>>>>> I'd >>>>>>>> wait until the ASG has launched a new instance to catch up with the >>>>>>>> one I >>>>>>>> terminated. >>>>>>>> >>>>>>>> Any suggestions on how to do either one, or if that's not possible, >>>>>>>> what the best-practice for what I'm trying to do it? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> -- >>>>>>>> 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/ >>>>>>>> 42240c16-c2a5-4dac-b6f9-a30fc6e5b8d2%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/ansible-project/42240c16-c2a5-4dac-b6f9-a30fc6e5b8d2%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/0cbd0506-887c-4dbc-9bc9-57576a5b2005%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/0cbd0506-887c-4dbc-9bc9-57576a5b2005%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/479073a0-6d6b-49c2-998a-f4dd15a4bc96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
