Containers are the new way of running applications. Containers provide a logical packaging mechanism in which applications can be abstracted from the environment in which they run. This decoupling allows container based applications to be deployed easily no matter what the underlying environment is.
One important benefit of the containers is that application teams will focus on code development without needing the underlying infra details, while platform teams focus on deployment and management without needing the application details. But a container has its own challenges. One biggest challenge running these containers.it will be very hard for platform teams to manage and monitor these containers when they are many. This is where the container orchestrator tool comes into picture.
Understanding orchestrator
Container orchestration refers to the automated arrangement, coordination and management of software containers.
Container orchestration is used to automate the following tasks at scale:
1.Configuring and scheduling of containers2.Provisioning and deployments of containers
3.Availability of containers
4.The configuration of applications in terms of the containers that they run in
5.Scaling of containers to equally balance application workloads across infrastructure
6.Allocation of resources between containers
7.Load balancing, traffic routing and service discovery of containers
8.Health monitoring of containers
9.Securing the interactions between containers.
Amazon also provides a Container orchestrator called Ecs. In this article we will understand how Ecs works and we will understand how to configure that.
Introducing Ecs
A highly scalable, fast, container management service that makes it easy to run,stop and manage containers on a cluster.
Ecs runs our containers on a Cluster of Ec2 ( Elastic Compute Cloud ) instances. These Ec2 instances are created using Ecs Optimized Images that have a couple of Components pre-installed. These Ec2 instances created by Ecs optimized images come with Docker and Ecs agents preinstalled.
Ecs handles the installing of containers,scaling, monitoring and managing these instances through both an API and a management console. The specific instance a container runs on, and maintenance of all instances, is handled by the platform.
Here are the components of the Ecs cluster
Ecr ( Elastic Container registry )
Ecs Cluster
Ecs agent
Task Definition
Task
Docker
Launch Types
Now Lets understand the Ecs Cluster and its Components,
Ecr Registry - A separate article is written for understanding Ecr and how to push images to the Repository from our local machine. Check the link here.
Ecs Cluster - If we want to run our application in a container, we usually create the application in a Docker container and run it. If we are running the Container by its run command, we will be responsible for managing it. In Amazon an Ecs Cluster is a logical grouping of tasks ( Containers ). So An Ecs cluster will have a One of More Ec2 Instances where we can run our application Containers. The Ec2 Instance will be required to install with the Docker engine or any container engine for running our Containers.
Task Definition - Task Definition is a collection of 1 or more Container definitions and configurations. In Ecs, We need to define a configuration file where we need to tell what containers we are trying to run. We can define either 1 or more than one containers, How the containers are linked, Resource definitions like Memory and Cpu, ports to expose to the host machine, how to collect logs, environment variables and storage volumes that need to be attached to the containers etc.
Task - Once the Task definition is defined, we will use that to create a task. A Task is a Running instance of the Task Definition which in other means a task is nothing but a container. If we have 1 task defined in the Task definition, a task runs a single container and if we have more than 1 container defined in the task definition, the task runs more than 1 container. So the task is an instance of the Task definition which will run containers defined inside the task definition. No matter how many containers you define and run as a part of the task definition, we still call it a single task. The task will run until they are stopped or exit on their own.
Services - A Service is used to guarantee that you will always have the defined number of tasks running at all times. For example, let say I have defined a task definition ex: sample-test with 1 container definition. Next i will define a service ex: sample-test-service from that task definition saying that i will have 1 task running all time. This means now a task ( 1 or more containers defined in the task definition ) will run and Ecs service will make sure that task is running all time. For example if we stop the containers within that task manually, the Ecs service will start them again ( if it is 1 container or more than 1 as part of task definition).
There are 2 ways where we can run the Service either in Replica more or Daemon more. If we create the service in replica mode with task 1, then 1 task will run and if by chance the task dies, the Ecs service will take the responsibility of restarting the task for you. If you run the task in Daemon mode, a copy of that task will run in all members of the Ecs Cluster and Ecs service will take care of starting that container if it exists.
A Service is responsible for creating the tasks. These are mainly used with long running applications like web services etc. 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.
Another important point is that the service can be configured to use a load balancer so that it creates the containers defined in the Task definition and then the service will automatically register those containers Underlying Host ( Ec2 ) with the load balancer. Tasks cannot be configured to use a load balancer, only Services can.
Ecs Agent : The Amazon Ecs Agent is a software that Aws developed for its Amazon Ecs Container Service that allows Container Instances to connect to your Clusters. The Ecs Container agent runs on Each Ec2 Instance with an Ecs Cluster and sends telemetry data about the tasks and resources utilizations of that instance to the Amazon Ecs Service. It also has the ability to start and stop tasks based on the requests from Ecs.
The agent is included in the Amazon Ecs Optimised Ami by default. The agent can be installed in other operating systems also but there can be issues joining the cluster and sending data. The agent also interacts with the Amazon Api, as well as docker.
The components in the Ecs Service would like below,
In the next article we will see how we can create a cluster and create task definition, services and tasks.
No comments :
Post a Comment