Would you like to run and orchestrate Docker containers automatically on AWS? Do your applications need to scale up or down continuously, based on different metrics? Do you have microservices applications running on Docker containers? Would you like to free up compute resources after jobs or applications finish processing?
If so, this blog is for you. We’ll take a look at ECS, Amazon’s container management system, and its task placement strategies, to help you improve scalability and efficiency.
What is Amazon ECS?
Amazon Elastic Container Service (Amazon ECS) is a fast, highly scalable, high-performance service that manages Docker container orchestration using the compute capabilities of Amazon. It eliminates the need to install and operate your own container orchestration software, manage and scale a cluster of virtual machines, or schedule containers on those virtual machines. Amazon ECS uses Amazon Elastic Container Registry (Amazon ECR) to store the images needed to run the containers, but it can also retrieve images directly from Docker Hub. Docker daemon is used to run the containers inside an Amazon ECS Cluster.
Amazon ECS enables you to:
- Use AWS Fargate to deploy and manage containers without having to provision or manage servers.
- Containerize everything.
- Launch containers in an Amazon Virtual Private Cloud (Amazon VPC), using VPC security groups and network Access Control Lists (ACLs).
- Easily scale up to launch an unlimited number of Docker containers in seconds.
Amazon ECS Task Placement
Within a cluster, an Amazon ECS task is the instantiation of a task definition (the configuration that a Docker container will use when it is created by an ECS service such as image, volumes, environment variables, memory, CPU, etc.). After you have created a task definition for your application within Amazon ECS, you can specify the number of tasks that will run on your cluster.
When a task is launched, Amazon ECS determines where to place it based on the requirements specified in the task definition. When the number of tasks is scaled down, Amazon ECS determines which tasks to terminate.
Task placement strategies (logic to fine-tune task placement or tasks for termination) and constraints (task placement hard limits) enable you to:
- Customize how Amazon ECS places and terminates tasks when you are running a task or creating a new service.
- Have greater control over how tasks are placed inside your cluster, by changing the logic to ensure high availability, greatest cost efficiency, and best practices.
Service task placement strategies cannot be updated. If updating is required, the service will need to be recreated. Adding task placement strategies and constraints in AWS CloudFormation will cause a resource recreation instead of an updation.
Types of task placement strategies
Binpack places tasks on the instance which can fulfill the least requirements of memory and CPU, perfect for saving instance costs.
Spread allocates tasks evenly across instances to achieve high availability.
Random places tasks randomly across the cluster.
You can chain together multiple task placement strategies with their respective attributes, up to five strategy rules per service.
Let’s say you have a requirement to spread your tasks across availability zones while also minimizing the usage of memory and saving instance costs. You can chain the spread and binpack placement strategies to first spread the tasks across availability zones and then place them in a binpack configuration based on memory utilization.
It should look something like the following:
placementStrategy": [
{
"field": "attribute:ecs.availability-zone",
"type": "spread”
},
{
"field": "memory",
"type": "binpack"
}
]Types of task placement constraints
- distinctInstance is used to make Amazon ECS place tasks on individual instances so that every container is started on a unique instance in your cluster. You can use the distinctInstance placement constraint from the dashboard by selecting “One task per host” in the placement template on the Task Placement panel. Alternatively, if you are using AWS CloudFormation, you can add the following snippet to your CloudFormation template
"placementConstraints": [ { "type": "distinctInstance" } ] - memberOf describes a set of instances on which your tasks should run. It can be used for running a task, creating a new service, creating a new task definition, or creating a new revision of an existing task definition. It places tasks on the basis of a certain attribute such as ecs.ami-id (the ID of the Amazon Machine Image or AMI used to launch the instance), ecs.instance-type, ecs.availability-zone, ecs.os-type (operating system for the instance), and custom attributes. memberOf is great to specify task placement based on required business logic. You could separate two different variations of tasks (e.g we could place graphic-intensive tasks on a dedicated G3 EC2 instance while placing other memory- and compute-intensive tasks on better-suited instance types).
In Conclusion
We recommend that you use ECS Task Placement Strategies to:
- Implement applications faster.
- Optimize resources and costs.
- Scale up/down compute resources as needed.
- Have greater control over task placement inside clusters.
- Contribute to high availability and cost efficiency.
Need help with containers? The nClouds team is here to help with that and all your AWS infrastructure requirements.
