I created an EC2 instance on AWS to use as an ECS instance. I followed these steps here to do that.
I also created a new Cluster under ECS but for some reasons, I cannot see the instance under the cluster:
Any ideas on what might be the issue here?
I found the missing piece. It was stated here as part of 10th item on the list that:
By default, your container instance launches into your default cluster. If you want to launch into your own cluster instead of the default, choose the Advanced Details list and paste the following script into the User data field, replacing your_cluster_name with the name of your cluster.
I would strongly suggest letting ECS Cluster create its own EC2 Instance(s), especially if you are new to this. You can define the type of instance that you want when you create the cluster and everything will magically work.
Doing it the other way around (EC2 Instance first, then feeding/attaching it into the Cluster) might sound quite natural to you, but it means that you have to handle a lot of things by yourself. You have to manually spend time on
Making sure you pick the right AMI (ecs-optimized),
Making sure the VPC-Subnets are right,
Making sure the architecture is right (e.g. t4g medium instances don't take x86 containers),
Making sure the Cluster Name is in /etc/ecs/ecs.config and then after that restart docker & ecs-agent.
Making sure ecs-agent is properly set up and connecting,
... and blah blah blah.
Maybe, and hopefully, in future they will add an "attaching this EC2 Instance to that Cluster" button that does all these chores. But until then, save yourself this list of headaches and try to get the instance created by the cluster.
I already had a cluster configured, so the easiest way to do this for me was to go to EC2 Console > Auto scaling groups and select the autoscaling group for the cluster. Make sure to increase the desired capacity and maximum capacity. This should start a new EC2 instance.
Related
I have 1 perfect AWS EC2 instance in working condition which is running NODE js
which have its elastic IP.
Now I need to auto-scale if that instance in use over 80%.
I do know few ways to do that but am not able to figure out, when new instance launches how will my node code will be on that instance.
Later when I want to update my node code then on which instance should I connect with?
If anyone can help me with this then it would be awesome.
Thanks :)
If you want to use the EC2 AutoScaling, you must know that the instances are in a stateless mode ( can be started/Terminated) by the autoscaling group regarding the metrics and indications of elasticity ( cpu, number of request...) memory is
a custom metric
So to use the AutoScaling group, you must generate from your current working machine an AMI ( Amazon Machine Image) that contains the code of your node.js and create a launch configuration/template, for the next machines EC2 can use it to bootstrap.
IF you want to update your code, that means you must update your Launch configuration ( updated AMI, or use the user data bootstrap to get the update node.js from S3 or other location) or use maybe CodeDeploy wich is the perfect candidate for this king of subject.
I have created a cluster to run our test environment on Aws ECS everything seems to work fine including zero downtime deploy, But I realised that when I change instance types on Cloudformation for this cluster it brings all the instances down and my ELB starts to fail because there's no instances running to serve this requests.
The cluster is running using spot instances so my question is there by any chance a way to update instance types for spot instances without having the whole cluster down?
Do you have an AutoScaling group? This would allow you to change the launch template or config to have the new instances type. Then you would set the ASG desired and minimum counts to a higher number. Let the new instance type spin up, go into service in the target group. Then just delete the old instance and set your Auto scaling metrics back to normal.
Without an ASG, you could launch a new instance manually, place that instance in the ECS target group. Confirm that it joins the cluster and is running your service and task. Then delete the old instance.
You might want to break this activity in smaller chunks and do it one by one. You can write small cloudformation template as well because by default if you update the instance type then your instances will be restarted and to avoid zero downtime, you might have to do it one at a time.
However, there are two other ways that I can think of here but both will cost you money.
ASG: Create a new autoscaling group or use the existing one and change the launch configuration.
Blue/Green Deployment: Create the exact set of resources but this time with updated instance type and use Route53's weighted routing policy to control the traffic.
It solely depends upon the requirement, if you can pour money then go with above two approaches otherwise stick with the small deployments.
I've an ECS cluster with running one task for my backend instance. I would like to be able to stop/start the EC2 instance whenever I want. Is it possible?? I was trying to stop instance directly but it terminates after few second when stopped and after that new instance is created automatically. I tried to change the Auto Scale Group to match desired=min=0 capacity but when I do that the instance gets auto terminated. I just want to turn off the Ec2 instance when its not needed to be used but at the same time I want data to persist betweet turning on and off. I am fighting with this for a few days now and wasn't able to achieve my goals.
Also how to link EBS volume with VOLUME /root/.local/share/XYZ from docker file image to persist the data from the XYZ folder
I would suggest you to do modifications in autoscaling group, when you want to turn off instance put 0 in auto scaling and when you want to turn on change value in autoscaling,
... you can do that with aws cli , and you can shcdule the period also by putting aws cli command in cron job
I would suggest using EFS. Here is an article from AWS on how to persist data from ECS containers using EFS.
Using Amazon EFS to Persist Data from Amazon ECS Containers
Start/Stop instances and auto-scale don't really fit together.
Auto-scale is specifically designed to solve scalein/scaleout.
One way to address this could be using customized termination policy (but I never tried this in ECS setup).
One note though, if your customized termination policy never terminates the instances and you continue adding instances to keep always, you might get good amount EC2 bill.
I do not know much about how AWS works since the person who set the whole thing up does not work with us anymore, and I do not specialize in Amazon at all.
I need to set up an auto-scaling on my EC2 instance. I am currently reading all available tutorials to learn the how-to, but there is one thing I cannot find at all. The auto-scaling automaticaly start new instance of EC2 but I cannot find anything about how to do anything in those instance.
Currently, to start our webservices, we need to log into the instance, pull the code from git and launch the whole thing with PM2. I cannot find anything about how to do all those things automatically at the start of the instance.
I think this is supposed to be basic stuff, but as I said, I know next to nothing about how to start, and I do not have much time to learn (my boss just told me I had to be done by the end of the week !)
So if anyone know where to learn this, that would be really helpful. Thanks!
You need a Launch Configuration for setting up an Auto Scaling Group (ASG). The Launch Configuration is where you define all your instance configurations such as type, disk size, security groups, etc. One of these configurations is AMI ID. The AMI ID refers to the image to be used when launching a new instance in the ASG. So you basically need to launch a machine, install everything needed on it, create an image out of it, create a launch configuration using that image, and use that launch configuration in your ASG. This way you do not need to go to the newly added servers every time. But if you like them to run the updated (last) version of your application, you should have a scheduled job in your image which is triggered on-start. This job is responsible for copying the files (e.g. compiled files) from somewhere (a deployment machine for instance) to the newly added instance and then starting it.
The method for configuring an Amazon EC2 instance does not actually require Auto Scaling. The two main options for configuring an instance are:
Launching from a pre-configured AMI that already contains the desired software, or
Running a startup script via User Data, which executes once the instance has launched
You can choose one of the above and then test it by launching an instance via the management console or from a script that calls the AWS Command-Line Interface (CLI).
To incorporate it into Auto Scaling, configure the Auto Scaling Launch Configuration with the same parameters and then each new instance launched by Auto Scaling will automatically be configured.
I wonder if there is a simple way or best practices on how to ensure all instances within an AutoScaling group have been launched with the current launch-configuration of that AutoScaling group.
To give an example, imagine an auto-scaling group called www-asg with 4 desired instances running webservers behind an ELB. I want to change the AMI or the userdata used to start instances of this auto-scaling group. So I create a new launch configuration www-cfg-v2 and update www-asg to use that.
# create new launch config
as-create-launch-config www-cfg-v2 \
--image-id 'ami-xxxxxxxx' --instance-type m1.small \
--group web,asg-www --user-data "..."
# update my asg to use new config
as-update-auto-scaling-group www-asg --launch-configuration www-cfg-v2
By now all 4 running instances still use the old launch configuration. I wonder if there is a simple way of replacing all running instances with new instances to enforce the new configuration, but always ensure that the minimum of instances is kept running.
My current way of achieving this is as follows..
save list of current running instances for given autoscaling group
temporarily increase the number of desired instances +1
wait for the new instance to be available
terminate one instance from the list via
as-terminate-instance-in-auto-scaling-group i-XXXX \
--no-decrement-desired-capacity --force
wait for the replacement instance to be available
if more than 1 instance is left repeat with 4.
terminate last instance from the list via
as-terminate-instance-in-auto-scaling-group i-XXXX \
--decrement-desired-capacity --force
done, all instances should now run with same launch config
I have mostly automated this procedure but I feel there must be some better way of achieving the same goal. Anyone knows a better more efficient way?
mathias
Also posted this question in the official AWS EC2 Forum.
Old question I know but I thought I would share my approach.
I change the launch config for an ASG, I then launch the same number of instances as are currently in the ASG, as they become available (automated testing) they are attached to the ASG. once the machines have been added our deployment system updates our varnish loadbalancer(s) to use the new instances and the old instances are terminated.
All of the above is automated and a full site scale switch takes about 5 minutes depending on the launch time.
incase you are wondering, we use SNS to handle updating varnish when instances are added or removed or in the case of our loadbalancers scaling (which almost never happens) the deployment system will update our route53 config instead.
I think that pretty much covers everything
This isn't a lot different, but you could:
create the new LC
create a new ASG using the new LC
scale down the old ASG
delete the old asg and LC
I do deployments this way, and it's in my experience to roll from one ASG to another, rather than having to jump back and forth. But as I noted, it's not a huge difference.
It might be worth looking at: https://github.com/Netflix/asgard , which is a Netflix OSS tool for managing autoscaling groups. I ended up not using it, but it's pretty interesting nonetheless.