ECS Fargate

bogotobogo.com site search:

Note

The basics of ECS Fargate available from Deploy Docker Containers and Getting Started with Amazon Elastic Container Service (Amazon ECS) using Fargate

In this post, we will see how to run a Docker-enabled sample application on an Amazon ECS cluster behind a load balancer, test the sample application, and delete the resources.

AWS Fargate allows us to run containers without having to manage clusters. With AWS Fargate, we no longer have to provision, configure, and scale clusters to run containers so that we can focus on designing and building our applications instead of managing the infrastructure that runs them. Actually, it's a serverless container orchestration platform.

We can think of AWS Fargate as Container-as-a-Service.

By default, ECS uses the bridge network mode. Fargate requires using the awsvpc network mode. The implication of using awsvpc network mode is that the tasks with Fargate can get the same VPC networking and security controls at the task level that were previously only available with EC2 instances when we use the bridge network mode.

Now with Fargate, each task gets its own elastic networking interface (eni) and IP address so that multiple applications or copies of a single application can run on the same port number without any conflicts.

When we use Docker locally, we use a command like this to run our app container:

docker run --rm -p 8080:80 myapp

where the -p instructs Docker to make port 80 on the container available as port 8080 on the host.

When using Fargate, however, we don't have any control over the host, so we only specify the ports that we want to make available in the portMappings section of our container definition. With Fargate, we set the containerPort to the port that the container listens to (e.g., 80 for our app). Fargate will ensure that we then can access this container on the same port on the ENI.

Note that via tasks we can run multiple containers listening to the same port, one container listening to the same port per task, however, we cannot run multiple containers in a task that listen to the same port!

As we can see later, here is the Fargate ECS dashboard that shows us the running ECS services and tasks without any EC2 instance:

Compared with EC2 launch type, Fargate launch type, all we have to do is package our application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application. The EC2 launch type, on the hand, allows us to have server-level, more granular control over the infrastructure that runs our container applications, which gives us a broader range of customization options compared with Fargate launch type.

ECS allows us to scale at the task level: we can configure rules to scale the number of tasks running. However, these are containers running on EC2 instances, which may not have available CPU or RAM resources. So in practice, we may have to define another Auto-scaling rule at the ECS cluster level, where we define scale up or down based on the CPU or RAM reservation on the cluster.

With Fargate, the auto-scaling much easier: we simply need to define it at the task level, and we are good to go.

AWS Fargate pricing is calculated based on the vCPU and memory resources used from the time we start to download our container image (docker pull) until the Amazon ECS Task terminates.

Though the cost per container in Fargate will be higher, the maintenance costs probably be lower than ECS considering the hours for troubleshooting and the effort we need to put for upgrading ECS instance agents and updating EC2 instance packages.

Amazon ECS console first run wizard

The Amazon ECS first run wizard will guide us through creating a cluster and launching a sample web application.

We can start it from the console:

ECR

We'll use Amazon Elastic Container Registry (Amazon ECR) to create an image repository and push an image to it as part of the first run wizard.

Let's create an Amazon ECR repository to store our nginx image. Note the repositoryUri in the output:

$ aws ecr create-repository --repository-name ecs-fargate-repo
{
    "repository": {
        "repositoryArn": "arn:aws:ecr:us-east-1:526262051452:repository/ecs-fargate-repo",
        "registryId": "526262051452",
        "repositoryName": "ecs-fargate-repo",
        "repositoryUri": "526262051452.dkr.ecr.us-east-1.amazonaws.com/ecs-fargate-repo",
        "createdAt": 1544741719.0
    }
}

We want to test Fargate with "nginx". So, let's pull it from DockerHub and store it locally:

$ docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
a5a6f2f73cd8: Already exists 
1ba02017c4b2: Pull complete 
33b176c904de: Pull complete 
Digest: sha256:5d32f60db294b5deb55d078cd4feb410ad88e6fe77500c87d3970eca97f54dba
Status: Downloaded newer image for nginx:latest

Then, tag the "nginx" image with the repositoryUri value from the previous step:

$ docker tag nginx 526262051452.dkr.ecr.us-east-1.amazonaws.com/ecs-fargate-repo

Run a docker login authentication command string from the output we get the "aws ecr get-login --no-include-email" command. The command provides an authorization token that is valid for 12 hours:

$ $(aws ecr get-login --no-include-email --region us-east-1)
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded

Now, we want to push the local "nginx" image to Amazon ECR with the repositoryUri value from the earlier step.

