Elastic Container Service (ECS)
Last updated
Last updated
Its a fully managed container orchestration service that helps you easily deploy, manage, and scale containerized applications.
There are 3 ways to do capacity management for this orchestration service.
Docker containers are placed on Amazon EC2 instances in this type of launch configuration.
Provisioning and managing the EC2 instance infrastructure needs to be done.
Each EC2 instances would be running ECS Agent who would be registering EC2 instances to ECS cluster.
ECS Task Placement strategy and Task placement constraints assists us to decide which ECS task to terminate when adding new adding new ECS Task due to scaling or new deployment to cluster.
Task Placement Strategy
This strategy is done based on best effort basis.
Following is the strategy algorithm
Identify instances that satisfy ECS task requirement of CPU, Memory and port as per Task definition.
Identify instances that satisfy the Task Placement Constraints.
Select instance for task placement.
Following are the strategies.
Binpack
Place Task based on least available CPU or memory.
Reduces the number of instances in use, resulting in cost savings.
Random
Places Task randomly.
Spread
Places based on specified value.
This value can be ECS availability zones, Instance Id and so on...
These strategies can be mixed and matched.
Task Placement Constraints
distinctInstance
Two task of same type are never placed on same EC2 instance.
memberOf
Places instances based on the result of an expression written in cluster query language.
In this type of configuration, the infrastructure (no EC2 instances to manage) is serverless.
Based on configuration for RAM and CPU provided, ECS will run the ECS tasks behind the scene.
Scaling is simply increasing the number of tasks.
Fargate launch type does not require host port to be configured as each ECS task gets its own private IP address throug an Elastic Network Interface (ENI) i.e., infrastructure is not to be managed by the user.
Task Definition is a blueprint of an application to be created.
It is a JSON document which has details regarding how to run a task definitions.
Following are the crucial information,
Image Name
Port bindings
Environment Variables
CPU and Memory usage
Networking information
IAM roles
Logging configuration
Can define upto 10 containers per task definition.
Environment variables can be loaded from,
Hardcoded i.e from URL etc..
Secret Manager
SSM parameter store
Amazon S3 (Bulk )
Data can be shared between containers created from same task defintion by mounting data volumes (Bind Mounts).
This concept is called SideCar container pattern, where sidecar container is used to read or write data (e.g., metrics/logs) to other destinations.
For EC2 instance launch type, EC2 instance store is the Bind Mount with
For Fargate launch type, Ephemeral Storage is the Bind Mount.
ECS tasks are runtime instance of Task Definition.
Containers are ECS tasks that run on ECS clusters.
IAM roles are assigned per task definition
Following roles are used based on launch type to create and manage ECS Task
Used by EC2 agent when launch type is EC2 instance.
This role helps to make API calls to ECS service.
Send logs to CloudWatch Logs.
Pull docker image from ECR.
Reference sensitive data in Secret Manager or SSM parameter store.
Applicable to both launch types.
Allows each tasks to have specific role based on the requirement.
These roles are defined in the task definition of ECS service.
ALB and NLB is supported to be integrated with ECS cluster.
Classic Load balancer is not recommended for integration and does not support Fargate Launch Type.
Application Load Balancer can connect to correct EC2 port for EC2 Launch Type when Dynamic Host Port Mapping is configured (i.e only container port is mapped), provided that Inbound Rules allow mapping to any port from ALB's security group.
AutoScaling allows to increase or decrease the desired number of ECS task.
Scaling can be one of the following
Target Tracking (based on configured CloudWatch Metrics).
Scaling can be based on following metrics,
ECS Service Average CPU Utilization
ECS Service Average Memory Utilization
ALB Request Count Per Target
Step Scaling
Scheduled Scaling
This scaling is not same as EC2 Auto Scaling.
Auto Scaling Group Scaling
Scale your ASG based on CPU Utilization i.e Add EC2 instance when CPU utilization reaches the target threshold.
ECS Cluster Capacity Provider
Capacity provider paired with Auto Scaling Group.
Add EC2 instances when resource utilization reaches the target threshold configured.
This is a better scaling option that the Auto Scaling Group Scaling.
Rolling updates ensure high availability of your application when it getting updated or new changes are being deployed.
This is done by making sure a min number of tasks are running at the time of updates, but doesnt cross the max number of tasks running.
Can be mounted to ECS tasks of both EC2 and Fargate launch types.
Tasks running in any AZ can connect with EFS and share data. Hence help us achieve multi-AZ shared storage for your containers.
EFS + Fargate => Serverless.
Cannot be mounted as file system.
When min is 50% and max is 100% the following diagram shows how an application does rolling update.
