Overview of AWS Elastic Container Service

This article contains the high level overview of AWS Elastic Container Service and its concepts.

What is Docker ?

• DOCKER packages software into standardised units called containers that have everything your software needs to run including libraries, system tools, code and runtime.
• It lets you quickly deploy and scale applications into any environment and know your code will run.

Explain Docker Image:

Point in time capture of code and dependencies

What is ECR:

You can use Amazon ECR registries to host your images in a highly available and scalable architecture, allowing you to deploy containers reliably for your applications. You can use your registry to manage image repositories and Docker images. Each AWS account is provided with a single (default) Amazon ECR registry.

• Fully managed docker container registry.
• Store, Manage and Deploy registry.
• Integrated with ECS
• Encrypted, Redundant, and Highly-Available
• Granular security permissions with AWS IAM.
  
  ECR Registry Concepts
• The URL for your default registry is https://aws_account_id.dkr.ecr.region.amazonaws.com.
• By default, you have read and write access to the repositories and images you create in your default registry.
• You must authenticate your Docker client to a registry so that you can use the docker push and docker pull commands to push and pull images to and from the repositories in that registry. For more information, see Registry Authentication.
• Repositories can be controlled with both IAM user access policies and repository policies.
• To authenticate Docker to an Amazon ECR registry, run below command
  # aws ecr get-login — no-include-email

ECS Cluster:

• Logical group of EC2 instances that you can place containers onto.
• Can utilise on-demand, spot, or reserved instances.
• Can include different EC2 instance types region-specific
• EC2 instances are linked in a virtual private cloud(VPC)
• One ECS cluster cannot be accessible from another region.
• “ecsInstanceRole” = This role is used by containers to communicate to other AWS services

ECS Agent:

The Amazon ECS container agent allows container instances to connect to your cluster. The Amazon ECS container agent is included in the Amazon ECS-optimized AMI, but you can also install it on any Amazon EC2 instance that supports the Amazon ECS specification. The Amazon ECS container agent is only supported on Amazon EC2 instances.

• Updating the Amazon ECS container agent does not interrupt running tasks or services on the container instance.
• Must be on every EC2 instance in your ECS cluster.
• Included with the ECS-OPTIMIZED amazon machine image(AMI)
• Agent updates do not apply to Windows container instances. We recommend that you launch new container instances to update the agent version in your Windows clusters.

To check if your Amazon ECS container agent is running the latest version with the introspection API

# curl -s 127.0.0.1:51678/v1/metadata | python -mjson.tool

ECS Task:

Deploys containers onto EC2 instances in your cluster.

(i.e.)

A Task is created when you run a Task directly, which launches container(s) (defined in the task definition) until they are stopped or exit on their own, at which point they are not replaced automatically. Running Tasks directly is ideal for short running jobs, perhaps as an example things that were accomplished via CRON.

ECS Task Definition:

Template for running one or more tasks.

(i.e.) Docker Run command is equivalent to Task Definition.

A Task Definition is a collection of 1 or more container configurations. Some Tasks may need only one container, while other Tasks may need 2 or more potentially linked containers running concurrently. The Task definition allows you to specify which Docker image to use, which ports to expose, how much CPU and memory to allot, how to collect logs, and define environment variables.

The task definition specifies,

• Docker image for each container
• CPU and Memory requirements for each container.
• Links between containers.
• Networking and Port settings.
• Data storage Volumes
• Security (IAM) roles

What is a Service ?

• A Service is used to guarantee that you always have some number of Tasks running at all times. If a Task’s container exits due to error, or the underlying EC2 instance fails and is replaced, the ECS Service will replace the failed Task. This is why we create Clusters so that the Service has plenty of resources in terms of CPU, Memory and Network ports to use. To us it doesn’t really matter which instance Tasks run on so long as they run. A Service configuration references a Task definition. A Service is responsible for creating Tasks.
• Services are typically used for long running applications like web servers. For example, if I deployed my website powered by Node.JS in Oregon (us-west-2) I would want say at least three Tasks running across the three Availability Zones (AZ) for the sake of High-Availability; if one fails I have another two and the failed one will be replaced (read that as self-healing!). Creating a Service is the way to do this. If I had 6 EC2 instances in my cluster, 2 per AZ, the Service will automatically balance Tasks across zones as best it can while also considering cpu, memory, and network resources.

