I have a web app (Node.js on Elastic Beanstalk) already serving at example.com. I have a WordPress blog that I want to serve at example.com/blog.
I want to setup AWS Load Balancer to route requests at /blog to my WordPress server and all other requests at / to my web-app. How do I do it using AWS Load Balancer(s)?
My DNS and both of these servers are on AWS. I don't want to setup a self-managed Nginx/HAProxy reverse proxy. If possible, I want to avoid using CloudFront configuration at the moment.
This is possible by adding a listener rule to an Application Load Balancer. Listener rules determine how the load balancer routes requests to the targets in one or more target groups.
After creating the load balancer, see Listeners >> Add Listener. Add a Rule with a Condition for Path is /blog then select Action forward to send traffic to a separate target group mapped to the Wordpress instances.
For more see the docs for Listener Rules for Your Application Load Balancer.
Related
Some context here:
An old Symfony app is used in multiple EC2 instances. Handles millions of requests each day without issues.
For dev purposes, the app was added to a container and that container is used locally by the developers without having to install all the requirements. The dockerized app uses the same nginx/supervisor/php-fpm configs that productive ec2 instances.
To make easier some dev processes, it was decided to create multiple dev environments using AWS Fargate, instead of EC2 instances.
The image is pushed to ECR and is deployed using FARGATE strategy to clusters.
The approach perhaps is too much, since we have 1 Cluster running 1 service only with 1 task. That Service uses an ELB -> Target group.
The application is working fine, but after some time (hours, or days), some requests are returned with different headers. The response is a JSON, but the content type is returned as HTML, other headers are dropped from the request like access-control-allow-headers, access-control-allow-credentials, access-control-allow-methods, triggering a CORS error in the client's browser.
The weird part is that if 1 page creates 10 requests to this service, 9 will work correctly, but 1 request will return 200 with different headers. That endpoint consistently will behave in the same way to any user until the task is restarted.
The response headers are returned by the Symfony app. I also tried to force those headers including those in nginx config by default for every response, and the result is the same.
The docker image exposes port 80 to the service.
The load balancer has the rule to forward HTTPS (443) traffic to port 80, so traffic can reach the container.
The load balancer has enabled the use of HTTP/2
The only notable difference besides EC2/Fargate implementations is the load balancer. The production load balancer is an old class load balancer with only HTTP/1 enabled and the new ones are Applications load balancers using HTTP/2.
This is driving me crazy. Has anyone experienced something like this?
Incorrect headers
Correct headers
I am working backend server launched on ECS cluster, hosted on an EC2 instance using docker.
the ECS is running great, exposed by IP address and port, but to be used with my ios app it needs to be served over https.
How do serve my ECS container over https? I have read a couple of things regarding using a load balancer, but tutorials are outdated and I can't find one that shows configuration after the ecs cluster has already been created.
Please point me to the right direction so I can get it served over https.
You need to have the following resources:
DNS address
Valid SSL Certificate
Load Balancer
Load balancer security group
Target Group
The target group will mediate between your server and your load balancer.
Also, in the security group define all the rules you currently have in the server security group, and in the server's security group ad a rule that open is open to all traffic in all ports with the security group instead of id.
This guide can help you:https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html
(look at Create an HTTPS/SSL load balancer using the console)
I have a project that has routes and paths defined in a load balancer. Now I want to add a google cloud run container to that project. Do I need to make another load balancer, or can I add the paths to the current load balancer?
how would I add a path to the cloud run container path? (for either scenario)
like mydomain.com/"new-path/container"/"path-of-new-path"
like in load balancer paths:
/newPath/newPath/*
or /newPath
and then the container (express.js in my case) dicates the newPath -paths?
confused. Also now to add confusion to the matter. can i have two ports?
like:
mydomain.com:443/newPath:8080
There is many possible configuration. You can route the traffic on
The domain
The path prefix
A combination of both.
With Serverless NEG, you also have in addition an URL mask that you can use to route the traffic through different serverless services
If your service doesn't support the load balancer path, you can also use a rewrite rule to remove that additional path level and clean the API call to your service
Finally, about the port, it's independent: the frontend ports doesn't influence the path resolution for request routing. But the domain does.
Okay, I have a DB consisting of several nodes deployed to GKE.
The deployment.yaml adds each node as ClusterIP, which makes sense. Here is the complete deployment file:
https://github.com/dgraph-io/dgraph/blob/master/contrib/config/kubernetes/dgraph-ha/dgraph-ha.yaml
For whatever reason, the DB has zero security functionality, so I cannot expose any part using a LoadBalancer service because doing so would give unsecured access to the entire DB. The vendor argues that security is solely the user's problem. The AlphaNode comes with an API endpoint, which is also unsecured, but I actually want to connect to that API endpoint from an external IP.
So, the best I can do is adding an NGNIX as a (reverse) proxy with authentication to secure access to the API endpoint of the Alpha node(s). Practically, I have three alpha nodes so adding load balancing makes sense. I found a config that does load balancing to three alpha nodes in Docker Compose although, without authenication.:
https://gist.github.com/MichelDiz/42954e321620159c872c35c20e9d85c6
Now, the million-dollar question I have is, how do I add an NGNIX load balance to Kubernetes that authenticates and load balances incoming traffic to my (ClusterIP) alpha nodes?
Any pointers?
Any help?
If you want to do it that hard way, you can deploy your own nginx deployment and expose it as LoadBalancer Service. You can configure it with different authentication mechanisms that nginx support.
Instead, you can use Ingress resource backed by an IngressController that supports authentication. Check if your kubernetes distribution provides an IngressController and if it is supports auth. If not, you can install nginx or Traefik IngressControllers which supports authentication.
Looks like GKE ingress has recently added support for IAP bassed authentication which is still in beta - https://cloud.google.com/iap/docs/enabling-kubernetes-howto
If you are looking for more traditional type of authentication with ingress, install nginx or traefik and use the kubernetes.io/ingress.class annotation so that only IngressController claims your ingress resource - https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/
I have a Ruby on Rails App hosted on AWS using Elastic-beanstalk which works with HTTP 1 now I want to use HTTP 2. Can someone suggest me the best approach
If I remember correctly when you add a new load balancer to your Elastic Beanstalk environment, it defaults to using a Classic Load Balancer, which doesn't support HTTP/2, I think the solution would be using an Application Load Balancer that does support it, you can find this info here. You can also specify it while creating your environment as you can see here. This will only allow HTTP/2 communication between the client and the ALB, your ALB will convert those HTTP/2 requests into HTTP/1.1 to communicate with your instance.
As seen here: "If end-to-end HTTP/2 is a requirement for your application you can use a Layer 4 ELB ( Classic Load Balancer with TCP listener or Network Load Balancer). If you are interested also in SSL offloading the only option for now is Classic Load Balancer with an SSL listener."