Search code examples
amazon-web-servicesamazon-ec2amazon-amipacker

How to update custom AMIs using packer and integrated with auto-scaling group?


Goal: To maintain the minimum startup period for bringing up instances to load balance and reduce the troubleshooting time.

Approach:

  1. Create base custom-AMI for ec2-instances
  2. Update/rebundle the custom AMI on every release and s/w patches (code & software updates related to the healthy running instance). 2.a. Packer/any CI usage for update is possible? If so, how? (unable to find a step-by-step approach in documentations of package)
  3. Automate the step 1 and step 2 using chef.
  4. Integrate this AMI in the Auto scaling group (experimented this).
  5. Map the Load balancer to ASG [done].
  6. Maintain the desired count of Instances by bringing up instances from updated-AMI in ASG with LB upon failure.

Crux: Terminate the unhealthy instance and bring up the healthy instance with ami asap.

-- P.S: I have gone through many posts from [http://blog.kik.com/2016/03/09/using-packer-io-to-optimize-and-manage-ami-creation/] and https://alestic.com/.

Using docker is rolled out of discussion.

But still unable to figure out a clear way to do it.


Solution

  • The simplest way to swap out a new AMI in an existing ASG is to update the launch config and then one by one kill any instance using the old AMI ID. The ASG will bring up new instances as needed, which should use the new AMI. If you want to get fancier (like keeping old instances alive for quick rollback) check out tools like Spinnaker which brings up each new AMI as a new corresponding ASG and then remaps the ELB to swap traffic over if no problems are detected, and then later on when you are sure the deploy is good it kills off the old ASG and all associated instances.