ecs on Alperen Doc

vpc-and-networking-setup-for-ecs

Mon, 01 Jan 0001 00:00:00 +0000

VPC and Networking Setup#

As we dive into ECS (Elastic Container Service), I want to re-emphasize that having your networking set up correctly is critical. Luckily, we’ve already done it! Just know that it will be important that it’s all still set up.

For ECS to work properly, we need:

A VPC with CIDR 10.0.0.0/22 (our patientping VPC)
Two public subnets (patientping-public-a and patientping-public-b)
An Internet Gateway attached to the VPC (patientping-igw)
A route table that sends 0.0.0.0/0 to the Internet Gateway, associated with both public subnets (patientping-public-rt)

We’ll run our Fargate tasks and the load balancer in these public subnets. Tasks get outbound internet access (for example, to pull images from ECR) through the Internet Gateway, so we don’t need a NAT Gateway for this course. (In production, you’d often use private subnets and a NAT Gateway or VPC endpoints for stronger isolation.)

why-ecs

Mon, 01 Jan 0001 00:00:00 +0000

Why ECS?#

Containers are a big part of how software is typically built and deployed today.

If you’ve never used them before, you should take our course on Docker before proceeding! You’ll also need docker installed locally to complete this chapter.

If you’re running just a container or two on a single machine, docker is a great way to get up running, but When your needs grow beyond a single machine, Kubernetes, a powerful container orchestration platform, tends to be the go-to solution.

elastic-container-registry

Mon, 01 Jan 0001 00:00:00 +0000

Elastic Container Registry#

Before we can deploy any containers, we need somewhere to store their images. Those images need to be available all the time because containers are regularly replaced and may need to pull a fresh copy of the software.

AWS provides the Elastic Container Registry (ECR) as a managed registry service. It’s like Docker Hub, but integrated directly with AWS services.

ECR helps with straightforward things like storing images in the right region, and more advanced things like controlling access with IAM.

ecr-repo

Mon, 01 Jan 0001 00:00:00 +0000

ECR Repo#

Now that we have a Docker image, let’s host it on ECR!

Assignment#

Create an ECR repository patientping-ecs, and push the image.

Cost check: ECR storage costs about $0.10 per GB per month. For a small image like ours, which we’ll keep on ECR only long enough for learning/testing, this is essentially free. Data transfer costs also apply when pulling images, but again, for learning purposes it’s minimal.

ecs-clusters

Mon, 01 Jan 0001 00:00:00 +0000

ECS Clusters#

We’ve got our image, now it’s time to run it.

Enter the ECS Cluster. Think of it as a logical grouping of compute resources where containers can run. It doesn’t cost anything by itself, but it provides the foundation for running ECS tasks.

A cluster can hold a number of capacity providers, which provide resources to our cluster on an as-needed basis. It’s like the ECS version of EC2 Auto Scaling Groups.

ecs-permissions

Mon, 01 Jan 0001 00:00:00 +0000

ECS Permissions#

We’ve dealt with IAM roles with EC2, but they also apply to ECS. We have two problems to solve:

We need to give ECS access to specific containers to pull them in and start them up.
After the container boots up, it needs to have its own set of permissions. In our case, we’ll give it permissions to read SSM parameters.

Two different permission sets, and AWS handles them with:

ecs-task-definitions

Mon, 01 Jan 0001 00:00:00 +0000

ECS Task Definitions#

With our container image in ECR and our Fargate-ready ECS Cluster set up, we need to tell ECS exactly how to run our container. What ports should it expose? How much memory does it need? What permissions should it have?

We answer all these questions with a Task Definition. It’s a JSON file that describes everything ECS needs to know about running our container, for example:

{
 "family": "patientping-ecs",
 "cpu": "256",
 "memory": "512",
 "networkMode": "awsvpc",
 "executionRoleArn": "arn:aws:iam::<MY_ACCOUNT_ID>:role/patientping-ecs-execution-role",
 "taskRoleArn": "arn:aws:iam::<MY_ACCOUNT_ID>:role/patientping-ecs-task-role",
 "runtimePlatform": { "operatingSystemFamily": "LINUX" },
 "requiresCompatibilities": ["FARGATE"],
 "volumes": [],
 "containerDefinitions": [
 {
 "name": "patientping-ecs",
 "image": "<MY_ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/patientping-ecs",
 "portMappings": [
 {
 "containerPort": 8000,
 "hostPort": 8000
 }
 ],
 "essential": true,
 "logConfiguration": {
 "logDriver": "awslogs",
 "options": {
 "awslogs-group": "/ecs/patientping-ecs",
 "awslogs-region": "us-east-1",
 "awslogs-stream-prefix": "ecs"
 }
 }
 }
 ]
}

