If you’ve been following along with our series so far then you should have a working ECS deployment with two Docker containers running a “Hello World” application in Tomcat. To review, you can look back at Post 1, Post 2, Post 3, and Post 4 to catch up.
Now that we’ve walked through the ECS wizard and created an environment, this article presents an overview of how ECS works and reviews what the wizard did for us.
As mentioned in previous articles, ECS is Amazon’s answer to managing Docker containers and it leverages different components of Amazon Web Services (AWS) to host those containers. Figure 1 shows a high-level overview of the ECS architecture.
Figure 1. ECS Architecture
Let’s review this diagram from bottom up. You may recall that while using the ECS wizard we defined things such as:
- The Docker image from which to run a Docker container
- The ports on the container to map to the Docker host machine
- The amount of memory to allocate to the container
- The amount of CPU to allot to the container
- Persistent volumes to mount on the container
ECS groups all of these together into an ECS Task Definition. An ECS Task Definition consists of a set of docker container definitions; in our example we only created one, but a task definition can contain multiple container definitions. Each container definition defines the Docker image to run, such as an image hosted on DockerHub, the CPU and memory to allocate to the container, and configuration information such as ports on the container to map to ports on the Docker host, environment variables, volume mount points, log configuration, and so forth. Essentially, the ECS task definition tells ECS how to launch your containers.
Traveling up the diagram we see the ECS Service. The ECS service is responsible for managing a set of running tasks, all of which are of the same task definition type. You specify the task definition that you want to run, the desired number of instances of that task that you want to run, and optionally an Elastic Load Balancer (ELB) that will sit in front of the EC2 instances that will host your containers, and then the service makes sure that the desired number of tasks are running.
The service is configured with the “ecsServiceRole” that the ECS wizard created for us. This role allows the service to register and deregister EC2 instances from/with the Elastic Load Balancer, execute “describe” functionality for EC2 instances to retrieve information about EC2 instances, and the ability to manage security rules for EC2 instances.
Essentially, the ECS service is the component that keeps your Docker containers up-and-running: it ensures that the correct number of containers (at the granularity of tasks) are running and that their health status is good and it communicates with the ECS agent on the EC2 instances to ensure that essential Docker containers are running. If it finds a problem with any of the containers then it kills and restarts them. Figure 2 shows a screenshot of the ECS Service dashboard.
Figure 2. ECS Service Dashboard
Finally, the ECS cluster manages all of your ECS services and ECS container instances. The term “ECS container instance” is a little difficult to understand in the documentation, so let’s see if I can simplify it a little better:
An ECS container instance is an EC2 instance running the ECS agent and has been registered with the ECS cluster. Or stated another way, this is an EC2 “virtual machine” running the ECS agent and registered with our cluster.
The ECS cluster provides access to:
- All running services
- All running tasks
- All running ECS container instances
Figure 3 shows a screenshot of the cluster’s services.
Figure 3. ECS Cluster Services
In figure 3 we can see that our cluster has one service: tomcat-service, that is an active state, that is running version 1 of the tomcat-task-definition, and that there are currently 2 running task instances of a desired 2. Recall that the task definition defines the Docker container(s) to run and the service is responsible for creating instances of and running those task definitions.
Figure 4 shows a screenshot of the cluster’s tasks.
Figure 4. ECS Cluster Tasks
In figure 4 we can see two task instances that are of type tomcat-task-definition version 1. Those task instances are running on two different ECS container instances (EC2 instances running the ECS agent). Figure 5 shows what we see if we drill into one of those task instances.
Figure 5. ECS Cluster Tasks
The task instance details provides links to the ECS Container Instance, EC2 instance, and task definition. It also shows the Docker containers that are running (just one in this case) with the name of the image upon which the container is based and its configuration (CPU, memory, port mapping, volume binding, and so forth).
Figure 6 shows a screenshot of the cluster’s ECS instances.
Figure 6. ECS Cluster’s ECS Instances
In figure 6 we see two ECS container instances and information about them. We see that they are both running tasks of type tomcat-task-definitions version 1 and we can see the specific EC2 instances upon which they are running. Furthermore we can see information about the ECS agent and Docker versions running on those EC2 instances.
Finally, figure 7 shows a screenshot of the cluster’s metrics.
Figure 7. ECS Cluster’s Metrics
The metrics tab provides us with a view of the performance of the ECS Container Instances running in our cluster. These graphs are part of Amazon’s CloudWatch, which is available on all of your EC2 instances. This view is an aggregation across all of the ECS container instances in your cluster.
This gives us a good logical view of the architecture, and next we will revisit the deployment and all of the components in play in our ECS environment.
Stay tuned for part 6!