AWS ECS

Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service.

An Amazon ECS service enables you to run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster. If any of your tasks should fail or stop for any reason, the Amazon ECS service scheduler launches another instance of your task definition to replace it in order to maintain the desired number of tasks in the service.

Reference & Image credit: https://www.slideshare.net/AmazonWebServices/deep-dive-ecs-fargate-deep-dive

Terminology
  1. ECS Cluster : An Amazon ECS cluster is a logical grouping of tasks or services.
    1. If you are running tasks or services that use the EC2 launch type, a cluster is also a grouping of container instances.
    2. If you are using capacity providers, a cluster is also a logical grouping of capacity providers.
  2. Task definition: The task definition can be thought of as a blueprint for your application. It specifies various parameters for your application.. It specifies
    1. One or more containers required for the task.
    2. Container image and command to run when it starts
    3. Whether container should run on ECS/ Fargate
    4. CPU, Memory, Networking, data volumes etc.
    5. Logging configuration , IAM role etc.
  3. Task : A task is the instantiation of a task definition within a cluster.
  4. Service: An Amazon ECS service enables you to run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster.
    1. If any of your tasks should fail or stop for any reason, the Amazon ECS service scheduler launches another instance of your task definition to replace it in order to maintain the desired number of tasks in the service.
  5. AWS Fargate: AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances.With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.

Task
  1. Network mode
    1. None: The task has no external network connectivity
    2. Host: The task bypasses Docker’s built-in virtual network and maps container ports directly to the ENI of the Amazon EC2 instance hosting the task. As a result, you can’t run multiple instantiations of the same task on a single Amazon EC2 instance when port mappings are used..
    3. Bridge: The task utilizes Docker’s built-in virtual network which runs inside each Amazon EC2 instance hosting the task.
    4. awsvpc: The task is allocated its own elastic network interface (ENI) and a primary private IPv4 address. This gives the task the same networking properties as Amazon EC2 instances.
  2. Data volumes: Amazon ECS supports the following data volume options for containers
    1. Fargate task storage: Supported for tasks hosted on Fargate
    2. Amazon EFS volumes: Supported for tasks hosted on EC2 and Fargate
    3. Amazon FSx for Windows File Server volumes: Supported for tasks hosted on EC2
    4. Docker volumes
    5. Bind mounts: Supported for tasks hosted on EC2 and Fargate
  3. Task Lifecycle
Task Definition

Example 





{




  "requiresCompatibilities": [




    "EC2"




  ],




  "containerDefinitions": [




    {




      "name": "nginx",




      "image": "nginx:latest",




      "memory": 256,




      "cpu": 256,




      "essential": true,




      "portMappings": [




        {




          "containerPort": 80,




          "protocol": "tcp"




        }




      ],




      "logConfiguration": {




          "logDriver": "awslogs",




          "options": {




              "awslogs-group": "awslogs-nginx-ecs",




              "awslogs-region": "us-east-1",




              "awslogs-stream-prefix": "nginx"




          }




      }




    }




  ],




  "volumes": [],




  "networkMode": "bridge",




  "placementConstraints": [],




  "family": "nginx"




}

Service

The service scheduler ensures that the scheduling strategy you specify is followed and reschedules tasks when a task fails (for example, if the underlying infrastructure fails for some reason)

  1. Launch type: EC2 or Fargate
  2. Service scheduler strategies
    1. Replica: Maintains desired number of tasks.
    2. Daemon: Deploys exactly one task on each active container instance.
      1. Note: Fargate does not support Daemon scheduling strategy
  3. Deployment types
    1. Rolling update: When a new service deployment is started the Amazon ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that Amazon ECS adds or removes from the service during a rolling update can be controlled by parameters
      1. minimumHealthyPercent
      2. maximumPercent
    2. Blue / Green deployment (with Code Deploy) : This deployment type enables you to verify a new deployment of a service before sending production traffic to it. There are three ways traffic can shift during a blue/green deployment:
      1. Canary
      2. Linear
      3. All-at-once
  4. Task placement: A task placement strategy is an algorithm for selecting instances for task placement or tasks for termination.
    1. AZ Balanced Spread
    2. AZ Balanced BinPack
    3. BinPack
    4. One Task Per Host
    5. Custom
  5. Load balancing: ECS service can use Elastic Load Balancing to distribute traffic across the tasks in your service.
    1. ECS service supports ALB, NLB and CLB.
    2. ALB: Recommendation is to use ALB. ALB features that make attractive for ECS services
      1. Dynamic host port mapping: Containers can use dynamic host port mapping so that multiple tasks from the same service are allowed per container instance
      2. Path based routing and priority rules: multiple services can use the same listener port on a single Application Load Balancer
    3. Reference and image credit: https://appfleet.com/blog/route-traffic-to-aws-ecs-using-application-load-balancer/
  6. Service discovery: Service discovery uses AWS Cloud Map API actions to manage HTTP and DNS namespaces for your Amazon ECS services.As a service scales up or down in response to load or container health, the Route 53 hosted zone is kept up to date, allowing other services to lookup where they need to make connections based on the state of each service.
    Reference and image credit : https://aws.amazon.com/blogs/aws/amazon-ecs-service-discovery/
  7. Autoscaling: Automatic scaling is the ability to increase or decrease the desired count of tasks in your Amazon ECS service automatically. Amazon ECS Service Auto Scaling supports the following types of automatic scaling:
    1. Target Tracking Scaling Policies: Increase or decrease the number of tasks that your service runs based on a target value for a specific metric.
    2. Step Scaling Policies: Increase or decrease the number of tasks that your service runs based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.
    3. Scheduled Scaling: Increase or decrease the number of tasks that your service runs based on the date and time.

Cloudwatch Container insights

CloudWatch Container Insights collects, aggregates, and summarizes metrics and logs from your containerized applications and microservices.

The CloudWatch Container Insights dashboard gives you access to the following information:

  • CPU and memory utilization
  • Task and service counts
  • Read/write storage
  • Network Rx/Tx
  • Container instance counts for clusters, services, and task
  • and more

Reference and Image credit: https://aws.amazon.com/blogs/containers/using-prometheus-metrics-in-amazon-cloudwatch/

https://aws.amazon.com/blogs/mt/introducing-container-insights-for-amazon-ecs/