Difference between Run-Task and Service ?

a) Service:

• Finds EC2 instances in cluster that meet requirements in the task definition.
• Defines how tasks are distributed onto EC2 instances in the cluster.
• Communicates with ECS-Agent and docker daemon to run containers on eligible EC2 instances in the cluster.
• Can be executed via the ECS console, CLI or APIS.

b) Run-Task:

• Manage long-running workloads.
• Automate the RUN-TASK process
• Actively monitoring running tasks
• Restart tasks if they fail.

Task Placement Strategy:

A task placement strategy is an algorithm for selecting instances for task placement or tasks for termination. Task placement strategies can be specified when either running a task or creating a new service.

Strategies Include:

1. AZ Balanced Spread — This template will spread tasks across availability zones and within the availability zone spread tasks across instances.
2. AZ Balanced BinPack — This template will spread tasks across availability zones and within the availability zone pack tasks on least number of instances by memory.
3. BinPack — This template will pack tasks least number of instances by memory.
4. One Task Per Host — This template will place only one task per instance.
5. Custom

When Amazon ECS places tasks, it uses the following process to select container instances:

1. Identify the instances that satisfy the CPU, memory, and port requirements in the task definition.
2. Identify the instances that satisfy the task placement constraints.
3. Identify the instances that satisfy the task placement strategies.
4. Select the instances for task placement.

Task Groups

• You can identify a set of related tasks as a task group. All tasks with the same task group name are considered as a set when performing spread placement. For example, suppose that you are running different applications in one cluster, such as databases and web servers. To ensure that your databases are balanced across Availability Zones, add them to a task group named “databases” and then use this task group as a constraint for task placement.
• When you launch a task using the RunTask or StartTask action, you can specify the name of the task group for the task. If you don’t specify a task group for the task, the default name is the family name of the task definition (for example, family:my-task-definition).
• For tasks launched by the service scheduler, the task group name is the name of the service (for example, service:my-service-name).

Limits

• A task group name must be 255 characters or less.
• Each task can be in exactly one group.
• After launching a task, you cannot modify its task group.

Example Constraints

The following are task placement constraint examples.

This example uses the memberOf constraint to place tasks on T2 instances. It can be specified with the following actions: CreateService, RegisterTaskDefinition, and RunTask.

“placementConstraints”: [

{

“expression”: “attribute:ecs.instance-type =~ t2.*”,

“type”: “memberOf”

}

]

The example uses the memberOf constraint to place tasks on instances in the databases task group. It can be specified with the following actions: CreateService,RegisterTaskDefinition, and RunTask.

“placementConstraints”: [

{

“expression”: “task:group == databases”,

“type”: “memberOf”

}

]

The distinctInstance constraint places each task in the group on a different instance. It can be specified with the following actions: CreateService and RunTask

“placementConstraints”: [

{

“type”: “distinctInstance”

}

]

Service Updates:

• Automatically starts new tasks and stops old tasks.
• Keeps the service running during deployment.
• Health check ensure new tasks are stable before old stacks are stopped.
• Use the console, cli or APIS

What is Task Role:

With IAM roles for Amazon ECS tasks, you can specify an IAM role that can be used by the containers in a task.

What is Task Execution IAM role:

• This role is required by Fargate tasks to pull container images and publish container logs to Amazon CloudWatch on your behalf.
• The role that authorizes Amazon ECS to pull private images and publish logs for your task. This takes the place of the EC2 Instance role when running Fargate tasks.

Difference between Container Instance IAM Role,Task Role and Task Execution IAM Role ?

