CODEWITHSUNDEEP
dockeramazon-ecsaws-fargate
David Herron
David Herron

Reputation: 988

Cannot reach container in ECS Fargate cluster that looks properly configured

I have an ECS Fargate cluster that I configured after reading instructions in another StackOverFlow post. I have several containers that I've pushed into ECR repositories and can successfully launch the containers. But going to http://PUBLIC-IP-ADDRESS does not access the service exposed by the container.

In my most recent test I simply used the httpd container from Docker Hub because it is simple and provides a default web page. Still no luck.

The VPC has two subnets - public and private - and was constructed per the instructions in the above-linked post. I am attaching the containers -- as an ECS Service -- to the public subnet and also configuring the Service to make it a public IP address.

Public subnet (CIDR 10.0.1.0/24) has this route table:

10.0.0.0/16 local
0.0.0.0/0 igw-0ad0671cc2924857e

Network ACL inbound rules

100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
  * ALL Traffic ALL ALL 0.0.0.0/0 DENY

Network ACL outbound rules

100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW
  * ALL Traffic ALL ALL 0.0.0.0/0 DENY

(These are the default rules)

The private subnet (CIDR 10.0.2.0/24) has the same configuration but the route table instead connects to a NAT gateway. The NAT gateway is homed on the public net.

The only thing I did differently from the VPC configuration instructions is the security group. When creating the services, I configure the service with the default security group that came with the VPC. This security group allows all traffic both inbound and outbound.

For the Task Definition - I created an httpd T.D. using the awsvpc network mode (it's a Fargate ECS), 1/2 GB memory, 0.25 vCPU, exposing port 80 on the container,

For the Service, I attached it to the VPC, gave it the name httpd, attached it to the public subnet, and said to use a public IP address.

The Service and the contained Task launch correctly, and the Task shows a public IP address. Accessing that IP address results in a long wait and eventually the web browser gives up. (times out)

UPDATE --

I was not aware of the need to have a load balancer. I have attempted to add a load balancer. But it made no difference.

To add the load balancer required adding more public subnets configured as above. The Application Load Balancer is attached to the VPC and to the public subnets. It is listening to HTTP (port 80).

I then re-created the service for the httpd container. During creation of the service, I did my best to configure it for the load balancer and then the service description gives this summary:

Target Group Name   Container Name  Container Port
ecs-ecs-go-httpd             httpd              80

Upvotes: 3

Views: 4587

Answers (1)

Chart96
Chart96

Reputation: 480

An ELB shouldn't be needed if you are trying to hit a specific container. Run a TCP test against port 80 and see what the response is.

Powershell: Test-NetConnection <IP address> -port 80

Bash: nc -z <IP address> <80>

If you cannot connect over 80 then move back through the pieces:

  • Open up the task
    • Click on the link to the ENI
    • Double check the security group has 80 open
  • Open up the task definition
    • Open up the container definition
    • Ensure that the host port and container port are both 80

If it is not an issue with either the security group or the task definition that leaves only the VPC configuration and the container image.

  • Test the container image by launching it locally and hitting it on localhost:80
  • Test the VPC configuration by launching another EC2 instance in the same subnet as your container with the same security group
    • SSH in

If you can SSH in then the issue is most likely not a routing issue. If you cannot SSH in double check the route table, the VPC ACL, and the subnet ACL.

From the new EC2 instance

  • Ensure 80 is wide open and try to hit your container with it's local IP
  • Install a web server
  • Try to hit this from outside on port 80

If you can hit 80 on your EC2 instance with the same security group in the same subnet then you have eliminated any possible issues with networking and can focus on what might be wrong with the ECS configuration.

Lastly, don't forget to lock your security group and ACLs back down if you opened anything up wider.

Upvotes: 6

Related Questions