简体   繁体   中英

AWS auto-scaling group AMI

I have four EC2(API server) instances running on AWS with ELB and I would like to apply auto-scaling group. From my understanding, I first should create an AMI of one of four EC2 instances that I am running and it auto scales from the AMI that I have created based on configuration. At this point, should I re-create the AMI whenever pushing new codes so that it scales up from a latest version of it?

You have the basics down.

When you use Auto Scaling Groups (ASG), your EC2 instances should be stateless. This means that you do not keep data on the instances, but store your data someplace else such as RDS or S3. When ASG launches a new instance, your EC2 instance should have a script (such as in EC2 Userdata) to download or copy any required data for a new instance.

When you already have a good EC2 instance configuration and setup, create an AMI from one of the EC2 instances as your new AMI for the ASG.

When you modify your instance with permanent information (eg new Windows or Linux patches, software or application updates, etc.) then you create a new AMI to replace the previous AMI.

Auto Scaling Groups

There is more than one option to manage your AMIs for launching; from full-baked AMI to base OS AMIs that are configured on launch. Each has its pros and cons.

After many years of managing fully baked AMIs, we are moving towards an AMI build pipeline approach - with instances that self-configure on first launch - that will manage AMI provisioning in a more "continuous integration" way.

So to answer your question, yes you can use pre-baked AMI to use in your auto-scaling groups. But this approach limits flexibility, and can produce maintenance headaches, especially if running multiple accounts and/or environments.

From AWS AMI Design :

AMI design options fall along a spectrum of deployment simplicity in relation to deployment flexibility. The simplest AMIs are fully baked and purpose-built to deploy a complete running instance, including the installation and configuration of all required software. However, this approach limits flexibility, as a fully baked AMI can only be used to deploy a single instance or a farm of identical instances. The most flexible AMIs include only minimal configurations and software before then dynamically installing the required packages on first boot. This approach trades simplicity for flexibility as each instance must be properly bootstrapped before it can function as intended.

The right approach will consider your skill set, AWS experience, and DevOps infrastructure.

Yes, the updated code should be baked into a new AMI which will be pushed to EC2 (deploy) any time you're modifying the code.

Another approach would be to use a docker image this way you can use the same AMI and update your docker image instead.

You don't need to recreate the AMI each time you do code changes. In fact you can use AWS CodeDeploy with Autoscaling groups to have your latest code deployed each time a new EC2 instance is created.

It's explained here: https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorials-auto-scaling-group.html

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM