My main objective is to utilize GPU for one of our existing task being deployed through Fargate.
We have existing load balancers for our staging and production environments.
Currently we have two ECS Fargate clusters which deploy Fargate serverless tasks.
We want to be able to deploy one of our existing fargate tasks with GPU, but because fargate doesn't support GPU, we need to configure an EC2 task.
To do this, I believe we need to create EC2 auto-scaling groups associated with both the staging and production environments that allow for deploying an EC2 instances with a GPU through ECS.
I'm unsure whether or not we need to create a new cluster to house the EC2 task, or if we can put the EC2 task in our existing clusters (can you mix Fargate and EC2 like this?).
We're using Terraform for Infrastructure as code.
Any AWS documentation or relevant Terraform docs would be appreciated.
You can absolutely mix Fargate and EC2 tasks in the same cluster. Recommended checking out Capacity Providers for this: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html
Related
I have a cluster with a mixture of services running on EC2 and Fargate, all being used internally. I am looking to deploy a new Fargate Service which is going to be publicly available over the Internet and will get around 5000 requests per minutes.
What factors do I need to consider so that I can choose if a new cluster should be created or if I can reuse the existing one? Would sharing of clusters also lead to security issues?
If your deployment is purely using Fargate, not EC2, then there's really no technical reason to split it into a separate ECS cluster, but there's also no reason to keep it in the same cluster. There's no added cost to create a new Fargate cluster, and logically separating your services into separate ECS clusters can help you monitor them separately in CloudWatch.
Im developing a django website.
On the devops side, im considering using aws with an autoscaling. I still hesitate to contenerize my config, so I would use either beanstalk (without container) or container service (with docker). The database will be on aurora on a separate server.
I am new to aws and the help they provide online by expert is not free so here is my question :
When i compare with other hosting providers, their prices depend on the hardware configuration of the server.
I guess (because i dont yet have access to cost explorer) that it is the same with ec2 instances on amazon: you pay more for more powerful servers (cpu and ram and/or storage).
So im wondering how elastic beanstalk or elastic container instanciate new ec2 servers : do they invoke more powerful hardware configurations(scaling up) based on the demand on my website or does it depend on my manual configuration ? Or do they only replicate ec2 instances (scaling out) with the same config i manually set at the init?
Can i manually change the cpu,ram and storage of an ec2 instance of benstalk or ecs without re-configuring it all?
Can i fine tune the autoscaling out and autoscaling up and which scaling is better and cheaper (best choice)?
thanks a lot!
Auto Scaling groups scales out horizontally, means spawn new instances like defined in the launch template/launch configuration. Auto Scaling group cannot scale vertically. You can change the launch cofiguration and edit the instance type and size, which will replace your instances in the Auto Scaling Group.
https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html
With ECS, you have to option Fargate or ECS on EC2. With Fargate (serverless) you can easily define how much resource RAM/CPU you want to allocate to the "task" to run. With ECS EC2, you need to first create the ECS Cluster (need to allocate EC2 for running the cluster), then create a seperate task and then allocate RAM and CPU to it.
https://docs.aws.amazon.com/AmazonECS/latest/userguide/task_definition_parameters.html
Using Beanstalk you can easily define how much resources RAM/CPU want to use in the configuration. (Easier than just running plain autoscaling groups with a load balancer). It has a very easy interface to play around and adjust the resources.
I have 3 containerized applications. All these applications are a simple python script that calls an api at different times. For example, App1: calls every hour, App2: calls every 30 mins, and App3: calls every minute. Right now we have an ec2 instance for each application, which is ok because I need the applications to run on different AWS EC2 Instances because I don’t want my IP Blacklisted. But now how would I go about scaling an application? For example, I need 3 instances of app 1.
Im currently using Terraform to create the EC2 instances and while that can work I don't know how to go about automating updating the images on each EC2 instance.
I tried using AWS ECS to scale the container but this requires that it shares IP address ( I would like for these applications to live in different VMS(EC2 Instances.), so that the IP does not have a problem getting blacklisted.) with the other applications and I don’t want that.
What tools or architecture can best help me accomplish the scaling of these applications?
For your specific case, I would suggest AWS Fargate ECS + Cloudwatch events cron triggers (Scheduled Fargate ECS tasks).
Fargate instances have awsvpc network mode by default, which means if you run them in public subnet with public IP allocation, each container instance will retrieve unique public IP (via dedicated automatically attached ENI - Elastic Network Interface).
Additionally, running tasks on Fargate will allow you to utilize much more convenient docker packaging of your applications while keeping management & operating requirements low - as Fargate is a Server-less container scheduler, and it requires less effort than operating AWS EC2 instances.
You will need 3 ECS resources :
cluster
template resource for container definition
task definition resource
and 3 CloudWatch resources:
aws_cloudwatch_event_rule
aws_cloudwatch_event_target
aws_cloudwatch_log_group
in Terraform to make it work, + ECR repo/s for storing image artifacts.
I am trying to develop a spring cloud micro services. And I planned to deploy into AWS cloud. When I reading AWS resources I found that ECS providing configuration less environment for deploying microservices other than EC2. My doubt is that
Can I choose ECS resource for my complete services deployment without configurations?
For creating ECS service, is EC2 instance mandatory? Can I use ECS only in my account without creating EC2 VM? I need to know about ECS is alternative for EC2?
ECS is a service which offers clustering of vm for docker container, manages container lifecycle.
1) Yes. You can use ECS for your service deployment and it needs some basic configuration which will be one time.
2) No. To run docker container you need EC2 instance without that its not possible to run. EC2 instance are managed by ECS so you only need to provide some config like region,security group etc.
For complete config and deployment refer below link.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_GetStarted.html
I'm planning to use Docker, and associate 1 EC2 instance with 1 Microservice.
Why do I want to deploy Docker in AWS ECS vs. ElasticBeanstalk?
It is said that AWS ECS has a native support to Docker. Is that it?
It would be great if you could be elaborate the pros and cons of running docker on AWS ECS vs. ElasticBeanstalk.
Elastic Beanstalk (multi-container) is an abstraction layer on top of ECS (Elastic Container Service) with some bootstrapped features and some limitations:
Automatically interacts with ECS and ELB
Cluster health and metrics are readily available and displayed without any extra effort
Load balancer must terminate HTTPS and all backend connections are HTTP
Easily adjustable autoscaling and instance sizing
Container logs are all collected in one place, but still segmented by instance – so in a cluster environment finding which instance served a request that logged some important data is a challenge.
Can only set hard memory limits in container definitions
All cluster instances must run the same set of containers
As of ECS IT is Amazon’s answer to container orchestration. It’s a bit rough around the edges and definitely a leap from Elastic Beanstalk, but it does have the advantage of significantly more flexibility including the ability to even define a custom scheduler.
All of the limitations imposed by Elastic Beanstalk are lifted.
Refer these for more info :
Elastic Beanstalk vs. ECS vs. Kubernetes
Amazon EC2 Container Serivce
Amazon Elasticbeanstalk