Property	Description
`.family`	The name of the task definition
`.cpu`	The amount of CPU to allocate to the task, in units of roughly 1/1024th of a core
`.memory`	The amount of memory to allocate to the task, in MB
`.networkMode`	The network mode to use for the task; `awsvpc` assigns an IP address directly within the VPC.
`.executionRoleArn`	This is an IAM role that’s used while the task is booting up.
`.runtimePlatform`	The operating system family to use for the task
`.requiresCompatibilities`	The compute resources that the task can use
`.volumes`	Optional volume configuration for the task.
`containerDefinitions.name`	The name of the container
`containerDefinitions.image`	The container image to run
`containerDefinitions.portMappings`	The ports to expose from the container
`containerDefinitions.essential`	If `true`, the task will try to recover if this container exits
`containerDefinitions.logConfiguration`	The logging configuration for the container (more details on this later)

Example#

The cluster is ready, but ECS doesn’t know what to run or how. The task definition is the recipe: which image, how much CPU and memory, which IAM roles, where to send logs. Our app reads /CMO_NAME from SSM at runtime and returns it in the response when available.

ecs-security-groups

Mon, 01 Jan 0001 00:00:00 +0000

ECS Security Groups#

Now we need Security Groups to control who can reach our ECS tasks. We’ll place our tasks in public subnets; only the load balancer should be able reach them. Security groups let us define exactly which traffic is allowed. We’ll need two of them:

One for the ECS tasks. This will be an internal security group that allows traffic from an Application Load Balancer (ALB) to our ECS tasks. A powerful feature of security groups is that they can reference other security groups instead of IP addresses, so we can allow traffic from the load balancer without hardcoding IPs.
One for the Load Balancer. This will be an external security group that allows internet traffic to the load balancer.

Security groups referencing other security groups is one of those AWS features that seems obvious once you see it, but it’s easy to miss. It’s way better than managing IP addresses manually, especially when things change.

application-load-balancer

Mon, 01 Jan 0001 00:00:00 +0000

Application Load Balancer#

I know that it looks like we’re working on anything but ECS and containers at the moment, but I promise we’re getting closer. We just have to shave a few more yaks.

Now it’s time to start listening for traffic. To do that, we’ll set up a Load Balancer and a Listener.

A load balancer sits in front of our service and distributes incoming traffic across your task(s). It handles things like health checks, SSL termination, and routing traffic to healthy containers. We’ll place the load balancer in public subnets so it can receive traffic from the internet.

ecs-target-groups

Mon, 01 Jan 0001 00:00:00 +0000

Target Groups#

Now it’s time to configure the load balancer to actually route traffic to our ECS tasks (instead of just returning its own fixed response). This is where Target Groups come in.

A target group tells the load balancer where to send traffic. It defines:

Protocol and port: What protocol (HTTP/HTTPS) and which port your tasks are listening on
Health checks: How the load balancer determines if a target is healthy
Target type: Whether targets are IP addresses (for Fargate) or instance IDs (for EC2)

For ECS with Fargate, we’ll use the ip target type because each task gets its own IP address. The load balancer will route traffic directly to the task’s IP address.

cloudwatch-log-groups

Mon, 01 Jan 0001 00:00:00 +0000

CloudWatch Log Groups#

Now, how will we know if something goes wrong with our containers at runtime? We need to set up CloudWatch Log Groups so we can see what’s happening inside our containers (stdout, stderr, application logs, etc.).

Think of CloudWatch log groups and log streams as folders for your logs. Each group can have multiple streams (one per container instance), so you can see all logs for a service in one place.

ecs-services

Mon, 01 Jan 0001 00:00:00 +0000

ECS Services#

Finally! Time to build the ECS Service that ties everything together, and answers these questions:

Where do we place our tasks?
How do we scale them?
How do we connect to the load balancer?

Once we create an ECS service with load balancer settings, ECS automatically registers tasks with the target group as they start.

Assignment#

Create an ECS service patientping-svc that runs your task definition and connects it to the load balancer (cluster patientping-ecs, ALB patientping-alb, target group patientping-tg).