On Thu, Sep 11, 2014 at 2:51 PM, Scott Anderson <[email protected]> wrote:
> > The general problem with this approach is that it doesn’t work well for > blue-green deployments, nor if the new code can’t coexist with the > currently running code. > Yep, understood. > I think we’re probably going to move to a system that uses a tier of > proxies and two ELBs. That way we can update the idle ELB, change out the > AMIs, and bring the updated ELB up behind an alternate domain for the > blue-green testing. Then when everything checks out, switch the proxies to > the updated ELB and take down the remaining, now idle ELB. > > Not following this exactly -- what's your tier of proxies? You have a group of proxies (haproxy, nginx) behind a load balancer that point to your application? > Amazon would suggest using Route53 to point to the new ELB, but there’s > too great a chance of faulty DNS caching breaking a switch to a new ELB. > Plus there’s a 60s TTL to start with regardless, even in the absence of > caching. > Quite right. There are some interesting things you can do with tools you could run on the hosts that would redirect traffic from blue hosts to the green LB, socat being one. After you notice no more traffic coming to blue, you can terminate it. > You may have missed the “cycle_all” parameter. If False, only instances > that don’t match the new AMI are cycled. > > > You're right, I did miss that. By checking the AMI, you're only updating the instance if the AMI changes. If you a checking the launch config, you are updating the instances if any component of the launch config has changed -- AMI, instance type, address type, etc. > Using the ASG to do the provisioning might be preferable if it’s reliable. > At first I went that route, but I was having problems with the ASG’s > provisioning being non-deterministic. Manually creating the instances seems > to ensure that things happen in a particular order and with predictable > speed. As mentioned, the manual method definitely works every time, > although I need to add some more timeout and error checking (like what > happens if I ask for 3 new instances and only get 2). > > I didn't have any issues with the ASG doing the provisioning, but I would say nothing is predictable with AWS :). > I have a separate task that cleans up the old AMIs and LCs, incidentally. > I keep the most recent around as a backup for quick rollbacks. > That's cool, care to share? -- 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/CAMP2DW5Ngpn2jOaVnfGg5_fQwqyVFHpQP9xVLozjRjezZdoFxA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
