I have a few Elastic Beanstalk environments. It took a while for me to get the first working, and then I replicated my settings to create the others. However, I am unable to get past a 502 error that the load balancer target health check gives, and it's the same if I try to load the app.
I checked the instance and load balancer security groups, and the settings match between the working and non-working environments (with the exception that the instance inbound source comes from the respective load balancer security group). The VPC settings are all the same. Among the non-working environments, I have apps in both availability zones 1a and 1b. The working environment is in 1a.
The Elastic Beanstalk app versions are the same. Elastic Beanstalk creates a load balancer per environment, so each environment has a different load balancer (I chose application load balancer).
I can SSH into the EC2 instances for both working and non-working environments.
Curling my working environment health check URL succeeds: curl -i -k https://xx.xx.xx.xxx/health
Curling my non-working environment health check URL fails: curl -i -k https://xx.xx.xx.xxx/health with a response that says "curl: (7) Failed to connect to xx.xx.xx.xxx port 443: Connection refused."
I double-checked the HTTPS settings for the EC2 and load balancer security groups, and they both have the appropriate inbound/outbound settings (as mentioned, the working and nonworking environments match). The environments both have a single load balancer listener for port 443 with a self-signed certificate using security policy ELBSecurityPolicy-2016-08, and the target group looks on port 443 for the port and health check.
I looked at the Elastic Beanstalk logs and didn't see anything noteworthy.
From the nginx elastic beanstalk logs I see: xx.xx.xx.xx - - [19/Feb/2020:13:23:01 +0000] "GET / HTTP/1.1" 200 1410 "-" "ELB-HealthChecker/2.0"
In the eb-docker logs for the working app, I also see:
2/13/2020, 9:22:13 PM - �[32minfo�[39m: req - /health
�[0mGET /health �[32m200 �[0m14.449 ms - 56�[0m
(the req - /health being a log in the app for when the path doesn't match the specified app paths, in case of a 404).
I don't see this for the non-working environment.
I'm not sure what else to check or how to resolve this.
Related
I am trying to deploy a PHP through AWS CodeDeploy and am currently stuck on the AllowTraffic step in CodeDeploy. The application is on an EC2 instance behind an ALB. In the ALB, I am getting failing health checks. I have the PHP application code sitting in the following directory on the EC2 instance: /var/www/html/src. If I were to curl the private IP of the EC2 following by the directory where the code sits, I am getting an error 404 Not Found. Even though the index.php file is in that directory, I am unable to curl it. Currently I have security groups setup where the ALB security group allows any traffic from only HTTP, and all traffic from the ALB security group is allowed to reach the EC2 instance. I am able to curl the root of the instance and see Apache's default page.
If I were to adjust the health check settings on the ALB Target group, I get a 403 error when setting the health check to /. I get a 404 error when specifying the path to the directory that has the PHP application code.
Any advice on how I can get the instance to a healthy state for the ALB would be appreciated.
TG Health Check
Application Load balancer security group allows traffic on port 80
EC2 instance security group allows traffic from Application Load Balancer security group.
The PHP application should be accessible on port 80, where Apache is running. The Application Load Balancer has only 1 listener that is set up for port 80, that forwards traffic to the target group.
The heath check path in your TG should be URL path, not the actual location on the EB instance. You can try with just /index.php:
/index.php
This assumes that your application is actually working and the only issue are health checks.
I have created an Ubuntu EC2 instance, and created a load balancer to point to that EC2 instance. The rules on the Listener for the load balancer look OK (ports 80 and 443). I can access the EC2 instance Apache2 HTTPD server in a Browser using the EC2 IP address and Domain (only port 80 is working, no HTTPS).
The inbound rules for the security group look OK, i.e. port 80 and port 443.
The health check is checking the server every 30 seconds, and is showing as healthy every time.
The main problem is that when I try to connect to the webserver in a browser using the DNS name for the load balancer, the page times out, and I do not see the request hit the Apache2 server logs. However, I can connect when using the EC2 instance domain name, and I also see the request hitting the Apache2 server logs.
I wondered if I could please ask if anyone else has had the same issue with the load balancer DNS name not resolving to the EC2 instance?
Many thanks,
Martin
EDIT: This was resolved by setting the correct security group.
I have a running Web server on Google Cloud. It's a Debian VM serving a few sites with low-ish traffic, but I don't like Cloudflare. So, Cloud CDN it is.
I created a load balancer with static IP.
I do all the items from the guides I've found. But when it comes time to Add origin to Cloud CDN, no load balancer is available because it's "unhealthy", as seen by rolling over the yellow triangle in the LB status page: "1 backend service is unhealthy".
At this point, the only option is to choose Create a Load Balancer.
I've created several load balancers with different attributes, thinking that might be it, but no luck. They all get the "1 backend service is unhealthy" tag, and thus are unavailable.
---Edit below---
During LB creation, I don't see anywhere that causes the LB to know about the VM, except in cert issue (see below). Nowhere does it ask for any field that would point to the VM.
I created another LB just now, and here are those settings. It finishes, then it's marked unhealthy.
Type
HTTP(S) Load Balancing
Internet facing or internal only?
From Internet to my VMs
(my VM is not listed in backend services, so I create one... is this the problem?)
Create backend service
Backend type: Instanced group
Port numbers: 80,443
Enable Cloud CDN: checked
Health check: create new: https, check /
Simple host and path rule: checked
New Frontend IP and port
Protocol: HTTPS
IP: v4, static reserved and issued
Port: 443
Certificate: Create New: Create Google-managed certificate, mydomain.com and www.mydomain.com
Load balancer's unhealthy state could mean that your LB's healthcheck probe is unable to reach your backend service(Your Debian VM in this case).
If your backend service looks good now, I think there is a problem with your firewall configuration.
Check your firewall rules whether it allows healthcheck probe's IP address range or not.
Refer to the docoment below to get more detailed information.
Required firewall rule
I have created an AWS EC2 instance and running a jenkins container inside it,
Here are the details :
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
xxxxxxxxx docker.io/jenkins/jenkins 47 hours ago Up 47 hours ago 0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp jenkins
after that I have configured an AWS ALB to listen on port 443 and given this jenkins instance running jenkins container as target.
The loadbalancer health check details are as below:
I have tried with traffic port aswell, but that also showd unhealthy.
after this my loadbalancer is able to forward request to the instance and I am able to reach jenkins container with the loadbalancer dns.
But my Loadbalancer is showing my target as unhealthy,
Can some one help me why my target is not healthy and what steps i could do to make it healthy.
Jenkins EC2 should be assigned a security group that allows access on the Jenkins port (8080) from the ALB. and you’ll provide full outbound internet access to Jenkins in order that updates and plugins can be installed.
The Jenkins requires authentication, so when the ALB is doing its health check as an anonymous user it gets a 403 access forbidden page, but http health check expect 200 ok code, so You can switch this to a tcp health check.
Use /login instead of /
Verify the port no also. I am using 8080
I created a Jenkins container on Fargate ECS and it was giving me this error when I tried to configure an ALB to it.
service jenkins-alb (port 8080) is unhealthy in target-group ecs-demo2-jenkins-alb due to (reason Health checks failed with these codes: [403]).
I found the solution that when the ALB healthcheck tries to go to the target group, it is greeted with the jenkins login page and requires authorization which is why the healthcheck fails with error 403. The workaround I used for this was to change the healthcheck path from '/' to '/login?from=%2F' and it worked!
I created a load balancer and assigned it one of the running EC2 instance. After creation, I navigated to Target Group section in the AWS Console under Load Balancing and when I selected the target group that was assigned to the load balancer, it shows registered instance status as "Unhealthy" and there was a message above registered instance pane that says "None of these Availability Zones contains a healthy target. Requests are being routed to all targets". While creating the load balancer, I selected all the subnets (availability zones).
settings I used for health check are mentioned below,
Protocol: HTTP
Path: /healthcheck.html
Port: traffic port
Healthy threshold: 3
Unhealthy threshold: 2
Timeout: 5
Interval: 10
Success codes: 200
So why does my registered instance status as "Unhealthy" and how can I rectify/resolve that to change the status to "In-service"?
Unhealthy indicates that the health check is failing for the instance.
Things to check:
Check that the instance is running a web server
Check that the web page at healthcheck.html responds with a valid 200 response
Check that instance has a security group that permits access on Port 80 (HTTP)
In my case health check configuration on ALB is / with https.
I resolved with below steps.
Check the security groups - whether we have opened the required ports from ALB SG to EC2 SG.
Login to server and check does IIS server's default site has 443 port opened if your health-check is on 443. (whatever port you are using for health checks).
Use the curl command to troubleshoot the issue.
If you would like to check on HTTPS use the below command to check the response. Use -k or --insecure to ignore the SSL issue.
curl https://[serverIP] -k
For HTTP test use the below command.
curl http://[serverIP]
If you are sharing the load balancer among several EC2 instances that run similar services, make sure each of your services run in a different port otherwise your service won't be reachable and therefore your health check won't pass