Docker can be installed on the most commonly used OS platforms. CoreOS has Docker pre-installed, and is designed specifically for running Docker containers. Docker for AWS provides an out-of-the-box Docker swarm mode in which a cluster of nodes, called a swarm, provides a distributed platform for running Docker container applications.
Problem:All the aforementioned Docker platforms are only different types of Docker installations, and require Docker containers to run and be managed on the command line.
Solution: Amazon ECS (Elastic Container Service) is a managed service for Docker containers with built-in support for scaling, load balancing, networking, storage, logging, and other Docker container management tasks. Amazon ECS supports two launch types: EC2 and Fargate.
With the EC2 launch type, EC2 instances are started to run Docker containers. The Fargate launch type, which was introduced recently (November 2017), hosts tasks that encapsulate Docker containers. The tasks are directly made accessible to the user via an Elastic Network Interface (ENI). The EC2 instances on which Fargate is provisioned are not exposed to the user and are not directly accessible.
In this chapter, we will learn about the following:
- What Amazon Fargate is
- Benefits of Fargate
- Amazon ECS objects
- Compute resources in Amazon ECS Fargate
- What's new in the Amazon Fargate launch type mode?
Amazon Fargate is a new launch type for Amazon ECS and Amazon EKS (Elastic Kubernetes Service)-managed orchestration services for Docker containers on AWS. With the Fargate launch type, the infrastructure is fully provisioned by Fargate. It is serverless, and no EC2 instances are exposed to the user. Docker containers are defined as container definitions within a task definition. A service implements the task definition to run one or more tasks. Each task is associated with an ENI. If the auto-assignment of the public IP at the task level is enabled, a public IP on which an external client may access a task is automatically assigned to a task. Tasks communicate with each other over a private IP.
The benefits in ECS are as follows:
- A managed service for containerized applications that does not require much user input to run Docker applications
- Microservices consisting of multiple applications run in isolated containers
- Auto scales tasks based on application load
- Integrates with other AWS services including IAM, CloudWatch Logs, Elastic Load Balancing, CloudFormation templates, EBS Volumes, Batch, ECR, and CloudTrail logs
- A virtual private cloud (VPC) with no resources shared with other users
- Provides support for running a CodePipeline with ECS as the deployment platform
- Supports the latest Docker version 17.0
Fargate provides the following additional benefits:
- With a Fargate launch type, a user does not create or manage any EC2 instances, as none are exposed on the cluster.
- Tasks are directly exposed to the user via an ENI.
- The underlying infrastructure is provisioned by Fargate. EC2 instances are not to be managed with the Fargate launch type.
- CodePipeline supports Fargate as a deployment platform.
- Microservices based on Container definitions encapsulated in a task definition are explicitly linked, and are not to be linked with any additional options, such as links.
- CloudWatch Logs may be auto configured.
Amazon ECS objects with Fargate are the same as for the EC2 launch type. An ECS cluster is the outermost encapsulation, and it consists of one or more services. A cluster could be distributed over multiple availability zones. A service is an implementation of a task definition, and runs one or more tasks. A task definition could have one or more task revisions. A task revision is a distinct task definition with a set of tasks and a service associated with it. One Fargate instance is associated with a set of tasks in a service. A task definition consists of zero or more container definitions. Typically, a task definition would be associated with one or more container definitions, and a task definition that does not consist of any container definition would not run any task containers. A diagram of ECS objects is shown as follows:
Task definition is an application template and describes one or more containers. While some attributes or settings are configured at the task level, most of them are configured at the container level. Multiple revisions may be associated with a task definition.
Service implements a task definition, and defines a desired count for tasks to run for a task definition. Optional features such as auto scaling and load balancing are configured in the service.
Task size consists of
Task memory (GB) and
Task CPU (vCPU). While optional in the EC2 launch type, task size is required with the Fargate launch type. Docker container level memory and CPU settings may optionally be defined, but are overridden by task definition level settings. Only specific combinations of task memory and task CPU are supported, and the ECS wizard indicates with a message the supported value (or range of values) for a selected value. As an example, the valid CPU range for 1 GB memory is 0.25 vCPU to 0.5 vCPU. The total resources (memory or CPU) configured at the container level must not exceed the task level resource settings. As an example, if a task definition consists of two containers (MySQL and WordPress) with a memory limit of 128 MB for each container, the task level memory must be at least 256 MB. Also, the total of container level memory must not exceed 256 MB. Similarly for the CPU. Two memory limits may be defined at the container level:
Soft limit and
Hard limit. The Soft limit corresponds to the
memoryReservation attribute at the task level, and the Hard limit corresponds to the
memory attribute at the task level. The sum of container memory reservations (Soft limits) must not exceed the task memory. The Hard limit for each container must not exceed the memory configured at the task level. A minimum of 4 GB must be specified by default for a container.
An example task size is shown in the following screenshot, in which the
Task memory (
memory attribute) is set to
0.5 GB (512 GB), and the
Task CPU is set to
0.25 vCPU. At the container level, as configured in the two container definitions, the memory reservation is 128 MB for each container, which makes the total memory reservation of
256 MB well within the
512 GB allocated at the task level. The task size is allocated to a task, whether used or not. Similarly, the number of
CPU Units configured for each container is
10, which makes the total CPU units 20 for containers within the CPU units, 25 are allocated at the task level. Refer to the following screenshot:
Task size configuration and allocation for containers
- Networking mode,
awsvpc, is the only supported mode
- Host port mappings are not valid with the Fargate launch type networking mode (
awsvpc), and host ports on which an application is exposed are the same as the container ports
ecsTaskExecutionRoleis added for the Fargate launch type to allow for pulling Docker images and sending logs to CloudWatch Logs
- Only the
awslogslog configuration and
awslogslog driver are supported with CloudWatch Logs
- Task placement is not supported, as no ECS instances are provisioned to define placement constraints for
- Only Docker images on Docker Hub and Amazon ECR are supported
- Privileged Windows containers are not supported for the Fargate launch type
- Host devices cannot be exposed to a container
sourcePathparameters for volumes are not supported with the Fargate launch type
In this introductory chapter, we discussed the benefits of using the Fargate launch type, how compute resources are distributed and configured with the Fargate launch type, how the ECS objects with Fargate are the same as for the EC2 launch type, and the new features in Fargate. In the next chapter, we shall discuss networking as used with Fargate.