A brief info describing EC2 Launch Type Feature of ECS Service including info on the backend-processes it executes and certain requirements that need to be fulfilled in order for the Service to run Clusters of Containerized Applications…
There are 2 launch types which are 2 different ways of running your Containerized applications on a cluster in ECS
Under this method, you will need to satisfy each and every requirement of the service, for it to run your containerized applications. This Launch Type is recommended more for development/testing purposes so that you get familiar with the processes that run in the background for your application to run in clusters.
Due to the manual work that needs to be done by the user, AWS does not charge anything except for the AWS resources that are used in a cluster like EC2 Instances and attached EBS Volumes.
The difference is all about how the application uses underlying hardware like RAM and CPUs efficiently. Containerization reduces waste of underlying hardware because each container only holds the application and related binaries or libraries. Containerization is a lightweight alternative to full machine virtualization that involves encapsulating an application in a container with its own operating environment. By allowing more containers in the environment without the need for more servers, containe]rization increases scalability anywhere from 10 to 100 times that of traditional VM environments.
Here, we are going to understand the process or steps that need to be taken to deploy/run clusters under the EC2 launch type method.
The below given diagram shows the general architecture which includes all the steps/sub-processes that take place for the clusters to be created/run.
PREREQUISITES
List of components in a sequential order that are required or need to be configured.
Dockerfile
The first thing required is a Dockerfile; which acts as a standardized unit of software development.
It is a plain text file that contains everything that the software application needs to run:
code
runtime
system tools
system libraries, etc.
From this Dockerfile; Images are built which are read-only templates.
Images are then stored in a registry from which they can be downloaded and run on your container instances.
Task Definitions
Task Definition is a description of an application that contains one or more docker Containers.
Task Definition is needed to prepare application to run on ECS.
Task Definition has a maximum limit of 10 containers.
It is a text file, in JSON format, that specifies various parameters that form your application
Task family the name of the task.
IAM task role specifies the permissions that containers in the task should have.
Network mode determines how the networking is configured for your containers.
Container definitions specifies which image to use, how much CPU and memory the container are allocated, and many more options.
Volumes allow you to share data between containers and even persist the data on the container instance when the containers are no longer running.
Task placement constraints lets you customize how your tasks are placed within the infrastructure.
Launch Types determines which infrastructure your tasks use.
Tasks
It is the instantiation of a task definition within a cluster.
After you have created a task definition for your application, you can specify the number of tasks that will run on your cluster.
Task Scheduler
It is responsible for placing tasks within your cluster.
There are different scheduling options available
REPLICA Places and maintains the desired number of tasks across your cluster. By default, the service scheduler spreads tasks across Availability Zones. You can use task placement strategies and constraints to customize task placement decisions.
DAEMON Deploys exactly one task on each active container instance that meets all of the task placement constraints that you specify in your cluster. When using this strategy, there is no need to specify a desired number of tasks, a task placement strategy, or use Service Auto Scaling policies.
You can also upload a new version of your application task definition, and the ECS scheduler automatically starts new containers using the updated image and stop containers running the previous version.
Containers
Containers are created from the image which is a read-only template stored in the container registry.
Images are created from the dockerfile and are stored in a container registry from which they can be downloaded to run on your container instances.
ECS can also be configured to access a private docker image registry within a VPC as well as can be configured to access Docker Hub.
Clusters
When you run tasks using ECS, you place them in a Cluster, which is a logical grouping of resources. Typically, they are a bunch of Containers.
Clusters are Region-specific.
Clusters can contain tasks using both the Fargate and EC2 launch types.
When using the Fargate launch type with tasks within your cluster, ECS manages your cluster resources.
When using the EC2 launch type, then your clusters are a group of container instances that you manage.
These clusters can contain multiple different container instance types, but each container instance may only be part of one cluster at a time.
Before you can delete a cluster, you must delete the services and deregister the container instances inside that cluster.
Container Agent
Container Agent runs on each instance existing inside an ECS Cluster.
It sends information about the resource’s current running tasks and resource utilization to ECS, and starts and stops tasks whenever it receives a request from ECS.
So, these are the steps or sub-processes that run and complete in the backend for the cluster to work, function and deliver the output that you require from your application.
Other Services
ECS also allows you to run and maintain a specified number of instances of a task definition simultaneously in a Cluster.
In addition to maintaining the desired count of tasks in your service, you can optionally run your service behind a load balacer.
There are 2 deployment strategies in ECS
Rolling Update
This involves the service scheduler replacing the current running version of the Container with the latest version.
The number of tasks ECS adds or removes from the service during a rolling update is controlled by the deployment configuration, which consists of the minimum and maximum number of tasks allowed during a service Deployment.
Blue/Green Deployment with AWS CodeDeploy
This deployment type allows you to verify a new deployment of a service before sending production traffic to it.
The service must be configured to use either an Application Load balancer or Network Load Balancer.
Monitoring
You can also configure your container instances to send log information to AWS cloudWatch. These logs will enable you to view different logs from all your instances in one convenient location.
In the end, launching your containers using EC2 launch type under ECS service will fulfill your requirements by deploying the containers in clusters and you can also use FARGATE service in ECS, if you want majority of the above steps to be automated.
As a Director of Eternal Web Private Ltd an AWS consulting partner company, Nirav is responsible for its operations. AWS, cloud-computing and digital transformation are some of his favorite topics to talk about. His key focus is to help enterprises adopt technology, to solve their business problem with the right cloud solutions.
Let Us Talk About Your AWS Development Requirements
Have queries about your AWS project ideas and concepts? Please drop in your project details to discuss with our AWS experts, professionals and consultants.