$ docker push 526262051452.dkr.ecr.us-east-1.amazonaws.com/ecs-fargate-repo
The push refers to repository [526262051452.dkr.ecr.us-east-1.amazonaws.com/ecs-fargate-repo]
ece4f9fdef59: Pushed 
ad5345cbb119: Pushed 
ef68f6734aa4: Pushed 
latest: digest: sha256:87e9b6904b4286b8d41bba4461c0b736835fcc218f7ecbe5544b53fdd467189f size: 948

Check if the image in the ecr repository:

$ aws ecr describe-images --repository-name ecs-fargate-repo
{
    "imageDetails": [
        {
            "registryId": "526262051452",
            "repositoryName": "ecs-fargate-repo",
            "imageDigest": "sha256:87e9b6904b4286b8d41bba4461c0b736835fcc218f7ecbe5544b53fdd467189f",
            "imageTags": [
                "latest"
            ],
            "imageSizeInBytes": 44697677,
            "imagePushedAt": 1544741846.0
        }
    ]
}

Or we can check it from console:

Container definitions

As mentioned earlier, we'll use Amazon Elastic Container Registry (Amazon ECR). So, we may want to click "Configure" to use custom container from ECR:

Regarding the host mapping, please see the next section ("Task definitions").

Task definitions

Here, we specify a task definition so Amazon ECS knows which Docker image to use for containers, how many containers to use in the task, and the resource allocation for each container.

Note that because we are using containers in a task with the awsvpc (same for host network mode), exposed ports was specified using containerPort. So, the hostPort is set the same value as the containerPort (AWS Documentation => Amazon Elastic Container Service => API Reference => Data Types => PortMapping)

This is inevitable because there is no host to manage. So, we only specify a containerPort value, not a hostPort value.

Click "Next.

Service definitions

Now that we have created a task definition, we will configure the Amazon ECS service. By running an application as a service, Amazon ECS will auto-recover any stopped tasks and maintain the number of copies we specify: it is meant to run indefinitely, so by running it as a service, it will restart if the task becomes unhealthy or unexpectedly stops.

We can access our container app without using LB via Public IP which we can get from the Task Details page under the network section. For example, though our current container port 80, if the container is running on port 5000, we can see the app using http://<PUBLIC_IP>:5000/:

However, in this post, we're going to use a load balancer for our service.

Note that for awsvpc mode, and therefore for Fargate, we use the IP target type instead of the instance target type.

The two security groups will be created to secure our service:

An Application Load Balancer security group that allows all traffic on the Application Load Balancer port
An ECS security group that allows all traffic ONLY from the Application Load Balancer security group.

Note also that ECS will create a Service IAM Role named ecsServiceRole if it has not been created.

Review the settings and select "Next"

Configure cluster

Our Amazon ECS tasks run on a cluster, which is the set of container instances running the Amazon ECS container agent.

Review before Launching

We have a final chance to review our task definition, task configuration, and cluster configurations before launching.

Select "Create", then we can see the launch status:

Open the nginx

Click on Target Group Name:

It leads us to the Load Balancer and DNS:

Copy the ELB DNS name and paste it into a browser:

Postmortem

The wizard set up Security groups for us.

Load balancer security group:

ECS security group:

The Two security groups were setup as the following:

An Application Load Balancer security group that allows all traffic on the Application Load Balancer port
An ECS security group that allows all traffic ONLY from the Application Load Balancer security group.

ALB setup with forwarded to the target group:

Clean up resources

When we are finished using a particular Amazon ECS cluster, we should clean up the resources associated with it to avoid incurring charges for resources that we are not using.

If our cluster contains any services, we should first scale down the desired count of tasks in these services to 0 so that Amazon ECS does not try to start new tasks on our container instances while we are cleaning up:

$ aws ecs update-service --cluster my-ECS-cluster --service my-nginx-service --desired-count 0 --region us-east-1

Before we can delete a cluster, we must delete the services inside that cluster. After our service has scaled down to 0 tasks, we can delete it:

$ aws ecs delete-service --cluster my-ECS-cluster --service my-nginx-service --region us-east-1

Before we can delete a cluster, we must deregister the container instances inside that cluster. But in the ECS with Fargate, we do not have any instance.

After we have removed the active resources from our Amazon ECS cluster, we can delete it:

$ aws ecs delete-cluster --cluster my-ECS-cluster --region us-east-1

$ aws ecs list-clusters
{
    "clusterArns": [
        "arn:aws:ecs:us-east-1:526262051452:cluster/default"
    ]
}

Our cluster has been deleted!

We may want to delete the LB we created as well.