- Newest
- Most votes
- Most comments
The amazing dudes from the aws support helped me and after 6h it was solved with one single line in my .env file. My .env defines the HOST and PORT, which were localhost"and 80 respectively. The Dockerfile exposed the PORT and the applications health check was working from inside the container but not from the outside. This meant the ALB couldn't reach the target.
Therefore the solution was to set the HOST to 0.0.0.0 in the .env! This exposed it to the outside.
Hello,
as Hernan suggested, check out the Cloudformation Set in the AWS Console if you see any error.
Healthchecks on Port 80 are not a problem from loadbalancer.
Pretty sure the cdk(cloudformation) deployment fails because of the failing healthcheck.
Check out the target group in aws ec2 console if the ecs-tasks are registered correctly. But since you wrote that you are able to get a 200 successfully when connecting from the internet over the alb to the service, maybe the reason could also be that the default values for the target groups health check settings are to low, see following document:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html
Sincerely heiko
in the AWS console, go to cloudformation service and check the events of the stack that you are deploying. there you may find the error.
Unfortunately not. Since it timeouts after 3h I only get "The following resource(s) failed to create: [RelayerServiceMService30B8E9A6]. Rollback requested by user."
Relevant content
- asked 4 months ago
- asked 2 years ago
- asked 9 months ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 10 months ago
- AWS OFFICIALUpdated 8 months ago
Hi Heiko, the Cloudformation output does not show anything informational. I have now exposed port 8080 from my docker container and map it to port 80 from my host, but it doesnt work. Container is healthy. And I have a public loadbalancer and listener but now I get a 502 Bad Gateway when I open the DNS endpoint
Hey @Marvin, 502 could be because of bad port mapping or the instance was replaced/down during testing.
what I would check during deployment via cdk: Check out the ecs-service/tasks & the alb-target group. Check if the ips are correctly registered. Check the healthcheck-settings there, as I said maybe the healthchecks default values for the targetgroup were to low by default for your usecase. Check the security group of the ecs service/task. deploy an ec2 for testing purposes in the same network, connect to it and try to reach the ecs task on the health-path and see if it works. If it doesn't work, either your port mapping does not work or your container has a problem with the healthpath. If it works, probably your target group healtchecksettings have to be updated.
Thanks again for the help Heiko. The idea to deploy an ec2 for testing was very valuable to narrow it down on the ECS because we could rule out the ALB as cause of the problem.