Container instance IAM role

• The Amazon ECS container agent makes calls to the Amazon ECS API on your behalf. So if you give full access to Container instance by using “ecsInstancerole” role, then your containers will also have full access to AWS resources.
• This role only applies if you are using the EC2 launch type. Because in Fargate we do not manage EC2 instances.

Task role

• With IAM roles for Amazon ECS tasks, you can specify an IAM role that can be used by the containers in a task.
• This role allows you to associate permissions with individual Tasks rather than the underlying EC2 instance that is hosting those Tasks.
• Give minimal permissions by using “ecsInstancerole” and Use “Task role” in task definition with necessary permissions.

Task Execution IAM role

• This role is required by Fargate tasks to pull container images and publish container logs to Amazon CloudWatch on your behalf. (ecsTaskExecutionRole)
• The role that authorizes Amazon ECS to pull private images and publish logs for your task. This takes the place of the EC2 Instance role when running Fargate tasks.

What is Task size ?

The task size allows you to specify a fixed size for your task. Task size is required for tasks using the Fargate launch type and is optional for the EC2 launch type. Container level memory settings are optional when task size is set. Task size is not supported for Windows containers.

Task Placement Constraints:

• When you register a task definition, you can provide task placement constraints that customize how Amazon ECS places tasks.
• If you are using the Fargate launch type, task placement constraints are not supported. By default Fargate tasks are spread across availability zones.
• For tasks that use the EC2 launch type, you can use constraints to place tasks based on Availability Zone, instance type, or custom attributes.

What is Memory Limits ?

• If you specify a hard limit (memory), your container will be killed if it attempts to exceed that limit. If you specify a soft limit (memoryReservation), ECS reserves that amount of memory for your container; however, the container can request up to the hard limit (if specified) or all of the available memory on the container instance, whichever is reached first. If you specify both, the hard limit must be greater than the soft limit.
• When the Amazon ECS container agent registers a container instance into a cluster, the agent must determine how much memory the container instance has available to reserve for your tasks. Because of platform memory overhead and memory occupied by the system kernel, this number is different than the installed memory amount that is advertised for Amazon EC2 instances. For example, an m4.large instance has 8 GiB of installed memory. However, this does not always translate to exactly 8192 MiB of memory available for tasks when the container instance registers.
• If you specify 8192 MiB for the task, and none of your container instances have 8192 MiB or greater of memory available to satisfy this requirement, then the task cannot be placed in your cluster.
• You should also reserve some memory for the Amazon ECS container agent and other critical system processes on your container instances, so that your task’s containers do not contend for the same memory and possibly trigger a system failure. For more information, see Reserving System Memory.
• The Amazon ECS container agent uses the Docker ReadMemInfo() function to query the total memory available to the operating system. Both Linux and Windows provide command line utilities to determine the total memory.

Add Volumes to Container Instances ?

When you register a task definition, you can optionally specify a list of volumes to be passed to the Docker daemon on a container instance, which then become available for access by other containers on the same container instance.

The following are the types of data volumes that can be used:

• Docker volumes — A Docker-managed volume that is created under/var/lib/docker/volumes on the container instance. Docker volume drivers (also referred to as plugins) are used to integrate the volumes with external storage systems, such as Amazon EBS. The built-in local volume driver or a third-party volume driver can be used. Docker volumes are only supported when using the EC2 launch type. Windows containers only support the use of the local driver. To use Docker volumes, specify aDockerVolumeConfiguration in your task definition. For more information, see Using volumes.
• Bind mounts — A file or directory on the host machine is mounted into a container. Bind mount host volumes are supported when using either the EC2 or Fargate launch types. To use bind mount host volumes, specify a host and optional sourcePath value in your task definition. For more information, see Using bind mounts.

Conclusion:

• Automate the deployment of docker applications.
• Easily manage cluster of any scale.
• Fully managed service, No software to install, maintain or update.
• Native integrations with other AWS services
• Highly Secure