I created a t2.micro EC2 instance and configured node.js on it. That is running fine.
Next I tried to create an Auto Scaling group with this instance that creates a Launch Configuration then Auto Scaling group with Launch Configuaration also created successfully.
The problem is that when Auto Scaling works, the new instance created is not the exact replica (image) of the old instance. It does not copy my node.js configuaration and the data files.
Where I am going wrong and how achieve this requirement on AWS?
When Auto Scaling launches a new Amazon EC2 instance, it uses the Amazon Machine Image (AMI) specified in the Launch Configuration. The new instance will have the exact same contents as the AMI.
It sounds like you are either using a standard Amazon-issued AMI, or you created your own AMI before you configured your instance. Any configurations done after the AMI creation will not carry across to new instances because it is not part of the AMI.
You should:
Launch an instance and configure it how you wish
Create an AMI (Actions / Image / Create Image)
Create a Launch Configuration that uses that AMI
Edit your Auto Scaling group to use that Launch Configuration
Any new instances launched by Auto Scaling will use the new AMI, which will have all your configurations.
An alternate to create a custom AMI is to use a User Data Script that will automatically run when a new instance starts. This script can download software, change settings and generally personalize the instance. This could be easier to update rather than having to create new AMIs when you want to change something. The User Data script can be entered into the Launch Configuration, which will be used by Auto Scaling when launching new instances.
Related
I am using ASG for my application and I am attaching running instance to create ASG
Now the main problem is, Whenever new instance via ASG gets created it does not replicate the EC2 Instance attached to it so I cannot take updated or point in time binaries available on that running instance.
I get a fresh blank AMI to work which won't work for me.
Is there any way that I can replicate or I can use the attached instance as a base image in ASG while scaling out
AWS Auto scaling terminating instance & creating 2nd instance with new root volume,1st instance root volume available! what is the use of auto scaling here? It just created empty instance, IP changed,rpm's,services installed not replicated to 2nd instance.
If I manually deatach attach root volume of old instance to new instance and restore services manually then what is the use of Auto Scale?
Any way to handle this?
Amazon EC2 Auto Scaling will always scale-out by launching a new EC2 instance (including its own Amazon EBS boot volume) and will scale-in by terminating an EC2 instance. By default, EBS volumes on a terminated instance will be deleted by this can be overridden to keep the volume (but it won't be used when Auto Scaling launches a new instance).
To pre-load software onto an Amazon EC2 instance that is launched by Auto Scaling, there are two choices:
Create a fully-configured AMI containing all desired software and configurations. When Auto Scaling launches a new instance, it will create a boot volume (and additional volumes if desired) and will automatically load the disk contents from the AMI (Amazon Machine Image). Thus, each instance will boot with a fully-configured disk. It is your responsibility to create the AMI and maintain it with the latest version of the software you want to use. Also, please note that each new instance contains exactly what was saved on the AMI -- any changes to a disk attached to an instance is not reflected on any other instances because they are separate disk volumes.
Use a startup (User Data) script to configure the instance after it boots. This script can download and install software, set configurations and do anything you wish to script! The downside is that it takes a little longer for the instance to be ready because it needs to perform these startup tasks. The benefit of this method is that the software can be updated simply by starting a new volume — the script could automatically download the latest version of the software (whereas an AMI always contains the same contents unless a new AMI is created). This is a great way to upgrade systems — just throw away an old instance and start a new instance!
It is also possible to combine these two methods, such as having a mostly-configured AMI (eg with desired frameworks and security configurations) and then use a startup User Data script to finish the setup by installing the application.
I have the following flow for Patch update of web app code in AWS
1) An m4.xlarge instance (Patch Instance) in which development team update code at the particular interval.
2) I, then create an AMI and Launch Configuration using that instance.
3) Using newly created Launch Configuration, I update Autoscaling Group to add the new instance(m4.xlarge) with latest AMI.
Now the questions I have are:
1) Can I make my Patch Instance of t2.micro type and make Autoscaling create the new instance with m4.xlarge? This is just for optimization as Patch Instance is underutilized.
2) Any better way for the patch update?
Yes, you can make an AMI of any instance type and use it on a bigger or smaller one.
Could you collaborate on what the Development team is patching?
I have setup a HA architecture using Autoscaling, load balancer , code deploy.
I have a base-image through which autoscale launch any new instance. This base-image will get outdated with time and I may have to upgrade it.
My confusion is how can I provision this base AMI to install desire version of packages ? and How will I provision the already in-service instances ?
For-example - Currently my base AMI have php5.3 but if in future I need PHP5.5 then how can I provision in-service fleet of EC2 instances and as well as base AMI
I have Chef as provisioning server. So how should I proceed for above problem ?
The AMI that an instance uses is determined through the launch configuration when the instance boots. Therefore, the only way to change the AMI of an instance is to terminate it and launch it again.
In an autoscaling scenario, this is relatively easy: update the launch configuration of the autoscaling group to use the new AMI and terminate all instances you want to upgrade. You can do a rolling upgrade by terminating the instances one-by-one.
When your autoscaling group scales up and down frequently and it's OK for you to have multiple versions of the AMI in your autoscaling group, you can just update the launch configuration and wait. Every time the autoscaling process kicks in and a new instance is launched, the new AMI is used. When the autoscaling group has the right 'termination policy' ("OldestInstance", for example), every time the autoscaling process scales down, an instance running the old AMI will be terminated.
So, let's say your have 4 instances running. You update the launch config to use a new AMI. After 4 scale-up actions and 4 scale-down actions, all instances are running the new AMI.
Autoscale has a feature called Launch Configuration, which includes the ability to pass in userdata, which will get executed at launch time. The userdata can be saved within Launch Configuration so that you can automate the process.
I have never worked with Chef and I'm sure there is a Chef-centric way of doing this, but the quick and dirty would be to use userdata.
Your userdata script (i.e. BASH) would then include the necessary sudo apt-get remove / install commands (assuming Ubuntu OS).
The documentation for this is here:
http://docs.aws.amazon.com/AutoScaling/latest/APIReference/API_CreateLaunchConfiguration.html
UserData The user data to make available to the launched EC2
instances. For more information, see Instance Metadata and User Data
in the Amazon Elastic Compute Cloud User Guide.
At this time, launch configurations don't support compressed (zipped)
user data files.
Type: String
Length constraints: Minimum length of 0. Maximum length of 21847.
Pattern: [\u0020-\uD7FF\uE000-\uFFFD\uD800\uDC00-\uDBFF\uDFFF\r\n\t]*
Required: No
In autoscaling group I have four machines. I have modified or added few changes on the instance and took IMAGE/AMI. If load increase autoscaling will add new instances. Now, I want new launched instances with latest AMI. Is this possible?
Your AMI is associated at the Launch Configuration level. You have to update your Launch Configuration to point out to the new AMI you created. Then you associate your new LC with your AutoScalingGroup.