Up and Running with AWS Elastic Container Service (ECS) - Part 1

This post assumes at least a familiarity with building and running containers using Docker

What is ECS

Containerization is a computing model that allows you to package your application and it's dependencies into a runnable Image. This image can be put on any environment that has what is called a Container Runtime. Simply put, Container Runtimes allow you to run your containerized applications.

Docker has become the defacto CR in the industry, and with it, you can package your application into an image, and run it as a container(s).

On the Amazon Cloud (AWS), the Elastic Container Service (ECS) provides a runtime for your Image. You can deploy, manage and scale containerized applications on AWS using ECS.

Basics of ECS ?

Under the hood, the infrastructure where your ECS container runs can be any of the following:

• EC2 Instances
• Serverless (AWS Fargate)
• On-premises virtual machines (VM) or servers This infrastructure is otherwise known as Capacity

Once you have built a (Docker) Image, and stored it in an Image registry such as AWS Elastic Container Registry (ECR) or DockerHub, you can use ECS.

First, ECS needs to know what image you want to run, the operating system of the underlying infrastructure (remember Capacity?), which ports to open for your application and what volumes to use. You must define this so that ECS knows the task that it must do. AWS calls this a Task Definition.

A Task Definition can be created directly from the AWS Console, but in reality, it is a text file in JSON format containing the parameters mentioned above. With this task definition in place, ECS can now execute the "task".

Thus, we can say that a Task is a Task Definition that has been executed, or better put, it is an instance of a Task Definition.

If you're familiar with (Docker) containers, you will know that they are (ought to be) ephemeral. Ephemeral here implies that the container can be stopped and destroyed for whatever reason. If this happens, then the Task that you created will be destroyed, and you have to recreate it manually. In order to automate the creation of tasks, we can use something called a "Service".

An ECS Service can automatically restart your Task, for instance, if a health check fails. It can also be used to run and maintain your desired number of Tasks simultaneously (or call this scaling your application) based on your Task Definition.

All of this comes together under a Cluster. A cluster is a logical grouping of Tasks or Services that runs on the Capacity infrastructure that is registered to that cluster.

Lastly, in each container instance found on ECS, there is a Container Agent that sends information about the current running tasks and resource utilization of your containers to Amazon ECS. This agent is responsible for starting and stoping tasks whenever it receives a request from Amazon ECS.

Summary

1. Capacity: The underlying infrastructure for ECS e.g., EC2 servers or Serverless (fargate).

2. Task Definition: container information about a task such as the image to run.

3. Task: A running instance of the task definition.

4. Service: A collection of tasks, that automates things like restarting a container task.

5. Cluster: Everything is in a cluster, this is a logical grouping of tasks and serivices. For example, you can have a cluster for a Banking app, and another for the HR app.

6. Container Agent: Responsible for starting and stopping container tasks, and sending resource utilization to ECS